Exception path design: plan rejections before approvals

Why the happy path is not enough

Most teams start with the clean version of a workflow. A request comes in, someone reviews it, and it gets approved. It feels efficient, but it hides where the real work happens.

The happy path is usually the shortest path. The form is complete, the attachments are there, and the reviewer knows exactly what to do. In real operations, that is rarely the part that causes delays.

Delays start when something is missing, unclear, late, or only partly acceptable. A manager may approve the budget but reject one line item. Finance may need a tax document that was never uploaded. A support lead may send a request back because the reason field is too vague. Each of those moments creates extra steps, extra messages, and extra waiting.

If those situations are not planned early, people make decisions on the fly. One reviewer sends an email. Another leaves a comment in the tool. A third rejects the request with no explanation. The requester is left guessing: should they fix the issue, start over, or ask someone for help?

That confusion has a cost. It slows the person who submitted the request, the person reviewing it, and anyone pulled in to explain what happened. A workflow that looked simple on a whiteboard turns into follow-up chats, duplicate submissions, and manual handoffs.

A basic approval flow is easy to sketch:

• submit request
• review request
• approve request

The real version is harder. What if a document is missing? What if only part of the request is approved? What if the reviewer rejects it but the user can fix it? These are not unusual cases. For many teams, they are the normal cases.

That is why exception path design deserves attention before screens are drawn and statuses are named. The exception path defines what happens when reality interrupts the plan, and reality does that often.

If you are building an internal approval app, including one in a no-code platform like AppMaster, the rejected and incomplete cases need as much care as the approved case. They shape the messages people see, the actions they can take next, and whether the workflow helps people recover or leaves them stuck.

A happy path shows intent. Exception paths show whether the process can survive real use.

What an exception path looks like

An exception path is what happens when a request cannot move forward in the normal way. It is not a rare edge case. It is the part of the process that handles real-world mess: a request is denied, a form is incomplete, one part is approved but another is not, or the work simply gets stuck.

A clear exception path uses plain language. Instead of a vague status like "Failed," say what happened: "Rejected because the budget is over the limit" or "Waiting for ID document." People should know what is wrong, who needs to act, and what happens next.

Most workflows break in a few predictable ways:

• the request is rejected for a clear reason
• a required document or field is missing
• only part of the request is approved
• the request has no owner or no defined next step

Missing information is one of the most common problems. Imagine a supplier onboarding form that needs a tax document and a bank account number. If either one is missing, the system should not just stop. It should mark the request as incomplete, show exactly what is missing, and send it back to the right person.

Partial approvals are just as important. Think about a travel request for a flight, hotel, and meal budget. The manager approves the flight and hotel but cuts the meal budget. The process now needs rules. Does the employee accept the change, update the request, or cancel the trip?

Stalls matter too. A request can sit untouched because the assigned reviewer left the company, the team never set a backup approver, or the process reaches a step with no next owner. Nothing is technically broken, but the request still cannot move.

If you do not design these paths early, people handle them by email, chat, or spreadsheet notes. Soon nobody knows which version is final.

A simple approval example

Take a travel request for a sales manager who wants to attend a two-day conference. On paper, the flow looks easy: the employee enters the trip dates, estimated cost, and reason for travel. The manager approves it, finance confirms the budget, and the trip moves to booking.

That flow is clean, but it is also incomplete.

Now break the same request. The employee uploads the flight estimate and conference ticket but forgets the hotel quote. If the system only knows "submitted" and "approved," people get stuck fast. Finance may see an incomplete request, the manager may think it is ready, and the employee may not know what is missing.

A better flow gives that request its own state, such as "Waiting for document" or "Needs update." The employee should see a clear message: "Add hotel quote before this request can move to finance." The manager should not have to reject the whole trip just to ask for one file.

Now add a second problem. The manager agrees that the employee should travel, but not at the full amount. They approve the flight and one hotel night, but reject the extra workshop fee and the second hotel night.

This is where many teams discover they do not really have a partial approval process.

If the workflow cannot approve only part of the request, people start using workarounds. They may reject the whole request and ask the employee to submit it again. Or finance may approve the full amount by mistake because the system stores only one yes-or-no decision.

