Start with the decision, not the automation. An approval workflow needs a request, required evidence, an authorised decision-maker, explicit states, and a result. The notification and approve button come later.
You can define that system without writing code. KasiLabs then turns the definition into tailored workflow software your team can test privately before release.
If the policy already runs in a spreadsheet and your decision is how to cut over safely, use the spreadsheet approval migration guide instead. This guide focuses on defining and building the approval route itself.
Write an approval contract
For one approval, answer these questions:
| Part | Decision to record |
|---|---|
| Request | What record is being approved? |
| Trigger | What makes it ready to submit? |
| Evidence | What must be present before review? |
| Route | Who reviews it, in what order, under which conditions? |
| Authority | Which role may approve, reject, return, cancel, or override? |
| Deadline | When is it due, and what happens when it waits? |
| Delegation | Who acts when the assigned approver is unavailable? |
| Decision | What options and reasons are recorded? |
| Completion | What action follows approval or rejection? |
| Recovery | What happens after duplicate submission or a failed downstream action? |
Microsoft documents first-to-respond, everyone-must-approve, custom-response, and sequential approval types. Its more advanced approvals guidance includes reassignment, cancellation, conditional stages, nodes, validation, and versioned publication. These are not merely tool features. They are policy choices you must settle. Microsoft approvals overview, approval scenarios, preset approval configuration.
Give every request a state
Avoid a single free-text status column. A workable model may include:
draft → submitted → evidence missing → under review → approved or rejected → resubmitted or cancelled → completed
For each state, define who may move the request and what evidence is required. A requester may edit a draft but should not approve it. A reviewer may return a submitted request with a reason. A corrected request should preserve the earlier decision rather than overwrite it.
The state model gives your app something precise to enforce. It also gives staff a queue they can understand: what needs my action, what is waiting, and why can this request not move?
A supplier-onboarding example
Imagine a supplier request that needs Operations review and, under a customer-defined condition, Finance review.
The request holds the supplier, requester, category, supporting evidence, assigned reviewers, decisions, reasons, and timestamps. Operations can return missing evidence. Finance sees only the cases routed to it and the fields required for its decision. The owner can cancel a duplicate but cannot silently erase an earlier rejection.
This is an illustrative workflow. KasiLabs does not ship a prebuilt supplier-approval application. Your policy determines the records, conditions, roles, and evidence.
Keep the request and each decision separate
Do not store the whole history in a single status field and comment cell. The request is one record. Each submission, evidence item, assignment, decision, and transition should retain its own actor and time where the business needs accountability.
That separation answers questions a flat row often cannot:
- Which version of the evidence did the approver review?
- Was the request returned or rejected?
- Who reassigned it while the original approver was away?
- Did approval succeed while the next external action failed?
- Was a corrected submission reviewed again or silently moved forward?
The application should also distinguish a business decision from a delivery action. An approver can legitimately approve a request while an email, document creation, or connected update fails. Record the approval once, flag the failed action, and give an authorised person a safe retry path. Re-running the entire approval risks duplicate decisions and side effects.
Build the app from the operator’s language
In KasiLabs, you can describe the approval in ordinary terms: “A requester provides these records. Operations checks these items. Finance joins only under this condition. A rejection needs a reason. The requester can correct and resubmit. Nobody may approve their own request.”
KasiLabs turns that into a readable plan and private working version. Your team runs the real cases, asks for changes in plain words, chooses who can use the app, sets spending limits for paid actions, and approves the exact release. Earlier versions stay available.
This is the advantage: the policy owner remains in the loop. The application is shaped around the decision instead of the team being forced into a generic template.
Use an existing approval tool when it fits
If your process is a standard request with one approver and your organisation already administers Microsoft 365 or another suitable suite, use it. A separate tailored app would create unnecessary ownership.
Before choosing a tailored build, ask the policy owner to sign off the approval contract in plain language. Ask the people who submit and review requests to test it. A technically correct route can still be unusable if the evidence is hard to provide, the reason for return is hidden, or approvers cannot see the context needed for a decision.
KasiLabs becomes a stronger fit when the route, evidence, visibility, resubmission, and exceptions reflect how your organisation actually operates and existing tools scatter the process across forms, sheets, and messages.
Do not use this approach to imply legal signatures, regulatory compliance, or support for an integration that has not been verified. Life- or safety-critical decisions and specialised regulated workflows need the appropriate professional and technical review.
If your team keeps chasing one approval through email and spreadsheet columns, describe that approval in KasiLabs. Test the rejection, delegation, wrong-role, and failure cases privately before the first live request.