Approval workflow software development

Approval patterns

Writing approval rules down

Before building anything, write down who must approve what, based on type, value, department and risk. Many organisations discover that their real rules differ from the written policy, or that nobody has written them at all. Agreeing a clear table of rules, and the reasoning behind it, is often the most valuable step in the project. The software then applies that table consistently, and changes to it can be made by an administrator rather than a developer.

Keep rules as simple as policy allows; every extra condition is another thing to explain and maintain.

Keeping requests moving

• Delegation

  Approvers nominate a deputy while away.

• Reminders

  Pending approvals prompted after a set time.

• Escalation

  Overdue requests passed to a more senior or alternative approver.

• Visibility

  Requesters see where their request is and who holds it.

What a good approval request shows

The life of a request

1. 01

   Submit

   Requester completes a form with required details.

   Output: Request

2. 02

   Route

   Rules choose the approvers.

   Output: Approval route

3. 03

   Decide

   Each approver approves, rejects or queries.

   Output: Decisions

4. 04

   Act

   Approved requests trigger the next step, such as an order.

   Output: Action taken

5. 05

   Record

   Full history kept for audit.

   Output: Decision record

A record auditors can rely on

An approval record should show who requested what, which rule determined the route, who approved or rejected it, when, and what details they saw at the time. If the request was changed after approval, it should need approving again. This gives finance teams and auditors confidence that controls work, and it settles questions later about who authorised a commitment.

Separating duties

A common control is that nobody approves their own request, and that the person who approves a payment is not the one who sets up the supplier. The software can enforce these separations automatically, which is more reliable than relying on people to notice.

Approving from a phone

Approvers are often away from their desks. Letting them review and decide from a phone, with the key details and attachments readable on a small screen, keeps requests moving. Notifications should link straight to the request, and the decision should take no more than a couple of taps once the approver has read it. For high-value approvals, stronger sign-in on the phone adds protection.

Avoid approval by simply replying to an email, which is harder to secure and record reliably.

What happens after approval

Approval is rarely the end. An approved purchase becomes a purchase order, an approved refund triggers a payment, an approved holiday updates the rota. Connecting the workflow to these next steps removes another round of manual work and ensures nothing is actioned without approval. Rejected requests should go back to the requester with the reason, and allow resubmission with changes.

Learning from approval data

Reports on how long approvals take, where they wait and how often requests are rejected show where rules could be simplified or thresholds raised. If nearly everything at a certain level is approved, that step may be adding delay without adding control.