AI Center: Playbooks

Playbooks extend Robin's automation capabilities by letting technicians teach the AI how to behave in specific support scenarios.

Similar to Automation Rules, each Playbook starts with a trigger - typically when an end-user initiates a chat with Robin via the Portal, email, or any other supported communication channel. Technicians then define the conditions that must be met and the actions Robin should execute when the trigger fires.

Technicians describe these rules in plain language through a free-text prompt, and Robin automatically generates a structured, step-by-step workflow.

This empowers IT teams to build tailored automations without scripting, ensuring faster and more consistent ticket handling.

Before you begin

Important: Full admin permissions are needed to access AI Center.

Playbooks vs. other Atera features

Playbooks are exclusively for Robin. They do not apply to AI Copilot, and they are not designed to run continuous diagnostics on workstations (for that, use Threshold Profiles with self-healing scripts). Playbooks execute when Robin is triggered by an end-user interaction.

Access AI Playbooks

Go to AI Center > Optimize > Playbooks.

From the Playbooks tab, you can:

View all existing Playbooks
See the category assigned to each Playbook
Check whether a Playbook is enabled or disabled
Enable or disable Playbooks as needed

This centralized view allows technicians to easily manage automations across customers and use cases.

Enabled and disabled

Each Playbook has an activation toggle:

Enabled: The Playbook is live and will execute automatically when its trigger condition is met.
Disabled: The Playbook remains stored but inactive - useful for testing, revising, or temporarily pausing automations.

Tip: An Activity count of 0 on an enabled Playbook means its trigger has never matched a real ticket. Either the scenario has not come up yet, or the trigger is narrower than you intended.

Customer selection

Playbooks can be assigned per customer, allowing automations to reflect each customer's unique processes or systems. Use View playbooks for at the top of the page to select the customer a Playbook applies to, so automation behavior remains relevant and context-aware across managed environments.

Create a new Playbook

To create a custom AI-driven workflow:

Click Create Playbook.

Enter a Playbook name.
Select an existing category or create a new one.
Add a description that clearly explains the Playbook's purpose.

When writing your Playbook, structure your prompt in plain language around three elements:

The trigger: what event starts the Playbook (for example, "When an end-user requests access to a system...")
The conditions: any requirements that must be met (for example, "...only if the user is in the Marketing department")
The actions: what Robin should execute (for example, "...send an approval request to their manager and assign the ticket to the IT Security group")

Supported Playbook actions

Playbooks can perform a wide range of automated actions on tickets, allowing for fully customizable workflows.

Ticket management

Change ticket status
Change ticket type
Change priority
Change custom statuses

Assignment and ownership

Change assigned technician
Assign ticket to a technician group
Forward ticket to an email

Communication and documentation

Add an internal note
Write a public reply
Send an email template

Approvals and escalations

With the Entra ID integration enabled, Robin can pull organizational data such as a user's direct manager to dynamically route approval flows and automations.

Create an approval with a named approver
Create an approval routed to the requester's direct manager (via Entra ID integration)

Automation and integrations

Run script
Run cloud action
Reference Knowledge Base (KB)
Reference MCP integration
Install software

Pair Playbooks with Cloud Actions and MCP integrations to let Robin control external software - for example, creating a task in Asana, provisioning a user in a third-party system, or querying data from an external API.

Referencing Knowledge Base

A Playbook step can search and reference an internal Knowledge Base - a KB that isn't visible to end users. Because it's internal, Robin doesn't share a link to it in the conversation; it reads the KB to pull the information it needs and uses that information in the following steps.

This is useful for looking up mapped or per-site details, for example:

Printer mapping: when an end user asks to add a printer, Robin looks up the printer's name or IP in your printer-mapping KB, then uses it to run the next steps.
Per-site passwords: when an end user asks for a machine or Wi-Fi password, Robin checks the end user's site, finds the matching password in your internal KB, and provides it to the end user.

How approvals behave

An approval step pauses the Playbook until a decision is made, then continues down the approved or rejected path. A few behaviours are worth knowing before you build one.

Name your approvers explicitly

Robin sets ticket approvers from the instruction in your Playbook step, so the wording matters. Use a direct instruction:

Set allison@example.com and dave@example.com as the ticket approvers.

Note: Describing an approval loosely, for example "generate an approval request and send it to someone", may not produce an approval request at all. Robin can read that as an instruction to email a person instead. Set the approvers explicitly.

Tip: If your approvers are technicians rather than end users, say so in the step. It removes any ambiguity about who Robin is looking for.

