A purchase-request approval workflow in Boomi Flow

Purchase requests are the classic first workflow. Everyone has them, they usually run over email, and the rules are simple enough to automate in days: an employee asks to buy something, a manager approves anything above a threshold, and purchasing places the order. This article explains why the email version breaks, describes the pattern that works, and builds it step by step in Boomi Flow.

Why approvals by email fail

• No status. “Has my request been approved?” can only be answered by asking around.
• No audit trail. The approval is a reply buried in someone’s mailbox. Auditors want a record they can query.
• Rules live in people’s heads. “Anything above 2,000 EUR goes to the manager” is applied inconsistently.
• Re-typing. Purchasing types the request into the ERP by hand, with the usual typos in supplier codes.
• Holidays. When the approver is away, requests simply wait.

The pattern: request, route, decide, record

The workflow has four parts:

1. Request. A form captures the data in a structured way and validates it at entry.
2. Route. A rule decides the path: small requests go straight to purchasing, larger ones need a manager.
3. Decide. The approver sees the request on a dedicated screen and approves, rejects or sends it back with a comment. Only people in the approver role can do this.
4. Record. Every step is stored with who, when and what, and the requester is notified of the outcome.

Requester ──► Request form ──► amount > threshold? ──yes──► Manager approval ──► Approved / Rejected
                                      │                            │
                                      no ──────────────────────────┴──► Purchasing ──► notify requester

For our example, a company in Thessaloniki uses this rule: requests up to 2,000 EUR go straight to purchasing; above that, the department manager must approve.

Building it in Boomi Flow

In Boomi Flow, an app is a flow: a canvas of map elements (pages, decisions, steps and so on) connected by outcomes. Data is held in values, and structured data uses types. The steps below follow that model; exact menu labels can change between releases, so use them as a guide to the order of work.

Step 1: Define the data

Create a type called PurchaseRequest with these properties:

Property	Type	Example
requestId	String	PR-2026-118
requester	String	m.papadopoulou
costCentre	String	210
supplier	String	S-0381
description	String	3 laptops for warehouse
amount	Number	2450.00
status	String	Pending
approverNote	String	Approved, use framework deal

Then create a value of that type, for example Current Request, which carries the request through the flow. Create a separate value for the threshold (Approval Threshold, 2000) rather than typing the number into a rule. When the threshold changes, you change one value.

Step 2: Build the request page

1. Add a Page element to the canvas and create a page with input components bound to the properties of Current Request: description, supplier, cost centre and amount.
2. Make amount, supplier and cost centre required.
3. For the supplier, use a list (combobox) rather than free text. In this article we fill it from a static list; in Connecting a Boomi Flow app to integration processes we load it live from the ERP.
4. Add a Submit outcome from the page to the next element.

Step 3: Route on the threshold

1. Add a Decision element after the request page.
2. Create two outcomes from it: Needs approval and Auto-approved.
3. On Needs approval, add a business rule: Current Request → amount is greater than Approval Threshold. Leave Auto-approved as the default outcome, so it is taken when the rule does not match.

Keep the decision this simple. If routing grows (different thresholds per cost centre, a second-level approver above 10,000 EUR), add the extra rules here, one outcome per path, so the logic stays visible on the canvas.

Step 4: Restrict approval to managers

Approval must happen only by the right people. In Boomi Flow you do this with a swimlane: a lane on the canvas whose elements can only be used by the users or groups you specify, as resolved through the flow’s identity provider.

1. Configure the flow to use your identity provider, so users sign in with their company accounts.
2. Add a swimlane named Managers and restrict it to the managers group from your directory.
3. Inside the swimlane, add the approval page: a read-only summary of the request, a text field for approverNote, and three outcomes: Approve, Reject and Send back.

When the flow reaches the swimlane, the requester’s session stops there. The request waits until a manager opens it and acts. This is the long-running, stateful part that email can’t do.

Step 5: Set the status and notify

1. After each outcome, use an Operator element to set Current Request → status to Approved, Rejected or Returned.
2. Send back leads to the request page again, so the requester can fix the request and resubmit.
3. Send a notification to the requester with the result and the approver’s note. A common approach is to call an integration process that sends the email (or a Teams message) through a connector. Depending on your set-up, Flow’s own notification options may also cover this; check what your tenant offers.
4. Approved and auto-approved requests continue to purchasing. In the next article, this is where the flow creates the purchase order in the ERP automatically.

Step 6: Test it

Run the flow and walk through each path:

Test	Expected result
850 EUR request	Skips approval, status Approved
2,450 EUR request, manager approves	Waits in swimlane, then Approved
2,450 EUR request, manager rejects	Status Rejected, requester notified
2,450 EUR, Send back, then resubmit	Returns to request page with data kept
A non-manager opens the approval link	Access denied

The last test matters most. A workflow that lets anyone approve is worse than email, because it looks controlled.

Before you go live

• Plan for absence. Decide what happens when the approver is away: a deputy group in the swimlane, or a reminder and escalation after a few days.
• Store the history outside the flow. Write each decision (request ID, user, outcome, timestamp, note) to a database or to the ERP through an integration process, so you can report on it and keep it as long as audits require.
• Keep thresholds configurable. Finance will change the limit. Make sure that is a value change, not a redesign.
• Test on a phone. Many managers will approve from mobile.
• Agree ownership. The purchasing manager owns the rules; IT owns the platform. Write it down.

Summary

The approval pattern is simple: a structured request, a visible routing rule, a restricted decision step and a recorded outcome. In Boomi Flow these map to a page, a decision with business rules, a swimlane and operator steps. The next step is to stop re-typing approved requests into the ERP, which we cover in Connecting a Boomi Flow app to integration processes. For the wider picture, see Workflow automation and low-code apps: a practical guide.