Threshold-based routing for flexible approval rules

Why hard-coded approval rules break down

Hard-coded approval rules seem fine at the start. A developer adds a few conditions, the workflow runs, and the team moves on.

The problem shows up when the business changes. Finance raises a spending limit, one region gets a different policy, or a department needs an extra approver for certain requests. What looked like a small update now means changing app logic, testing it, and waiting for a release.

That delay is costly. A policy update that should take minutes can take days when it depends on technical work. During that gap, employees follow old rules, approvals stall, and managers start handling exceptions in email or chat.

Hidden exceptions make things worse. Over time, teams add one-off rules such as "if amount is over 5,000 and department is Sales, send it to Director A" or "if the request comes from Europe, skip this step." When those rules live deep in the workflow, only a few people can see them.

Then simple questions become hard to answer:

• Who approves purchases over a certain amount?
• Does Marketing follow the same policy as Operations?
• What happens in another region?
• Which exception was added last quarter?

When nobody can see the full rule set, mistakes follow. Someone thinks they are following policy, but the app is still using an old rule. A new manager gets requests they should never see, while the real approver is left out.

That is why threshold-based routing works better when approval policies change often. Instead of treating rules as fixed parts of the app, you store them as business data that can be reviewed and updated.

Picture a simple expense policy. Requests under 1,000 go to a team lead, requests from 1,000 to 10,000 go to a department head, and anything above that goes to finance. If those limits change next month, the business should not need a developer just to keep approvals moving.

Hard-coding turns ordinary policy updates into software projects. That is the real cost.

What threshold-based routing means

Threshold-based routing means the approval path changes based on values you define in advance. A threshold is simply a boundary, such as an amount over $1,000, a request from the Finance department, or a purchase made in Europe.

Instead of writing those rules directly into the app, you store them in tables. The workflow reads the table, finds the matching rule, and sends the request to the right person.

A basic setup might look like this:

• Requests under $500 go to a team lead.
• Requests from $500 to $5,000 go to a department manager.
• Requests above $5,000 go to a director.
• HR requests follow one path, while IT requests follow another.
• North America and EMEA can have different approvers.

The process stays the same, but the values that control it can change.

Keep logic separate from policy

This is the key idea. Logic is the part that says, "check the rules and pick the first match." Policy data is the list of rules itself: amount ranges, departments, regions, approvers, and priority.

When logic and policy are mixed together, even a small change may need a developer to edit the workflow. When they are separated, the workflow stays stable and only the rule rows change.

For example, if Sales in APAC now needs director approval above $3,000 instead of $5,000, you update one table entry. You do not rebuild the whole approval process.

This is easier to manage because policy changes more often than process structure. Teams reorganize, budgets shift, and regions get new owners. A table handles that better than hard-coded conditions.

In a no-code platform like AppMaster, that usually means creating a rules table and letting the business process check it at runtime. The model is easy for non-technical teams to understand because it matches how policy is written in real life: if this condition matches, send it here.

What belongs in your rules table

A good rules table should answer one simple question: when a request matches these conditions, who needs to approve it?

If routing depends on values hidden in code, every policy update turns into a rebuild. A table keeps those changes visible and easier to manage.

A practical rules table usually starts with the fields that describe the request:

• amount
• currency
• department
• region
• request type
• approver role

Amount and currency matter because the same number can mean different things across budgets or countries. A request for 5,000 USD may follow one path, while 5,000 EUR or 500,000 JPY may need another.

Department and region reflect how companies really work. Finance, HR, and Operations often have different approval paths even for the same spend. Region matters too when local rules or managers differ.

Request type is another useful filter. Travel, software purchases, vendor payments, and discount approvals may need different reviewers. Without that field, unrelated requests can end up using the same rule.

For the approver, store a role instead of a person’s name. Use values such as Department Manager, Regional Director, or Finance Controller. When someone changes jobs, you update the role assignment once instead of editing every rule.

