Autotask ATES Configuration Checklist for MSPs

Every time a monitoring alert hits your Autotask inbox, the Add Ticket Email Service (ATES) makes a quiet decision: match it to an existing contact, create a new one, or assign it to your own organization. Get that configuration wrong, and you're not just dealing with duplicate contacts. You're dealing with misrouted tickets, broken billing trails, and client records your team can't rely on.

The tricky part is that none of this fails loudly. When the incoming data doesn't match your records, ATES follows its processing rules exactly, which can mean tickets landing in your own organization, placeholder contacts, and reporting that slowly drifts further from reality with every alert cycle.

Here's what's actually happening under the hood, and what to fix first.

How ATES Contact-Matching Logic Works (And Where Configuration Gaps Show Up)

ATES uses a decision tree when processing incoming alert emails. The outcome depends entirely on what's in the XML token appended to the email and how closely that data matches your existing Autotask records.

The three primary matching paths, per the official processing rules, work like this:

• Customer name only: ATES searches for an exact organization name match. No match means the ticket goes to organization ID: 0, which is your own local organization.
• Email address only: ATES searches all contact email addresses (primary, secondary, tertiary). No match triggers a domain-level lookup against organization web addresses. Still no match, and again: organization ID: 0.
• Both Customer name and Email: Customer name is checked first. If the name doesn't match, ATES ignores the email value entirely and assigns to organization ID: 0.

Three configuration gaps create most of the issues MSPs see:

• Name mismatch on exact match: Your RMM sends "Acme Corp" but Autotask has "Acme Corporation." ATES requires an exact match by design, so the names need to agree. Otherwise, the ticket goes to your organization.
• Missing Contact element in XML: If the organization matches but no contact is found, and your XML token doesn't include the <Contact name="Firstname Lastname"/> element, ATES assigns no contact. The ticket gets a note saying no contact match was found, and your workflow rules that trigger on contact assignment never fire.
• Auto-created contacts with incomplete data: If the Contact element is present but the contact doesn't exist yet, ATES creates one. Fields it can't populate get set to "unknown," including potentially required user-defined fields unless you've configured default values.

That last one compounds fast. A week of monitoring alerts from a new client can generate a dozen contacts named "Unknown Unknown" before anyone notices.

The Downstream Impact Nobody Warns You About

A contact or organization mismatch at ticket creation isn't just a data quality issue. It affects downstream processes that depend on accurate ticket-to-organization associations.

Contract billing breaks. Autotask contract associations are organization-specific. A ticket assigned to organization ID: 0 (your local org) won't pull from the correct client contract. Time entries on that ticket may not roll up to the right billing period, and you won't catch it until a contract reconciliation or a client dispute.

SLA reporting becomes unreliable. SLA calculations depend on the ticket being associated with the correct organization, which carries the SLA settings. Misassigned tickets either inherit the wrong SLA or none at all. Your reports show green when a client's response times are actually breached.

Workflow rules don't trigger. Many MSPs use workflow rules to notify contacts at ticket creation. If no contact is assigned (because the XML was missing the Contact element), those rules never trigger. The client doesn't get notified, nobody escalates, and the ticket sits.

ATES does log a note in the ticket description when this happens, but most technicians don't read ticket descriptions on auto-generated alerts.

The Specific Misconfiguration Patterns to Audit First

Most ATES problems I've seen come down to three configuration areas that MSPs set up once during onboarding and never revisit.

Organization name synchronization. ATES requires an exact string match on organization names. If your RMM, documentation tool, and Autotask don't use identical client names, every alert from that client will land in the wrong place. Audit your top 20 clients: compare the Customer name value your RMM sends against the exact organization name in Autotask. Even a trailing space causes a mismatch.

XML token Contact element handling. The <Contact name="Firstname Lastname"/> element is optional but strongly recommended, especially if you rely on workflow rules to notify contacts at ticket creation. If you're using a third-party email parser to forward alerts, you can dynamically populate this field using a tag like <Contact name="%msg_fromname"/>. Many MSPs skip this entirely during setup, then wonder why their contact notification workflows never fire.

New contact creation permissions and UDF defaults. When ATES auto-creates a contact, it populates only four fields: First Name, Last Name, Organization, and Email Address. Any user-defined fields (UDFs) marked as required are ignored unless you've set a default value. If your contact UDFs include required fields without defaults, you're generating technically incomplete contact records that may cause validation issues elsewhere in your instance.

The ATES Configuration Checklist for MSPs

Work through this in order. The first two items catch the majority of ongoing data issues.

1. Validate organization name matching

• Export your Autotask organization list
• Compare against the Customer name values your RMM is sending in XML tokens
• Document every discrepancy and standardize on one naming convention
• Pick Autotask as the canonical source and update your RMM to match

2. Lock down the Contact element

• Confirm every alert template in your RMM includes the <Contact name="..."/> element
• If you're using a third-party parser, verify the %msg_fromname variable is populated correctly before the XML is forwarded
• Test with a manual alert submission and check whether the contact is assigned correctly on the resulting ticket

3. Audit UDF defaults for auto-created contacts

• Review your contact UDF configuration in Autotask Admin
• For any required UDF, set a default value (even a placeholder like "ATES-Created") so auto-created contacts pass validation
• Flag these contacts for periodic cleanup review

4. Set up a recurring data cleanup workflow

• Run a monthly contact search filtered to contacts with "unknown" in First Name or Last Name
• Run a monthly ticket search for tickets assigned to organization ID: 0
• Assign a resource to review and correct these records before they compound into billing disputes

5. Test your domain fallback logic

• If ATES can't match on email, it falls back to matching the email domain against organization web addresses. Verify your organization records in Autotask have the correct website URLs populated, especially for clients whose alerts might arrive without a Customer name value.

Stopping the Slow Leak Before It Becomes a Flood

ATES misconfiguration doesn't announce itself. It accumulates quietly over months until someone pulls a billing report that doesn't match reality, or a client asks why they never received ticket notifications, or a technician notices that half the alerts from a major client are landing in the internal queue.

The fix isn't complicated, but it requires treating ATES configuration as an ongoing operational process rather than a one-time setup task. Standardize your organization names across every tool that feeds Autotask. Include the Contact element in every alert template. Set UDF defaults so auto-created contacts are complete. And run cleanup queries monthly before the data debt gets expensive.

Your data accuracy is only as good as what comes in at the front door. ATES is that front door for a significant portion of your ticket volume, so make sure your configuration is giving it the right information to work with.

Clean data is also what makes automated dispatch accurate. When every ticket lands with the right organization and contact, tools like Rocketship can triage and assign it to the right technician instantly. If you'd like help auditing your ATES setup, our Autotask Consulting team can help, or grab the free Autotask Data Clean-Up Kit.