Overview

​

Setup Overview

Setting up the Autotask integration involves three main steps:

​

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 Microsoft Teams — Technician Mapping — the same mapping that makes “assign this ticket to me” work.

​

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:

​

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.

Time entries are never affected. They carry the technician through a normal Autotask field rather than impersonation, so they work regardless of these settings — and on every other PSA too. An unmapped technician isn’t blocked either — their record is created under Neo and the reply tells them to ask an administrator to map their account.

​

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, role, and billable status for Neo’s entries exactly as it does in the UI, and the work type too, unless you pick one for the agent’s entries on the Time Entries permission group. 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.

​

Autotask emails your admin mailbox about callout delays

Symptom: a burst of Autotask emails — often a dozen or more within a minute — with subjects like Autotask Callout - Delivery Delayed: Neo Tickets callback [ALL] and Autotask Callout - Delivery Resumed: Neo Tickets callback [ALL]. They arrive at your Autotask administrator mailbox, and nothing in Autotask lets you switch them off: the Admin → Extensions & Integrations → Webhooks page is read-only by design, because webhooks are created and managed through the Autotask API. Cause: they are Autotask’s own notice that its outbound queue for a webhook fell behind and then caught up. Autotask sends each notice to two recipients: the address recorded on the callout, and the callout’s owner resource. The owner resource is the Neo API user, and the mailbox on that user is yours — so one copy always lands with you. Autotask does not allow the owner resource on a webhook to be changed after creation. The notices describe an Autotask-side delivery delay, and they name no action for you to take. Neo records the same delay on every callback it receives, so the information is already with us. Fix: turn them off in the dashboard:

1. Open Integrations → Autotask.
2. Expand Advanced settings at the bottom of the panel — it is collapsed by default and summarised as “Filters, callbacks and webhooks”.
3. Under PSA callbacks, each callback row carries a Delay emails button reading On or Off. Click it to switch it.

Delay emails: Off means Autotask no longer mails you about that callback’s delivery delays. The dashboard does not offer you the toggle at the end of the row or the controls behind Manage events — Neo support owns those, and keeps the events your setup requires subscribed. Neo also no longer switches the notices on when it creates a webhook, so a newly connected Autotask tenant never receives them at all. Turning them on again uses the same switch, if you would rather see the notices.

​

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