Approvals that live in someone's email inbox are not a workflow -- they are a process that stops every time that person is on leave.

Routing rules are defined as condition-action pairs -- configurable by an administrator without code changes -- so the approval chain adapts to every request's attributes rather than applying a one-size-fits-all sequence. Threshold-based routing: purchase orders below £5,000 route to the department manager; £5,000--£25,000 route to department manager and finance director in sequence; above £25,000 add the CFO as a third tier. Vendor-type routing: new vendor purchases route to the procurement director for supplier approval regardless of value; approved vendor purchases follow the standard value-based chain. Department routing: IT capex routes to the CTO in addition to finance; marketing spend above a threshold routes to the CMO. Risk-category routing: contracts with data processing clauses route to the Data Protection Officer before commercial sign-off; contracts with liability clauses above a configured amount route to legal review. Routing mode per step: sequential approval (each approver acts in order, the next is only notified when the previous has approved -- standard for financial approvals where each level is a gate); parallel approval (all approvers in a tier are notified simultaneously and the item advances when all have responded -- used for reviews where multiple departments give independent input simultaneously); any-one approval (the item advances when one approver in a defined group responds -- used for out-of-office resilience where any member of a team can approve). Routing rule evaluation is deterministic and logged: the specific rules that determined the approval chain for each item are recorded in the audit trail so the routing decision is explainable to auditors.

SLA thresholds are configured per approval step and per request urgency level: standard invoice approval allows 48 hours at each approver step; urgent payment authorisation allows 4 hours; contract review allows 5 business days. Business-hours-only SLA calculation ensures that weekends and company holidays are excluded from SLA consumption -- an item submitted at 4pm on Friday with a 24-business-hour SLA does not expire at 4pm Saturday. Escalation tiers: at 70% of the SLA window consumed, the approver receives a reminder notification with the item details and SLA deadline. At 100% (SLA breach), the first escalation fires: the approver's manager receives a notification with the stalled item and how long it has been waiting; the approver receives a breach notice. If no action is taken within a second configured window after the first escalation, the item is auto-assigned to the delegate approver (if configured) or escalated to the approval manager's queue. Auto-approve at SLA limit: for low-value, low-risk items where the business impact of delay exceeds the risk of proceeding without explicit approval, an auto-approve-on-timeout rule can be configured -- the approval is recorded as system-approved with the timeout reason and the accountable manager notified. SLA performance reporting: approval cycle time by step, by approver, and by approval type; escalation rate by step; SLA breach rate trend over time -- the metrics that identify whether slow approvals are a process design problem, a capacity problem, or a specific approver problem.

The audit trail is written to an append-only log -- every event is a new record; no event can be modified or deleted after it is written. Events recorded per approval item: request submission (submitter identity, timestamp, request content snapshot); each approval action (approver identity, action type, timestamp, comments entered, IP address, and device); each routing decision (which rule triggered the routing and to whom); each escalation event (SLA threshold breached, escalation action taken, escalating party notified); each reassignment (original assignee, new assignee, reason); and each attachment upload (uploader, timestamp, document name, version). The record is tamper-evident: a hash of each event record is stored separately so any modification to a historical event is detectable. For audit and compliance use cases -- SOX financial controls, ISO 27001 access approvals, FCA regulated activity sign-offs, NHS IG approval processes -- the audit trail export produces a structured evidence pack filtered by date range, approval type, approver, or individual request. Audit exports include the full sequence of events, the approval chain that was applied (with the routing rules that determined it), and the supporting documents attached at the time of submission and decision. Retention policy: audit records are retained for a configurable period (minimum 7 years for financial approvals under standard accounting standards) and stored in immutable cold storage (AWS S3 Object Lock or Azure Blob Storage Immutable) to satisfy long-term retention requirements.

Each user role has a tailored dashboard view that shows only the information relevant to their function -- a requestor's view, an approver's view, and a manager's oversight view are different surfaces built on the same data model. Requestor dashboard: all submitted items with current approval step, time in current step vs SLA, expected completion date, and last action taken. The requestor sees the current status without needing to email the approver or a colleague to find out where their request is. Approver dashboard: items pending the approver's action, sorted by SLA urgency (items closest to breach shown first); each item shows the request summary, the submitter, the amount or key decision field, the time remaining before SLA breach, and a direct approve/reject action -- approvers can clear their queue without navigating to a detail page for simple items. Manager dashboard: team-level view showing all open items across the approval process, which approvers have the most pending items, average cycle time by approval type, SLA breach rate for the current period, and items currently overdue with the breached SLA time. Manager operations: bulk reassignment for an approver who is unexpectedly absent; delegate configuration for planned absence; SLA threshold adjustment for specific approval types. Notification channel preferences per user: email (all platforms), Slack (direct message to the user's Slack account via Slack API), Microsoft Teams (adaptive card message via Teams webhook), or in-app notification for users who work primarily in the approval portal. Users configure their preferred channel in their profile settings and can suppress notifications for specific approval types they have delegated.

Rejection handling is structured to accelerate resolution rather than simply terminating the request. When an approver rejects an item, they are required to select a rejection reason code from a configurable list (insufficient budget, missing documentation, incorrect vendor, out of policy, requires additional approval) and optionally add a free-text note. Mandatory reason codes prevent uninformative rejections ("rejected" with no context) that generate back-and-forth communication to understand what the requestor needs to change. The rejection notification to the requestor includes the reason code, the approver's note, the specific step at which the rejection occurred, and (for items where correction is possible) a direct link to the revision form. Revision workflow: the requestor updates the required fields and resubmits without creating a new request -- the revised submission is linked to the original, the revision number is incremented, and the approval chain restarts from the beginning or from the rejecting step depending on the configured revision routing (restarts from beginning for high-value items where all tiers should see the revision; restarts from the rejecting step for corrections that don't require re-review of earlier approvals). Version history per item: every submitted version is preserved with a diff view showing what changed between versions -- approvers reviewing a resubmission can see exactly what the requestor changed without reading the full request again. Partial approval for line-item requests (purchase orders, expense reports with multiple lines): individual line items can be approved or rejected separately, with approved lines advancing to fulfilment and rejected lines generating a targeted rejection notification for just those lines.

Integration with the system where the approval item originates means approval requests are created automatically without a separate data entry step and approval decisions update the source record without manual status changes. ERP integration: SAP (RFC/BAPI and OData) for purchase requisitions and invoice approvals; Oracle ERP Cloud REST API for purchase orders and expenses; NetSuite SuiteTalk REST API for bill approval and purchase order workflows; Microsoft Dynamics 365 Business Central REST API for purchase invoice and expense approval. Procurement platform integration: SAP Ariba API for procurement workflow items; Coupa API for requisition and PO approvals; Jaggaer REST API. Expense management integration: Concur SAP Expense API; Expensify API for expense report approvals; Spendesk API. HR system integration: Workday REST API for employee change requests, headcount approvals, and compensation changes; BambooHR API for HR action approvals; SAP SuccessFactors API. Document management integration: SharePoint Graph API and OneDrive for Business for document retrieval so approvers view the actual contract or invoice PDF within the approval interface without downloading files; DocuSign API for triggering e-signature workflow after final approval. Identity and access: SAML 2.0 SSO integration with your identity provider (Okta, Azure AD, Google Workspace) so approvers authenticate with their existing corporate credentials; SCIM provisioning to automatically create and deactivate approval system accounts when users are added or removed in the IdP, eliminating orphaned accounts for departed employees.