Handling ServiceNow requests in your PSA

For MSPs managing co-managed IT environments, one of the more persistent challenges is dealing with customers who use ServiceNow. The platform is powerful and highly configurable, but that same flexibility creates a real headache when you need to action work in your own PSA.

The instinct is often to try and mirror the customer's environment. If they have 50 catalogue items with dozens of fields each, surely you need to recreate all of that in Autotask or ConnectWise before the integration can work? In practice, that approach is slow, expensive, and brittle. Every time the customer updates a form, you're back to square one.

The catalogue complexity problem

ServiceNow's Service Catalogue can be genuinely sophisticated. A single request might have multiple workflows, different assignee groups responsible for different stages, and catalogue item forms with a mix of picklist fields, free text, attachments and more. That's all fine inside ServiceNow, where it was designed to handle it. But none of that maps neatly to the way work is structured in a PSA.

MSPs don't need to manage the customer's internal workflow. They need to know what work has been assigned to them and what information they need to do it. That's a much simpler problem, and it's the one worth solving.

Working at the task level

The approach we use at Support Fusion is to sync at the task level rather than the request level. In ServiceNow, a request (or RITM) can spin off multiple tasks, each assigned to a different resolver group. If an MSP is fulfilling one of those tasks, they only need to see the task assigned to them, not the whole request tree.

That task becomes a ticket in the MSP's PSA, with the form output rolled into the ticket description. So if a customer submits a catalogue request for a new router and fills out a ten-field form, all of that information lands in the description of the Autotask ticket. The MSP doesn't need a matching field for every item in the form. They just need the information, and it's all there.

When the MSP updates the ticket or resolves it, that status flows back into ServiceNow against the relevant task. The customer sees progress on their end without anyone having to manually keep two systems in sync.

What this means in practice

This approach works well for the most common ServiceNow request scenarios: incidents, standard requests, and catalogue items with a single task and assignee group. It also handles more complex catalogue workflows where tasks are assigned out to multiple parties, because each group only receives the task relevant to them.

Where it gets more involved is change management. Change workflows in ServiceNow tend to have more structured approval and review stages, which don't always translate directly into a PSA ticket model. That's not a blocker, but it's worth discussing upfront so the right expectations are set before an integration is scoped.

Getting the scope right

One thing that comes up in almost every ServiceNow integration conversation is alerts. Monitoring tools connected to ServiceNow can generate a significant volume of alert tickets, and blindly syncing all of them into the MSP's PSA is rarely a good idea. Part of scoping an integration properly is deciding which alerts are worth actioning, which ones should be filtered, and whether there are rules in the monitoring tool itself that can reduce noise before it ever reaches the ticketing layer.

The same thinking applies to the integration overall. The goal isn't to replicate everything ServiceNow does inside the PSA. It's to give the MSP the right information, at the right time, so their team can get on with the work.

If you're currently managing a ServiceNow customer and working through what an integration might look like, we're happy to talk through the specifics. The detail of how a customer uses their catalogue makes a difference to how the integration is configured, and it's usually worth a conversation before anything is scoped.