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 purchase order thresholds, ema runs one configurable approval engine with three parts:
- Policies decide when review is required — a condition on a record ("any purchase 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 records — expense claims, purchase orders, bills, payment runs — 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," but what happens next depends on maker-checker: if the organization's maker-checker rule is satisfied (most commonly, off, or satisfied by someone other than the submitter), it approves the instant the submitting action completes and there is no multi-step chain waiting to run; if maker-checker is not satisfied, the record stays "Pending Approval" and still needs a separate person with the right permission to decide it by hand — just without a policy-driven routed request behind that decision. 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.
Timesheets and leave requests are wired into the same engine but behave differently absent a policy: there is no "Pending Approval" status to show, and no manual decision either — a submission with no matching blocking policy goes straight to Approved on submit. See Timesheets.
Where the shared inbox draws from
My Approvals (staff self-service) is a real cross-module inbox — three tabs, Needs My Action, My History, and My Requests, each searchable by title, requester, or entity type, showing everything currently routed through the shared engine that's assigned to, decided by, or requested by you. 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.
An approver outside your team — most commonly a client organisation contact — has no admin approvals section: client organisation roles carry no approval permission, so the organisation-wide Approval Requests list is never open to them. What they do have is their own My Approvals page, which lists the requests assigned directly to them within their active organisation, and each request's own page at /approve/<request id>, where they sign in and see and decide that one request. The team shares that link with them directly today; ema does not yet send it by email automatically.
Your own pending and past approval requests, across every project you have access to.
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. 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 purchase order over $10,000 routes through a two-step Finance-then-Director workflow — that request lands in the configured Finance approver's My Approvals (Needs My Action) the moment it's created, and in the submitter's My Approvals (My Requests). 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.