Purchase request

An employee submits a purchase request. Their manager reviews it and approves it, sends it back for changes, or rejects it. Approved requests go to procurement, which creates the purchase order and sends it to the supplier.

This is the Purchase request template. To open it in the app, select Templates in the rail, then Purchase request.

process Purchase request
lanes Employee | Manager | Procurement

lane Employee
start Need identified
user Submit purchase request
lane Manager
xor #resubmitted
user Review request
  on~timer(P2D) Review pending two days -> Send reminder
xor Request approved?
  yes -> Create purchase order
  needs changes -> Revise request
  no (default) -> Notify rejection

lane Procurement
service Create purchase order
send Send order to supplier
end Order placed

lane Employee
user Revise request
  -> #resubmitted

lane Manager
send Notify rejection
end Request rejected

send Send reminder
end Reminder sent

What to noticeCopy Anchor Link

• Rework loop. "needs changes" goes to Revise request, which points back to xor #resubmitted, a merge just before the review. See Approval with rework.
• Reminder. on~timer(P2D) is non-interrupting, so the review carries on while a reminder goes out after two days. See Deadlines and reminders.
• Every path ends in a named end event: Order placed and Request rejected for the two outcomes, and Reminder sent for the reminder's side path.
• The happy path comes first. The approved branch is written right after the decision, so the layout keeps it straight.
• Lanes switch mid-block. start Need identified in Employee connects to xor #resubmitted in Manager without a break.

To show the supplier as an outside party, add pool Supplier (below) under the process line and a message under the step that sends the order. See Pools and messages.

send Send order to supplier
  => Supplier: Purchase order