The day a reorganization is announced, the development team gets the same request it always gets: "Please add the new division head to the purchase approval line." It is a familiar scene at any company where approval lines live inside the code. This article lays out the design criteria for pulling approvals out into a single workflow engine.
Approval Logic Scattered Across Screens
When purchase, leave, expense, and quotation approvals are each built as the need arises, you end up with four sets of approval code that are similar but never quite the same. Status names differ, and so does the way a rejection is handled.
What Korean Approval Lines Require
Korean approval practice distinguishes several participant types, which a simple approve/reject model cannot express.
The approval line should be determined automatically from conditions. For example, expenses under KRW 5 million are finalized by the team leader, those from KRW 5 million up to KRW 30 million go to the division head, and those of KRW 30 million or more require the CEO. Add withdrawal, resubmission after rejection, and changes to the line while approval is in progress, and the state transitions become more complex than they first appear.
The Workflow Engine's Data Model
The key is to separate four things.
A line definition should name roles, such as "the drafter's team leader" or "finance team officer," rather than people. At submission, the engine resolves those roles against the org chart and freezes the result in the instance. Org units and positions carry effective start and end dates, so that an old document still shows the titles that applied at the time. For people holding concurrent positions, the history records which department's authority they acted under.
We do not recommend trying to make everything configurable. Amount thresholds, the number of steps, and role mappings belong in configuration; the business processing that follows a completed approval is easier to operate when it stays in code.
Connecting to Business Systems
The engine publishes an "approval completed" event, and each business system consumes it and updates the status of its own data. Writing the approval status change and the event record in one transaction, the outbox pattern, prevents lost events. The receiving side deduplicates by document ID, retries failures at increasing intervals, and surfaces anything that still fails on an admin screen. A daily batch that compares the status on both sides is a sensible safety net.
Whether to use your existing groupware depends on how deep the integration needs to go. For document-centric requests such as general proposals, groupware approval is enough. If the approval result must directly change inventory, purchase order, or settlement data and the groupware's integration API is limited, your own engine is the better choice.
Problems That Surface in Operation
The POLYGLOTSOFT Approach
POLYGLOTSOFT designs approval as a shared module separated from the business screens, so that ERP, MES, WMS, and other systems all call the same engine. Because approval rules keep changing after go-live, subscription-based development is a good fit: it lets you respond continuously to revised delegation rules and reorganizations. If you are scheduling development work every time an approval line changes, we would be glad to hear from you.