Triggering a model business process in a Workday Extend app is a two-step API sequence: first,
create or select an instance of the target Custom Business Object
(POST /apps/{appId}/v1/{collection}), and second, pass that record's Workday ID inside
businessProcessTarget.id to the generated Extend Business Process Event REST API
(POST /apps/{appId}/v1/{businessProcessName}Events). To read the approval status, current
assignees, or completed steps back into your app, call the Workday Business Process REST service
(GET /businessProcess/v1/events/{eventId} and
GET /businessProcess/v1/events/{eventId}/inProgressSteps).
Whether you are initiating an Extend model business process, triggering a Workday-delivered business process via Graph API or REST, or pausing an asynchronous orchestration until an approval completes, the endpoints, payload schemas, and inbox routing rules follow strict contracts.
Four ways an Extend app interacts with Workday business processes
| Scenario | How It Is Triggered | Target Object & Payload | How Status or Completion Is Tracked |
|---|---|---|---|
| Scenario1. Extend Model Business Process | How It Is TriggeredPOST /apps/{appId}/v1/{businessProcessName}Events | Target Object & PayloadRequires an existing Extend Custom Business Object WID in businessProcessTarget.id plus optional description | How Status or Completion Is TrackedGET /businessProcess/v1/events/{eventId} or automatic inbox routing (queryParams.eventId) |
| Scenario2. Workday-Delivered Business Process | How It Is TriggeredDomain REST endpoint (such as POST /workers/{id}/requestTimeOff), Graph API mutation, or SOAP API in Orchestrate | Target Object & PayloadWorkday-delivered business object fields defined by that service's schema | How Status or Completion Is TrackedGET /businessProcess/v1/events?worker={id} or GET /businessProcess/v1/events/{eventId} |
| Scenario3. Extend Subprocess inside a Workday BP | How It Is TriggeredParent Workday BP reaches the subprocess step; initiation page calls PATCH /apps/{appId}/v1/{businessProcessName}Events/{eventId} | Target Object & PayloadAssociates the subprocess eventId with a target Extend Custom Business Object WID, then calls POST /eventSteps/{id}/submit | How Status or Completion Is TrackedSaved inside the parent Workday-delivered business process event history |
| Scenario4. Business Process ↔ Orchestrate | How It Is TriggeredService step (Orchestration Service) on BP definition, or Configure Orchestrations on status change (Cancel, Rescind, Correct, Deny) | Target Object & PayloadKey/value parameters configured on the orchestration's Business Process Trigger step | How Status or Completion Is TrackedFind Events > Orchestrations tab; optional Advance business process step when orchestration completes |
Step-by-step: Initiating an Extend model business process
Every Extend business process (limit: 5 per app) must be associated with a targetBusinessObject
in its .businessprocess model file and secured by an app security domain configured in App
Manager.
Because the Extend Business Process Event API does not accept arbitrary business object fields
in its request body (it accepts only businessProcessTarget and description, up to 500
characters), your PMD edit page or orchestration must create the Custom Business Object record first
and chain its returned id into the event creation call.
1. Create the target Custom Business Object instance
On your PMD initiation page (or in an orchestration), define the first outbound endpoint to POST
the user's form inputs to the Custom Business Object API:
POST https://api.workday.com/apps/tuitionApp_abcdef/v1/tuitionRequests
Workday returns the newly created business object instance, including its 32-character Workday ID
(id).
2. Initiate the Business Process Event
Define a second outbound endpoint in outboundEndPoints[] after the business object endpoint.
Workday invokes PMD endpoints sequentially in the order they appear in the PMD file, so the second
endpoint can reference <% createTuitionRequest.id %> directly:
{
"outboundData": {
"outboundEndPoints": [
{
"name": "createTuitionRequest",
"baseUrlType": "app",
"url": "tuitionRequests",
"httpMethod": "POST",
"authType": "sso"
},
{
"name": "initiateTuitionBP",
"baseUrlType": "app",
"url": "tuitionReimbursementApprovalEvents",
"httpMethod": "POST",
"authType": "sso",
"values": [
{
"outboundPath": "businessProcessTarget.id",
"value": "<% createTuitionRequest.id %>"
},
{
"outboundPath": "description",
"value": "<% 'Tuition reimbursement for ' + worker.descriptor %>"
}
]
}
]
}
}
Notice the URL naming convention: Workday appends Events to the name of your .businessprocess
component (TuitionReimbursementApproval becomes tuitionReimbursementApprovalEvents). The
response returns the new business process event id, descriptor, and businessProcessTarget.
Configuring inbox page routes and advancing steps
When an Extend business process routes steps to a user's Workday Inbox (My Tasks), your
.businessprocess model definition maps each step type to a PMD pageRoute that matches a
routingPattern in your App Metadata (.amd) tasks[] array:
{
"id": 1,
"name": "TuitionReimbursementApproval",
"label": "Tuition Reimbursement Approval",
"targetBusinessObject": "TuitionReimbursementRequest",
"allowsCancel": true,
"useForOrchestrate": true,
"approvalStep": {
"actions": ["APPROVE", "DENY", "SEND_BACK"],
"pageRoute": "/approve/{eventId}"
},
"details": {
"pageRoute": "/details/{eventId}"
},
"actionSteps": [
{
"id": 1,
"name": "ReviewRequest",
"label": "Review Reimbursement Request",
"pageRoute": "/actionStep/{eventStepId}"
}
],
"revisePageRoute": "/revise/{eventStepId}"
}
How {eventId} and {eventStepId} work on routed PMD pages
| Step / Page Type | Route Parameter Passed to PMD | Required PMD Page Type | How the Step Advances |
|---|---|---|---|
Step / Page TypeApproval step (approvalStep) | Route Parameter Passed to PMDqueryParams.eventId | Required PMD Page TypeView page (recommended) | How the Step AdvancesWorkday automatically renders Approve, Deny, and Send Back buttons and advances the workflow. If you use an edit page, Workday replaces the Submit button and ignores all outboundEndPoints. |
Step / Page TypeDetails page (details) | Route Parameter Passed to PMDqueryParams.eventId | Required PMD Page TypeView page | How the Step AdvancesRead-only view rendered whenever a user views the event in Workday. |
Step / Page TypeAction step (actionSteps[]) | Route Parameter Passed to PMDqueryParams.eventStepId | Required PMD Page TypeEdit page | How the Step AdvancesMust call POST /businessProcess/v1/eventSteps/{eventStepId}/submit in outboundEndPoints. |
Step / Page TypeRevision page (revisePageRoute) | Route Parameter Passed to PMDqueryParams.eventStepId | Required PMD Page TypeEdit page (required if SEND_BACK is enabled) | How the Step AdvancesMust call POST /businessProcess/v1/eventSteps/{eventStepId}/submit in outboundEndPoints. |
Advancing an Action or Revision step via /eventSteps/{id}/submit
To advance an Action step or a sent-back Revision step from its PMD edit page, add a data provider
for https://api.workday.com/businessProcess/v1/ in your .amd and call
POST /eventSteps/{id}/submit with the required stepAction.id WID:
{
"name": "submitActionStep",
"baseUrlType": "workday-bp",
"url": "<% '/eventSteps/' + queryParams.eventStepId + '/submit' %>",
"httpMethod": "POST",
"authType": "sso",
"values": [
{
"outboundPath": "stepAction.id",
"value": "d9e4223e446c11de98360015c5e6daf6"
}
]
}
Workday accepts two fixed WIDs for stepAction.id:
d9e4223e446c11de98360015c5e6daf6: Submitted (used on both Action steps and Revision pages)d9e41a8c446c11de98360015c5e6daf6: Saved for Later (supported on Action steps only)
(Note: POST /eventSteps/{id}/submit is a built-in Business Process service endpoint, even though
it is not listed in the public REST API Explorer.)
Reading business process status and assignees back into your app
To display real-time approval status, initiator details, awaiting approvers, or comments inside an
Extend page or orchestration, call the businessProcess/v1 REST endpoints through the API Gateway.
Users calling these endpoints require permissions on the Core Navigation and Public Business
Processes (Tenant Non-Configurable) security domains, plus view permissions on the business
process security policy.
1. Reading status when you have the eventId
Call GET https://api.workday.com/businessProcess/v1/events/{eventId}:
{
"id": "49367bfa904f9001addc140bf5f50000",
"descriptor": "Tuition Reimbursement Approval: Request 104",
"for": {
"id": "49367bfa904f9001add1a9fbe1530000",
"descriptor": "Request 104"
},
"status": {
"id": "e2d08afc53614c37b32b31270bb8bee3",
"descriptor": "In Progress"
},
"initiator": {
"id": "3aa5550b7fe348b98d7b5741afc65534",
"descriptor": "Logan McNeil"
},
"creationDate": "2026-11-04"
}
Note that for.id returns the Workday ID of the underlying Custom Business Object
(businessProcessTarget), which your approval or details page (queryParams.eventId) can pass to a
second inbound endpoint (GET /apps/{appId}/v1/{collection}/<% bpEvent.for.id %>) to load all
custom fields of the record.
2. Reading status from an Action step page where you only have eventStepId
On an Action step or Revision PMD page, Workday passes queryParams.eventStepId rather than
eventId. Chain two inbound endpoints in endPoints[]:
stepInfo:GET /businessProcess/v1/eventSteps/<% queryParams.eventStepId %>— returnsevent.id.eventInfo:GET /businessProcess/v1/events/<% stepInfo.event.id %>— returnsstatus.descriptorandfor.id(the target Custom Business Object ID).
3. Inspecting awaiting approvers, completed steps, or worker event lists
| Endpoint | What It Returns | Key Query Parameters / Notes |
|---|---|---|
EndpointGET /events/{id}/inProgressSteps | What It ReturnsActive steps awaiting action, including status.descriptor (Awaiting Action), awaitingPersons[], and step id | Key Query Parameters / NotesEquivalent to View Event > Process Tab (In-Progress Steps) |
EndpointGET /events/{id}/completedSteps | What It ReturnsCompleted approval and action steps | Key Query Parameters / NotesEquivalent to View Event > Process Tab (Completed Steps) |
EndpointGET /events/{id}/remainingSteps | What It ReturnsFuture steps in the workflow definition | Key Query Parameters / NotesEquivalent to View Event > Process Tab (Remaining Steps) |
EndpointGET /events/{id}/comments | What It ReturnsEvent comment history | Key Query Parameters / NotesEquivalent to the Comments column on the Process tab |
EndpointGET /events?worker={wid} or GET /events?initiator={wid} | What It ReturnsList of events for a target worker or initiator | Key Query Parameters / NotesRequires either worker or initiator; optionally filter by businessProcess={bpTypeWid} and initiatedOnOrAfter=YYYY-MM-DD |
Connecting Business Processes and Orchestrate
- Pausing an asynchronous orchestration on an Extend BP (
useForOrchestrate: true): Set"useForOrchestrate": true(Enable for Orchestrate) in your.businessprocessfile when an orchestration initiates the Extend business process via Send API Request and needs to pause while human approvals run, resuming only when an Orchestration Service step on the business process definition signals completion. - Triggering an orchestration from a business process step: Create an orchestration using the Workday Business Process starting point, configure its expected input keys on the Business Process Trigger step, deploy the app, and add a Service step (Orchestration Service) to the business process definition in your tenant. Check Advance business process step when orchestration completes if the workflow must wait for the orchestration to finish.
- Launching an orchestration on Cancel, Rescind, Correct, or Deny: After deploying a Workday Business Process orchestration (which must use ISU authentication if it makes API calls), set User to Perform Orchestration Launches in Edit Tenant Setup - Business Processes, then open Business Process > Configure Orchestrations on the business process and create an Orchestration Launch Configuration (Workday does not create launch configurations automatically on deployment). Remember that a Rescind action on an Extend business process only marks the event as rescinded—it does not automatically roll back Custom Business Object data unless your rescinding orchestration explicitly reverses those writes.
How kiweely fits
kiweely builds your Custom Business Objects, .businessprocess definitions, inbox PMD pages, and
status-tracking endpoints against your live tenant—verifying that step actions, security policies,
and page routes work end to end. In your Workday personal developer account and its tenant, Kiweely
Personal is free (Kiweely Personal is free for your Workday personal developer account and its tenant. Any other tenant needs a Personal licence, $99 a month, or a seat in your firm.).
Frequently asked questions
Why did my outbound endpoint on an Approval page never run when the approver clicked Approve?
On a PMD page mapped to approvalStep.pageRoute, Workday's business process framework replaces the
standard page Submit button with the configured approval action buttons (Approve, Deny,
Send Back) and does not invoke any outboundEndPoints defined on that PMD. Workday
recommends using a view page for approvalStep.pageRoute. If an approver needs to enter data and
trigger an outbound endpoint during the workflow, use an Action step (actionSteps[]) instead,
or trigger an orchestration from the business process definition after the approval step completes.
Can I pass custom fields directly into POST /{businessProcessName}Events or run it with ?bulk=true?
No to both. The Extend Business Process Event REST API does not support ?bulk=true (each event
must be initiated individually), and its POST body only accepts businessProcessTarget.id and
description. Store all custom payload fields on the target Custom Business Object first, then
retrieve them on your approval or action PMD pages using for.id from GET /events/{eventId}.
Why can't I select my newly deployed orchestration in the Configure Orchestrations task?
Deploying an app to your tenant does not automatically create an Orchestration Launch Configuration. When pairing a Cancel, Rescind, Correct, or Deny status change in Business Process > Configure Orchestrations, select Create Orchestration Launch Configuration in the Orchestration prompt first, map your input parameters, and then select that new configuration.
Sources checked
- Workday Extend Developer Guide: Extend Business Process Event REST API
- Workday Extend Developer Guide: Reference, Business Process Event API Requests
- Workday Extend Developer Guide: Concept, Business Process Steps and Page Routes
- Workday Extend Developer Guide: Events REST APIs
- Workday Extend Developer Guide: Event Steps REST APIs
- Workday Extend Developer Guide: Trigger an Orchestration from a Business Process
- Workday Extend Developer Guide: Launch Orchestrations on Business Process Status Changes