The Modulix documentation covers every module, step by step.Read the docs
All blog posts
BlogOperations & inventory

Approval workflows that don't slow you down

Approvals protect the business only if people actually decide. Eight practical rules for workflows that catch what matters and stay out of the way of everything else.

ZTZantrey TeamThe people who build and support Modulix 5 min read
Cover image: Approval workflows that keep moving

Every growing business reaches the point where someone says "large purchases should be approved". A month later, approvals are the reason purchases are late. The control is right; the design is wrong. Here are the rules we follow when building approval workflows in Modulix.

1. Approve exceptions, not everything

A workflow's conditions decide which records need a decision at all. Approving every expense claim teaches approvers to click without reading. Approving claims above a threshold, or purchase orders over a certain total, keeps their attention for the cases that matter. Use changed to on the status field so the workflow runs once, when a record is submitted, not on every edit.

2. Ask a role, not a person

Approvers can be named people, or everyone with a role. Role holders are resolved when the approval is requested, and only active members are asked. When the finance lead goes on holiday or changes jobs, the workflow keeps working.

3. Decide how many approvals you really need

One approver means the first decision counts: fast, and right for most routine checks. Every approver means one rejection rejects: slower, and worth it only when two different people genuinely need to agree.

4. Keep four eyes on it

Tick The person who made the change cannot approve it. It costs nothing on most days and closes the obvious gap on the day it matters. Expense claims have the same rule built in: nobody can approve their own claim.

5. Escalate instead of waiting

Turn on Escalate if nobody decides and choose after how many hours (from 1 to 720) more people are asked. A request should never wait silently because one person is busy.

The workflow editor with conditions on an expense claim and a Request approval step
Conditions decide which records need a decision; the approval step decides who makes it.

6. Handle both outcomes in one workflow

Set If rejected to Continue, then use Run this step on the steps that follow: one step only if the last approval was approved, another only if it was rejected. For expense claims, this is the whole pattern:

  1. Trigger: an expense claim is updated, with the condition Status changed to Submitted.
  2. Request approval from the finance role, continuing if rejected.
  3. Approve an expense claim for the triggering record, only if approved.
  4. Reject an expense claim, only if rejected, with the approver's comment ({{approval.comment}}) as the reason.

The employee sees the decision and the reason on the claim, as if a person had clicked the button.

7. Put the decision where people already are

Approvers see requests in the Approvals inbox, as a badge in the top bar and in the Waiting for your approval widget on the dashboard. Approval requests are also notified in the app, by email and as browser push notifications by default. Encourage approvers to keep push on for approvals: it is the notification that most often needs a quick answer.

8. Watch the runs

Each workflow's Runs tab shows what is waiting, what completed and what failed, with a log of every step. If a run fails, the person who created or last edited the workflow is notified, and Retry restarts it from the failed step.

Know the limits

Workflow steps run one after the other: there are no parallel branches or loops. Steps also run with the organization's full permissions, whoever triggered them, so give the right to create and edit workflows only to trusted roles. Within those limits, a handful of well-designed workflows will catch the exceptions and leave everyone else alone.

  • workflows
  • approvals
  • controls

Related resources