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: To access AI Center, you need full admin permissions or a role with the AI center permission on its System tab. See Roles and permissions.

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
• Search Playbooks by name or description
• See which Playbooks have insights that need your attention
• See how many tickets each Playbook handled, and open those tickets

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

Category

Playbooks can be organized into categories based on topic, use case, or purpose (for example Power BI, Onboarding, Access Requests, Security). Categorization helps technicians quickly browse, filter, and maintain multiple Playbooks across different customers and departments.

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.

Activity and related tickets

The Activity column shows how many tickets a Playbook handled in the last 90 days. Select the count to open those tickets in the Tickets list and check how Robin applied the Playbook in real conversations.

The Tickets list opens with the Playbook filter set to that Playbook and the Date range set to the last 90 days. You can change either filter from there.

If you selected a customer in View playbooks for, the Tickets list shows only that customer's tickets.

Note: Opening related tickets from the Activity count works with Atera ticketing only. If you use ServiceNow for ticketing, the count is shown but doesn't open the Tickets list.

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:

1. Select Create playbook.
2. Under Let's get started, describe what you want the Playbook to do. Structure your description around the three elements below.
3. Select Generate. Robin builds the Playbook and shows it in two parts: What it does and when it's used and Steps Robin takes.
4. Review both parts. To change anything before you save, see Edit a Playbook below.
5. Replace New Playbook at the top of the page with a name for the Playbook.
6. Under Category, select a category, or type a new one and press Enter.
7. Select Save. The Playbook created. confirmation appears.

A new Playbook is saved as disabled. When you're ready for Robin to use it, turn on the toggle at the top of the Playbook. The label changes from Disabled to Enabled.

Note: A generated Playbook isn't saved until you select Save. Select Cancel to discard it.

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")

Edit a Playbook

You can change an existing Playbook in two ways: ask Robin to refine it, or edit the text yourself. Open the Playbook from the Playbooks list to start.

To refine a Playbook with Robin:

1. In the refine box at the bottom of the Playbook, describe the change you want. For example: "Ask for the device name before running the script."
2. Select Generate. Robin updates the Playbook.
3. Review the changes, then select Save. The Playbook created. confirmation appears. Select Cancel instead to discard the changes.

To edit a Playbook manually:

1. Select Edit at the top of the Playbook.
2. Change the text in What it does and when it's used, Steps Robin takes, or both.
3. Select Save. The Playbook created. confirmation appears. Select Cancel instead to discard your changes.

Tip: Keep specific trigger phrases in What it does and when it's used. Robin reads this text to decide when to run the Playbook, so a vague description such as "Helps with tickets" makes the right Playbook harder to pick.

Each time you save, Atera checks the Playbook again and updates its insights. See Review Playbook insights below.

Review Playbook insights

Playbook insights flag steps that Robin can't carry out, or that need your review, before a Playbook handles a real ticket. Atera checks a Playbook when Robin generates it and each time you save it.

Each insight is one of two types:

• Red: Robin can't carry out the step. Nothing in your account can perform the step, the step works through a system that isn't connected to your account, or the step names a technician, technician group, end user, custom field, or email template that doesn't exist in your account.
• Yellow: Robin can carry out the step, but something needs a check. For example, a step leaves out details its action needs, a name matches more than one technician, a named technician is disabled, an integration needs each end user to approve access first, or a step duplicates or contradicts a ticket automation rule.

For example, these red insights flag two steps that work through JumpCloud, which isn't connected to the account:

These yellow insights flag two steps that leave out the shared mailbox address their action needs:

Insights also flag two writing rules:

• Escalating or resolving the ticket must be the last step on its path. Talking to the end user or adding an internal note can still come after it.
• A step that tells the end user what Robin is about to do must come before that action, not after it.

To review a Playbook's insights:

1. Open the Playbook. If it has insights, the Playbook insights panel opens. To open it yourself, select Playbook insights at the top of the Playbook.
2. Read each insight and fix the step it describes. See Edit a Playbook above.
3. Select Dismiss on an insight you've checked and want to keep as is. The insight moves to Dismissed at the bottom of the panel.

To bring back a dismissed insight, select Restore. When nothing is left to review, the panel shows All insights reviewed.

On the Playbooks list, a wrench icon with a number next to a Playbook's name shows how many insights still need attention. Red means at least one step can't be carried out.

Important: Insights don't block a Playbook. You can save and enable a Playbook that still has red insights, and Robin runs it when its trigger matches. Fix red insights before you enable the Playbook.

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

Three 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. Playbook insights flag a step that duplicates or contradicts an automation rule with the same trigger.
• 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:

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:

1. Review your automation profiles for anything covering the same area.
2. Review your auto-healing scripts and threshold profiles.
3. 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.

Related articles

• AI Center: Optimize
• Manage ticket approval requests
• AI Center: Model Context Protocol (MCP) integrations
• AI Center: Cloud actions
• AI Center: Definitions
• Automate patch management via automation profiles
• Auto-healing scripts
• Manage alert threshold profiles

Updated October 2026: added editing a Playbook, Playbook insights, and opening related tickets from the Activity count, and updated the steps to create a Playbook.