Extend business processes do not support delegation

You cannot delegate a business process that you built in a Workday Extend app. Workday states it directly in Reference: Design Considerations for Business Processes, and the comparison table in Workday-Delivered vs. Workday Extend Business Processes lists Delegation as Yes for delivered processes and No for Extend ones.

In practice that means none of the delegation tools a Workday admin normally reaches for will move an Extend step:

  • A manager's own delegation from My Tasks > Manage Delegations, or one an administrator sets up through the Manage Delegation Settings report and Request Delegation Change.
  • Single task delegation with Delegate Task.
  • Delegating the initiating action ("Start On My Behalf").
  • The Put Business Process Delegation web service.

So a manager who goes on leave with a delegation in place should expect their delivered approvals to go to the delegate while the Equipment Request approvals from your Extend app keep routing to them. That gap is the thing to design for.

Delegation and reassignment are different, and only reassignment works

Workday's admin guide draws the line clearly: delegation is temporary and leaves ownership with the original person, while reassignment permanently moves responsibility for the task to someone else (Concept: Business Process Task Delegation). Extend business processes support the Reassign Task action, along with Approve, Deny, Rescind, Cancel and Ad hoc Approve. So the supported way to get an Extend step done while its assignee is away is to reassign it.

There are two routes, both described in Reassign Tasks:

  1. The assignee requests it. In My Tasks, the assignee opens the Task Actions icon, chooses Reassign and picks the proposed person. The request goes for approval to members of the groups on the process's Reassign Tasks permission and to groups with Modify on the Business Process Administration domain. Who can request it is controlled by the Request Reassignment permission on the business process security policy.
  2. An administrator does it. The Reassign Tasks task moves the step without further approval. It is secured by the Business Process Administration domain in the System functional area, or per process by the Reassign Tasks permission on that process's policy.

Workday describes both routes as permanently moving responsibility for the task to the new person, so the step does not return to the original assignee when they are back. Reassignment also cannot target someone without an active Workday account, such as a candidate.

Set up the policy so reassignment is possible for the app

An Extend business process has a business process security policy like a delivered one. You attach a security domain to the process in App Builder, then configure the policy for the app in App Manager in the tenant (Extend Business Process Event REST API, Security Considerations). While you are adding the groups that approve and act on the steps, also decide:

  • Which groups may approve reassignment requests and run Reassign Tasks for this process (the Reassign Tasks permission).
  • Whether assignees may request reassignment themselves (Request Reassignment). The default offers All Users; clearing it stops anyone requesting reassignment on that process.

A quick test after saving the policy: sign in as a member of the group you granted, open an Extend task that is awaiting someone else and confirm Reassign is offered.

Route to roles, not to named people

Most delegation requests start with a step that routes to one person. The more durable fix is to make the step route to whoever holds a role, so that cover is handled by role assignment rather than by delegation:

  • Route approval steps to a role-based group such as Manager or a custom role on the supervisory organization. When someone covers the team, assign them the role and new events route to them.
  • Advanced Routing is a supported step option for Extend steps, so a step is not limited to the standard routing.
  • If the routing depends on the record, put a SINGLE_INSTANCE field with "secureByTarget": true on the target business object. Workday documents this as the way to route an Extend process to constrained security groups (Design Considerations).

These role-based routes are a recommended design, not something the Extend documentation prescribes. Keep in mind that an Extend business process has only one default definition and rule-based definitions are not supported, so you cannot send one country's requests through a different definition with a different approver (Workday-Delivered vs. Workday Extend Business Processes).

Find what is stuck while someone is away

Before or during an absence, list the Extend steps awaiting the absent person and reassign them in one pass. The Business Process Transactions Awaiting Me report lists the steps awaiting a person's action, including steps excluded from My Tasks (Reassign Tasks). The person who is away can run it for themselves. For everyone else, finding who a business process is awaiting covers the administrator view, and Workday lists a report data source as supported for Extend business processes. In the Extend event API, GET /events/{ID}/inProgressSteps returns each in-progress step with its awaitingPersons.

Reassigning in bulk or from an orchestration

Workday notes that because Extend business processes do not support delegation directly, reassigning steps programmatically may need a SOAP API called from an orchestration (Extend Business Process Event REST API). The docs name no specific operation, so confirm the operation in the Human Resources or Integrations SOAP reference before building on it. Prove it on one event first and check the result in the event's process history before running it for a team; the Extend event API itself does not support bulk operations.

How to prove the cover works

Test the actual absence, not the configuration screen:

  1. Initiate an Extend event as a test initiator and confirm in the event's process history which person the approval step is awaiting.
  2. Reassign that step (by request and by the Reassign Tasks task, if you allow both) and confirm the new person sees it in My Tasks and can open the approval page with its data.
  3. Approve it as the new person and confirm the event moves on and the business object shows the approved state.
  4. For role-based routing, change the role holder in a sandbox, initiate a new event and confirm it routes to the new holder. Check what happened to an event that was already awaiting the old holder, so you know whether in-flight steps still need reassigning.

If the reassigned person cannot open the task or its data, the cause is security rather than routing; see domain versus business process security policies.

Sources checked