Robin ships with a library of built-in diagnostics and actions that Robin manages itself, so there is nothing to enable or disable individually. What you control is which of your own scripts Robin can run, which integrations are connected, and which playbooks it follows. This article explains how that library is organized, what the difference between a check and an action means in practice, and where to see what Robin has actually been using.
Before you begin
To run diagnostics and actions on a device, Robin needs all of the following:
- Robin is activated for the end user's customer or site (AI Center > Settings > Activation).
- The device has a reporting Atera Agent and is assigned to the end user. Robin acts only for the person who submitted the request, on the device assigned to them. Without an assignment, Robin can still answer general questions but cannot act on the device.
Important: If a technician assigned the device to the end user from the Atera console, no verification is needed. Otherwise, end users must complete two-factor authentication before Robin runs any self-service action or software installation for them. The user enters the phone number they want to use for verification, then confirms a code sent by SMS. Without this, Robin can still read device state but cannot change anything on the user's behalf.
Note: The phone number a user enters for verification is written back into their user details in Atera. See Robin: AI assistant for end users for the verification flow and how to reset it.
Checks read, actions change
This distinction determines what Robin can resolve on its own.
| What it does | Example | |
|---|---|---|
| A diagnostic or check | Reads the state of something and reports back. Changes nothing. | Reading how much disk space is free. |
| An action | Changes the state of the device or the system it reaches. | Emptying the Recycle Bin to free that space. |
Most tickets need one of each: a check to find out what is wrong, then an action to fix it.
Note: Sensitive actions, such as adding a user to a group or creating a user, ask for approval before Robin runs them. Approvers can respond by email or in Slack. To define who approves a request type, use a playbook.
Tip: If Robin consistently diagnoses issues but never resolves them, check whether your end users have completed phone verification, or have their devices assigned from the console. Without either, Robin can run diagnostics but not actions.
How Robin's capabilities are grouped
Robin's capabilities split along two lines: whether they run on the device or against a cloud service, and whether they read or change something. Two further categories cover resolutions that need no device operation at all.
| Category | What it covers |
|---|---|
| On device actions | Changes something on the machine: clearing a queue, restarting a service, deleting temporary files. |
| On device diagnostics | Reads the state of the user's machine: disk space, CPU load, printer status, event logs. |
| Cloud actions | Changes something in a connected cloud service, for example a password reset or a group membership. |
| Cloud Checks | Reads the state of a connected cloud service rather than the device. |
| KB article | Resolutions where the answer was documentation, and no device or cloud operation was needed. |
| Playbooks | Resolutions that followed a workflow you defined, rather than Robin choosing its own steps. |
The on-device and cloud categories have different prerequisites, and fail for different reasons. An on-device capability needs a reporting Atera Agent on the machine, assigned to the end user, and it also depends on the operating system: many work on both Windows and macOS, but some are Windows-only, such as anything reading Windows event logs or Outlook profiles. A Windows-only diagnostic simply does not run for a Mac user, so on-device coverage is uneven across a mixed fleet.
A cloud capability has no such dependency, because it never touches the user's machine. It needs the relevant integration or credential connected instead.
See Robin Security & Compliance FAQ for how risk is handled across these categories.
How a diagnostic turns into a resolution
Diagnostics rarely stand alone. A useful one surfaces the state, and one or more actions resolve what it found. Three examples of the pattern:
| The complaint | What Robin reads | What resolves it |
|---|---|---|
| "My computer is slow" | Top CPU consuming processes, memory utilization | Depends on what is named - the value is turning a vague complaint into a specific process. |
| "I can't save anything" | Disk space availability, then the largest folders | Deleting temporary files, emptying the Recycle Bin. |
| "Printing is stuck" | Printer health status, active print jobs | Resetting the print spooler service, clearing the print queue. |
When you decide which scripts to add for Robin, start from the complaints your users actually raise.
Extend the library with your own scripts
The shipped library covers common issues. For anything specific to your environment - a line-of-business application, a vendor tool, a site-specific fix - add a script and expose it to Robin: go to Admin > Monitoring and automations > Scripts, create or edit a script, turn on Enable for AI assistants, then turn on Enable for Robin.
Important:
- Enable for Robin is only available when Enable for AI assistants is on. That toggle makes the script available to AI Copilot, so a script enabled for Robin is always enabled for AI Copilot too. To make a script available to AI Copilot only, leave Enable for Robin off. Turning off Enable for AI assistants removes the script from both.
- Write clear, precise script descriptions. Robin chooses which script to run based on the description, so a vague one either does not get picked or gets picked for the wrong request.
- Require user confirmation makes the script wait for the end user to confirm before it runs. Turn it off for scripts that are safe to run unprompted, such as a read-only check. This setting applies whenever the script is enabled for AI assistants.
- Run script on sets where the script runs: User devices, Domain controller, or Specific device. This setting also applies to the AI assistants section as a whole.
- Max script run time (minutes) is also the action's timeout for Robin. If you change it on an existing script, save the script again so Robin picks up the new value.
See what Robin has been using
Go to AI Center > Analyze. The Actions and diagnostics panel shows how many times Robin used each category over the selected period, with each category's share of the total.
This is the fastest way to find gaps in your configuration. Some patterns worth reading for:
- Playbooks at zero while escalations are high. Robin is solving what it can generically and handing back everything that needed your process.
- Cloud categories at zero. Usually an integration or credential that was never connected, rather than a lack of demand.
- Diagnostics far outweighing actions. Robin is finding causes but not fixing them. Check whether end users have completed phone verification, and whether the scripts Robin needs are enabled for it.
The Ticket flow breakdown on the same page shows how tickets were handled over the selected period: the channel they came in on (for example, Email), assignment to Robin, whether any actions or diagnostics ran, and the outcome. Tickets that ended as Robin assisted with No actions and diagnostics are the ones to look at first.
Important: This panel shows what Robin used, not everything it could use. A category at zero does not mean the capability does not exist.
Prove it before you rely on it
Before enabling Robin for real users, run a handful of the shipped diagnostics end to end on a pilot device and confirm the result appears in the ticket. That tells you two things a list cannot: that the diagnostic works in your environment, and that your technicians can see what Robin did.
Run the test as the end user, from a device that is assigned to them, in a customer or site where Robin is activated. Robin only acts for the person who submitted the request.
Test at least one action as well as the diagnostics, so the phone verification step is proven rather than assumed. Diagnostics will run without it and actions will not, unless the device was assigned from the console.
Then check AI Center > Analyze and confirm your test runs appear in the Actions and diagnostics panel. If they ran but do not show, that is worth resolving before you rely on the panel for anything.
