Approval matrix design before UI: map rules before screens

Why screens fail without a clear matrix

A clean screen can still hide a messy process. If the approval logic is not defined first, people may see Approve and Reject buttons but still not know who should act, when they should act, or what happens next.

That confusion shows up quickly in real work. Someone submits a request, it lands in the app, and the first question is, "Does this go to the manager, finance, or both?" The screen looks finished, but the decision path is missing.

This happens because screens make rules look simpler than they are. A form can show status, comments, and action buttons, but it cannot guess the real approval matrix behind the process. If the business has amount limits, department rules, or temporary delegates, the UI starts breaking as soon as those cases appear.

It often takes only one exception to push work outside the app. Maybe approvals usually go to a department head, except when the request is urgent, above a certain amount, or the approver is on leave. If that case was never mapped, people fall back to email, chat, or spreadsheets.

Then a bigger problem appears: each team starts applying its own version of the rules. Operations sends the request one way, finance sends it another, and support handles exceptions differently from HR. The app becomes a shared screen for inconsistent decisions instead of a shared process.

The warning signs are usually easy to spot:

• users ask who owns the next step
• similar requests get different outcomes across teams
• exceptions are handled in chat or email
• policy changes force screen changes instead of rule changes

Policy updates expose this weakness fast. When the logic lives inside the screen instead of in clear workflow rules, every threshold change or role change turns into UI rework. That slows teams down, creates new errors, and makes users lose trust.

The screen should reflect the decision path, not define it. When the matrix is clear first, the UI becomes simpler, more stable, and easier to use.

What to map before any wireframe

Start with the decision logic, not the screen. A solid approval matrix begins as a plain table that shows who can approve what, under which conditions, and what happens when someone is unavailable. If that logic is fuzzy, even a polished interface will confuse people.

For each request type, map the approval levels in order. Write down the role that owns each step and what that step allows: approve, reject, review, or send back. Roles work better than personal names because people move, teams change, and the process still needs to hold up.

Then define the rules that change the route. Amount is the obvious trigger, but it is rarely the only one. Approval workflow rules often depend on region, department, vendor type, request category, or risk level. The same amount might be routine in one team and sensitive in another.

Absences need rules too. If the main approver is out, who takes over right away? If the backup is temporary, what dates apply? Without that, requests sit still because nobody knows who owns them this week.

Time limits matter just as much. Decide what happens when a request gets no response. You might send a reminder after one day, escalate after two days, and notify operations after three. Those choices affect status labels, notifications, and queue views, so they should be settled before screen design starts.

A practical matrix usually answers five basic questions:

• What condition starts this rule?
• Which role approves at this stage?
• Who is the backup?
• How long does the approver have to act?
• What happens if the deadline is missed?

If you map those answers early, the rest of the build gets much easier.

How to build the matrix step by step

Use a table, whiteboard, or spreadsheet. Keep it simple enough that a manager, team lead, and process owner can all understand it in one pass.

First, list every request type that needs approval. Do not force everything into one generic flow if the business already treats requests differently. A purchase request, refund, discount approval, and access request often need different approvers, limits, and deadlines.

Next, write the first approver and then each decision point after that. For every request type, note who reviews it first and what happens after approval or rejection. Follow the path until you reach a final outcome such as approved, rejected, sent back for edits, or canceled.

After that, add the thresholds that change the route. This is where many teams get stuck later. If a request under $500 goes to a team lead but anything above $500 goes to a department head, write that now. If urgent requests skip a step or follow a faster path, capture that too.

Then record exceptions, deadlines, and end states. Include cases like missing documents, duplicate requests, policy violations, and overdue approvals. The rule is not finished until you know how it behaves when things go wrong.

Finally, review the draft with the people who approve requests today. Ask where work usually stalls, where people skip steps, and what happens when the normal approver is unavailable. Real habits often reveal rules that were never documented.

A small example makes this clear. Imagine a purchase request: office supplies under $200 go to the team lead, software between $200 and $2,000 goes to the department manager, and anything above that also needs finance. If the form does not capture amount and category early, the UI cannot send the request down the right path.

