How to build a procurement approval workflow app

The short answer

A useful first version needs seven connected records:

1. The purchase request and its purpose.
2. One or more requested line items.
3. The evidence attached to the request.
4. Each approval assignment.
5. Each decision, reason, actor, and time.
6. Any budget or exception response.
7. The downstream action, such as creating a purchase order in another system.

Do not compress these into one spreadsheet row. Separate records preserve which evidence an approver saw, why a request moved, and whether the action after approval actually succeeded.

If you need a general model for many kinds of decisions, start with how to build an approval workflow app. This guide covers the procurement-specific controls around purchase requests, authority, budgets, and supplier or accounting hand-offs.

Start with a purchase request contract

Before drawing a screen, choose one real request type and answer the following questions with the policy owner.

The route belongs to your organisation. Avoid copying a threshold from a template or another company. Amount, category, department, risk, project, and supplier status can all affect authority, but only your current policy can say how.

Microsoft documents several useful route shapes: first response, everyone must approve, custom responses, and sequential approvals. These are implementation patterns, not substitutes for authority. Microsoft approvals overview

Model a request as states, not a coloured status cell

A procurement request may move through states such as:

draft → submitted → evidence missing → under review → returned, rejected, or approved → hand-off pending → ordered or closed

Each transition needs an actor, a condition, and a recorded result. A requester can edit a draft. A reviewer can return a submitted request with a reason. A corrected request becomes a new submission rather than silently replacing the evidence already reviewed.

Approval and ordering should remain separate. An authorised approver can approve the business decision while the downstream purchase-order action fails. Record the approval once, mark the hand-off as failed, and give a named role a safe retry or reconciliation path. Re-running the full approval can create duplicate decisions or duplicate orders.

This separation also makes the queue useful. An approver should see what needs a decision. Procurement should see approved requests waiting for action. A requester should see what is missing without gaining access to restricted budget or supplier information.

Keep authority visible and enforce it on every request

Procurement control is not achieved by hiding a button. The app must reject an action when the person is not authorised, even if they try to call it through another route.

The OECD describes authorisation, approval, verification, reconciliation, and segregation of duties as important procurement controls. It also warns that too many participants can make the process slow and create new risks. The practical goal is a proportionate separation: no one person controls every important stage, but every stage still has a clear owner. OECD procurement internal controls

OWASP recommends least privilege, default denial, checks on every request, and tests for authorisation logic. Translate that into plain operating rules:

• A requester cannot approve their own request unless a documented policy explicitly permits a narrowly defined case.
• An approver sees only the requests and fields needed for their authority.
• A delegate receives authority through an approved route and for a defined period.
• A change to material evidence after approval sends the request back through the required review.
• Cancellation and override actions retain the actor, reason, and earlier history.

OWASP's authorization guidance is written for application teams, but its test is useful for buyers too: can the system prove that an unauthorised request is denied?

Design exceptions without creating a hidden bypass

Urgent purchases, sole-source decisions, budget changes, unavailable approvers, and supplier changes are normal. If the app handles only the ideal path, staff will move exceptions back to email.

Give each exception a defined route:

An exception route should make unusual work more visible, not less controlled.

Build three views before adding automation

Most teams can begin with three focused views.

The requester view creates drafts, lists missing evidence, and shows the current outcome. It should not expose other departments' requests or restricted review notes.

The approver view shows the decision context, relevant evidence, previous returns, and the actions allowed to that approver. It needs a clear difference between return, reject, and approve.

The operations view shows ageing requests, assignments, exceptions, approved cases awaiting hand-off, and failed actions. This is where the process owner sees whether work is stuck because of policy, missing information, absence, or a connection failure.

Notifications can support these queues. They should not become the system of record. A message should take someone to the controlled request rather than invite a decision that cannot be tied to the evidence reviewed.

Test the route with records designed to break it

Before release, run at least these cases in a private working version:

1. A valid everyday request.
2. A request missing required evidence.
3. A requester trying to approve their own request.
4. A changed quotation after the first approval.
5. An unavailable approver and a valid delegation.
6. A duplicate submission.
7. A request that the budget owner refuses.
8. An urgent exception with the required additional review.
9. A successful approval followed by a failed downstream action.

Ask the people who do the work to test, not only the person sponsoring the app. The requester should find out whether returns are understandable. Approvers should confirm they see enough context. Procurement or Finance should prove that a failed hand-off is recoverable without repeating the business decision.

In KasiLabs, the team describes these rules in ordinary language, reviews the plan, and receives a private working version. Owners choose access and spending limits. An authorised reviewer approves the exact release, and the previous version remains available if application behaviour needs to be restored. Returning to an earlier app version cannot reverse an order, email, payment, or other outside action already completed.

Use your existing system when it already fits

Do not build a separate app merely because a tailored route is possible. Use the approval function in your existing accounting, ERP, procurement, or Microsoft 365 environment when it covers the policy, evidence, access, reporting, and exception route and has a clear administrator.

A focused tailored app becomes more reasonable when the organisation has a stable, owned process that existing systems split across forms, sheets, messages, and manual re-entry. It is a poor fit when nobody owns the policy, the process changes every week, or required accounting, tendering, tax, banking, supplier-network, signature, or regulated controls have not been verified.

KasiLabs does not arrive as a finished procurement product. It gives your team a way to create and govern the workflow software around its actual purchasing decisions. See how the private build and release process works, review the current access and release controls, and check workspace pricing and spending limits.

Describe one purchase request in KasiLabs. Bring the missing-evidence, wrong-role, delegation, and failed-hand-off cases with it, and do not release until they behave as your policy requires.