Skip to main content

Attention Queue

The Attention Queue holds agent actions that need your approval, such as sending an email, creating an invoice, or changing an ad budget. Action types use Propose by default: the server stores a pending request and waits for an authorized reviewer to approve or reject it.

Administrators can enable Auto-run or Auto-run and notify in Agent Autonomy. Those actions run without entering this queue. Keep an action type on Propose when you want to review it before it runs. The queue sits at the top of the sidebar with a count of pending approvals across agent actions, CRM, and workflows; review AI Activity for recorded agent outcomes.

How an agent action reaches you An agent proposes an action. It is stored as a pending request and appears in the Attention Queue. Nothing runs until a person approves, at which point the tool executes and the outcome is written to AI Activity. Rejecting stops it permanently. Raising an action type to auto-run skips the queue but still records to AI Activity. Agent proposes Writes down intent Attention Queue Stored pending Approve Tool runs now Reject Stops permanently AI Activity Permanent record Auto-run tiers skip the queue; the record still happens

Propose actions wait for server-side approval; auto-run actions bypass the queue. Everything starts on Propose, and the gate queues the action whenever the policy cannot be read.

Actions on Propose wait for approval. Administrator-enabled auto-run actions bypass the queue.

What's included​

PageWhat it's for
Attention QueueCompact review rows, search and filters, plus individual or bulk Approve / Reject
Agent AutonomyPer action type, whether the agent queues for approval or runs on its own
Agent BudgetsEach agent's monthly AI credits against a cap, and pausing an agent outright
AI ActivityThe record after the fact: what was proposed, approved, executed, rejected, and what it cost

The page header and sidebar both read Attention Queue. The subtitle explains that Waiting on you contains your actions, while administrators can use Team for teammate email drafts.

Getting started​

  1. Open Attention Queue from the top of the sidebar. The number beside it is how many approvals are waiting across agent actions, CRM, and workflows.
  2. Scan the compact rows. Each one shows the action type, subject or title, a one-line preview, the recipient where there is one, the proposing agent, and how long it has been waiting.
  3. Use search, the Agent and Tool filters, or Oldest first to bring the right work to the top. The default order is newest first.
  4. Open a row to read the full proposal. This is the actual content of what would happen, not only a summary.
  5. Select Approve to let one action run now, or Reject to stop it permanently. To decide several actions, select their checkboxes and use Approve selected or Reject selected.
  6. Work down the list. When it is clear you see No actions awaiting review.

What lands in the queue and why​

Action types start on Propose and arrive here by default. Types an administrator has moved to an auto-run tier bypass review; check Agent Autonomy for your workspace's current policy.

The actions available to agents today are:

AreaWhat the agent proposes
Email and CRMSend an email, create a follow-up task, complete a task, update a contact or deal
BillingCreate an invoice, send an invoice, record a payment, draft invoices from approved time, place a collections call
SalesCreate a quote
SchedulingDraft a shift, propose a schedule, publish a week of shifts
MarketingAdjust a campaign's daily budget, pause or resume a campaign at the ad provider
OtherCreate a support ticket, file a compliance task, assign a learning path

Some of these are recoverable and some are not. Sending an email and placing a collections call cannot be taken back once they go out. Publishing a week of shifts is only partly reversible, since people will already have seen it. Read those proposals with more care than a draft task.

Proposals also appear inline in Ask SaaSy. If a chat answer produces a proposed action, the same review card is shown in the conversation with the same two buttons, and deciding there is the same decision as deciding here.

Finding and grouping work​

The queue starts with the newest work and presents each proposal as a compact row. Search matches the action type, recipient, subject or title, agent, and preview. The Agent and Tool filters can be combined with search, and Oldest first reverses the order. Select all visible selects only the actionable rows left in the current search and filter view.

Email drafts with the same recipient and subject are grouped into one row. Differences in letter case, extra spaces, and repeated Re:, Fw:, or Fwd: prefixes do not create another group. The newest draft represents the group, and a badge shows how many drafts the row contains. Non-email actions stay separate.

The server also prevents an old email draft from competing with a newer version. When an agent submits another pending email from the same connected mailbox to the same recipient with the same subject, the newer draft replaces the older one in the queue. The older proposal is marked superseded and can no longer be approved.

Reviewing an item​

What you see depends on the kind of action.

