Automation playbook
Approval and document workflow automation: routed by rule, on the record
Approvals are where work waits. A leave request in a chat thread, a purchase waiting for a signature, a discount nobody is sure who can give. We build the routing so each request reaches the one person who can decide, with the facts attached, and the documents that follow a decision are generated rather than typed.
In short
Approval workflow automation sends each request, whether leave, a purchase, an expense or a discount, to the right approver by rules you set: amount, department, role or policy. The approver sees the facts and decides; the system records who approved what and when, generates the document that follows, and moves the work on. Rules are versioned, so the policy that applied on any day can always be shown.
The flow
Step by step, who does what
- Request raised Leave, purchase, expense, discount
- Routed by rule By amount, department or policy
- Approver decides With the facts and the history attached a person decides
- Document generated Order, letter or voucher as a PDF
- Everyone notified Requester, accounts, the next step
- Decision recorded Who, what, when, under which rule
Stays with people: The decision itself, and any exception to policy, stays with the approver.
What gets automated
Routing. A request is checked against the rules first: the leave balance, the budget line, the discount limit. If it is within someone’s authority it goes to that person; if it exceeds it, to the next level; if the rule can answer it outright, it is answered. Reminders go to approvers who have not responded, and requesters see where their request is without asking.
Paper. The documents that follow a decision are generated from the record: the purchase order, the appointment or warning letter, the expense voucher, the quotation. Each is numbered, dated and filed against the request, and exported as PDF or Excel when it needs to leave the system.
- Requests routed by amount, role, department or policy
- Reminders to approvers, status for requesters
- Documents generated from the record, not typed
- A history of who decided what, and when
- Policies versioned with the date they apply from
How we build it
We write your approval matrix down with you, which is often the first time it has been written down, and turn it into rules the system applies. Exceptions are designed in: who can override, and how an override is recorded.
In AurumOne, hiring, warnings and resignations run as workflows, and salary rules keep a history of every change. The same pattern carries to purchases, expenses and discounts in a custom system: a request, a rule, a decision, a document, a record.
What it connects to
The systems that hold the facts an approver needs: your HR or payroll system for balances, your accounts for budgets, your CRM for the customer and the deal. Notifications go by email or WhatsApp, and generated documents are filed where your team already looks.
- HR and payroll, for leave and balances
- Accounts, for budgets and payments
- CRM, for customers and quotations
- Email and WhatsApp, for notifications
Questions
Common questions
Can the owner still approve everything?
Yes, and many owners start that way. The difference is that every request arrives in one place with the facts attached, instead of in five chats. Over time you can hand defined categories to managers, with limits, and the record stays complete.
What happens when an approver is on leave?
Routing rules can name a deputy or escalate after a set time, so a request never waits on an empty chair. The record shows who decided and why they were the one to decide.
Can we change the rules ourselves?
Limits, approvers and deputies are settings an administrator changes. Each change is kept with the date it applies from, so an old request is always judged by the rule that was in force at the time.
Related