Approvals
Ask three different teams "where do approvals happen in ema" and you'll get three different, all-correct answers: the sponsorship deal that needed director sign-off, the expense claim sitting in someone's queue, the registration that's waiting on a scholarship review. It's tempting to assume that's one system wearing different hats. It mostly is — but not entirely, and the gap matters operationally.
The shared engine: policies, workflows, requests
Underneath ad-hoc task and document sign-off, exhibitor status changes, and financial order thresholds, ema runs one configurable approval engine with three parts:
- Policies decide when review is required — a condition on a record ("any order over $5,000", "exhibitor status changes to Confirmed").
- Workflows decide who reviews and how — one approver or a sequential chain, parallel steps, quorum ("any one" vs "all"), timeouts, and escalation.
- Requests are the instances in flight — created when a policy fires, or raised ad hoc from a task, a document, or the Approvals section directly. Each moves through Pending → In Progress → Approved / Rejected / Cancelled / Expired, with every decision, delegation, and comment kept as an audit trail.
This is genuinely one system — not a family of similar-looking ones. Once you've configured a policy and a workflow, every request it produces behaves the same way: same statuses, same delegation, same audit trail, same place to review it.
Configure policies and workflows: conditions, routing, quorum, and escalation.
Submit and review ad-hoc requests from a task, a document, or the Approvals dashboard directly.
No policy configured means nothing to approve
The engine is opt-in per record type. If nothing has ever defined a policy for, say, exhibitor status changes on this project, an exhibitor moving to Confirmed just... moves to Confirmed. There's no default fallback that quietly requires sign-off — the absence of a policy means the action proceeds immediately, not that it's silently blocked or silently approved by nobody.
Several financial and workforce records — expense claims, purchase orders, bills, timesheets, payment runs, leave requests — carry their own "Pending Approval" status and are wired into the shared engine, but only produce an actual routed request when a matching policy exists for that record type on that project. Without one, the record still shows "Pending Approval" while someone with the right permission decides, but there is no policy-driven routing behind it — it approves the instant that person acts, and there is no multi-step chain waiting to run. If you want director-level sign-off on large expense claims, that only happens once you configure the policy for it — enabling the feature and wanting the behavior are two different steps.
Where the shared inbox draws from
My Approvals (attendee/staff self-service) and Client Approvals (client portal) are real cross-module inboxes — one list, filterable by entity type, showing everything currently routed through the shared engine. That's the useful part: you don't hunt through six different modules to find what's waiting on you.
The boundary is exact, not fuzzy: only requests that actually exist in the shared engine appear there. A financial record with a matching policy shows up. The same kind of record on a project with no policy configured for it does not — it was never routed, so there's nothing to list.
Your own pending and past approval requests, across every project you have access to.
What a client organisation's contacts see when you route something to them for sign-off.
What looks like an approval but isn't
A few flows use approve/reject language and a "Pending" status but are not connected to the shared engine at all — no policy, no workflow, no entry in My Approvals or Client Approvals. Each is a single reviewer decision, gated by a permission, recorded directly on that record:
- Registration approval — the initial decision on an approval-required registration type, and the decision on a change request (cancellation, downgrade, transfer). See Registration Approval Workflows.
- CPD/CE credit certification — the reviewer queue that turns logged attendance or a self-attested claim into an awarded credit. See Approvals and Certification.
If a pending registration or a CPD credit claim isn't showing up in the shared Approvals inbox, that's not a bug — those two flows were built as standalone reviewer decisions rather than on the shared engine. Look for them on their own dashboards (Registration and CPD/CE respectively) instead of expecting a routed request.
A PCO configures a policy so any budget line change over $10,000 routes through a two-step Finance-then-Director workflow — that request appears in the deal owner's My Approvals the moment it's created. The same project also runs a Scholarship Pass registration type with Require Approval turned on. Both use the word "approval." Only the first one is a routed, multi-step request with an audit trail in the shared engine; the second is a single admin clicking Approve or Reject directly on the registration, with no policy behind it.
Tasks can require approval as one of their completion types — the same shared engine, triggered from a task instead of a policy.
An approval-required registration type can attach a form so reviewers see supporting detail alongside the request.