How to put documents from a Workday Extend business process on the worker's profile

Uploaded files do not become Worker Documents on their own

A file a worker uploads on an Extend page is stored on your app's attachment object (Concept: Attachment Objects). Nothing in Workday's documentation links that object to the worker's documents, so it does not show in the Maintain Worker Documents report. To put a reviewed file there, create the Worker Document explicitly once the review is done, with the Staffing web service operation Put_Worker_Document, called from an orchestration that the business process runs after approval.

Why the Review Documents step is not the answer here

Extend business processes do support the Review Documents step type (Workday-Delivered vs. Workday Extend Business Processes), and it is tempting to use it. Workday's description of that step is specific about where uploaded files end up: documents workers upload are available in the Worker Document File only when the worker has signed them electronically and the distributing business process is worker-related, with examples such as Hire, Onboarding and Request Leave of Absence (Concept: Review Documents Step). An Extend business process targets your own business object, such as an Equipment Request or a Certification Claim, not a worker event, and the documentation does not describe Extend processes as worker-related for this purpose, so do not count on it.

Review Documents is also built for distributing a document to someone to acknowledge or sign. The usual Extend requirement is the opposite direction: an employee supplies evidence, an HR partner checks it, and the approved file should be kept against the employee. Uploading the file in your Extend page and filing it after approval models that directly.

The pattern: upload, review, approve, then file

1. Upload. On the initiation page, a fileUploader posts the file to an attachment object with a SINGLE_INSTANCE field back to the request, as described in attachment objects: POST, multipart and updates. The request business object should hold the worker the document belongs to in a SINGLE_INSTANCE field targeting WORKER.
2. Review. The Approval or Action step page shows the file with an attachmentList, so the reviewer reads the actual document before approving.
3. File. After the approval step, a Service step with Orchestration Service runs an orchestration that creates the Worker Document. Extend business processes support the Service step type, and Trigger an Orchestration from a Business Process documents the setup: build the orchestration from the Workday Business Process starting point, deploy the app, then in the tenant add the Service step, choose Configure Orchestration Service, select the orchestration, pick the user it runs as and map the keys it expects (at minimum the request's id).

Select Advance business process step when orchestration completes if the event should only complete once the document is filed. Without it, the business process moves on without waiting for the orchestration.

Filing after approval, rather than at upload, keeps rejected documents off the profile; this is a recommended design, not a Workday requirement.

The orchestration: read the file, call Put_Worker_Document

You cannot call SOAP from a PMD; Workday says to launch an orchestration for that (Call Workday SOAP APIs Using the API Gateway). The orchestration needs four values, all of which it can read from the request and its attachment:

• The worker. From the request's worker field.
• The file content. A GET on the attachment instance returns the file itself; the attachment object stores it as base64 (Concept: Attachment Objects). If the step gives you raw data, the Orchestrate data member function base64encode returns the base64 form that the SOAP File element expects (Reference: Data Member Functions). The details of moving binary content through a flow are in base64 attachments in Orchestrate.
• The file name and content type. A second GET on the same instance with Accept: application/json returns fileName and contentType instead of the bytes.
• The document category. A fixed category ID you created for this purpose (next section).

The request body, built in a text template and posted to https://api.workday.com/soap/{version}/Staffing with Content-Type: text/xml:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:bsvc="urn:com.workday/bsvc">
  <soapenv:Body>
    <bsvc:Put_Worker_Document_Request bsvc:Add_Only="true" bsvc:version="{version}">
      <bsvc:Worker_Document_Data>
        <bsvc:Filename>{fileName}</bsvc:Filename>
        <bsvc:Comment>Approved on Equipment Request {requestId}</bsvc:Comment>
        <bsvc:File>{base64Content}</bsvc:File>
        <bsvc:Document_Category_Reference>
          <bsvc:ID bsvc:type="Document_Category_ID">{categoryId}</bsvc:ID>
        </bsvc:Document_Category_Reference>
        <bsvc:Worker_Reference>
          <bsvc:ID bsvc:type="WID">{workerWid}</bsvc:ID>
        </bsvc:Worker_Reference>
        <bsvc:Content_Type>{contentType}</bsvc:Content_Type>
      </bsvc:Worker_Document_Data>
    </bsvc:Put_Worker_Document_Request>
  </soapenv:Body>
</soapenv:Envelope>

In the Staffing schema, Filename, Document_Category_Reference and Worker_Reference are required, Filename is limited to 255 characters and Content_Type to 80. Workday describes the operation as adding documents that are not associated with events and are not secured by events. That matters: the document you create is secured by its category and the worker document domains, not by your app's domain or the business process.

Add_Only="true" marks the call as add-only rather than an update, which is what a filing step should be. The request also carries the validation "Worker Document, '[document]', already exists." The response returns a Worker_Document_Reference; write it back to a field on the request so a rerun can tell the document was already filed and skip the call.

Set up the category and security first

Create a category with Maintain Document Categories (secured by Set Up: Tenant Setup - Document Categories). Give it an ID you will not need to change, since the ID cannot be edited after saving and is what the orchestration references (Set Up Document Categories). An inactive category is rejected with the schema's validation "The category "[cat]" is inactive and cannot be used."

If the documents are sensitive, restrict the category with Create Document Category Security Segment so access to that type of document can be limited (Maintain Worker Documents). Set it up before the first filing.

Workday secures adding worker documents with the Worker Data: Add Worker Documents domain in the Personal Data functional area, and the SOAP reference marks Put_Worker_Document as using contextual security without naming a domain. So give the account the orchestration runs as that domain and check it by running the call. The Service step defaults to running as the user of the previous step; you can pick a different named user or a user derived from a field (Trigger an Orchestration from a Business Process). With the default, the approver's own permissions decide whether filing works; a dedicated named user is more predictable.

How to prove it worked

Run one event end to end in a sandbox and check four things:

1. The event. The Service step completes, and with "advance when orchestration completes" selected, the event completes only after it. If it fails, read the orchestration run in the app's logs for the SOAP fault.
2. The worker's documents. Open Maintain Worker Documents for the worker. The file is there, in the right category, with the expected file name and the comment you set. Open it and confirm the content is the original document, not an empty or doubly encoded file.
3. Who can see it. As a user in the category's segment, the document is visible; as a user outside it, it is not.
4. No duplicates. Rerun the orchestration for the same request. With your filed-reference check in place, no second document appears.

Documents created this way are not tied to any event, so you can't correct them by correcting the Extend event. Remove a wrongly filed document through Maintain Worker Documents, which is secured by Worker Data: Edit and Delete Worker Documents.