Approval workflows are one of the most common automation targets for ops teams, and also one of the most frequently under-designed. The basic case — someone submits a request, an approver reviews it, and a notification goes out either way — is straightforward enough that most teams can build it quickly. The problem is that most real approval processes are not the basic case. They have multiple approval levels. They have exception paths. They have SLA requirements. They have situations where the designated approver is unavailable and the process needs to continue. Designing for these cases upfront, rather than discovering them after go-live, is what separates approval workflows that stay in production from ones that get abandoned within a month.
This article covers the structural patterns we have seen work consistently across purchase approvals, budget exceptions, vendor onboarding, and HR leave requests. None of this requires code. The patterns translate directly into TASKBASE node configurations.
Pattern 1: The tiered threshold chain
The most common approval structure in Japanese mid-size companies is tiered by amount or organizational level. A purchase request under ¥100,000 needs manager approval. Between ¥100,000 and ¥1,000,000, it needs manager plus department head. Above ¥1,000,000, it routes to the CFO or equivalent. This is a threshold-based branch pattern.
In TASKBASE, this is implemented with a Branch node immediately after the trigger. The branch evaluates the request amount against the thresholds and routes to one of three parallel approval paths. Each path has its own Human Gate node configured with the appropriate approver role. The paths converge at a merge node that continues the workflow once the required approvals are collected.
A subtlety worth designing for upfront: what happens if a request starts in the lower tier but gets revised upward? Build a re-evaluation loop into the workflow. After each approval gate, a condition check re-evaluates the current amount against the tier thresholds. If the amount has changed (some workflows allow revisions before the final sign-off), the workflow routes back to the appropriate tier rather than continuing on the original path. This avoids the situation where a request that started small but grew during negotiation slips through with only the lower tier of approval.
Pattern 2: The parallel approval path
Some approvals require sign-off from multiple parties who are independent of each other — the department head and the legal team, or the budget owner and the IT security team. These are parallel, not sequential: both reviews happen simultaneously, and the workflow proceeds only when all parties have approved.
TASKBASE handles this with a split node that creates parallel branches, each with its own Human Gate, converging at an AND-join node that waits for all branches to complete before proceeding. The key configuration decision is how to handle the case where one party approves and the other rejects: does the workflow terminate immediately on the first rejection, or does it wait for all parties to respond before surfacing the result? Both patterns are valid; the right choice depends on whether partial approvals carry any interim meaning in your process.
For processes involving legal review specifically, it is often worth adding a data-passing step between the legal gate and the subsequent node: the legal reviewer's comments and conditions should flow forward as structured fields, not just a binary approved/rejected status. That way, downstream nodes (and the submitter) can see what conditions were attached to the approval, not just the final outcome.
Pattern 3: Escalation with SLA timers
Approval workflows fail operationally when approvers go silent. A request sits at a Human Gate for three days without a response, the submitter has no visibility into why, and the process stalls. SLA-based escalation is the structural fix.
In TASKBASE, a Human Gate node can be configured with a response deadline. If the approver has not acted within the defined window — say, 24 hours for a standard purchase request — the workflow triggers an escalation path. The escalation path typically does one of two things: sends a reminder to the original approver with increasing urgency, or reroutes the approval to a designated backup approver (the deputy, the manager's manager, or a shared ops team inbox).
When designing escalation, specify the escalation chain at configuration time, not at runtime. The backup approver should be a named role or a specific person, not an open field that the submitter fills in. This prevents the situation where every escalation becomes a negotiation about who should be responsible.
A practical note on SLA windows: set them based on your actual process data, not on aspirational targets. If your current average approval time is 36 hours, setting a 24-hour SLA timer will generate a lot of escalations in the first weeks, most of which will be false positives. Start with a timer that reflects the 80th percentile of your current approval times, then tighten it as the workflow establishes new norms.
Pattern 4: Exception paths and conditional overrides
Every approval process has exceptions — cases that do not fit the standard flow and need different handling. Emergency purchases that need same-day approval outside the normal chain. Requests from certain vendor categories that require compliance pre-screening before operations sees them. Requests above a certain sensitivity threshold that require a confidentiality gate before routing to approvers.
The mistake is to try to handle exceptions within the main flow by adding more branches. This makes the main workflow harder to read and maintain. A better pattern is to evaluate exception flags at the very start of the workflow — immediately after the trigger node — and route genuine exceptions to a separate, explicitly designed exception flow. The main flow stays clean. The exception flow handles its specific logic. Both are visible in the canvas, but they are structurally distinct.
We are not saying that every exception needs its own full workflow. For minor exceptions, a Human Gate with an "override required" flag and a free-text comment field is often enough. The key is that the exception case is handled explicitly, with a logged decision and a clear audit trail, rather than falling through the cracks of the main flow or getting resolved by someone editing the spreadsheet directly.
Pattern 5: The approval-to-action chain
The approval workflow does not end when the final approver clicks "approve." The downstream actions — updating a record in kintone, sending a confirmation notification in Slack, creating a PO in the finance system — are part of the workflow too. Approvals that end at "notification sent to submitter" and require the submitter to then manually execute the next step have broken the automation at the critical handoff point.
In TASKBASE, the downstream action nodes sit after the final approval gate. The workflow handles the record update, the notification, the file creation — whatever your process requires — as subsequent nodes. The approver's decision flows forward as a data field (approved/rejected, plus any comments they added), and the action nodes act on that data deterministically.
This also means the audit log captures the full chain: who submitted, who approved at each stage, when, with what comments, and what downstream actions were taken as a result. For finance and HR processes where this audit trail has regulatory significance, the run log is a complete record without any additional documentation effort.
Designing for maintainability
Approval workflows need to change. Thresholds shift when the company grows. Approvers change roles. New exception categories emerge. The ops team that built the workflow needs to be able to update it without rewriting it from scratch.
The structural practices that make TASKBASE workflows maintainable over time: keep each branch clean and self-contained; use descriptive node labels (not "Branch 1" but "Route by amount threshold"); put threshold values in workflow-level variables rather than hard-coded into branch conditions; and document exception paths with a brief comment in the node description field. These habits take an extra two minutes at build time and save hours when the CFO calls on a Friday afternoon to say the approval threshold has changed.
