I85PREP
⌘ K
MB-800 study materials
MB-800 study resources

Purchase Approval Thresholds, Approver Limits, and Delegation

MB-800 · Put your knowledge to work in context.

All case studies

Purchase Approval Thresholds, Approver Limits, and Delegation

Northwind Paper's purchasing policy: orders below 2,500 are released without approval; 2,500 to 25,000 need the department manager; above 25,000 need the CFO; above 100,000 need the CEO. Purchasing agents maintain blanket orders and release purchase orders from them. After go-live: a 900 order has sat in Pending Approval for four days; a 30,000 order was approved by a department manager whose Approval User Setup shows a 25,000 purchase limit; the CFO's week of leave stalled eleven requests; and orders created by releasing a blanket order never enter the approval process at all.

1. Why does a 900 order require approval, and how do you make sub-2,500 orders bypass the workflow?

Read the worked answer

Why. Approval limits do not create automatic approval. A limit governs what an approver may approve; the workflow still sends a request for every document that meets the step's conditions. With no amount condition on the first step, the 900 order routes, and it will keep routing no matter how the limits are set.

Fix. Put the threshold in the workflow, not the user setup. On the first approval step, condition the Send Approval Request response on the purchase header amount being greater than or equal to 2,500. Documents below it never generate a request and stay open for release. Choose Amount or Amount Including VAT deliberately - they differ by tax, and for foreign-currency orders Amount is the document-currency figure - then document the choice so the policy and the workflow agree.

Follow-ups. Requests already pending when you change the workflow keep their existing instance; cancel and re-create them. And test the blanket-release path explicitly: a released order is an ordinary purchase order and only routes if the step's conditions fire on creation rather than on a status change.

2. A 30,000 order was approved by a manager with a 25,000 limit. Where do you look, in what order, and how do you harden it?

Read the worked answer

Check in this order.

  1. Approval User Setup for that user: the Purchase Amount Approval Limit and whether Unlimited Purchase Approval is ticked. Unlimited overrides the number, and a blank limit is not the same as zero.
  2. The approval step's Approver Limit Type. It determines whether the step reads the approver's own limit or the direct approver's limit; a mis-set type lets a request sit with someone who should have escalated.
  3. Timing. Changing a limit does not re-route or invalidate approvals already given, so a limit set after the approval explains the symptom without proving the workflow is wrong.
  4. Scope. Whether approval was actually taken on a different document - a blanket order or a purchase invoice - and the order simply inherited the outcome.
  5. Identity. Whether the approver has a second user record, or a record in another company.

Harden. Clear every Unlimited flag, give each approver an explicit numeric limit, configure the escalation response for above-limit requests, and prove it with a 24,999 order and a 25,001 order so you can name the step that catches each.

3. How do you cover the CFO's leave, and how do you investigate blanket-order releases that skip approval?

Read the worked answer

Leave. Use Approval Delegation: the CFO as delegator, a named delegate, Starting Date and Ending Date covering the leave, and the purchase amount type. Three things are easy to miss and all three cause a stalled queue: delegation does not import the CFO's limit, so the delegate needs their own Approval User Setup limit that is high enough; the delegate needs the permission sets to open and approve purchase documents; and delegation takes effect forward only - requests already assigned to the CFO are not picked up, so they must be reassigned or the delegation created before the requests exist.

Blanket releases. Reproduce in a sandbox with a 40,000 release. The release produces a standard purchase order, so the workflow should apply; if it does not, inspect the step's trigger and conditions. A condition that depends on a field changing to Released never fires on a document created in that state, which matches the symptom exactly. Also confirm the workflow is enabled, that only one version of that workflow code is enabled, and that the step has a real approver rather than a blank approver or empty user group.