It also helps to add start and end dates. That covers policies that begin on a certain day, temporary rules during budget season, or planned changes for next quarter. You keep history without leaving expired rules active.

A priority field is also worth adding. A rule for "EU + Finance + over 10,000" should usually win over a broader rule like "all departments + over 10,000." Clear priority keeps routing predictable.

How to structure the table

Keep the structure simple: one row should equal one approval rule.

If marketing expenses above $2,000 in Europe need a regional manager, that should live in one record. When each row has one clear meaning, the setup is easier to update, test, and audit.

The main table should focus on two things only: the conditions that trigger a rule and the outcome that tells the workflow what to do next. That keeps it readable for both business users and the person building the process.

A practical layout

A clean table often includes these fields:

• rule ID or rule name
• active status, plus optional start and end dates
• condition fields such as minimum amount, maximum amount, department, region, and request type
• outcome fields such as approver role, approver user, or next step
• priority and a default-rule flag

For condition columns, use exact fields instead of free text when possible. A department ID is safer than typing "Finance" by hand every time. The same goes for region codes, request types, and cost centers. Small lookup tables for departments, regions, and approver roles help avoid spelling mistakes and make filtering easier.

For outcome columns, decide what the workflow should return. In some teams, the rule should point to a specific person. In others, it should route to a role such as Regional Manager or Finance Director. Pick one approach and stay consistent.

Priority matters because more than one rule can match the same request. Do not rely on row order or creation date. Add a numeric priority field and define how it works, such as 1 checked first and 100 checked later.

You also need a fallback rule. This is the safety net for anything not covered by a specific row. A default rule might send unmatched requests to an operations manager or an admin review queue. Without it, requests can get stuck with no route at all.

If you build this in AppMaster, these tables can be edited visually, so policy changes happen in data rather than hard-coded workflow branches.

How to set it up

Start with the decision, not the table. Write down the exact questions your workflow needs to answer. Does a purchase over $5,000 need a manager? Does Finance review anything from Sales? Do requests from one region follow a different path?

Once those choices are clear, threshold-based routing becomes much easier because you are storing policy instead of trying to guess the logic later.

A simple setup usually follows five steps.

First, create an approval rules table with the fields that affect routing. Common columns include amount_min, amount_max, department, region, approver_role, priority, and active_status.

Second, decide which fields can be left blank. A blank department or region can mean "this rule applies to all" when no more specific match exists.

Third, add rules from most specific to most general. A rule for "Sales + Europe + over $10,000" should be checked before a broad rule like "any department + any region + over $10,000."

Fourth, test with real examples before launch. Use edge cases such as exactly $5,000, missing department data, or a region with no custom rule.

Fifth, limit who can edit the table. Policy changes should be easy, but they should not be open to everyone.

Here is a simple example. A request for $12,000 from HR in North America may first match a rule for "HR over $10,000," which sends it to the HR director. If no HR-specific rule exists, the system can fall back to a wider rule such as "any department over $10,000," which sends it to finance.

The order matters more than many teams expect. If broad rules sit above specific ones, the wrong person gets the request and people stop trusting the system.

Before going live, assign one owner for rule changes, keep a short policy document, and test again after each update. Small routing changes can have big effects.

A simple example in practice

Imagine a company that uses one purchase request form for every team. Each request includes an amount, a department, and a region. The system checks those values against a rules table and picks the right approver.

Say the company has two departments, Marketing and IT. Both can submit a request for $4,000, but the approval path does not have to be the same.

Now compare two requests with the same amount. A Marketing request for $4,000 in the US goes to the Marketing Manager. An IT request for $4,000 in the US skips the IT Manager and goes to the CTO, because IT has a lower threshold.

Region can change the outcome too. A $2,500 Marketing request in the US goes to the Marketing Manager, but the same request in the EU goes to the Regional Marketing Lead. The form stays the same. Only the matching rule changes.

That is the real value of a rules table. Policy lives in data, not inside workflow logic.

