Approvals That Don't Break When Staff Leave: Route by Role, Not by Name

It is early April at a precision parts maker in Shizuoka, about 280 staff, supplying automotive OEMs. The annual personnel reshuffle has just been announced. Three section managers moved departments. One department head retired. A new general manager arrived from the Tokyo sales office. By 10 a.m. the IT team already has a queue of tickets. Half the approval routes in the workflow system now point at people who are either in the wrong seat or no longer with the company. A purchase request for tooling sits untouched because it is routed to a manager who left for a competitor last Friday. The procurement team calls IT. IT opens the route editor and starts rebuilding, line by line.

This is the hidden tax that most manufacturers pay every spring, and on every resignation. The approval engine works, but the routes are bolted to names instead of positions. The moment a person moves, the route breaks. Under Japan's persistent labor shortage, the burden only gets heavier. The 2025 White Paper on Information and Communications reports that 48.7 percent of companies cite the shortage of people as the single biggest barrier to pushing digitalization forward. When back-office staff are already stretched thin, no one has time to babysit approval routes every time the org chart shifts.

The fix is structural, not heroic. A modern core business system routes approvals to the role, the position, or the department, and dynamically to the requester's own manager. The route is expressed in terms of the organization, not the individual. When people move, the route keeps flowing to whoever currently holds the seat.

Why Named Routes Break So Often

Most companies built their first electronic approval system by digitizing the paper ringi (internal approval proposals) route. On paper, the route was a list of names and a stamp order. When that list was copied into a system, it stayed a list of names. That worked on day one. It fails on every day after a reorganization.

The failure shows up in three predictable ways. First, the ghost approver. A request lands in the inbox of someone who has already left the company. Nobody notices until the requester chases it days later. Second, the misdirected approval. A manager was promoted into a new department, but the route still sends their old cases to their old inbox. They approve things they no longer own, or they ignore them. Third, the IT bottleneck. Every reshuffle becomes a mini project to rewire dozens of routes, and IT becomes the unintended owner of the approval process itself.

None of this is a technology failure. The approval engine runs fine. It is a modeling failure. The route describes the wrong thing. It describes people, when it should describe the organization. Frequent reorganizations are normal business life for a growing manufacturer. The approval system should absorb them silently, not collapse under them.

Route by Role, Position, or Department

The first principle is to stop naming people in the route definition. A core business system that was built for this lets you point an approval step at a position or a department rather than at a person. The route says "section manager of the requesting department" or "general manager of procurement," and the system resolves that to whoever currently holds the role at the moment the request is submitted.

The difference sounds small until you watch a reshuffle go through. On April 1, the new section manager logs in and finds the cases already in their inbox. No ticket to IT. No route editing session. No gap in service. The procurement request that used to stall for three days now reaches the right desk on the same morning because the seat, not the surname, owns the step.

This also fixes the resignation problem. When the department head retires, their successor inherits the open queue automatically once they are assigned to the position. The route does not need to be told that a person left. It only needs to know that the position still exists and who fills it. The organizational master becomes the single source of truth, and the approval routes read from it live.

There is a governance payoff too. Internal control and J-SOX reviewers want to see that approvals came from someone with the correct authority for that spend. A route defined by position makes that self-evident. The audit trail shows that the general manager of finance approved the journal correction, not just "Tanaka-san," and it did so because the route required that seat. Authority travels with the role, which is exactly what the rules of delegation are supposed to guarantee.

Dynamic Routing to the Requester's Own Manager

Routing by position solves the fixed part of the org chart. But many approvals are not fixed at all. They depend on who is asking. A sales rep's expense claim should go to their sales manager. A line worker's overtime request should go to their production supervisor. If every requester has a hard-coded route, you are back to the same maintenance problem, just hidden inside the requester profile.

The cleaner model is dynamic routing. The core business system looks at the requester, finds their direct manager or department leader in the organizational master, and routes the first approval step there. When the requester changes teams, their approvals automatically follow their new reporting line. When their manager changes, the route updates without anyone editing it.

This is the capability that finally kills the spring IT queue. The annual reshuffle is just a set of manager reassignments in the organizational master. Once those are updated, every dynamic route across the company adjusts in the same instant. There is no route list to rebuild, because the route was never a list. It was a question: who manages this person right now?