A clearer model tracks each cost item, or at least the approved total. A request might show:

• Flight: approved
• Hotel: approved for 1 night
• Workshop add-on: not approved
• Total requested: $1,450
• Total approved: $980

That single example shows why approval workflow errors often come from missing rules, not careless people. If you define those rules before you design the screens, the rest of the workflow becomes much easier to trust.

Design exceptions before screens

A good way to improve a workflow is to assume the request will not go through cleanly. That one shift changes the quality of the design fast.

Start with the messy cases: the form is incomplete, the policy is unclear, the approver is absent, or only part of the request should move forward. Most teams can group these into three main patterns:

• rejection
• missing information
• partial approval

That keeps the work manageable. Instead of inventing a new answer for every edge case, you define a small set of patterns and apply them to each request type.

Work in this order.

First, list every point where the request can stop. Think about missing documents, invalid values, policy violations, expired deadlines, duplicate submissions, and manual review. If the request can wait, fail, or return to the sender, write it down.

Next, decide what happens in each case. For every exception, answer four simple questions:

• who is notified
• what status the request shows
• what the user must do next
• when the request moves again

For example, imagine an employee submits a travel expense claim for $600. The hotel receipt is missing, and one meal is above policy. If you only design the happy path, the request either gets stuck or gets rejected as one big block. If you design exceptions first, the system can pause the claim for the missing receipt, notify the employee with a clear message, and still mark the allowed items as conditionally approved.

That is where partial approval rules matter. You need to decide whether the approved amount can move forward now, whether the rest stays on hold, and whether the requester can edit only the disputed part or must resubmit the full claim.

If you are building the process in AppMaster, this is the point to map those branches in the business logic before you polish the UI. It is much easier to trust a workflow when reject, return-for-edits, and approve-with-conditions are treated as separate paths instead of being hidden behind one vague status.

Finally, test one real scenario from start to finish. Use actual numbers, one real document gap, and one policy exception. If a person reading the flow cannot tell what happens next in under a minute, the design is still too vague.

Set the rules before the interface

Screens feel concrete, so teams often start there. They sketch buttons, forms, and dashboards before they agree on the rules. That usually creates problems later, because the interface ends up hiding decisions nobody actually made.

A better order is simple: define the states, handoffs, deadlines, and proof required to move forward. Then build the screens around that.

Exception path design gets much easier when the rule set is small and clear. If a request can be approved, rejected, sent back for fixes, or partly approved, those states need plain names that mean one thing only. Avoid near-duplicates like "returned," "reopened," and "needs changes" unless they truly behave differently.

Take a purchase request. A manager opens it and notices the quote is missing. If the team has not decided what happens next, people improvise. One manager rejects it. Another leaves it pending. A third sends a chat message and changes nothing in the system. Soon nobody trusts the status.

Write the rule first. When a quote is missing, the request moves to "Needs documents." The requester owns the next step. The request stays there for five business days. If nothing arrives, it changes to "Expired" and a new submission is required.

That one rule shapes the product better than a mockup can. Now you know what the user should see, what reminder to send, and what history to keep.

A practical rule set should answer four questions:

• What are the few status names everyone will use every day?
• Who acts next in each status?
• How long can the item stay there before it escalates, expires, or closes?
• What fields, files, or checks are required before it can move?

Partial approvals need the same level of care. If travel is approved but hotel cost is not, does the requester edit the same record or create a new one? Does finance review only the changed part, or everything again? If that is not decided early, the screen may look tidy while the process behind it stays messy.

When teams settle the rules first, the interface becomes simpler. More important, users know exactly what to do next, even when the answer is "not approved yet."

Write messages people can act on

A bad exception message slows everything down. People do not just need to know that something failed. They need to know what happened, what it affects, and what to do next.

This is where the design becomes real for users. Your internal rules may be clear, but if the screen only says "Error" or "Pending review," people will guess, resend the wrong files, or ask support for help.

Take a vendor approval example. A user submits a form with a tax document, bank details, and insurance proof. The bank details are fine, the tax document is outdated, and the insurance proof is missing. If the system only shows "Request not approved," the user has no clear next step.

