Approval Flows and Requisition Routing Design
Explains how approval flows are designed and configured in Ariba Buying to route requisitions correctly, covering approvable rules, approver determination, escalation, and common integration touchpoints with organizational and financial master data.
Explanation
Approval flow design is one of the most business-critical configuration areas in Ariba Buying because it directly controls spend control, segregation of duties, and cycle time for requisition-to-PO conversion. Unlike simple linear sign-off chains, Ariba approval flows are built from approvable rules that evaluate conditions on the requisition (such as total amount, commodity code, cost center, supplier, or custom fields) and then insert approvers dynamically using approver determination methods like organizational hierarchy lookups, cost center owner lookups, ad hoc approvers, or rule-based groups. A typical design starts with identifying the control objectives: dollar thresholds requiring additional approval, category-specific approvals (for example legal review on services with specific commodity codes), and budget or cost object validation before the requisition can proceed. Each of these becomes a distinct approvable rule that is evaluated against the requisition data model. Rules are usually layered: a baseline manager-approval rule using the organizational hierarchy, followed by conditional rules that insert additional approvers only when specific conditions are true. Care must be taken with rule ordering and duplicate approver suppression, since an approver appearing twice in a flow can either be auto-approved or require repeated action depending on configuration, and this behavior must be validated during testing rather than assumed. Approver determination frequently depends on accurate organizational data — user records, supervisor relationships, cost center ownership, and commodity-to-approver mapping tables. When this master data is incomplete or inconsistent (for example, a user without an assigned manager, or a cost center without a designated owner), the approval flow can stall or default to an escalation path, which is a common production issue. Escalation and delegation settings determine what happens when an approver does not act within a defined timeframe; poorly tuned escalation windows are a frequent source of user complaints about slow requisition turnaround. From a runtime perspective, when a requisition is submitted, the system evaluates all applicable approvable rules against the requisition data, builds the ordered approval flow, and notifies the first approver. As each approver acts, the system re-evaluates whether subsequent steps are still applicable (since data can change during editing before final submission, though not typically mid-flow). Once all required approvals are obtained, the requisition converts into one or more purchase orders, which are then transmitted to suppliers, often via SAP Business Network or a direct integration channel. In S/4HANA-integrated landscapes, some approval-relevant data such as cost center validity, budget availability, or account assignment correctness may be checked against the ERP system through integration calls, meaning approval flow reliability is partly dependent on integration health, not just Ariba-side configuration. Public cloud, private cloud, and pure standalone Ariba deployments can differ in how deeply this validation occurs, and teams should not assume identical validation behavior across environments without confirming it in their specific landscape. Supporting this area operationally requires understanding how to trace a stuck requisition: checking which approvable rule inserted a given approver, confirming the approver's delegation settings, and verifying master data feeding the approver determination method. Because approval flow changes affect live spend controls, configuration changes should go through a controlled testing and change management process, including validation in a non-production tenant where feasible, before promotion.
Real project scenario
During a rollout, procurement leadership requires that any requisition with a total value above a defined threshold for a specific category of professional services must route to both the requester's manager and a category-specific compliance approver before PO creation. The functional consultant designs a layered approvable rule: a baseline hierarchy-based manager approval plus a conditional rule keyed on commodity code and amount that inserts the compliance approver group. During testing, the team discovers that some requesters have no assigned manager in the organizational data, causing flows to escalate immediately; this is resolved by correcting master data and adding a fallback approver group before go-live.
Common mistakes
• Assuming approval flow behavior without testing edge cases like missing manager assignments or multiple applicable rules firing simultaneously • Not accounting for duplicate approver suppression behavior when the same person appears via two different rules • Setting escalation timeframes without input from business stakeholders, leading to either overly slow or overly aggressive escalation • Overlooking that approver determination depends on accurate, current organizational and cost center master data • Changing approval rules directly in a live environment without adequate regression testing of existing requisition types
Best practices
• Document control objectives before building approvable rules so each rule maps to a clear business requirement • Test approval flows with realistic edge-case data, including users missing managers or cost center owners • Keep escalation and delegation settings aligned with actual business SLA expectations • Validate rule ordering and duplicate approver handling explicitly rather than assuming default behavior • Use a non-production or test tenant to validate approval flow changes before promoting to production • Maintain a change log for approval flow modifications given their direct impact on spend control
Interview angle
Interviewers commonly probe whether a candidate understands the difference between approvable rules and approver determination methods, how layered rules interact, and how to diagnose a stuck requisition — a strong answer walks through checking rule evaluation, approver master data, and delegation settings rather than only describing configuration screens.