Dynamic routing also handles the awkward middle cases that defeat manual routes. A staff member on a temporary secondment to another plant still gets approvals from their acting manager at that plant, because the organizational master reflects the secondment. A dual-reporting role can route to a functional leader for one request type and an administrative leader for another. You model the reality of the organization, and the routes keep up.

What This Means for Back-Office Burden

The labor shortage number is worth pausing on. When 48.7 percent of companies name the labor shortage as the top digitalization barrier, the implication is that any system that adds maintenance work is a system that will stall. Approval route upkeep is exactly the kind of quiet, repeated, thankless task that eats the back-office hours a short-staffed company cannot spare.

Routing by role and dynamic manager routing remove that task almost entirely. The route maintenance budget drops to near zero, because the routes are derived from data the company already maintains. The organizational master has to be correct for payroll, for access provisioning, for cost-center reporting. The approval system simply reuses it. One source of truth, consumed by many processes, and no duplicated list of names to keep in sync.

There is a downstream effect on adoption too. When a system survives a reshuffle without breaking, trust in it goes up. Staff stop circumventing it with email and chat, because the official route actually reaches the right person faster than the workaround. The shadow approval processes that grow around a fragile system start to wither. The core business system becomes the default, not the fallback.

A Few Honest Boundaries

Routing flexibility is a real, built capability. It is worth being precise about where the automation ends. The approval flow itself, with role-based and dynamic manager routing, is built and runs today. The system can see exactly where every request is stuck, enforce business-day deadlines, and keep a frozen snapshot of what was approved for audit.

Where the story stays honest is around automatic write-back into ERP records. The workflow engine can confirm an approval and drive the next step. For expense reimbursement and leave applications, an approval also finalizes the corresponding record automatically, because those handlers are built. For other record types, such as purchase orders, journal entries, vendor master, or inventory lots, the automatic write-back on approval is on the roadmap, not yet shipped. The honest way to say it: the approval route is built now, the automatic ERP record creation for those types is on the roadmap. That line matters when a vendor is comparing promises.

The workflow module can also stand on its own first. A company does not have to wait until the full ERP rollout to fix its broken routes. It can deploy the approval engine, prove that routes survive the next reshuffle, and then connect it to the rest of the core business system as the rollout matures. For a short-staffed manufacturer, that sequencing is the difference between starting this quarter and starting never.

Common Questions, Answered Plainly

What happens to requests already in flight during a reshuffle?

Requests that have already passed a step keep their history. The audit trail records who approved at the time, which is the correct behavior for internal control. Requests that have not yet reached a role-based step resolve to whoever holds the role when the step activates. So an open request does not get stranded on a departed manager. It moves forward to the current seat holder the moment the org master is updated.

Can we still force a specific person for sensitive approvals?

Yes. Role and dynamic routing are the default, not a straitjacket. A high-value capital expenditure can still name a specific director, or require a committee with a quorum, or use an any-of-N approver set for speed. The point is that the common, high-volume routes stop being maintained by hand, while the exceptional, high-risk routes keep whatever explicit control they need.

How does delegation fit in?

A manager traveling on business can delegate approval authority for the period they are away, so approvals do not freeze. For high-risk items, the system can require mandatory re-approval by the original authority on return, so delegation never becomes a quiet bypass of control. Delegation and role-based routing work together: the route points at the role, the role is held by a manager, and the manager delegates temporarily without the route itself changing.

Does this require a clean organizational master to start?

It requires an accurate one, which is a lower bar. Most companies already maintain reporting lines for payroll and email distribution. The first cleanup is usually a few days of confirming who reports to whom, and it pays for itself the first time a reshuffle passes without an IT ticket storm. After that, the master is kept current as part of normal HR operations, and the approval routes follow along.

Key Takeaway

Approval routes break every spring and on every resignation because they are modeled as lists of names. Model them as the organization instead. Route by role, position, and department. Route dynamically to the requester's own manager. Let the organizational master be the single source of truth, and the routes survive reorganizations, secondments, and departures without a single support ticket.

Get Started With Kikan System

If your IT team dreads April because it means rebuilding approval routes, look at Kikan System. The workflow module routes approvals by role, position, and department, and dynamically to the requester's manager, so routes survive reshuffles and resignations on their own. You can start on the free plan with up to 2 users, no credit card required, at /#get-started.