Opening: Approval for business trips relies on group messages, and finding the approver depends on asking
At a manufacturing enterprise of around 200 employees, the first business trip request after the New Year was processed like this: An employee @-mentioned their supervisor in the group chat; upon seeing it, the supervisor replied with “OK,” and the employee saved a screenshot. At month-end, when finance prepared travel expense reports, they cross-referenced each screenshot against the budget. Meanwhile, HR tallied “employee travel days” at year-end—only to discover that some screenshots were incomplete and data across departments didn’t align.
This isn’t an isolated case. In many domestic companies, approval processes unfold this way:
- Finding people relies on asking : During a new employee’s first week, the most common question is, “Who do I ask for leave approval? Who reviews my reimbursement?”
- Group messages serve as proof : A WeChat or DingTalk group message saying “@Boss approved” is treated as official approval, leaving no audit trail afterward.
- Interdepartmental data doesn’t match : The sales department believes a client visit has been approved, while marketing thinks it hasn’t; finance paid based on the sales team’s screenshot.
- Permissions rely on verbal agreements : When a manager leaves, their permissions aren’t revoked, and the new hire doesn’t know whose hands hold the contracts previously approved by the former manager.
The root cause of these issues isn’t how complex the approval process is, but rather that the approval workflow hasn’t been integrated into a system . Group messages, verbal instructions, and screenshots are all temporary mediums; what’s missing is a structured, traceable, and auditable platform. An OA system (office automation system) does exactly that: it structures the entire process—“who, which matter, when, who was consulted, under what rules approval was granted, and how the data is recorded afterward”—all within a single approval flow.
Breaking down the approval process reveals three distinct layers:
- Matter layer : Employees initiate specific matters such as “business trips, leave requests, expense reimbursements, contracts, seal usage, or procurement,” each accompanied by amounts, durations, attachments, and related business entities (e.g., a trip request linked to a sales order, or an expense claim tied to an invoice).
- Process layer : Matters flow from one node to the next, with approvers dynamically determined based on department, level, amount, and category—rather than fixed in advance.
- Data layer : After approval or rejection, relevant data must be written back into the business systems (HR, finance, sales, contract databases), instead of remaining confined to the approval workflow.
The relationship among these three layers is as follows: Matters serve as the entry point, processes form the backbone, and data constitutes the exit . If an OA system only implements processes without integrating data output, the approval workflow becomes an isolated island; if it focuses solely on matters without establishing clear procedures, it degrades into a mere “form-filling system.”
02 How to design: Dynamic nodes, permission matrices, and traceability—a trifecta
Node design: Approvers shouldn’t be hardcoded
Many OA systems predefine approvers right from the start: “Business trip request → Department Manager → HR → General Manager.” As a result, when department managers change positions, HR gets merged into administration, or the general manager goes on leave, the entire system falls into disarray.
The correct approach: Approvers should be dynamically calculated according to predefined rules . Typically, there are four rule dimensions:
- Department dimension : The applicant’s department corresponds to its current head (checked in real-time via the organizational chart).
- Level dimension : Different ranges of amounts, durations, and contract values map to different approval levels.
- Role dimension : Contracts exceeding 500,000 require legal involvement; overseas business trips necessitate safety and compliance signatures.
- Proxy dimension : When an approver is on leave or traveling, authority automatically transfers to a designated proxy, set either through organizational relationships or HR.
By combining these four dimensions into a “rule expression,” the workflow engine calculates nodes in real time according to the rules, without hardcoding approver names . Changes in personnel or organizational restructuring thus don’t require modifications to the workflow template.
Permission design: Three-tiered access control over menus, data, and fields
Permissions aren’t about “whether you can enter the system”; they operate on three levels:
- Menu-level access : Whether you can view a particular module (e.g., regular employees cannot see “Organizational Structure Management”).
- Data-level access : Whether you can view specific pieces of data (e.g., Sales Department One can only see reimbursement records of its own employees, not those of Sales Department Two).
- Field-level access : Whether you can view certain fields within a piece of data (e.g., ordinary approvers cannot see applicants’ salary fields, but HR can).
With these three tiers of permissions clearly defined, the OA system can support complex organizational structures—group–branch–department–team—with cross-level data governed by two parallel rules: “I can see my own line of reporting + I am responsible for this line.”
Traceability design: Seven essential elements of the approval log
Each approval action must record seven key details:
- Operator : Who initiated the action.
- Time of operation : Precise to the second.
- Action taken : Agree, reject, forward, add signature, withdraw.
- Opinion on the action : Rejection reasons must be provided; agreement may remain blank.
- Location of the node : Which stage of the workflow the action currently stands at.
- Snapshot of associated data : Field values of business objects at the time of approval (amounts, attachments) are preserved intact, preventing any post‑approval changes to business objects without updating the approval record.
- Device and IP traces : From which device and IP address the action originated (for compliance audits).
If even one of these seven elements is missing, auditors will inevitably raise objections. A common pitfall is leaving the “opinion” field blank, resulting in rejections lacking clear rationale, repeated appeals from employees, and prolonged approval workflows.
03 How to develop: Three core components—the workflow engine, form engine, and message bus
The heart of OA development lies in these three engines, not in N separate pages:
Workflow engine
The workflow engine requires no coding; it runs entirely through configuration. Key features to support include:
- Serial, parallel, joint signature, or signature by another person : Four basic workflow types—regular applications follow a serial path (HR → Supervisor → CEO), while procurement uses a parallel process (finance and procurement supervisors review simultaneously).
- Conditional branching : Diverting workflows based on amount, category, or applicant’s level—under 5,000 yuan takes a simplified route; between 5,000 and 50,000 undergoes dual review by department and finance; above 50,000 requires CEO approval.
- Reverting and Rejecting: Three types of rejection are supported—reverting to the applicant, reverting to any node, and reverting to the previous node.
- Adding Signatures and Transferring Signatures: The approver can transfer the task to a colleague (transfer signature) or invite another colleague to review it together (add signature).
- Withdrawing and Voiding: The applicant can withdraw items that have not yet been approved; the administrator can void abnormal items.
After the process engine is developed,a new type of approval can be added without writing any code—simply draw a diagram and configure a form, and it’s ready to go live. This is the key distinction between OA and “outsourced approval development.”
Form Engine
Forms must support “zero-code design”: field types (text, number, date, attachment, related business object), validation rules, required vs. optional fields, and visibility conditions—all can be configured visually through drag-and-drop. This way, when HR adjusts reimbursement fields or sales adds contract fields,there’s no need for IT to schedule a development cycle.
The form engine must support:
- Field-level permissions: On the same form, different approvers see different fields (for example, ordinary approvers cannot see the applicant’s phone number).
- Field Linkage: When “Contract Type = Service Contract” is selected, fields specific to service contracts are automatically expanded.
- Data Write-back: After approval, data is automatically written back into business systems (contract status, HR attendance, financial vouchers).
Message Bus
Upon approval or rejection, both the applicant and relevant business systems (HR, Finance, Sales) receive instant notifications. The message bus handles unified dispatch:
- In-system Notifications: Includes in-app messages and to-do items.
- IM Notifications: Enterprise WeChat, DingTalk, and Feishu webhooks push notifications to corresponding groups or individuals.
- Emails and SMS: Backup notifications for key milestones (contract approvals, overseas business trips).
- Business System Messages: After approval, a notification is sent to the business system’s to-do list (e.g., finance receives an expense reimbursement to-do, HR receives an onboarding to-do).
The message bus is not merely decorative—it serves as the “feedback loop” of the approval process. Without notification, applicants won’t know who to approach next, causing the entire workflow to stall.
Conclusion: Sequence, risks, and metrics of implementation
The OA system rollout proceeds in three phases:
- Phase One (1 month): Introduce three high-frequency tasks—leave requests, business trips, and expense reimbursements—covering all employees. First, migrate these three processes from WeChat groups into the system, even if only these three are moved, cross-departmental data alignment will immediately be achieved.
- Phase Two (2–3 months): Add four medium-frequency tasks—contracts, official seals, procurement, and payments—and integrate with the finance system. This phase also requires enabling data write-back (automatically archiving approved contracts into the contract library).
- Phase Three (as needed): Cover the full HR workflow—including performance reviews, promotions, formal employment, recruitment, and departures. Led by HR, this phase aims to connect HR master data.
Common Risks:
- Overly flexible rules: If approval workflows are configured too freely, no one knows who should handle the next step. Principle: Workflow templates should not exceed 30 steps, otherwise control is lost.
- Missing alternate approvers: If an approver is away on business without designating a substitute, the process can get stuck for up to three days with no one reviewing it. The system detects “processes stalled for over 24 hours” and issues automatic alerts.
- Lack of data write-back: Even after approval, attendance records remain unchanged in the HR system, and no vouchers are generated in the finance system. Write-back must include “dual verification”—after OA completes its entry, it actively calls the business system’s API to confirm receipt.
Metrics for assessing success:
- Average approval completion time: Before launch, processes took about three days via WeChat group; after launch, they close within one day through the system.
- Cross-departmental data consistency: The error rate in reconciling HR, finance, and sales data has dropped by more than 80%.
- Audit traceability rate: Random sampling of 20 historical approvals reveals a 100% compliance rate across all seven essential elements.
Moving approvals from WeChat groups into the system isn’t just about “going digital”; rather, it’s about shifting the responsibility of “finding the right person” from human dependency to rule-based automation. Once rules are codified, regardless of employee turnover or organizational changes, approval workflows remain orderly.