Robin doesn't do everything the moment it's switched on. What Robin can actually do for your end users depends on how much of the surrounding setup is in place - this article walks through that progression, from basic activation to fully custom automation, so you know what unlocks at each stage and why.
Activation: Robin is present, but limited to what it already knows
Turning Robin on for a site or customer (AI Center > Settings > Activation) makes it available in the portal and by email, plus any communication apps you connect under AI Center > Settings > Configuration: Slack, Teams, and the Robin web widget. At this stage, Robin can chat with end users and search whatever knowledge base content already exists. Whether it can act on anything depends on the next stage: Robin can only run its built-in diagnostics and actions on a device that is assigned to the end user, and password resets need a connected domain or identity provider.
Setup: the checklist that expands what Robin can actually do
AI Center > Setup opens the Initial Setup page. It tracks what you have completed for the selected customer or site and rolls it up into an Overall optimization score. The page has two sections:
- Fundamentals: whether Robin can operate and act at all. Identity providers lets Robin follow your organization's roles and permissions. Contacts assignment links end users to their agents and phone numbers, so Robin can act on the right device for the right person. Customers activation turns Robin on, Communication channels sets where users reach it, and Domain actions connects your domain controllers for password resets. None of these are Robin settings exactly - they're prerequisites that determine whether Robin's built-in actions will actually work when a user asks.
- Power up your setup: what Robin knows and what it can do beyond the basics. Knowledge base articles and Definitions turn generic answers into your organization's answers. Integrations, Playbooks, and Scripts extend what Robin can do (see the stages below).
This is the stage most likely to get skipped, since Robin will still chat and search KB content without it - the gap only shows up later, when an end user asks for something Robin should be able to do and can't, because a contact isn't linked to an agent or a domain isn't connected.
Note: The score measures configuration, not results. For how Robin is actually performing, see AI Center: Analyze.
Integrations: connecting Robin to the rest of your stack
Robin's on-device actions work through the Atera Agent. Anything outside the device - your identity provider, cloud apps, other business tools - is unlocked under AI Center > Integrations:
- Product integrations: connect an identity provider (Microsoft 365 & Entra, Google Workspace, Okta, or JumpCloud), built-in integrations such as Microsoft Intune or Salesforce, and MCP integrations such as Atlassian, Monday, or Notion. You can also add a custom MCP.
- Cloud actions: API calls Robin can make to a service that has no native or MCP integration. Turn on Activate for Robin on an action to let Robin run it when a user's request calls for it.
- Knowledge base: connect the knowledge sources your team already uses, such as Confluence, Notion, or SharePoint, and describe what each source contains and when Robin should use it. Sources are managed per customer. The Atera Knowledge Base is listed by default and needs no description. It can't be disabled while it's the only source.
This stage is what fills the Cloud Checks and Cloud actions categories in AI Center > Analyze. If those stay at zero, an integration is usually missing.
Configuration: shaping how Robin behaves once it can act
The rest of AI Center > Settings controls behavior rather than capability:
- Configuration: communication apps, reply language, ticketing rules, and follow-up and resolution timing.
- Custom fields: how Robin fills ticket custom fields.
- Software: which Windows and Mac software end users can install themselves.
- Excluded addresses: email addresses Robin should not handle.
These don't unlock new abilities so much as decide how the abilities from the earlier stages actually get used day to day.
Playbooks and scripts: custom automation beyond the built-in action library
Everything above works from Robin's existing, built-in set of actions and diagnostics. AI Center > Optimize > Playbooks is where that stops being the ceiling - a Playbook lets you describe a support scenario in plain English and have Robin follow a custom, multi-step workflow for it, including things with no built-in equivalent (routing an approval to a specific person, referencing an internal-only KB for per-site details, chaining a script and a cloud action together).
For fixes the built-in library doesn't cover, add your own scripts under Admin > Monitoring and automations > Scripts. Turn on Enable for AI assistants, then Enable for Robin. See What Robin can check and change on a device.
Important: Ticket Automation Rules run independently of playbooks. If a rule acts on the same ticket, for example by assigning new tickets to a technician group, it can take the ticket away from Robin before the playbook finishes. Don't repeat automation rule steps in a playbook, and check your rules for conflicts before relying on a playbook.
This is the layer where Robin stops being "the built-in assistant" and starts reflecting your organization's actual processes.
Putting it together
The practical takeaway: if Robin isn't doing something you expect, the fix usually isn't in Robin's own settings - it's in whichever earlier stage was skipped. A password reset that doesn't work is usually a Setup problem (no domain connected, no identity provider synced, or no mobile number on the contact), not a Configuration problem. A request that needs a cloud app Robin can't reach is an Integrations problem. A support scenario Robin handles generically instead of your way usually needs a Playbook, not a Settings change.
