The distinction in practice
A field service company runs on maybe five kinds of things: customers, the equipment installed at each property, jobs that get done, calls that come in, and money that changes hands. That’s the business. The business-intelligence schema should have a table for each of those things because those are the entities the owner actually thinks about when making decisions.
What those tables should not look like is the data structure of the field service management software. That software has hundreds of fields on a job record. You need maybe twelve of them. Pulling everything because you might need it someday creates noise that makes the schema harder to understand, harder to query, and much harder to maintain when the tool changes.
When the source system gets replaced, the schema shouldn’t change. Only the adapter that feeds it should change. If your integration breaks every time a vendor updates their API, you modeled the tool, not the business.
External references belong at the edge
The right way to handle the connection between your business model and your source systems is to store external identifiers as simple nullable text columns on the relevant entity. A customer row has a servicetitan_customer_id. These are references to the source, not dependencies on it. When a tool gets replaced, you write a new adapter that populates the same columns from the new source. The downstream queries, dashboards, and reports don’t know anything changed.
Start with the question, not the data
The discipline that saves integration projects is starting with the decision you need to make rather than the data you have available. “What is our call-to-job conversion rate by technician this month?” is a question. Working backwards from that question tells you exactly which fields you need. Working forwards from the entire contents of a vendor export tells you nothing.
The better project shape is: identify the five decisions the business makes every week, reverse-engineer the minimal schema that answers each one, and build adapters from the source systems to that schema.
Why it matters when AI gets involved
This distinction becomes more consequential once you’re connecting AI systems to operational data. An AI that can answer questions about your business is only as good as the business model its data represents. If the schema mirrors a tool instead of the actual business, the AI is reasoning about a tool rather than about customers and equipment and jobs. The answers will be technically correct and practically useless — and they’ll be confident about it.