Tool approvals
Individual tools — typically ones that write to your CRM or take another destructive or hard-to-reverse action — can be marked as requiring approval. When Swan calls one of these in a chat conversation, execution pauses and an approval card appears asking you to approve or deny it before anything happens. Deny it and the action is skipped; approve it and Swan carries on. Whether a given tool requires approval is configurable per organization — an admin can turn approval on or off for a specific tool, and set the minimum role required to use it at all. This is separate from sequence approval, described next.Sequence approvals
Outreach sequences default to holding for your approval before anything sends — Swan can only skip this and send automatically for a given sequence if it’s explicitly instructed to. While a sequence is awaiting approval you can review and edit each step’s message (and subject line, for email) before approving, reject the sequence to stop it, or approve it to let sending proceed. See approvals for the full workflow.Tasks
For judgment calls Swan can’t or shouldn’t make on its own — an ambiguous data conflict, a decision that needs business context Swan doesn’t have — it creates a task and assigns it to a person, rather than guessing or blocking. Tasks show up on the Desk with a description and suggested next actions; nothing about the underlying run is stuck waiting for the task to be resolved unless the work genuinely depends on the answer. See desk and tasks.The background asymmetry
Tool approvals work differently depending on where the tool call happens. In a chat conversation, an approval-required tool call pauses execution and waits for your decision — that’s the approval card behavior above. During a trigger run happening in the background, there’s no chat window open to pause on, so Swan doesn’t wait: it skips the protected action, leaves a note for itself that the action needs human approval, and continues the rest of its work. Getting that skipped action actually approved and executed is then a manual follow-up — check your notifications for the trigger run in question if you expect an action was supposed to happen but didn’t. This means background runs are non-blocking by design: a trigger won’t sit stalled indefinitely because one step needed a human. It also means it’s worth periodically checking runs that call approval-gated tools, since a skipped action doesn’t retry itself.Other guardrails
A few checks apply regardless of approval settings:- Per-sender sending caps. Each connected email and LinkedIn account has its own daily and weekly sending limits, independent of any approval setting — see sending limits.
- Credit checks before running. Swan checks that your org has enough credits before starting billable work; if you don’t, the action is refused up front rather than run partway and left incomplete. See credits.
- Delegation credit reservations. When Swan delegates work across a batch of contacts or companies to sub-agents, it checks that enough credits are available to cover all of them before starting, so a large batch doesn’t run out of budget halfway through.
- Org-scoped data access. Every tool call operates within your organization’s data only — Swan can’t read or act on another organization’s companies, contacts, or sequences. See security.