Before you begin
- A Atlas AVD plan. The Integrations hub is not available on Community
- The Administrator role in Atlas to connect, configure or disconnect a connector. Integrations appears under Administration only for administrators
- A tenant selected in the tenant picker. Credentials are stored encrypted per tenant, so each tenant you manage connects its own account
- An Autotask administrator who can create resources, to create an API user for Atlas
- At least one active ticket queue in Autotask. Atlas files every ticket in a queue
What you can do
- Open Autotask tickets automatically from Atlas alerts, Atlas Reach devices going offline, Atlas Reach checks failing, and failed deployments, with a rule per kind of problem.
- Avoid ticket storms: one open ticket per affected resource, a wait between tickets per rule, and quiet hours during maintenance windows. A repeat adds a note to the open ticket.
- Note the recovery on the ticket when the problem clears, and optionally move the ticket to a status you choose.
- Choose the queue, priority and status new tickets get, and send one customer's tickets to a different queue.
- Create a ticket by hand from the Datto Autotask page.
- Map each Atlas tenant to an Autotask customer, with suggested matches by name.
- See every ticket Atlas opened and its Autotask status, refreshed every 15 minutes.
- Sync Autotask configuration items into Atlas Vault, by configuration item type.
- Ask Atlas Advisor whether Autotask is working, with or without an AI provider.
Step 1: Create an API user in Autotask
In Autotask, go to Admin → Account Settings & Users → Resources/Users and create a new API user. Give it the security level API User (system), and an email-style username such as atlas-api@yourcompany.com; Atlas uses the username to find which Autotask zone hosts your database. Generate its secret (its password) and copy it. In the API Tracking Identifier section, choose Custom (Internal Integration), enter a name such as Atlas AVD, and copy the tracking identifier Autotask shows. A dedicated API user keeps working when staff change.
Step 2: Connect in Atlas
Once connected, the card shows Manage, which opens the Datto Autotask page, and Disconnect. The secret and the tracking identifier are stored encrypted.
- Select the tenant in the tenant picker.
- Go to Administration → Integrations and click Connect on the Datto Autotask PSA card.
- Enter the API Username, the API Secret and the API Tracking Identifier, and click Connect. Atlas finds your Autotask zone, signs in and reads your customers before saving anything; if Autotask rejects the credentials, nothing is stored.
Step 3: Choose the queue
On the Datto Autotask page, open Settings and choose the Queue for new tickets. Autotask needs a queue on every ticket, so until you choose one Atlas opens no tickets. You can also choose the Priority (left on Autotask's default priority, Autotask's default applies) and the Status of new tickets (New unless you change it). Click Save. New tickets are given a due date a day ahead, which your SLA or a technician can move.
Step 4: Map tenants to customers
Open Customers. Each active Atlas tenant has a row: pick its Autotask customer and click Save. Only active companies of type Customer are offered.
- Suggest matches proposes a customer for each tenant that has no mapping yet, matching names while ignoring case, punctuation and suffixes such as Inc or Ltd. A name that matches two customers suggests nothing. Suggestions are only filled in: review them and click Save.
- A mapping can name its own queue, so one customer's tickets can go to a different queue from the default chosen on Settings.
- If a tenant has no mapping and there is exactly one mapping in total, its tickets use that mapping.
Step 5: Create automation rules
Open Automation and click Add automation rule. Give the rule a name and choose what opens a ticket: An Atlas alert fires (a named condition such as Session Host Unhealthy, or any alert type), An Atlas Reach device goes offline, An Atlas Reach check fails, or Provisioning or a deployment fails. Set the lowest severity, how long a device must stay offline or a check must keep failing, and the wait between tickets, then save.
- One ticket per resource: while a resource has an open Autotask ticket from automation, a new alert for it adds a note to that ticket instead (once per alert).
- Wait between tickets: after a rule opens a ticket for a resource, it opens no new ticket for that resource for the number of minutes you set; a device that is still offline when the wait ends gets its ticket then.
- Tickets are titled [Atlas AVD] followed by the rule name and the resource, and the description carries the alert, resource, severity, time and message.
- Autotask rules run whatever the Atlas Flow and ConnectWise setting says, and are managed only on the Datto Autotask page.
When the problem clears
With Resolve the ticket when the problem clears switched on (the default), Atlas adds a recovery note to the open ticket when the resource recovers. To also close it in Autotask, open Settings and choose the status in When the resource recovers, move the ticket to; the list shows your Autotask ticket statuses, such as Complete. With Keep the status (add a note only), closing the ticket stays with your team. Either way the next outage of that resource opens a new ticket.
Tickets and status sync
- Tickets lists every ticket Atlas opened, newest first: the Autotask ticket number (such as T20261030.0001), title, resource, whether automation or a person created it, and its status.
- Every 15 minutes Atlas reads the open tickets back from Autotask and records their status. A ticket your team completes in Autotask shows as Closed, so the same problem can open a fresh ticket next time. Custom statuses that start with Complete, Closed, Resolved or Cancelled count as closed; statuses such as Ready to Close or Pending Close stay open. Sync ticket statuses now on Settings runs it straight away.
- Create ticket opens a short form (title up to 255 characters, description up to 8,000). The ticket is filed under the selected tenant's mapped customer. A double-click or retry does not create a second ticket.
Sync configuration items into Atlas Vault
With Autotask connected, open Atlas Vault → Assets → RMM & PSA sync and click Add sync: pick Datto Autotask as the source, a configuration item type (such as Workstation or Server), and the asset template each item becomes, then map fields. Atlas then creates and updates a Vault asset for each active configuration item of that type every hour, or when you click Run now. Fields you can map include the item's name, reference number, type, serial number, install date, warranty expiry, location and company, and what the RMM audit reported: hostname, operating system, IP and external IP address, MAC address and last user. Values someone edits by hand in Vault are never overwritten.
What the integration does not do
- It does not sync time entries, invoices, contracts, projects, opportunities or contacts, and it does not create or change companies.
- It does not assign a ticket to a resource or set a ticket category; Autotask applies its own defaults.
- It opens tickets against the tenant's mapped customer only; it cannot pick a different company per ticket.
- Notes added in Autotask are not shown in Atlas.
- Configuration item sync only reads Autotask; it never creates or changes configuration items there.
- It connects one Autotask database per Atlas tenant. Credentials cannot be edited in place: disconnect and connect again with the new ones.
GCC High tenants
On a tenant or deployment in Azure Government (GCC High), calls to Autotask are blocked by default, because they can carry VM, host-pool and tenant names to a service outside the Government boundary. Connect fails with an Azure Government (GCC High) egress boundary message and nothing is stored, and pages that read from Autotask stay empty. The operator who runs your Atlas deployment can approve Autotask as a destination that is allowed to receive that data; once approved, the connector works normally. Running in Azure Government does not by itself make a third-party integration GCC High or CMMC compliant.
Switching off and disconnecting
- Switch off: on Settings, turn off Open tickets in Autotask and click Save. Your credentials, mappings and rules stay, but no tickets are opened and statuses are not synced until you turn it back on.
- Disconnect: click Disconnect on the card and confirm. Atlas deletes the stored credentials, stops opening tickets and syncing statuses, and pauses any Atlas Vault asset sync from Autotask. Mappings and rules are kept for when you reconnect. Tickets already opened stay in Autotask. Deactivate the API user in Autotask too if you no longer need it.
Troubleshooting
- Autotask sign-in failed: the username, secret or tracking identifier is wrong, or the API user is inactive. Check the API user in Autotask, generate a new secret if needed, and connect again.
- Autotask did not return a zone for this API user: the API username must be the API user's full email-style username exactly as Autotask shows it.
- No tickets are created: check the integration is switched on, a queue is chosen on Settings (or on the customer's mapping), the rule is enabled and matches the alert, a maintenance window is not active, the wait between tickets has passed, and the tenant is mapped to a customer.
- Choose a default Autotask queue in Settings, or a queue on this company's mapping: Autotask needs a queue on every ticket. Pick one on Settings.
- Autotask refuses the ticket: a chosen queue, priority or status may be inactive now, or a ticket category rule in Autotask requires a field Atlas does not set. Pick another value on Settings, or relax the rule in Autotask.
- Couldn't load this from Autotask: Autotask could not be reached or refused the request. Try again shortly.