What it is
The Universal Approval Engine is a single, shared capability that any TATER feature uses when a request needs a human decision before it proceeds. Instead of every module reinventing its own approve/deny screen, queue, and notifications, they all plug into one engine — so every pending decision shows up in one place (My TATER → My Approvals), reminders and escalation work the same everywhere, and you define your approver pools once.
Flows already on the engine include travel exemptions and license rentals, with more migrating onto it over time. The engine is generic: each flow registers an adapter that performs its own side-effect (schedule a travel exemption, provision a license, …) when a decision lands, while the engine handles the groups, stages, quorum, reminders, escalation, audit trail, and inbox.
Approval groups
An approval group is a reusable, named pool of approvers — for example "IT Security Approvers" or "Risk Committee". Manage them in TATER Manage → Audit & Telemetry → Approvals → Approval Groups (Admin role).
- Members can be typed in directly (one email per line), or the group can be backed by an Entra security group. When you set an Entra group ID, the Sync members from Entra group button pulls the group's members into the approver list via Microsoft Graph (using your org's existing scanning credential — read-only).
- Decision mode controls when the group's stage is satisfied:
- Any one approves — the first approval wins (default).
- All must approve — every member must approve.
- Quorum (M of N) — a set number of approvals is required.
- Percentage — a percentage of the members must approve (board-style).
- Veto on deny (default on) — any single deny finalizes the request as denied, even in "any one" mode.
- Reminders — pending approvers are re-emailed every N hours until they decide.
- Escalation — after N hours with no decision, named escalation contacts are emailed as backup approvers.
Reminder status describes submission, not proof that the recipient received an email. A queued reminder is pending delivery. Failed or held submissions remain eligible for a later reminder; notification-policy skips do not claim an email was sent. If an email is accepted but its reminder date cannot be saved, review notification delivery status before retrying because another attempt may repeat it.
Workflows & stages
A workflow is an ordered (or parallel) set of stages, each pointing at a group (or an inline list of approvers). Sequential stages advance one after another — e.g. a travel exemption goes Manager → IT / Security. Built-in flows construct their stages automatically from their own configuration; for custom needs you can define reusable workflows under Manage → Approvals → Workflows.
A deny at any stage denies the whole request. When the final stage is satisfied, the engine marks the request approved and runs the owning flow's side-effect.
My Approvals (for approvers)
Everything awaiting your decision — across every flow and every organization you belong to — appears in My TATER → My Approvals, with a badge so you know when something is waiting. Each item shows what's being requested, who requested it, and which stage it's at. Approve or deny inline (denials can include a reason). You'll also get an email when something needs you, a reminder if it lingers, and a final notification when a request you raised is decided.
Org-wide queue & oversight
Admins and auditors can see the whole organization's pending approvals in Manage → Approvals → Queue — useful for spotting bottlenecks. The Approval Activity & Bottlenecks report in TATER Insights breaks down volume and status by flow, average time-to-decision, and the oldest still-pending requests. Every decision is written to the audit log (who decided, when, via which channel), so approvals double as compliance evidence (change management, segregation of duties, risk acceptance sign-off).
Self-approval and administrative decisions
In Manage → Approvals → Self-approval policy, an organization administrator can require an independent approver or allow self-approval with an audit exception for each request type. Reimbursements require independence by default. Other types retain their existing self-review behavior with an audit exception until the organization selects a different policy. The server applies this policy; a decision cannot override it by sending a different setting. Policy edits belong to the selected organization. Changing organizations while a load or save is pending requires refreshing that view; the editor locks its controls while saving and confirms the returned policy before reporting success.
An administrative override records the administrator who acted and preserves other people's votes. Each known actor contributes at most one current vote per stage, including when the same user ID appears under another email address. The decision history shows overrides and self-approval exceptions. Change request exports include the deciding actor and exception fields.
When independence is required, a requester's matching email or stored user ID blocks approval. Older records without a stable user ID cannot identify every email alias; records missing requester identity require correction before approval under enforcement. Configured automatic workflows and expiry actions have their own existing policies.
MCP / AI access
Approvals are available to AI assistants through the TATER MCP server (HTTP and stdio):
list_my_approvals— what's awaiting your decision.list_approvals— the org-wide queue (Auditor+), with status / subject-type filters.decide_approval— approve or deny a request (with optional comment).list_approval_groups/create_approval_group— view and create approver groups.
Related
- Travel Exemptions — international-travel CA-policy exemptions (manager + IT approval on the engine)
- License Rentals — time-boxed Microsoft license grants (approval on the engine)
- MCP setup — connecting Claude Desktop / API to TATER