Workflow and approval field guide

This chapter is about approval rules: what is allowed and who must agree. Handing the work to people (the store delivers, accounts invoice) is a workflow; read the Workflows field guide. The two work side by side on the same order.

OSERP workflows turn business policy into visible, testable transitions. A document is not approved because a user clicked a button; it is approved when the configured rule, authority, evidence, and status transition succeed. The same pattern applies to sales, purchasing, journals, expenses, payments, inventory adjustments, HR, and master-data changes.

Workflow definition fields

Open Administration → Workflow → New.

Field	Example	Purpose and impact
Workflow code	PO-APPROVAL-2026	Stable configuration key
Module	Purchasing	Document family
Entity	Purchase Order	Triggered record
Company scope	company_uae	Legal isolation
Version	v3	Effective rule set
Effective from	2026-09-01	Policy boundary
Trigger	Submit	Starts evaluation
Condition	Total > AED 50,000	Route selection
Approver source	Manager + CFO	Authority resolution
SLA hours	24	Escalation clock
Escalation	Finance director	Overdue action
Delegation	Allowed with expiry	Continuity control
Active	Yes	Future execution

A workflow version is immutable once used. Amendments create a new version with author, reason, approval, and effective date. Historic decisions remain tied to the version that evaluated them.

State and transition fields

Each entity stores status, previous status, transition, actor, timestamp, comment, reason, and evidence. Typical states are draft, submitted, pending approval, approved, rejected, returned, posted, cancelled, closed, or expired.

Transition	Required evidence	Impact
Draft → Submitted	Required fields and attachments	Starts workflow
Submitted → Pending	Rule and approver resolved	Creates task
Pending → Approved	Decision and comment	Enables next action
Pending → Returned	Correction reason	Sends back to owner
Pending → Rejected	Final reason	Blocks downstream
Approved → Posted	Posting validation	Ledger/stock effect
Posted → Reversed	Approved reversal	Corrects history
Posted → Closed	All downstream complete	Locks lifecycle

Backward transitions require explicit permission and reason. A rejected PO cannot be posted; a draft journal cannot be included in reports as actual.

Rule conditions

Conditions may use amount, currency, company, branch, department, fund, project, account, supplier risk, customer class, discount, tax, warehouse, item category, or user role. A rule must define whether comparisons use transaction or functional currency and how tax/freight are included.

For a USD PO with functional total AED 77,122.50, an approval threshold of AED 50,000 should evaluate functional amount if policy says so. Record the rate source used by the decision. Do not allow a currency switch to avoid a tier.

Approver resolution

Approver source can be direct manager, department owner, project manager, role, named group, budget owner, or sequential chain. Store resolved user IDs at task creation so later org-chart changes do not rewrite an in-flight decision. Check active status, company scope, delegation, conflict of interest, and separation of duties.

The preparer cannot approve their own document when maker-checker is required. A supplier bank change, refund, payment batch, journal adjustment, or credit note may require independent approval even when amount is small.

Approval task fields

Task fields include task ID, workflow/version, entity ID, assignee, group, priority, due date, status, created time, completed time, decision, comment, evidence, escalation count, and correlation ID. Notifications should include safe summary, link, amount, company, and due date without exposing restricted data.

An approver may approve, reject, return, delegate, or request information according to policy. Every action records old/new status, user, time, reason, and version. A request for information pauses or restarts the SLA only when configured.

Delegation and escalation

Delegation fields include delegator, delegate, scope, start/end, reason, approval, and notification. Expired delegation cannot approve a new task. Escalation records original assignee, escalation level, time, recipient, reason, and outcome.

If a PO approval SLA is 24 hours and no action occurs, escalate to the finance director; do not auto-approve unless explicitly configured and legally acceptable. An overdue dashboard shows age, owner, amount, company, and next action.

Evidence and attachments

Evidence fields include document type, reference, version, uploader, timestamp, checksum, retention class, and access rule. A tender, quotation, tax certificate, bank verification, board resolution, or medical document may be mandatory for a route. Missing evidence should produce a field-level message and keep the task pending.

Posting gates and side effects

Approval enables, but does not itself perform, posting. Before posting, OSERP revalidates period open, source status, account mapping, tax, currency, budget, stock, credit, and permissions because data may have changed while waiting.

A posted sales delivery changes stock and COGS; a posted invoice changes receivable and revenue; an approved payment batch may generate a bank file; an approved adjustment changes inventory and GL. The workflow event links to resulting document IDs and journal/movement IDs.

API and webhook behavior

Use workflow ID, entity ID, version, action, comment, evidence IDs, and idempotency key. An API caller may request an action, but server-side role and scope decide whether it succeeds.

{"entityType":"PURCHASE_ORDER","entityId":"po_00041","workflowVersion":"PO-APPROVAL-2026-v3",
 "action":"APPROVE","comment":"Tender and budget evidence verified","evidenceIds":["doc_tender_41"]}

Webhook events such as approval.task.created, document.approved, document.rejected, and document.posted include event ID, tenant, entity, version, actor, occurred time, and correlation ID. Verify signatures and deduplicate replays.

Audit and reporting

The audit trail shows configured rule, values evaluated, approver resolution, decision, evidence, delegation, escalation, and downstream effects. Reports should distinguish configured, pending, approved, posted, reversed, and closed. A document may be approved but not posted; never count it as actual accounting.

Practice checklist

Configure a purchase workflow with budget, supplier risk, currency threshold, sequential approvers, 24-hour escalation, and expiring delegation. Submit a PO, return it, resubmit, approve, post, reverse, and close. Test self-approval, changed amount, expired certificate, period lock, webhook replay, and API retry. Explain every field’s owner, format, status, permission, rule, evidence, journal/stock effect, API ID, and audit event.

Related: Purchase Order field guide, Sales Order field guide, Journal Entry field guide, Administration Atlas, and API cookbook.