All named approvers must approve

Important: When you assign more than one approver, every one of them has to approve before the Playbook continues. There is no setting for "any one of these people". A ticket waiting on some but not all approvers shows an Approval Status of Partially Approved.

Tip: If you want redundancy without one absent approver blocking the ticket, add an instruction to the Playbook to the effect that the request counts as approved once at least one approver has approved it. This is Playbook wording rather than a configuration option, so test it before relying on it.

Where approvers respond

End users approve from the portal. Technicians can approve or reject from the Admin Portal, so an approval can be picked up from the ticket queue by whoever is available.

Let the Playbook create the approval request

Warning: Do not send the approval request manually from the ticket page when a Playbook is handling the approval. Robin will not recognize a manually created request, and will not see the approval decision when it is made. The Playbook stays waiting.

Track approvals outside the Playbook

Every ticket carries an Approval Status: Pending Approval, Partially Approved, Approved, or Rejected. You can add it as a column on the Tickets list, filter by it, and use it in automation through the Approval Status Changed trigger and the Approval Status condition. Approvers can leave a comment with their decision.

See Manage ticket approval requests.

Tip: An automation on Approval Status Changed is the practical way to chase an approval that has been sitting too long, since the Playbook itself waits without prompting anyone.

AI-driven workflow creation

Technicians define Playbooks simply by describing their intent in plain language. Robin interprets the description and generates a structured flow, including steps, conditional logic, and execution paths.

Example prompt:

"If a user requests access to SharePoint, assign it to Technician A, get approval from their manager, and notify IT Support."

The AI translates this into a ready-to-run automation, which the technician can review, categorize, and activate.

Common use cases

Playbooks typically fall into three categories:

Approval flows: When an end-user requests specific hardware, Robin checks Entra ID for the user's manager and routes an approval request to them.
Information gathering: When an end-user requests time off, Robin asks for start date, end date, and reason, then emails the details to the responsible HR manager.
Autonomous actions: When an end-user reports a specific IT issue, Robin runs a designated script from the script library; if unsuccessful, it escalates to a predefined technician group.

Avoiding conflicts with other features

Two Atera features can interact with Playbooks in ways that may cause unexpected behavior:

Ticket Automation Rules: Automation Rules may overlap with Playbook triggers. When both apply to the same ticket, the Playbook takes precedence and will override the Automation Rule. Review existing rules to avoid unintended outcomes.
Knowledge Base articles: KB articles can supply Robin with information that contradicts your Playbooks. To prevent conflicts, archive or delete any KB articles that cover processes now handled by a Playbook.
IT automation profiles and auto-healing scripts: These already act on your devices without a Playbook. An automation profile handles conditions on a schedule, and an auto-healing script remediates them with no human involved. A Playbook that handles the same condition on request becomes a second owner of it. See One owner per condition below.

One owner per condition

Three different mechanisms can remediate the same problem on a device, and they are triggered by different things:

Mechanism	What starts it
IT automation profile	A schedule.
Auto-healing script	An alert, with no human involved.
Playbook	An end user asking Robin for help.

Give every condition exactly one owner. If a disk-space threshold is already remediated by an auto-healing script, a Playbook that clears temporary files when a user complains about disk space is a second owner of the same condition.

Warning: When two mechanisms own the same condition, the same fix can run twice. The second run has nothing left to do, and a remediation that finds nothing to remediate looks like a failure rather than a duplicate.

Deciding which one should own it

Ask whether the condition needs a person.

It should be fixed before anyone notices. That is an automation profile or an auto-healing script. No conversation adds anything, and waiting for a user to complain means the problem persisted longer than it needed to.
It needs context only the user can give, or the user needs telling what happened. That is a Playbook. Robin can ask which application, which printer, or which file, and confirm the outcome in the conversation.

Tip: A useful split is to let the automated mechanism own the condition and let the Playbook own the conversation. The auto-healing script clears the disk; the Playbook explains to the user what happened and why their files went, without clearing anything itself.

Before you enable a Playbook that touches devices

Check what already handles the condition:

Review your automation profiles for anything covering the same area.
Review your auto-healing scripts and threshold profiles.
Where you find an overlap, decide which one owns the condition and remove the remediation from the other. The Playbook can still handle the conversation.

Note: This is easy to miss because both mechanisms work. Nothing warns you that a condition has two owners, and the symptom appears later as an intermittent failure on whichever one runs second.

How can we help?

Common topics:

MSP

IT Department

Related articles