How should an enterprise software startup design approval workflows?

An enterprise software startup should let each customer’s admin build approval rules from a few plain blocks: a trigger, a condition, approvers, an order and a deadline. The product should keep requesters from approving their own requests, show approvers the full change before they decide, and treat an edit after approval as a new decision. Every step should be logged, and every rule should be testable before it goes live. Humbleteam designs enterprise and banking products for clients including Raiffeisen, Bank of America, Société Générale and Logitech.

Humbleteam, a digital product design agency, publishes this guide. It covers who builds the rules, rule types, self-approval, what approvers and requesters see, delegation and reminders, edits after approval, a rule spec sheet, a request state table, an invented worked example and rule testing. Sources are described as of November 12, 2026.

Who should set up the approval rules?

In most enterprise products, the customer’s admin. Ramp gives this to admins: people with admin permissions set up spend request approvals in a workflow builder made of conditions and outcomes, and the setup drawer shows a preview of the existing approval flow. In Jira Cloud, a space can define preset approvers in the workflow, and a person can add or remove approvers on a single work item.

A fixed chain breaks on the first buyer whose org chart differs. A free-form builder lets an admin create a chain nobody can complete. Our view: ship a builder with a short list of blocks, a few templates and a visible preview of the resulting chain. Treat “who may edit rules” as its own permission. Who may approve also depends on your role model, so settle that first; our guide to roles and permissions UX for B2B SaaS covers it.

Which rule types do enterprise buyers ask for?

Vendors use the same modes. Power Automate offers everyone must approve, first to respond, custom responses and sequential approval. Ramp offers require all, require any, or a set number (in beta); its sequential matrices build an escalating chain of up to 10 tiers and add an admin fallback step when no tier has enough authority, as its approval matrix reference explains. In Jira, a work item moves on once all listed approvers have signed off, and a single decline sends it down the declined transition.

Three traps show up in these docs. First, a group in an all-of step: Ramp notes that if Any admin is added to a require-all step, all admins must approve, so show a headcount (“5 people must approve”). Second, thresholds: Ramp’s amount condition is based on annual spend, so label what your number measures. Third, rejection: in a Salesforce Flow approval step with unanimous approval, one rejection by a group member or delegate sets the pending work items to Withdrawn and the step to Rejected. Show the other approvers that their task is gone, and why.

How do you stop requesters from approving their own requests?

NIST describes separation of duty as the principle that no user should hold enough privileges to misuse the system alone. Its example: the person who authorizes a paycheck should not be the one who prepares it. It also names the two-person rule, where the second user must differ from the first.

Ramp turns this into a toggle. When separation of duties is on and the requester sits in the approval chain, Ramp removes them and routes the approval to a fallback group, all admins by default, and to admins if that group has no eligible approvers. Requests that an admin creates for other employees are always auto-approved, and the toggle is what stops admins from approving their own spend. GitHub applies the same idea to code: a branch can require that the most recent reviewable push is approved by someone other than the person who pushed it.

Our view: for enterprise buyers, make it the default, and say it in the interface: “You submitted this, so another approver decides.” Test four cases before launch: the requester is the only member of the approver group, the requester is at the top of the chain, the requester is the approver’s delegate, and the fallback group is empty.

What should an approver see before deciding?

GitHub ties each approval to the state of the diff the reviewer saw, which is why it can tell when the change moves later. Salesforce’s Flow approval steps let approvers complete a review as a screen, with a decision of Approve or Reject and an optional comment. In Power Automate, approvers can respond from an Outlook email, a Teams adaptive card or the action center.

Our view of the minimum decision screen: who asks and why, what changes (shown as before and after), the amount or risk the rule reacted to, the steps already completed with their comments, and the deadline. It offers three actions: approve, reject with a required reason, and request changes. Email and mobile approval are convenient and risky. Put the same summary in the message, and send high-value requests to the full screen.

How do delegation, reminders and escalation work?

