The revise page is the detection

In an Extend business process you don't need logic to notice a send-back. When the approver clicks Send Back, Workday's business process framework creates a revision step and routes it to the page named in the business process's revisePageRoute, passing that step's ID in queryParams.eventStepId. Whatever loads on that page is, by definition, handling a send-back. Its job is to show why the request came back, let the initiator fix the record, and submit the step so the request returns to the approver.

That gives the page four jobs, in order: find the event and its target record, show the reviewer's comment, save the corrected record, and submit the revision step.

Turn Send Back on and give it a page

Send Back is one of the approval step's allowed actions. In Visual mode, the Actions tab enables APPROVE, DENY and SEND BACK by default. In Code mode, list it in approvalStep.actions, and add revisePageRoute, which Workday requires whenever SEND_BACK is allowed:

"approvalStep": {
  "actions": ["APPROVE", "DENY", "SEND_BACK"],
  "pageRoute": "/approve/{eventId}"
},
"revisePageRoute": "/revise/{eventStepId}"

The route must match a task in the AMD, for example { "id": "eaRevise", "routingPattern": "/revise/{eventStepId}", "page": { "id": "eaRevise" } }. Use {eventStepId}, not {eventId}: the framework sets the revise page's context to the step.

Separately, Enable Manual Send Back (allowsManualSendBack) lets an administrator send the process back at any point, even when it isn't assigned to them. That needs a security group with the Manual Send Back action in the "Who Can Do Actions on Entire Business Process" section of the policy.

Find the event and the record from the step

The revise page receives a step ID, while the comments and the target record hang off the event. Workday's Tuition Reimbursement sample chains three inbound endpoints to get there:

"endPoints": [
  {
    "name": "bpEventStep",
    "baseUrlType": "WORKDAY-BP",
    "url": "<% '/eventSteps/' + queryParams.eventStepId %>",
    "authType": "sso"
  },
  {
    "name": "eventInfo",
    "baseUrlType": "WORKDAY-BP",
    "url": "<% '/events/' + bpEventStep.event.id %>",
    "authType": "sso"
  },
  {
    "name": "requestData",
    "baseUrlType": "app",
    "url": "<% 'equipmentRequests/' + eventInfo['for'].id %>",
    "authType": "sso"
  }
]

WORKDAY-BP is an AMD data provider for https://api.workday.com/businessProcess/v1/. The event's for field is the business process target, the record the request is about. Write it as eventInfo['for'].id: for is a reserved word in PMD Scripting, and Workday's syntax reference uses exactly this case to show bracket notation. The step endpoint returns a 404 if the user can't view the event, so a revise page that loads blank for one user but not another points first at the business process security policy, which decides who can view the event.

Show the reviewer's comment

The approver's reason travels as a business process comment. Read it with the event's comments endpoint, which returns rows with person, comment and commentDate:

{
  "name": "eventComments",
  "baseUrlType": "WORKDAY-BP",
  "url": "<% '/events/' + bpEventStep.event.id + '/comments' %>",
  "authType": "sso"
}

Two ways to put it on the page. The plain one is a read-only text or grid bound to eventComments.data, with the newest comment first. The Workday-styled one is a bpExtender whose commentHistory is a bpTemplatedList on that same data, mapping person.descriptor, comment and commentDate; set displayTimeZone on the date, because these REST dates are UTC. The bpExtender guide covers that container and its button wiring.

The event step itself also returns comments, status and completedDate, and GET /events/{id}/completedSteps lists the finished steps with who completed them. Use that list if the page should name the approver who sent it back.

Save the record, then submit the step

Workday's framework doesn't edit the business object for you. The revise page must update the record and then call the step-submit endpoint; the sample does both as outbound endpoints in this order:

"outboundEndPoints": [
  {
    "name": "saveRequest",
    "baseUrlType": "app",
    "url": "<% 'equipmentRequests/' + eventInfo['for'].id %>",
    "httpMethod": "PATCH",
    "authType": "sso",
    "values": [
      { "outboundPath": "quantity", "value": "<% quantity.value %>" }
    ]
  },
  {
    "name": "resubmit",
    "baseUrlType": "WORKDAY-BP",
    "url": "<% '/eventSteps/' + queryParams.eventStepId + '/submit' %>",
    "httpMethod": "POST",
    "authType": "sso",
    "values": [
      { "outboundPath": "stepAction.id", "value": "d9e4223e446c11de98360015c5e6daf6" }
    ]
  }
]

d9e4223e446c11de98360015c5e6daf6 is the documented Submitted state for action steps and revisions. The Saved for Later value applies to action steps only, so a revise page has one real outcome: submit. Outbound endpoints run in the order they appear, so the PATCH above the submit means the approver sees corrected data.

The submit endpoint has conditions: it works only on Extend business processes, only through the Extend API Gateway, and only for the person awaiting action on the step. Anyone else who opens the revise item can view it but can't submit it. The page shows an OK button by default; use editButtonBar if you want it labelled Submit.

Things Workday doesn't do on a send-back

  • It doesn't lock or snapshot the record. If the initiator changes a field, the event history displays the new value, and the business object's audit trail holds the change.
  • It doesn't support delegation for Extend business processes, so a revise item can't be delegated while the initiator is away. Workday notes that reassigning steps may need the SOAP API through an orchestration; the delegation guide covers the options.
  • It offers no Correct action for Extend business processes. If an approved record must change, use an action step after approval or an orchestration, as Workday's design considerations suggest.

Prove the round trip

  1. Start an event as the initiator, then as the approver send it back with a reason.
  2. Sign in as the initiator, open the revise item from My Tasks, and confirm the comment shows and the fields are pre-filled from the record.
  3. Change a field and submit. Read the record back with GET equipmentRequests/{id} and confirm the new value.
  4. Call GET /events/{eventId}/inProgressSteps and confirm the approval step is again "Awaiting Action" with the approver in awaitingPersons. If the revise item is still in the initiator's inbox, the submit call didn't run; check the application logs for that request and any exclude condition on it.

Sources checked