A drafted email shows To, Subject, and Body, rendered as the recipient will receive it. These are the stored bytes of the proposal, not a re-rendering, so what you read is what gets sent.

An ad spend change shows the Campaign, and where SaaSy could measure them, Recent spend, Baseline cost per conversion, and Current daily budget, each with the account's currency code. Below those, the proposed change is stated as a sentence, for example "Proposed change: move this campaign's daily budget by 20%, from 100.00 USD to 120.00 USD per day." followed by the reversal, "Reversal: one click on Undo restores the previous daily budget of 100.00 USD per day." The campaign name and the money figures are taken from your own spend records rather than written by the agent, and anything SaaSy could not measure is left off the card rather than guessed at.

Everything else shows the action's parameters as a labelled list, so you can read exactly which record, which amount, and which dates are involved.

If the list fails to load you get an error panel with Retry rather than an empty queue. Treat an empty-looking page with an error on it as unknown, not as clear.

Approving, rejecting, and changing your mind​

Most cards are read-only: you approve exactly what the agent wrote, or you reject it. Email drafts are the exception. A pending Send email card has an Edit button that lets you fix the recipient, subject, and body before approving, so a nearly-right draft does not have to be thrown away. The saved draft is re-checked by the server and the card re-displays exactly what is queued, so what you approve is what gets sent; an Edited badge marks a draft a reviewer changed. The server rejects a save or approval if another reviewer has changed the draft since you read it. Refresh the card and review the latest version before trying again. For anything else that is nearly right but not quite, reject it and send your own, or adjust the agent's instructions and let it propose again.

Where a proposal names a record it would touch, such as the contact an email goes to, the campaign a budget change lands on, or the invoice a payment records against, the card shows a View record link to that page, so you can inspect or edit the record itself before deciding. Each card also shows how long the proposal has been waiting; a proposal that has sat for several days is marked so a stalled queue is visible rather than silent.

For a bulk decision, select individual rows or use Select all visible. The bulk buttons show how many selected actions you are allowed to approve or reject. Before bulk approval, the confirmation states exactly how many emails will be sent. Each selected action is decided independently, so one failure does not block the rest; the result reports how many succeeded and failed, and failed rows remain available for review.

Approve records your decision. Once the action has every required approval, it runs immediately while you wait and is recorded in the outcome ledger that AI Activity reads from. The record carries the agent that proposed it, the parameters, who approved it, and how long it took. An approved action is claimed once, so double-clicking or two reviewers approving at the same moment still runs it exactly once.

Reject is final for that proposal. The action never runs, and the decision is recorded. The agent is free to propose something again later.

If a decision fails, a message appears: Could not approve this action or Could not reject this action. An approval error does not guarantee that nothing changed: the action can run before its outcome is recorded. Check the affected record and AI Activity before trying again. If the outcome is unclear, contact support with the action details instead of submitting it again.

Ad spend changes are the one case with an undo. After you approve one, the card stays on screen showing approval and confirming that the change is live at the ad provider. An Undo button restores the previous budget or status at the provider. The same undo is also available to administrators on the change's row in AI Activity, where it stays offered after a reload. An already-undone change reads (undone) instead.

Pending proposals expire after 14 days by default. The service operator can configure this review window. Expiry never runs the action: it removes the stale proposal from the pending queue and marks it expired. If the work is still needed, the agent must submit a current proposal for review.

The badge and how you find out​

Two places carry the count, and they show the same number: everything waiting on a decision you can make, including pending agent actions, CRM approval requests, and workflow approvals assigned to you.

The Attention Queue item in the sidebar shows a badge with that total, and hovering it reads "3 pending approvals". The notification bell in the header shows the same number as its main badge, and opening it puts a row at the top reading "3 actions awaiting approval" and "Review in the Attention Queue", above your ordinary notifications. That row stays put when you mark notifications as read, because approvals are not notifications. A second, smaller dot on the bell means you also have unread notifications waiting behind it.

Both counts refresh about once a minute while you have the product open. If the count cannot be fetched, no badge is shown rather than a zero that would be misleading.

The Needs you band on Command Center is the same idea in summary form. It shows an approval count and up to three compact, grouped rows, with links to the full queue and the remaining items. It also lists CRM approval requests, workflow approvals, returned delegations, stored decisions, and chase nudges, so one glance covers every surface that can hold work for you.

