Approvals and approval rules

Some actions wait for someone's OK before they happen: an email to a customer, a refund, a post. The agent asks, the request waits under Approvals, and nothing runs until it's approved. Who is asked depends on the agent's charter and your company's approval rules, with safeguards on top that no rule can switch off.

Decide a request

Approvals has three tabs: Waiting for me (requests on a step you approve), All pending and History. Approval requests always reach you in the app and by email too, so nothing waits on you without you knowing.

Each request shows the tool and its risk tier, who asked and why, a preview, and the exact arguments it will run with. A request marked After untrusted input comes from a session that read content from outside your company, such as an email or a web page. Then choose:

• Approve: it runs with exactly the arguments shown. When the card shows only part of them, the dialog shows them all before you confirm.
• Edit and approve: change the arguments, then approve your version. Only what you approve runs. An edit after the first step sends the request back to step 1, so earlier approvers see your version.
• Request changes: nothing runs; the agent gets your note and can try again.
• Reject: nothing runs, and the agent is told why.

Requesting changes and rejecting need a note, so the agent knows what to do next. If someone changed the arguments while you were looking, Everdeck refuses your decision and asks you to look again. Deciding a tier 4 request asks you to confirm it's you if you haven't in the last 15 minutes.

Nobody approves their own request: if you asked for something, someone else decides it.

Without any rules

Each agent's charter decides. A tool set to Ask first goes to the agent's manager, then a person. A tool set to Auto runs, and one set to Never is refused. The safeguards below still apply.

Approval rules

Company admins (and account owners and admins) set rules on the Policies page, under Approval rules. Every change asks you to confirm it's you.

Rules are checked in order, lowest number first, and the first enabled rule that matches an action decides who approves it, whatever the charter says for that tool (a tool the charter sets to Never is still refused).

Presets

Two presets give you a starting point in one click, and your own rules stay when you switch:

• Strict: a person approves every tool call from tier 2 (changes that can be undone) up.
• Balanced: tool calls from tier 3 (anything customers or the public see) go to the agent's manager, then a person. If the agent has no manager who can review it, or they don't answer within 1 hour, the person decides alone.

Add a rule

Select Add a rule and give it a Name and an Order. Under Which actions, choose:

• Kind of action and Risk tier: for example, tier 3 and up.
• Tools and Connectors: pick from the lists, or type names like gmail_send_message or gmail. Leave them empty for every tool and every connector.
• Agents asking: leave all unticked for every agent.
• Conditions (Add a condition): check the action's arguments with paths like args.amount or args.to, for example "amount is more than 500". All conditions must hold.

Under Who approves, in order, add steps with Add a step. Each step names its Approver:

• People with a role (choose How many must approve: Any one of them, All of them or A number of them),
• A specific person, The requester’s manager, A specific agent, or Whoever asked for the task.

Set how long to Wait up to, and what happens If nobody decides in time: Move to the next step or Deny the request. The last step always denies when it times out.

Tick People who approve may edit the arguments first to allow Edit and approve. Select Add rule to save it. A rule that can never apply, or needs fixing, is marked in the list.

Safeguards that are always on

These apply on top of every rule, charter and setting:

• A person approves every tier 4 action: moving money, deleting things and changing access always include a person.
• Untrusted input raises the bar: once a session has read outside content (emails, web pages, customer tickets), its tier 4 actions need a person, and so do its tier 3 actions unless the approval setting below lets an agent review them.
• Visiting an address raises the tier: an action whose input takes an address the agent chooses (a page to read, a url field) could send what the session has read to that address. Once a session has read outside content, such an action counts as tier 3 at least, whatever its own tier: apps' actions, MCP tools marked Visits addresses and API server operations alike.
• Nobody approves their own request: the requester is left out of every step, and an agent approves only while it's active, with Decide an approval and the tool in its own charter.
• Timeouts never approve: when the last step times out, the request is denied.

Approval settings

Under Approval settings, Let an agent review tier 3 actions after untrusted input lets a rule have an agent approve those requests instead of a person. Tier 4 always needs a person. Only the account owner or an account admin can turn it on.

Approvals in Slack and Teams

Approvers can also decide in Slack, and Microsoft Teams can get a notice for each request. See Approvals in Slack and Teams.