No-Code Playbooks
Playbooks are admin-defined, deterministic flows: "if a ticket like this comes in, always do these exact things" — instead of leaving it to QueAssist to freestyle a response every time. Use them for the handful of ticket types your team handles the same way every single time (a specific onboarding request, a recurring access request, a known outage category) where you want guaranteed, repeatable steps rather than an AI-generated response.
1. Where to find them (Settings → Playbooks)
Go to Settings → Playbooks (/admin/settings/playbooks). You'll see a list of any playbooks already created, each showing its name, its WHEN/THEN summary, and an active/inactive toggle.
Settings → QueAssist for a playbook to ever fire. They apply to tickets from forms and email, the same channels agentic resolution covers.2. Creating a playbook
Click New playbook and fill in:
- •Name and an optional description — for your own reference.
- •Trigger categories — one or more ticket categories that should match this playbook.
- •Trigger keywords — one or more words/phrases to match against the ticket title and description, for cases where category alone isn't specific enough.
- •Active — toggle off to keep a playbook saved but not currently running.
A ticket only needs to match on category or keywords, not both. If more than one active playbook could match a ticket, an exact category match wins over a keyword-only match; if there's still more than one candidate, the first one found wins — so keep your triggers specific if you're running several playbooks.
3. Adding steps
Steps run in order, top to bottom — reorder them with the up/down arrows once you've added more than one. Five kinds of step are available:
| Step | What it does |
|---|---|
| Run an integration tool | Runs one specific tool from a connected integration — e.g. "check if this user's Google Workspace account is locked." Only tools that are already connected, tool-grant-enabled, and not tier sensitive show up in the picker — a playbook can never do anything you haven't already explicitly allowed in Integrations settings. |
| Set priority | Sets the ticket's priority to Low, Medium, or High. |
| Assign to group | Assigns the ticket to one of your groups. |
| Send a message to the employee | Posts a message on the ticket thread, visible to the requester. |
| Escalate to a human | Stops the playbook and hands the ticket to your agent queue immediately, with a reason you specify — use this as a deliberate "and now a person needs to look at this" step, e.g. after a run_tool step comes back with something a playbook shouldn't decide on its own. |
4. What happens when a ticket matches
When a new ticket comes in and QueAssist runs triage + agentic resolution, it checks for a matching active playbook first. If one matches, its steps run in order instead of the general-purpose AI resolution flow for that ticket — you get the exact same outcome every time a ticket of that shape comes in, rather than the AI deciding fresh each time.
Every run_tool step this triggers is logged in the same Tool-call audit log on Settings → QueAssist as any other integration call, and playbooks are covered by the Emergency stop kill switch — turning that on pauses playbooks along with agentic resolution and integration tool calls.
5. Identity on integration steps
Each Run an integration tool step acts on the ticket subject — the same identity rules as agentic resolution:
1. Raise on behalf of email, if the agent entered one when creating the ticket
2. Affected user
3. The requester
4. Inbound email sender
Example — Account lockout playbook:
1. Run an integration tool → getUserAccountStatus (read — runs automatically when Entra or Google is connected)
2. Run an integration tool → resetPassword (write — only if you enabled it in Integrations)
3. Send a message to the employee → "We've reset your password. Check your email for a temporary password."
4. Escalate to a human → if the status check shows the account is disabled for a reason the playbook should not override
Train agents to use Raise on behalf of whenever the reporter is not the person who needs the fix. Full detail: Identity Scoping & Safety.
Next: read Connecting Integrations & Custom MCP Servers to set up the tools a playbook's run_tool steps can use, Identity Scoping & Safety for portal chat vs ticket rules, or Agentic Auto-Resolution to understand the flow playbooks slot into.