Set thresholds people can actually follow

Thresholds only work when people can read them quickly and make the same choice every time. If a rule says "small purchases" or "high-risk vendors," different people will interpret it differently. Use fixed numbers, dates, and named conditions instead.

A clearer rule sounds like this: "Up to $1,000 goes to the team lead. $1,001 to $5,000 goes to the department manager. Over $5,000 goes to finance and the director." Nobody has to guess where the request belongs.

Amount is common, but it should not be the only trigger if your process depends on other factors. A low-cost software purchase from a new vendor may need more review than a larger order from an approved supplier.

Most teams only need a small set of routing rules. Common examples include amount range, vendor status, purchase category, department, and urgency. The important part is not the number of rules. It is whether everyone applies them the same way.

The order of rules matters too. If people do not know which condition wins, they will route the same request differently. Pick one order and keep it consistent. You might check vendor status first, then category, then amount. Or you might check amount first and handle exceptions after. Either approach works if everyone follows the same sequence.

It also helps to define who can override a threshold, and when. Without that, staff either wait too long or bypass the process in email and chat. "Finance director may approve above-limit requests during month-end close" is useful. "Senior leadership can make exceptions" is not.

A simple test works well here: give the same example request to three people and ask where it should go. If they give three different answers, the thresholds are still too vague.

Plan fallback approvers, substitutes, and escalations

A strong matrix does not stop at the main approver. Real work keeps moving when someone is on leave, out sick, or simply does not respond on time. If you do not plan for that early, the screen may look neat while the process quietly stalls.

Start by naming the fallback approver for each important step. This should be a person or role with the right context, not just "the next manager" by default. If a finance lead approves expenses above a certain amount, decide who steps in when that person is unavailable.

Temporary substitutes need limits. A substitute should get approval rights only for a defined period, such as vacation dates or planned leave. That keeps responsibility clear and avoids cases where someone keeps approval access long after they should not.

A simple setup should answer four things: who is the main approver, who is the backup, how long the substitute can act, and when the request moves up the chain.

Escalations should be based on clear triggers, not guesswork. Common triggers include time, amount, risk, or missing information. For example, if a purchase request above $10,000 sits untouched for 24 hours, it might escalate to the department head.

Keep the escalation path short. If people need a complex diagram just to understand who gets the request next, the rule is probably too complicated. One or two clear jumps are usually enough.

Record each decision as well. Save who approved, who substituted, when the handoff happened, and why the request escalated. That history matters when someone later asks why a request was delayed or approved by a backup.

One more rule matters more than it seems: avoid loops. A request should never bounce back to someone who already approved it, or to a substitute acting for that same person. Check the matrix for circular paths before you build any app logic.

A simple example: purchase request approval

Picture a small company buying everyday items. An employee submits one purchase request with the item, amount, reason, and needed-by date. Routing is driven by the rules, not by whoever happens to be online.

If the request is for $420, it goes straight to the team lead. That keeps small purchases moving. A $3,200 request skips the team lead and goes to the department manager because the budget impact is higher.

Now take a $7,800 request for new equipment. The department manager still reviews it, but that is not enough on its own. Because the amount is above $5,000, finance must also review it. That is where a clear matrix helps: higher amounts add control without adding guesswork.

Absences matter here too. If the department manager is on leave, the request should not sit in limbo. A named substitute receives it automatically and can act for that defined period.

Time limits need the same level of clarity. If no one acts within two days, the request escalates to operations. Operations can follow up, reassign it, or make sure it does not block work.

In this example, the matrix answers a few simple but important questions: how much is being requested, which role approves at each amount, when finance is added, who covers absences, and what happens when a deadline is missed.

Once those answers are defined, screen design becomes straightforward. The form only needs the right data, and the request page only needs to show the current approver, any substitute, and whether the escalation clock is running.

Common mistakes that cause rework

Most rework starts before a single screen is drawn. Teams guess the approval path, then try to make the UI fit rules that were never actually agreed.

