When ServiceNow implementations stall, configuration is often blamed—but integration is frequently the real culprit. This blog explores the common integration challenges that derail implementations, from API and legacy-system issues to identity, access, and middleware decisions, and explains why clear ownership and early integration planning are essential for successful ServiceNow projects.
But after watching enough implementations up close, I've come to think configuration rarely is the real problem. The real problem shows up one layer down, where almost nobody is looking: integration.
Why configuration gets blamed for what integration breaks
Configuration issues are loud. They show up in a demo, in a user complaint, in a screenshot someone sends to their manager. Integration issues are quiet until they aren't. A data sync that silently fails for three weeks. Duplicate records piling up because two systems disagree about what "closed" means. A workflow that behaves perfectly in the ServiceNow sandbox and then breaks the moment it has to talk to the actual ERP system in production.
By the time these problems surface, they're usually months into the project — long past the point where anyone thinks to reopen the "configuration was fine" conversation. So the blame stays with the last visible failure, not the first real one.
Where integrations actually break
A few patterns show up repeatedly in enterprise ServiceNow rollouts:
- API assumptions that don't survive contact with real data. Rate limits and throughout assumptions get set based on pilot-scale data, then buckle under actual production volume.
- Legacy systems with undocumented or inconsistent APIs. This is especially common in manufacturing, healthcare, and finance, where core systems predate modern API standards and integration becomes reverse engineering as much as engineering.
- Identity and access treated as a technical afterthought. SSO and directory integration often get slotted in near the end of a project instead of being treated as a design constraint from day one — which is exactly backwards, since access model decisions shape how workflows, permissions, and data visibility are built.
- Middleware decisions made too late. Whether to route through a platform like MuleSoft or Boomi, or lean on ServiceNow's native integration hub, is an architecture decision. Too often it gets made reactively, mid-project, once teams realize point-to-point connections aren't going to hold up.
The organizational root cause
Underneath all of this is a structural issue: the people who understand the integration landscape — enterprise architecture, security, the teams who own the legacy systems — are often not the same people driving the ServiceNow implementation. Configuration has an owner. Integration frequently doesn't.
That gap is where things quietly go wrong. Nobody is deliberately ignoring integration; it's just nobody's single job to get it right end to end.
What good actually looks like
The implementations that avoid this trap tend to share a few habits:
- Integration architecture gets reviewed before configuration starts, not bolted on after.
- There's a named integration owner, on both the customer side and the implementation partner side, accountable for how ServiceNow talks to everything else.
- Integrations roll out in phases tied to the most business-critical workflows first, rather than an attempt to connect every system simultaneously.
None of this is exotic. It's mostly discipline — deciding early who owns the hard, invisible part of the project, instead of discovering three months in that no one did.
The reframe
ServiceNow is a strong platform. Most of what goes wrong with it isn't a platform limitation — it's an integration discipline problem. If you're evaluating an implementation partner, that's a more useful question to ask than "how good is your configuration team?" Ask instead: who owns integration, and when in the project do they start?