A better message sounds like this: "Your bank details were approved. We still need an updated tax document and insurance proof before final approval." That one sentence saves time because it separates what is done from what still needs work.

Good messages usually answer four small questions:

• What part was rejected, missing, or still under review?
• What part was already accepted?
• What does the person need to upload, change, or confirm?
• What happens after they resubmit?

That last part matters. People are more likely to finish the task when the next step is obvious. "Upload the missing file and resubmit for review" is much better than "Action required."

Vague labels also create anxiety. "Pending review" can mean waiting for a person, missing data, or an internal check. If you know the reason, say it plainly. "Waiting for manager approval" and "Waiting for proof of address" are not the same situation, and they should not look the same.

If a process allows partial approval, show it clearly in the status itself. A short breakdown often works better than one label:

• Approved: identity document
• Needs update: tax form
• Missing: insurance certificate

Now the user can fix only what matters. They do not need to start over.

This is also where resubmission should be easy to find. Put the next action near the message, not on another screen. If you are building the flow in AppMaster, it helps to match the user-facing status text to the actual business process states so the app says exactly what the workflow is doing.

Good messages reduce support tickets, speed up approvals, and make the process feel fair. People can accept a rejection when they understand it.

Mistakes that create rework

Most rework starts with one wrong assumption: the normal path is the main thing to design. Teams map request submitted, approved, completed, and stop there. Then real life shows up: a file is missing, a manager wants changes, or only part of the request can move forward.

That gap creates extra work fast. People invent manual fixes, send side messages, and rename statuses on the fly. A few weeks later, nobody trusts the workflow because every exception feels like a special case.

One common mistake is treating the ideal path as the product and everything else as cleanup. Imagine an expense request that needs a receipt, department approval, and finance review. If the receipt is missing, does the request pause, return to the employee, or get rejected? If that rule is not clear from the start, the team usually patches it later with emails and comments.

Confusing status names cause another round of rework. Labels like "In review 2" or "Pending action" sound harmless, but they force people to guess what happens next. Clear names reduce mistakes because they show either the problem, the owner, the outcome, or the next step.

Ownership is another place where workflows break. A request should never sit in a status that belongs to no one. If a case is waiting, someone must be responsible for moving it forward, asking for more information, or closing it. Otherwise, silent delays pile up and users assume the system lost their request.

Partial approval is often handled badly too. Teams treat it like a full rejection because it feels simpler. But those outcomes mean different things. If a travel request asks for flight, hotel, and meals, finance might approve the flight and hotel but deny meals. That case needs its own path, its own message, and often its own follow-up action.

When partial approval gets lumped in with rejection, people resubmit the whole request, duplicate documents, and restart reviews that were already done. That is pure rework.

A simple test helps: read each non-happy-path status and ask, "Who owns this, what does the user see, and what happens next?" If the answer is fuzzy, the process will probably break in the same spot later.

Quick checks before you build

Before you build screens or automate anything, do one last pass on the messy cases. Good exception path design is often just a few clear decisions made early, before confusion turns into rework.

If a request is rejected, paused, or only partly approved, someone should always know what happens next, who does it, and what information is still missing.

Use this quick check on each exception in your process:

• Every exception has an owner.
• Every status leads to one clear next step.
• Missing items are named in plain language.
• Partial approvals have rules, not guesses.
• Timing is clear.

Then run one simple test. Hand the process to someone who did not help design it. Give them a rejected request and a request with one missing document. If they cannot tell what to do in under a minute, the process is still too vague.

A small example makes the point. Imagine a manager approves a software request but rejects the hardware part. If the status only says "Partially approved," the employee may assume everything can move forward. A better status says exactly what was approved, what was denied, and whether the employee can resubmit the missing part.

If you want to turn those rules into a working internal app, map the exception states first and build the happy path second. In AppMaster, that can mean defining statuses, business rules, and required fields before worrying about polished screens. It is a practical way to build no-code applications that handle real work, not just the ideal version of it.

The next step is simple: list your top five exceptions, assign an owner to each one, and write the message the user should see. If those three parts are clear, the build usually gets much easier.