The hire that sat three weeks behind one approval
A manufacturing client rang me in November about an engineer who had started three weeks earlier and still had no worker record. She had a laptop and a badge from IT. She had no pay, no time entry and no benefits enrolment, because the hire event was still open, parked on an approval routed to a security group whose only member had left the company in September.
Nobody had rejected anything. Nobody had seen it. The step existed because a director in an implementation workshop had asked to see new headcount before it landed, and the step outlived the director, the reason and the person who was meant to click it.
The model underneath all of this takes an afternoon to learn. What separates competent configuration from copying whatever the last consultant built is judgement about which steps deserve to exist and who they resolve to. Plenty of tenants have the first part right and have never gone back to the second.
What the model actually gives you
A business process in Workday is a defined sequence of steps attached to an event such as a hire, a job change or a termination. Each step has a type. An approval asks somebody to accept the event or send it back. A to-do asks somebody to confirm they did something outside the system. An action step captures data. A notification tells somebody without holding anything up.
The exact set of step types, and the events you can configure, vary by module and by what you have licensed, so read your own tenant rather than a vendor deck. The shape holds everywhere. Steps run in an order you define, the event moves on when the current step completes, and nothing downstream happens until it does.
Every step routes to a security group rather than to a person. Workday resolves that group when the step becomes ready, against the organisation on the event, which is why a role-based group that resolves to the worker's manager keeps working after a reorganisation. Routing to a group with one named member produces the failure I opened with.
So the routing decision matters more than the step order. Groups that resolve from the position rather than from a membership list survive leavers, transfers and acquisitions without anyone editing configuration. That is also why security group sprawl tends to surface as stalled work long before it surfaces as a security finding.
Fewer steps than the workshop asked for
Every approval you add is delay you add. Two days per approver is normal in an organisation where managers live in meetings, so a five-approver chain on a job change means a fortnight before anything reaches payroll. Most of those chains encode organisational anxiety from the design phase rather than a control anybody can name.
The honest test has two questions. Has this approver ever rejected one of these, and what exactly would they look at if they did. If the answer to the first is no and the second draws a shrug, you have found a step to delete and a notification to add in its place.
Deleting a step is easier before go-live and still worth doing afterwards. The people who asked for approvals in a workshop were answering a narrower question, which was what could possibly go wrong, and nobody in that room was counting the cost of waiting. That cost lands on the new starter, and it is where the quiet failures in an employee's first weeks come from.
Conditions instead of steps that never vary
Conditions decide whether a step runs at all. The step stays configured for the cases that need it and gets skipped for the cases that do not, which beats asking a compensation partner to approve four hundred changes a year that all fall inside policy. Approvers who only ever see exceptions read them properly.
Write conditions against data that already sits on the event and that somebody maintains. Amount thresholds, worker type, country, organisation and reason codes hold up well. Conditions built on stacked calculated fields hold up until the field changes underneath them, which is one more reason to watch calculated fields that multiply.
What you can use as condition criteria varies by business process and by module, and some processes give you far less to work with than others. Find that out early in design, because a plan that assumes a condition you cannot build turns into a chain of manual approvals by default.
The traps that stall a process in production
Sequential steps add their waiting times together. Parallel steps wait for the slowest approver and no longer. If three people need to see a change and none of them needs another's decision first, running them in parallel turns six days of waiting into two. Sequential order earns its place only when the later approver genuinely needs the earlier decision in front of them.
Delegation is the most common cause of stalled work I find. An approver goes on leave without delegating, or delegates the wrong set of processes, or their delegation expires mid-cycle, and everything routed to them stops quietly. The options differ by tenant, so check what your delegation rules allow and whether managers know the feature exists. Most do not until somebody shows them.
Whether the initiator can also approve their own event is a segregation question, not a convenience one. A manager who submits a pay change and approves it has no control over that transaction, whatever the process diagram says. Decide it deliberately for each process, write down why, and expect your auditors to ask, which is the same argument as one person wearing four hats.
Effective dating catches teams out. A process that completes after its effective date applies the change retroactively, and what happens next depends on the module. Payroll may pick it up as a retro calculation in a later period. A report run for a date in between shows the old value until the process closes. Long approval chains on anything dated make that routine rather than rare.
Finding the stalls you already have
Start from where work is sitting, not from the configuration. A list of in-progress events grouped by the step they are parked on, with the age of each, tells you in one pass which steps are the problem. A configuration review tells you what somebody intended. The queue tells you what is happening.
The usual instinct is to add a reminder or an escalation to the slow step. That keeps the step and adds noise to somebody's inbox. The better fix is nearly always removing the step, or putting a condition on it so it fires only for the cases that need a human. Reminders belong on steps you have already decided must exist.
Before I change anything on a process that is already live, I work through the same short list.
- The three steps where work sits longest, with the average age of each.
- The security group each of those steps routes to, and how many people it resolves to today.
- Any step that resolves to a single member or to a named individual.
- Which steps have rejected at least one event in the last twelve months.
- Which approvers hold an active delegation, and who is due to be away this quarter.
- The effective dates on open events, and whether any of them have already passed.
- The person who owns the decision to remove a step, by name.
Somebody has to own whether the steps still make sense
Steps get added readily and removed almost never. Every business process needs a named owner who reviews at least once a year whether each step still has a reason, and who has the standing to delete one when it does not. Without that, a tenant collects approvals for six years and nobody can say who asked for any of them.
Give that owner the authority a change board has when it works well, which means the right to refuse a new step and the duty to justify the ones already there. The change approval board that moves is the same problem in a different system, and the same habit fixes both. Put the review on your governance calendar so it happens without anyone volunteering.
Pull your in-progress events this week, sort them by age and read the top ten. Then ask the group each one is waiting on what they were checking. Their answers will name the steps you can delete before the next cycle.
