One of the questions or trivia that comes up in almost every ServiceNow implemenration is:
“Should we build this integration directly in ServiceNow or pass it through the enterprise integration layer?”
It sounds like a simple question, but the answer can affect how maintainable, scalable, and reusable your setup is down the line. After working on a few large-scale implementations across multiple entities, here’s a way I’ve found to approach it.
Starting with the Basics
Whenever a new integration request lands, first ask:
What system are we integrating with, and is it something ServiceNow already supports?
If it’s something standard like SAP, Microsoft Teams, or Jira, there are already a spoke or plugin available through IntegrationHub or the ServiceNow Store.
If that’s the case, life is easy — just enable the connector (after your governance checks, of course) and configure it.
Reusability Matters
If it’s a common use case that might come up again for other business units or entities, check whether the connector can support multiple connections.
If yes, use it. No reason to reinvent the wheel.
This approach keeps your platform clean and avoids a flood of custom scripts that no one wants to maintain later.
When There’s No Connector
Sometimes you’ll deal with a system that doesn’t have an existing spoke or plugin. In that case, ask yourself:
Can this be handled using ServiceNow’s out-of-the-box APIs, like the Table API or Attachment API?
If the integration just needs to read or update records, the Table API is usually enough.
It’s reliable, easy to secure, and simple to expose through your Enterprise Integration Bus (EIB) — whether that’s MuleSoft, Azure Logic Apps, or something in-house.
That way, other systems can reuse it later without new development effort.
When You Really Need Custom APIs
If your use case involves extra business logic, multiple data sources, or specific data transformations, then yes — it’s time to build a Scripted REST API in ServiceNow.
The key is to treat custom APIs as a last resort, not the default.
Once you’ve built one, publish it on the EIB. That keeps visibility centralized and helps future teams know what’s already available.
Why the Enterprise Bus Still Matters
The integration bus isn’t just another layer of complexity; it’s your integration control tower.
When used properly, it gives you:
- Better control of authentication, tokens, and access keys
- One place to manage error handling and monitoring
- Easier reuse of APIs across different systems
- Decoupling, so if ServiceNow changes, downstream systems don’t break
So if multiple systems will consume the same data, or you need transformations and routing, go through the bus.
If it’s a single, lightweight, real-time exchange, a direct integration is fine.
A Simple Way to Decide
Here’s the decision path I normally use (and it’s worked well on large government and enterprise programs):
- Is there a spoke or plugin available?
Use it. Don’t overthink. - If not, can it be handled with OOTB APIs?
Use the Table API and publish it through the EIB for reuse. - If not, does it need complex logic or data shaping?
Build a Scripted API and still publish it on the EIB. - If multiple systems or entities will use it, always go through the EIB.
Finally, Integrations are rarely “one and done.” The more structure you have upfront — in how you decide what goes directly into ServiceNow versus what belongs on the enterprise bus — the fewer surprises you’ll have later.
The goal isn’t to add bureaucracy; it’s to build once, reuse often, and keep things maintainable as your ServiceNow implmentaion footprint grows.
