Cost Center Owner Approval Disappears on Requisitions
A services company runs a four-step job requisition business process: Manager Submit, Recruiter Review, Cost Center Owner Approval, then HR Partner Approval. The Cost Center Owner step routes to the role Cost Center Manager on the cost center related to the requisition. Recruiters are permitted to submit requisitions before finance has assigned a cost center, and 8% of requisitions reach workforce planning with no cost center owner approval at all. In the same period, any edit to an approved requisition - including moving the target start date by one day - sends it back through all four steps, and recruiters have started editing outside the process to avoid the churn. HR Partners are configured as a group of six covering all regions, and their step requires the approval of all six.
1. Explain why the Cost Center Owner step vanishes, and rank the available fixes from least to most disruptive.
Read the worked answer
Why it vanishes: the step's approver is derived from a related object (the cost center on the requisition). When that relationship is empty at the time the step is reached, there is no approver to build an approval chain from, so the step's fallback routing executes. The default fallback behaviour is to skip the step and proceed. Eight percent is exactly the population where finance hadn't assigned a cost center yet - a data-timing problem surfacing as a control gap.
Fixes, least to most disruptive:
- Change the step's fallback routing from skip to route to a named group - for example a Finance Approvers group. Nothing is skipped, and the step becomes a visible work queue item instead of silence. Fastest change; the cost is that the fallback group absorbs the 8%.
- Stop the condition at submit: make the Cost Center Owner step run only after a cost center exists, with the requisition parked in a waiting state rather than proceeding. Better control, but it introduces a queue someone has to work.
- Make cost center required on the Manager Submit step (conditional validation so it is only required when the requisition is for a new position or a funded hire). This is the real fix: it moves the problem to the person who can answer it, at the moment they submit.
- Change the process order so finance assigns the cost center in a step before Recruiter Review. Most disruptive - it changes everyone's workflow and training.
Recommend 1 immediately as containment and 3 as the durable fix. Do not treat 1 as the fix; it hides the same gap behind a different approver.
2. A functional lead proposes a condition rule that routes any requisition without a cost center to the HR Partner step for approval instead. Assess this.
Read the worked answer
Mechanically it can be done - a condition rule can test whether the cost center is empty and route accordingly - but it doesn't solve the problem.
- It doesn't restore the control. The control being tested is 'the person who owns the spend has approved the spend.' Routing an unassigned requisition to an HR Partner asks someone with no cost center ownership to approve spend they don't own. That is a step, not a control.
- It creates a self-approval case. HR Partners frequently are cost center managers in this kind of org. If the same person is both, and self-approval is permitted on the step, the requisition is approved by the person it was routed to for lacking an approver.
- It leaves the data problem in place. The requisition still has no cost center at the end of the process, so downstream reporting, budgeting, and the payroll feed inherit a null.
- It adds a branch nobody maintains. Condition rules layered on condition rules are the usual source of 'why did this go there' tickets months later.
What to say yes to instead: use the fallback routing to a Finance Approvers group so an accountable owner is engaged, and add validation at submit so the requisition cannot proceed without an owner. A condition rule is the right tool for which approver, not for whether the control applies.
3. The HR Partner step requires all six HR Partners to approve. What is the effect, and how would you redesign it given that HR Partners are region-aligned in practice?
Read the worked answer
Effect of requiring all six: every requisition waits for six people, five of whom have no relationship to it. Approval steps with an all-must-approve group do not fail loudly - they sit. The observable symptom is exactly what the setup describes: recruiters finding a path around the process, because the process costs days for a one-day change.
It also makes the step's outcome dependent on the slowest approver, which is a governance problem dressed up as a control problem.
Redesign:
- Route to one accountable approver, not a pool. Approve by the role held on the worker's supervisory org, or by a role-based group scoped to region, so the HR Partner who covers the requisition's region is the only approver.
- Keep the group as a fallback, not a primary. If regional coverage is missing, fall back to the group with single-approval semantics rather than blocking.
- Reduce re-approval scope on edits. If the BP restarts on every edit, fix that separately: confirm which fields the BP's routing actually depends on, and whether a restart is being triggered by fields no approver cares about. A one-day start date change should not re-summon four approvers.
- Instrument it. Approver cycle time per step, before and after. If the redesign doesn't move the number, the bottleneck was elsewhere.