SaaSy does not email you when something enters the queue. The badge and the bell are how you find out, so if agents are running unattended, plan on someone opening the product regularly.

Who can act on the queue​

The Attention Queue is not limited to administrators. What appears under Waiting on you, and which buttons are available, depends on the kind of action and your authority:

  • For an email sent from a person's connected mailbox, the mailbox owner or a member with delegated mailbox access can approve or reject it. A workspace administrator who does not have that mailbox authority cannot approve or reject the email on the owner's behalf.
  • Actions that change shared workspace resources, such as invoices, tasks, and campaigns, require a workspace owner or admin, or an authorized SaaSy platform staff role.
  • Administrators also get the Team view for email drafts waiting on other mailbox owners. They can nudge the owner or cancel a send as a safety control, but they cannot send as that person.

If dual control is enabled for email, the mailbox owner or delegate approves first and a different administrator supplies the second approval.

These are server-side controls, not only hidden buttons. The list and every approve, reject, cancel, nudge, and undo request are checked against the signed-in user's verified tenant, role, and mailbox authority. Opening a direct URL does not bypass those checks.

If someone needs to decide shared workspace actions, give them an administrator role under Settings → Roles and permissions. Email approval follows mailbox ownership and delegated mailbox access instead. See Team and roles for how roles are assigned.

Changing what arrives here​

Agent Autonomy is where you decide how much lands in the queue in the first place. Each action type has an Autonomy tier with three settings:

TierEffect
Propose (queue for approval)"The agent queues this action for a human to approve. This is the default and the safe floor."
Auto-run and notify"The agent runs this action immediately, then records it for you to review."
Auto-run"The agent runs this action immediately and silently. Every run is still fully audited."

Everything starts at Propose, and it stays there until an administrator deliberately changes it. The floor is what the queue depends on: if the policy cannot be read, is not set, is switched off, or is not understood, the action is queued rather than run. Raising a tier is the only way to take actions out of the queue, and it is a decision only an administrator can make.

Each card also shows a Has side effect tag where the action changes something outside SaaSy, and a tag reading Queued, Automated, or Default so you can see at a glance which action types you have moved off the floor.

How spend caps affect auto-run

Once you choose either auto-run tier, a Spend cap (USD, optional) field appears on that action type. An action requires approval if its declared cost exceeds the cap or its cost is unknown.

Four action types attach a real amount, so a cap compares against the actual figure: Record payment (the payment amount), Create invoice and Create quote (the document's value, rounded up; tax is counted and discounts are not, so the cap never sees less than the real total), and Adjust campaign budget (the daily increase; a budget cut is never blocked by a cap).

Every other action type has no amount SaaSy can know before running it. Send invoice, for example, is given only an invoice to send, and its value lives in your records. Those count as "cost unknown", so setting a cap on them keeps them in the queue even when their tier allows auto-run. That is deliberate: a cap means you want a ceiling on this action type, and if we cannot prove an action is under your ceiling, we ask you rather than assume it is free.

Leave the field empty only if you want that tier to run without a per-action spending ceiling. The cap does not replace your review of an action you choose to approve.

Eligible auto-run actions bypass the Attention Queue; actions held by a spend cap remain there. Automatic outcomes are recorded in AI Activity after the fact. You lose the opportunity to reject each automatic action before it runs; an execution or recording error may need investigation. Change tiers for an action type only after you have watched that type in the queue for a while and agree with what the agent was proposing.

Agent Budgets is a separate control. It caps each agent's monthly AI credits and lets you pause an agent entirely, which stops it proposing anything. It does not decide what needs approval.

Availability​

The Attention Queue belongs to no navigation module. For roles that can reach it, the queue stays in the sidebar whatever industry pack your workspace uses and whatever is switched off under Settings → Navigation. It cannot be hidden that way. Scoped professional and custom roles can still be limited by their assigned route permissions.

There is no separate entitlement and no add-on to buy for the queue itself. It is not sold, and opening it never shows an upsell card: if agents are proposing work in your workspace, the place to approve it is included. What your plan includes is which AI features run in the first place, which is covered in the plan table. There is no free tier, so an active subscription is required. Your role and, for email, your mailbox authority decide which proposals you can see and act on.

See Modules, packs, and plans for how visibility and entitlement interact.