Learning PathModule

Why procurement governance matters

Understand the business problem approval workflows solve, and meet the three resources that solve it natively.

Ask about this Page
Copy for LLM
View as Markdown

After completing this page, you should be able to:

  • Explain why B2B purchasing needs spending governance and separation of duties.

  • Identify the three resources that implement approval governance and how they relate to Associate Roles and Business Units.

  • Describe where approval evaluation sits in the purchasing flow.

An Atlas Corporate APAC buyer assembles a 180-line requisition worth AUD 92,000 and is ready to submit. In a consumer purchase, that is the end of the story: the shopper decides, the shopper pays. In B2B, it is the start of a second story. Who is allowed to commit that spend? Does it need a manager's sign-off, a second approver above a threshold, or a compliance check first? Procurement governance answers those questions, and you can configure it directly on the platform rather than bolting on an external workflow engine.

The business problem: controlling who can commit spend

B2B organizations delegate purchasing to many people but rarely delegate unlimited authority. Three needs recur across almost every buyer:

  • Spending thresholds. A buyer can self-serve up to a limit; above it, someone with more authority must approve.
  • Separation of duties. The person who raises a purchase should not be the only person who approves it. You designed Associate Roles with this split in Configure associate access; approval workflows are where that split is enforced.
  • Departmental controls. Different divisions, cost centers, or product categories carry different sign-off requirements.
Approval Rules and Approval Flows model all three, scoped to the Business Unit hierarchy you already designed.

The three resources at a glance

Approval governance is built from two configuration resources and one runtime resource.

  • Approval Rule: the policy. It states which Orders need approval (a predicate), which roles' Orders it applies to (requesters), and who must approve and in what order (approvers). A rule belongs to one Business Unit.
  • Approval Flow: the runtime instance. When an Order matches an active Approval Rule, the platform creates an Approval Flow automatically to track that Order's approvals, rejections, and the parties involved.
  • Associate Role: the currency of authority. Both the requesters and the approvers in a rule are expressed as Associate Roles, not individual people, so governance stays stable as staff change.
Approval governance evaluates Orders, not Carts. A rule's predicate is an Order Predicate, and an Approval Flow references the Order it governs. The buying-committee Cart freeze you met in the previous module protects a price before checkout; an Approval Flow governs whether the resulting Order may proceed.

Where approval sits in the purchasing flow

Approval Rules are designed once, ahead of time. The Approval Flow is created at the moment an Order is placed and matches a rule. From there, the flow moves through the rule's approver tiers until it is fully approved or a single rejection stops it.

The next pages build each piece in turn: the rule's predicate and requesters, the approver hierarchy, the flow at runtime, and how rules inherit across a Business Unit hierarchy.

Key takeaways

  • B2B purchasing needs governance for spending thresholds, separation of duties, and departmental controls; you configure it natively.
  • An Approval Rule is the policy (predicate, requesters, approver hierarchy); an Approval Flow is the runtime instance the platform creates when an Order matches a rule.
  • Both requesters and approvers are expressed as Associate Roles, so governance is role-based and survives staff changes.
  • Approval governance acts on Orders: rules use Order Predicates, and a flow references the Order it governs.

Test your knowledge