One common mistake is copying the org chart and calling it a workflow. That may look tidy, but real requests usually move by amount, risk, location, or request type. If the matrix ignores that, the screens will later need extra fields, extra states, and awkward exceptions.

Another problem is forgetting special cases. Urgent requests, regulated purchases, or cross-team requests often need a different route. If those exceptions are not mapped early, people start asking for manual workarounds, and the interface fills up with one-off options that confuse everyone.

Teams also create trouble when they give two people the same job with no tie-break rule. If both can approve, who acts first? If they disagree, whose decision stands? Without that answer, requests bounce around and users lose trust.

Substitute rules are another weak spot. A substitute should cover an absence, not quietly become a second owner forever. When temporary coverage and permanent ownership get mixed together, reports become messy and accountability disappears.

Designing forms before routing is settled creates another round of rework. A form may look complete, but once the approval rules are finalized, you often discover missing fields such as amount band, department, urgency, or policy flag. Then the layout, validation, and notifications all need to change.

A quick reality check helps catch this early:

• Can two approvers receive the same request at the same time?
• Is there a clear difference between temporary backup and permanent ownership?
• Do urgent or regulated cases follow a different route?
• Does each routing decision depend on a field that already exists?
• Would the process still make sense if one approver left the company?

If any answer is unclear, stop there. Fix the matrix before polishing the screens.

Quick checks before you design the screens

Before you sketch a form or status badge, test the logic in plain language. A good approval matrix should be easy to explain without opening a diagram. If a manager, finance lead, or operations teammate cannot describe the route in about a minute, the process is still too vague for UI work.

Run a fast review using real examples. Ask one person to explain the full route from request to final decision. Check that every likely outcome has a named next approver, not just the happy path. Rewrite vague thresholds as exact rules such as "$1,000 and under" or "more than 10% discount." Confirm that fallback and escalation rules use clear time limits like "after 24 hours" or "after 2 business days."

Then test traceability. Later, someone will ask why a request was delayed, who approved an exception, or when a substitute stepped in. Your process should already answer those questions. Timestamps, decision history, and clear status changes are not extras. They are part of the rule set.

A simple scenario usually exposes weak spots. Imagine a $4,800 purchase request arriving on Friday afternoon while the usual approver is out. Who gets it next? How long does the system wait before it moves? What happens if the backup also does nothing? If those answers are not written down, the UI will hide confusion instead of solving it.

When these checks pass, screen design gets much easier. You are no longer guessing what the interface should show. You are giving clear rules a clear shape.

Next steps: turn the matrix into a working app

Once the rules are clear, build the process before you polish the screens. Start with the logic, the data fields, and the approval states. If the routing works, the interface becomes much easier to design. If the routing is still changing, attractive screens only hide the problems.

A practical first version usually includes the basics: request type, amount, department, current approver, final status, and a clear history of each decision. Then add the rules that move a request forward, send it to a fallback approver, or trigger an escalation when someone does not respond on time.

Keep the first screens simple. A requester should be able to submit, check status, and respond to follow-up questions. An approver should be able to review, approve, reject, or reassign. That is enough to test whether the workflow makes sense in daily use.

A sensible build order is straightforward:

• define the core data fields and status values
• add routing rules for thresholds, fallback approvers, substitutes, and escalations
• create basic screens for requesters and approvers
• make sure every channel uses the same source of truth
• test one real request from start to finish before rolling it out wider

That shared source of truth matters more than many teams expect. If mobile shows one status, the web panel shows another, and the backend follows different thresholds, trust disappears quickly.

If you're building this in AppMaster, a clear matrix makes the setup much easier. You can model the data, business logic, and approval flow first, then carry the same process across backend, web, and mobile without rewriting the rules in separate tools.

Use one real case for the first test. Run an actual purchase request with a threshold, a substitute approver, and an overdue escalation. Watch where people hesitate, what data they miss, and which status labels confuse them.

Improve the wording and layout after that. When the process works with a real request, the screens are easier to design and much less likely to be rebuilt a week later.