Setup Overview
Setting up the Autotask integration involves three main steps:Creating an API Member
Set up a dedicated API user with the proper permissions and security levels for Neo Agent to access your Autotask system.
Connecting to Neo Agent
Configure the connection between your Autotask system and Neo Agent using API credentials and integration settings.
Configuring End-User Email Notifications
Configure how Neo Agent sends email notifications to your customers when updating tickets.
How Permissions Work
Neo Agent uses two layers of access control: the Autotask security level sets the maximum API access (configured during setup), while the Neo Agent dashboard controls what Neo actually does — which areas it can read, write, or ignore, and whether actions require technician approval.Records Created From Teams Carry the Technician’s Name
When one of your technicians asks a chat agent — in the Teams bot or the dashboard chat — to log time or raise a ticket, Autotask records it under them, not under the Neo API user. A time entry lands on their own timesheet; a ticket, note or attachment they asked for shows their name in the ticket history. This is what makes Teams usable as a quick time-entry front end: “log 20 minutes on T20260729.0031, replaced the switch” from a phone, credited to the right person. Nothing to switch on. It applies as soon as the technician is mapped to their Microsoft account under Teams Technician Mapping & Availability — the same mapping that makes “assign this ticket to me” work.Automations are never attributed. Only chat turns driven by a person are. Anything Neo does on its own — a triage agent, a scheduled sweep — is still recorded as Neo, so your audit trail always shows what was automated.
What Autotask needs
Autotask calls this Resource Impersonation, and it checks two security levels — this catches people out, because granting only the first looks like it should be enough:1
The Neo API user's security level
Admin → Account Settings & Users → Security Levels → edit the level your Neo API user is on → Web Services API → Resource Impersonation → Full Permission. This is part of the standard security level setup, so it’s usually already done.
2
Each technician's own security level
The level a technician sits on must also allow resources on it to be impersonated. Autotask states this on the same page: “The security level of the resource being impersonated must be configured to allow impersonation.”This is the one that’s usually missed, and it’s per security level, not per tenant — so you can see most of your technicians attributed correctly while everyone on one particular level is not. Restricted or administrator-style levels are the common culprits.
If Autotask refuses
The record is still created — it’s just recorded under Neo rather than the technician. Neo never drops the work to preserve the attribution:- The technician is told in the chat reply that the record may need reassigning, so they find out immediately rather than a month later in their utilization figures.
- An inbox item and email go to your administrators naming both security levels above, since the person in the chat usually can’t change either.
Creating, not changing. Autotask records who created a record and does not revise that on edit, so a status change, reassignment or close on an existing ticket stays recorded as the API user. This is an Autotask behaviour, not a Neo limitation.
Troubleshooting
Time entries stay Not Posted
Symptom: time entries created by Neo show Not Posted and accumulate in Contracts → Approve & Post → Labor, while entries your technicians type in post immediately — even on the same ticket and contract. Opening a Neo entry and hitting Save & Close without changing anything posts it. Cause: Autotask posts a time entry — turns it into a billing item — only on an interactive save in the Autotask UI. Entries created through the Autotask API are always created unposted, and the API offers no way to post them; even a contract whose posting preference is “Immediately without review” auto-posts UI entries only. This is an Autotask platform rule that applies to every API integration, not a Neo behaviour, and nothing on the entry is wrong: Autotask derives the contract, work type, role, and billable status for Neo’s entries exactly as it does in the UI. Posting is the only difference. Fix: fold a bulk post into your existing billing routine — open Approve & Post → Labor, select all, post. It handles up to 500 items in one click, so it stays a one-minute task at any realistic volume. Two details worth getting right:- Don’t filter that view by resource. With technician attribution, time logged from chat is recorded under the technician who asked — a filter on the Neo API user would miss those entries.
- Editing each entry and re-saving it also posts it, but one at a time — the bulk sweep is the same action for the whole queue.
If automatic posting of API-created labor matters to your billing flow, that capability has to come from Autotask — it’s worth a feature request to Kaseya/Datto asking that API-created time entries honour the contract’s “Immediately without review” posting preference.
Prerequisites
Before starting the integration setup, ensure you have:- Admin Access: Full administrative access to your Autotask system
- API Permissions: Ability to create API users and manage security levels
- Workflow Access: Permissions to create and manage Autotask workflow rules
