If tickets are landing in the wrong queues, sitting unassigned, or somehow evading your SLA timers entirely, the instinct is to blame the routing rules. But nine times out of ten, the rules aren't broken. They're working exactly as configured, which is the actual problem.
Most Autotask ticket routing chaos traces back to automation settings built during the first chaotic month of PSA deployment and never touched since. Your routing rules are faithfully executing instructions that no longer reflect how your MSP operates. Before you spend another hour debugging workflow logic, it's worth understanding what's actually feeding the machine.
The Service Desk automation settings in Autotask are where ticket assignment, queue routing, and escalation triggers actually live. They're also where the majority of MSP routing failures originate.
The most common offenders:
These aren't edge cases. I've seen MSPs spend weeks convinced they have a staffing problem when they actually have three overlapping workflow rules fighting each other over the same ticket queue.
The fix starts with opening your workflow rule list and sorting by modification date. If most of your rules were last touched during initial setup and you've added five technicians and three new service lines since then, there's your problem.
Ticket categories in Autotask control what fields are visible on a ticket, what defaults apply, and critically, how routing logic can interact with that ticket. They're the silent architecture behind your entire workflow.
When categories are poorly defined, routing automation becomes partially blind. If a ticket doesn't match a category that your workflow rules are built around, it falls outside expected processing entirely. No assignment, no SLA clock, no escalation.
The specific failure pattern I see most: MSPs create a handful of categories early on, then let technicians use them interchangeably. Over time, category selection becomes inconsistent, and workflow rules that depend on category matching start misfiring.
API-only categories add another layer of complexity. In Autotask, you can designate a category as API-only, which hides it from manual selection and applies it only when tickets are created through an integration or import. This is useful and appropriate for RMM-generated tickets. However, if an API-only category is misconfigured or lacks the right default field values, every ticket from that integration arrives malformed from the start.
The practical consequence: your ConnectWise RMM alerts come in with the wrong queue assignment or no SLA because the API-only category assigned to that integration wasn't set up with those defaults. The tickets exist, they're just invisible to your normal triage process.
A large percentage of MSP tickets originate from customer emails. If your incoming email processing configuration is off, tickets arrive already broken before routing even gets a chance to run.
The configuration chain looks like this: customer email arrives, Autotask converts it to a ticket, defaults are applied from your mailbox configuration, and then workflow rules attempt to route it. If the email-to-ticket conversion applies the wrong defaults, the downstream routing logic is working with garbage data.
Common failure points in email processing:
The fix here is straightforward but requires attention. Review each incoming email mailbox configuration and verify: the default ticket category, the default queue, and what happens when organization matching fails. Autotask lets you configure notification behavior for failed ticket creation, so at minimum, enable that so failures surface instead of disappearing.
Routing logic is only as good as the data it reads. If your organization and contact records are messy, your automation has nothing solid to work with.
This is where the organization and contact configuration in Autotask matters beyond just CRM hygiene. Workflow rules that route based on organization type, territory, or custom fields will produce wrong results if those fields aren't populated consistently.
Specific problems this creates for routing:
I've seen MSPs build sophisticated routing rules and then wonder why they only work for some clients. The rules are fine. The underlying org data is the problem.
Run a report on your organization records filtered by the fields your workflow rules actually use. Any blank values in those fields represent tickets that will route incorrectly or not at all.
Rather than chasing individual routing failures, the better approach is a structured audit that examines each layer of the configuration chain. Here's a repeatable framework:
This audit typically takes a full day for an MSP with moderate complexity, longer if the PSA has years of accumulated configuration drift. The payoff is routing logic that actually reflects how your business works today, not how you thought it might work on day one.
Tools like Rocketship can layer automation on top of a properly audited configuration, handling real-time ticket triage and dispatch. But no automation layer fixes bad underlying data. The audit comes first.
Ticket routing failures in Autotask are almost never caused by broken rules. The real causes are:
Fix the inputs and the routing logic usually works. Skip the audit and you'll keep patching symptoms indefinitely.
Pick one layer from the framework above and start there today. The configuration debt doesn't clear itself.