Start with what the data can do? 3 things - Come in, go out or stay put & still create value
Product is never the decision. The situation decides the product.
Two teams can describe the same need in the same words and still need completely different routes. Nothing about the products changed. The situation around the request did.
Ask a team what they want and you get a wish. Ask what their week looks like and you get a design.
Six nuances that flip the answer
| The nuance | One situation | The other situation |
|---|---|---|
| Do you report on it afterwards? | No. Read it live, store nothing | Yes. Extract on a schedule |
| How many systems need to know? | One. Call it directly | Several and growing. Publish once |
| What is doing the pulling? | A person's report. A lean result set | An agent. Many small reads |
| How wide is each record? | Narrow. The volume routes are cheap | Wide and bulky. Batched calls win |
| Who starts it? | ServiceNow pushes | The far side pulls |
| Is there an API at all? | Yes. Any of the routes below | No. Screen level automation |
Not one of those is about a product. Every one of them changes which route is right.
The paths, by direction
Coming in, the first question is whether you need to report on the data afterwards or generate calculations. If you do, it has to land in a table, which means a scheduled copy or real-time stream. If you do not, read it live and store nothing.
Going out, the first question is who starts it. If ServiceNow pushes, fan out decides the route. If the far side pulls, the consumer decides it.
Both directions is a smaller set, and the choice is mostly about where validation happens.
Four forks worth slowing down at
These are the four places I have watched teams branch on the wrong attribute and only find out months later.
The trigger tells you nothing
IntegrationHub Spokes and Stream Connect both fire from a flow. So asking how fast it needs to be, separates nothing at all.
The question that actually separates them is how many systems need to know. One named system with a settled contract, call it directly. Several, or a list that will grow, publish once and let any number of listeners subscribe.
One meter, two different bills
The Table API and Live Connect are both counted by volume on the way out. They do not cost the same for the same information.
The Table API wraps every record in JSON with resolved fields, display values and reference links. Live Connect returns the result set and nothing else. Ask for identical data through both and the fatter payload draws more.
Which means the cheaper option is also the better architecture. That is rarer than it sounds.
Live or extracts
Zero Copy Connector for SQL & ERP does Live and if need be they can store
- A live read makes the security tight while making reporting accessible
.
Agents read in small steps
An agent does not run one clean query. It explores, in many small reads, moving very little data.
High call counts and small payloads. Scope the tools and the fields deliberately, because an agent will explore more widely than a person would.
Reading and acting are different risks. Decide which one you are opening up.
Different routes on one page
| Route | Direction | Copies |
|---|---|---|
| IntegrationHub Spokes | Both ways | Yes |
| IntegrationHub Data Stream | In | Yes |
| External Content Connectors | In | Index only |
| Stream Connect | Both ways | Yes |
| Zero Copy Connectors | In | No |
| Zero Copy Connector for ERP | In, plus write back | Either mode |
| Live Connect, the SQL API | Out | No |
| Table API | Out | Yes |
| ServiceNow MCP Server | Out | Yes |
| RPA Bots | In | Yes |
| Import Sets and Data Sources | In | Yes |
| Export Sets | Out | Yes |