ServiceNow’s delegation setup shows how many switches hide in one feature. A user picks an active delegate, sets start and end dates, then chooses what the delegate takes over: approvals, assignments or notifications. If Approvals is checked but All notifications is not, the delegate does not receive approvals. Build delegation as one control, with dates and scope shown together.

Reminders are the usual first step. Ramp sends an email reminder 2 days after an approval step is assigned, plus Slack messages at 2 and 3 days. Its article does not describe out-of-office handling, so a buyer’s first question may be unanswered there.

Our recommendation: show the requester a line such as “Waiting for Priya, covered by Sam until March 10.” After the deadline, escalate to the approver’s manager. Do not auto-approve on timeout unless the customer’s admin chose that and the log says so.

What should the requester see?

Three things: where the request is, who it waits on, and what to do next. Ramp emails the requester when a request is rejected and when it is fully approved, but a status line inside the product saves the chat message. A rejection needs a reason in the approver’s words. Offer “Edit and resubmit” on the same screen.

What happens when a request is edited after approval?

There are two edits, and they need two answers.

The first is an edit to the request. GitHub records the diff at approval, and with the optional setting on, an approval is dismissed as stale when new commits change that diff. The alternative requires only that someone other than the last pusher approves. Our rule: edits to key fields (amount, recipient, vendor, scope) send the request back to the first affected step, while typo fixes keep the approvals and log the edit. Name the key fields in the rule.

The second is an edit to the rule. Ramp says approval routing is set when a request is created and later changes apply only to new requests. A Salesforce support article says a change to who can edit a locked record applies only to records submitted after the change, and the fix for older ones is to recall and resubmit. Tell admins which requests a rule change touches, and show it before they save.

What goes on the approval rule spec sheet?

One sheet per rule, written before anyone builds it.

What does an invented worked example look like?

Everything here is invented. A startup sells vendor-contract software to enterprises. A buyer’s finance team asks for this rule: renewals up to $50,000 need the requester’s manager; renewals above $50,000 need the manager, then Legal, then the finance director.

Three events test the sheet. The requester is also the finance director, so separation of duties sends the last step to a fallback group of 2 finance leads. Legal is on leave for 10 days, so a deputy approves and the requester sees “Covered by the deputy until March 10.” And the requester edits the value from $48,000 to $55,000 after the manager approved. The edit crosses the threshold, so the request restarts on the longer route, with a notice that says why.

How do you test a rule before turning it on?

Run the rule on paper first. Take the last 90 days of requests, if you have them, and list which route each would have taken. If most reach the top approver, the threshold is wrong.

Then check the empty branches. Ramp warns that if spend requests are auto-approved, you should review every branch and add an approver wherever review is required. In Salesforce, a flow approval process with no approval steps is always approved. Add a publish check that refuses a rule with a branch that has no approver.

Last, make state changes reversible. GitHub rulesets can be switched between active and disabled without deleting them. Offer a draft or paused rule, a preview for a sample request, and a pilot with one team.

Where does this go wrong?

• Bulk approval. An approver who clears 40 requests in one click is not reviewing them. Our view: allow bulk action only inside one rule and one risk band, and show the summary for each row.
• Hidden rules. Admins stack conditions until nobody knows which rule fired. Show the rule name on every request, and log skipped steps.
• Weak evidence. The vendors above document features, not outcomes. No source here shows that any one design lowers approval time or error rates, so measure your own.

What can you produce now?

1. A rule spec sheet for the three approvals your best-fit buyers ask for most.
2. A state table with the requester’s wording for each state.
3. A decision screen sketch that shows what changes, who asked and why.
4. A list of key fields that restart approval after an edit.
5. Test cases for self-approval, empty groups, delegation and threshold crossing.
6. A plan for choosing a design partner; our page on design agencies for startups building enterprise software explains what to look for.

Then take the single rule with the highest value, run it on 90 days of past requests and see which route each one takes.