If the company updates its policy next month, you do not need to rebuild the whole process. If IT decides that requests above $2,000 should now go to the CTO, you only edit one row:

• Old rule: IT, US, $3,001+, CTO
• New rule: IT, US, $2,001+, CTO

Everything else keeps working. New requests follow the new policy right away while the app structure stays untouched.

Common mistakes to avoid

The hardest part of threshold-based routing is usually not the core idea. It is the messy edge cases that appear later, when policy changes and nobody remembers why a request went to the wrong person.

One common mistake is overlapping rules without a clear priority. You might have one rule that sends all Marketing requests over $3,000 to the department head and another that sends any request over $5,000 to Finance. A $6,000 Marketing request matches both, so the system needs a clear winner. Put that priority in the rules table, not in hidden workflow logic.

Another mistake is hard-coding people instead of roles or groups. Names change. Teams change. Someone goes on leave or moves to a new department. If a rule says "send to Maria Lopez," you will be editing it every time staffing changes. It is safer to route to a role such as Regional Finance Manager or Sales Director, then map that role to the current person.

Skipping a fallback path causes quiet failures. Sooner or later, a request will not match any rule because the amount is unusual, the department is new, or a field is blank. When that happens, the workflow should still do something safe, such as sending the item to a default queue or admin team.

Regional exceptions are another weak spot. A policy that works in one country may not work in another because of local spending limits, tax rules, or reporting needs. If you only test one region, you may miss cases where EU, US, or APAC requests should follow different paths.

Time-based rules also get forgotten. If you create a temporary rule for quarter-end, a budget freeze, or a special project, make sure it has start and end dates. Expired rules should stop applying automatically. Otherwise, old exceptions stay active and send requests down the wrong path.

Final checks before launch

Before you turn on threshold-based routing, review it from a real user’s point of view. Every request should move to the right approver without anyone guessing why.

Keep the final review simple.

Check that each normal request has one clear match. If two rules can apply at the same time, users will get inconsistent results.

Make sure there is a fallback path. Missing departments, new regions, or unusual amounts should still go somewhere safe.

Confirm that policy updates can happen without a developer. If Finance or Operations needs to change limits, dates, or approvers, they should be able to edit records in a table rather than request a code change.

Test dates, not just values. Yesterday’s policy and next month’s policy should both behave as expected when effective dates are in play.

Write the routing logic on one page in plain language. If a manager cannot explain it clearly, it is probably too complex.

A useful final test is to create five sample requests that cover normal cases, edge cases, and outdated-policy cases. If your team can predict the result before running them, the setup is likely ready. If they cannot, simplify it.

Next steps

Start small. Pick one approval flow that causes the most delay or confusion today, such as purchase requests over a set amount or expense claims by department. Build that first, test it with real cases, and then add more rule types.

That approach makes the routing model easier to trust. People can see how the rules work, where exceptions appear, and what needs to change before the setup grows.

The first rollout should answer four basic questions:

• Which request type should be automated first?
• Which fields control routing, such as amount, department, or region?
• Who approves each case today?
• Who will update the rules when policy changes?

That last point matters a lot. If no one clearly owns policy updates, the workflow slowly drifts away from how the business actually works. Assign one person or a small team to review rule changes, approve edits, and keep a short record of why a policy changed.

It also helps to set a review schedule. If policies change often, review the rules monthly. If the process is stable, quarterly may be enough. A short review can catch outdated thresholds, missing departments, or regional exceptions before they cause delays.

Keep the review practical. Ask simple questions: are approvals going to the right people, have any teams changed structure, do current limits still match finance policy, and are there too many manual overrides?

If you want to build this visually, AppMaster can be a good fit for creating the rules table, the routing process, and the admin screens where non-technical staff update policies. Since it is designed for full no-code applications, it works well when you want business teams to manage approval changes directly instead of sending every update back to developers.

Once one flow is working well, reuse the same pattern in the next process. Small, clear steps usually work better than a full rebuild.