Workday business process stuck Awaiting Action: how to fix it

Start with the Full Process Record, not a guess

Before you touch anything, find out exactly which step the event is on and who Workday is waiting for. Open the event and from its related actions menu select Business Process > Full Process Record. That view lists every step the business process has gone through, the person or security group each step is or was assigned to, and any comments — it is the closest thing Workday has to a case file for a single stuck instance.

If the record shows a step with no completed action and no visible assignee, that is your answer already: the step is unassigned, not merely slow. If it shows a real person's name with no action, the problem is usually that the person never saw it — check whether they have an active account, whether they delegated their tasks, or whether a security change removed their access after the item landed in their My Tasks (covered below). Don't assume the step is broken just because it's old; some steps genuinely wait on a person for days by design.

The step's role has nobody in it

A step usually routes to a role-based security group — HR Partner, Manager, Recruiter — scoped to the organization the event belongs to. If nobody currently holds that role for that organization, Workday does not silently escalate the step to a manager's manager or a superior organization's role holder. The task action Workday shows instead is literally called Reassign: "There isn't a worker to perform the current step because the role required by the business process definition is unfilled." The event sits there until an administrator either assigns a worker to the missing role or reassigns that specific step directly to a person.

This is a different failure than a task nobody happened to open. Workday calls it an unassigned task, and the underlying cause is broader than an empty role: the security group behind the step doesn't contain a user at all, or every member of it has a disabled, expired, or locked account, or a future hire date. The fix is the same either way — populate the security group (assign the missing role from the organization's related actions under Roles > Assign Roles, or add a member directly to a user-based group), then reassign the specific stuck task so the instance picks it up. Adding the person to the group on its own doesn't restart the instance.

The security policy changed after the task was already assigned

A step can be correctly assigned and still go dead if someone edits the business process security policy while the task is sitting in a worker's My Tasks. The task doesn't disappear and it doesn't reassign itself — it stays exactly where it was, but the person who owns it may no longer have the access the step requires to open or complete it. From the person's side this looks identical to a task that was never delivered.

This is a mismatch between two different things: the security group named on the step in the business process definition (the Group column on an Approval or Action step), and the permissions currently granted on the business process security policy for actions like Approve, Deny, Cancel, or Reassign Tasks. If a security edit removes a group's permission for the action a step needs, or the change is sitting unactivated, the step can no longer be completed by anyone in that group. Run Activate Pending Security Policy Changes to confirm there isn't an edit waiting to take effect, and reassign the specific task to someone whose access is current rather than waiting for the original assignee to somehow regain it.

Delegation moved it, or nobody can see it in their inbox

Delegation and reassignment are not the same fix. Delegating My Tasks lets someone else act on a task without taking ownership of it — the delegator is still the task's owner, and it can be delegated for a defined period or configured on an ad hoc basis. Reassignment permanently moves the task to a different owner. If a step looks stuck because "the right person" can't see it, check whether they delegated their tasks to someone else (My Tasks > Manage Delegations) before assuming the routing itself is broken.

Delegation depends on the business process allowing it: the Allow Business Process Delegation setting has to be enabled on that business process's security policy, and routing restrictions can exclude a delegate or alternate delegate from a step the same way they can exclude the original assignee. When both the delegate and the alternate delegate are excluded by a routing restriction, the task isn't delegated at all — the Reassign Tasks task has a specific Reassign Non-Delegated Tasks option for exactly this case, separate from a plain unassigned task.

It's actually waiting on a sub-process or a To Do, not the step you're looking at

Some Action steps don't send a review — they launch a sub-process, and the parent business process holds at that step until the sub-process reaches its own completion step. The parent's Full Process Record shows that it entered the sub-process step, but the person actually holding things up is on the child instance, not the parent. Open the sub-process itself and pull its own Full Process Record to find the real "awaiting" person.

A To Do step is a different kind of dead end: it's a reminder or an activity the assigned person has to complete inside or outside Workday, and it can be assigned to any active security group in the tenant. Because a To Do can't display dynamic, worker-specific information, it's easy for the assigned group to not realize what the reminder is actually asking them to do, and the step just sits there until someone completes it manually. If the stuck step is a To Do, check that the assigned security group actually has access to whatever task the To Do is pointing them to.

"Fix" and "On Hold" mean something more specific than "stuck"

Two task statuses look like ordinary delays but mean the instance can't proceed at all without intervention. Fix means the business process definition itself isn't valid; Workday sends a Fix Business Process task to your business process administrators and expects someone to correct the definition, then click Restart Business Processes in Error. On Hold means the event is blocked on a separate event that has to complete first — the only action available is to open that other event and finish it.

Run the Business Process Exception Audit report to find business process definitions with critical errors before they generate a wave of Fix tasks. If an event started while its intended definition had a critical error, was inactive, or wasn't yet effective, Workday quietly falls back to the default definition instead of failing loudly — which can make a stuck step look like a routing mystery when the real cause is the definition Workday actually used. See the condition rule guide if the step in question never ran at all rather than running and then stalling.

Finding every stuck instance, not just the one someone complained about

One reported case is rarely the only one. Run Business Process Transactions Awaiting Action for X Days, which puts the oldest instances at the top — a step that's been open for three weeks is a different problem than one open for three hours. If the full list is too broad to work through, Business Process Transactions of Type Awaiting Action lets you filter to specific business process types so you're not scrolling past expense reports to find stuck hires.

For unassigned tasks specifically, filter the Unassigned Tasks report by business process or date range before working through it — for each row it names the security group with nobody in it, and the related actions menu on that group tells you whether you need to add a worker to a user-based group or populate whatever the group is actually built on (a role, job profile, organization, or another security group).

Reassign, Send Back, Correct, or Cancel — and what each one actually costs

There's no single "unstick" button, and the available actions aren't interchangeable. Pick based on what's actually wrong with the instance, not on which one sounds closest to "make it move."

Reassigning a task requires either Modify access to the Business Process Administration domain or a security group added to the Reassign Tasks permission on that business process's security policy — it doesn't require being the person the step should have gone to. Whoever reassigns it should be someone with a legitimate reason to see the event, since reassigning to the wrong person just creates a new version of the same problem.

Prove the fix before you call it fixed

After reassigning or sending back a step, open the Full Process Record again and confirm the instance actually moved — a reassignment that lands in another unfilled role or another security group with the same problem will produce the exact same symptom a day later. If the process keeps landing on the same kind of dead end across multiple events, the fix belongs in the business process definition or its security policy, not in reassigning each instance by hand.

If you're chasing this because a Workday Extend app is waiting on the business process to finish before it can take its own next step, kiweely can read the event's Full Process Record and the reports above in your tenant, tell you exactly who a step is waiting on, and make the one change needed with your consent. In a Production tenant it makes changes one at a time and reads each one back.

Sources checked

• Reference: Actions Available on Business Processes
• FAQ: Business Processes
• Reassign Tasks
• Delegate My Tasks
• Setup Considerations: Delegation
• Concept: Approval Step
• Concept: Business Processes