Leave requests, cash advances, expenses, purchase requisitions, invoice payments, bookings — all flow through the same polymorphic approval engine. Requests route by amount band, move through the role sequence, and every decision is recorded with a full audit trail. Your people get a single "Pending My Approval" inbox; you never build a separate approval system for each document type.
An ERP keeps each document in its own silo; it offers no common approval layer shared across leave, expenses, procurement and payments — one that routes by amount band and supports delegation. Customising a separate hierarchical approval chain for every document type — with department scope, escalation and an audit trail on top — is an unbearable cost and maintenance burden. The Intranet Portal solves this once, polymorphically: you configure the engine a single time and every module consumes it. The ERP remains the single source of truth for the financial record; the approval process runs in the portal, and only the approved result is written back to the ERP.
The engine is document-agnostic. Any request (leave, advance, procurement, payment, booking) plugs into the chain simply by implementing a single Approvable interface. The same infrastructure serves dozens of different document types via morphTo; you never write an approval system from scratch for a new module.
You define a threshold amount (escalation_limit) and an escalation role on the flow. If the request amount exceeds the threshold, an additional senior approval step is automatically added to the chain. Small spend flows through quickly; large amounts escalate to top management — the rule lives in the engine, not in code.
Approval steps are ordered by role (position). Only one step is ever 'active' at a time; once approved, the next step activates automatically, and when the final step is approved the process completes. A rejection ends the process instantly. Who decided, in which role, when and with what note — all of it is visible in the chain.
Each step is tied to a role; the active users holding that role are the eligible approvers. If the role is represented within the requester's department (e.g. Department Manager), the step is routed only to the relevant authorities in that department. Central roles, by contrast, reach all their holders. Authority sits at the step level, not locked to a single individual.
When an approver is on leave or unavailable, their authority is delegated to a deputy; the process doesn't stall. The delegation is written to the audit trail — who decided on behalf of the actual authority is on record. During leave periods, approvals don't get stuck and the process keeps moving.
If steps aren't resolved within a set time, the process isn't left waiting; per the rule, it escalates to a senior role or triggers a reminder. Approvals never 'get forgotten on someone's desk' — every pending request has an owner and a countdown.
Managers see pending requests from every module in one inbox — leave, advances, expenses and procurement all in the same place. The 'My Approvals' badge in the sidebar shows a live count of what genuinely awaits a decision (with department scope applied). Approvers never navigate a separate screen for each module.
When a new approval lands, a decision is made, or a request is approved or rejected, the relevant people are notified (email, push, SMS, live notification). The notification carries a deep link to the request; the approver reaches the decision screen in a single tap, and the requester learns the outcome instantly.
Every transition runs in a single database transaction: a fresh-state guard, the mutation, the step record and the notification all in the same transaction. No double approval or race condition can arise from a stale screen. The role name is snapshotted at the moment of the step; even if the role is later deleted, the 'who approved' record stays intact. A reason is mandatory for rejection; a pending request can be withdrawn by its owner.
An employee creates a request via mobile or web (leave, advance, expense, procurement...). The engine finds that module's active approval flow, snapshots the steps onto the instance, and — if an amount is present — checks it against the escalation threshold.
Steps are arranged by role sequence; if the amount threshold is exceeded, a senior approval step is added automatically. The first step becomes 'active' and a notification goes to the authorities holding that role (with department scope where applicable).
Each authority approves — or rejects with a reason — from their own 'Pending My Approval' inbox. On approval, the next step activates; on rejection, the process ends immediately. Delegation and SLA rules come into play along the way.
Once the final step is approved, the process is marked 'Completed' and the requester is notified. The request's own status is mirrored from the approval outcome (syncApprovalState) and the coarse stage label is updated.
The approved amount or decision — timesheet entry, expense total, payment instruction, purchase order — is transferred to the ERP cleanly and in a single pass. The audit trail stays in the portal; the financial record is kept in the ERP.
The approval engine is the portal's core, cross-cutting infrastructure; on its own it is not dependent on the ERP. It leaves the ERP as the single source of truth: the approval process runs in the portal, and only the approved result is written back to the ERP. It reads master data (personnel, roles, departments, accounts, amounts) from the ERP.
The role/department scope of the approval chain is fed from the personnel master data in the ERP (SAP, Logo, Mikro, Uyumsoft, Netsis). Who holds which role, in which department — that information stays in the ERP, and the portal mirrors it read-only. For non-ERP companies, the same data is managed via Excel import.
When the process is 'Completed', the output — expense total, payment instruction, purchase order, timesheet — is transferred to the ERP through the relevant module in a single, clean pass. Double data entry and the 'which one is right' chaos disappear.
The escalation threshold operates on the request amount, and that amount is consistent with the price/invoice/budget data in the ERP. Above-threshold spend automatically escalates to top-management approval; the financial record stays in the ERP while the decision flow stays in the portal.
Tell us your ERP and your process. We’ll show how this module works and scope it into your subscription — no man-day, licence or setup fee.
Book a Demo →