Most companies run on a collection of specialized systems.
Finance may live in an ERP. Sales may live in a CRM. Customer success may live in a CSM platform. Service may live in a ticketing system. Delivery may live in a PSA. People data may live in an HR platform. Reporting may live in a BI layer.
That structure is normal. Different teams need different tools to do their work well.
The problem starts when the work crosses functional boundaries, but the data does not.
A service team may need customer health context before prioritizing an issue. A customer success manager may need visibility into open tickets before walking into a renewal conversation. A finance or operations leader may need delivery, margin, and staffing context in the same operating review. A delivery manager may need sales commitments, project status, and resource constraints to understand where risk is forming.
None of those needs are just technical integration problems.
They are operating design problems.
Start With the Use Case
The first question should not be, “Can these systems connect?”
The better question is:
Where does this data need to show up for the business to make a better decision?
That question usually separates integration needs into two broad categories.
If a team needs the data during day-to-day work, the data usually belongs inside the system where that work happens. For example, if a support team needs account tier, contract status, or customer health before responding to a ticket, that context should appear in the ticketing workflow. The person should not need to leave the work system, open a dashboard, search for the account, and manually reconcile context before acting.
If the data is used on a weekly, monthly, or quarterly basis to support review and planning, it may belong in a reporting layer. In that case, the goal is not to interrupt the daily workflow. The goal is to create a reliable view for operating reviews, trend analysis, planning, and escalation.
Both patterns can be useful.
But they solve different problems.
An integration into a working system helps people act in the moment.
An integration into a reporting layer helps people review, compare, and decide on a cadence.
Confusing those two needs is one reason integrations become expensive without becoming useful.
Integration Design Is Decision Design
Data is part of the decision-making process. If the data is late, inconsistent, incomplete, or hard to trust, the operating decision gets worse.
That is why integration design should not stop at field mapping.
A good integration needs to answer practical questions:
- Who needs the data?
- Where do they need it?
- How often do they need it?
- What decision or action does it support?
- Which system is the source of truth?
- What happens when the integration fails?
Without those answers, teams may successfully move data from one system to another and still fail to improve the work.
The connection works, but the operating loop does not.
Extract: Know the Source
Every integration starts by reading data from a source system.
Sometimes that source is an API. Sometimes it is a flat file. Sometimes it is a warehouse or reporting database. Increasingly, it is an API because most modern business systems are cloud platforms, not databases that a company directly owns and controls.
That creates a different kind of dependency.
The source system may change an endpoint. An API key may expire. Access permissions may shift. A vendor may update its data model. A field that looked stable during testing may behave differently after a product update.
The extraction step often feels straightforward when the integration is first built, but it still needs ownership and monitoring. If the source changes and nobody notices, every downstream decision built on that data is exposed.
Transform: Make the Data Usable
The transformation step prepares the source data for the destination system.
This is where definitions matter.
The source system may call something a customer. The destination system may call it an account. One system may use a user ID. Another may require a lookup against an email address. One platform may allow free-text values. Another may require a fixed dropdown. One system may store a relationship directly. Another may require a foreign key to a separate object.
These details are not minor.
They determine whether the integration creates trust or confusion.
For example, loading account data may require a relationship to an owner record in the destination system. If the source system does not provide the destination system’s user ID, the integration may need to match on a shared lookup value. If that lookup is missing, duplicated, or inconsistent, the integration can fail or load incomplete data.
This is why transformation logic should be designed around clear definitions, not assumptions.
The question is not only, “Can we move the field?”
The question is, “Will the receiving system understand the field in a way that supports the decision?”
Load: Protect Trust in the Workflow
The load step is where the transformed data enters the destination system.
It is also where trust is often won or lost.
During testing, many integration issues are discovered and corrected. But once an integration is live, the load step becomes an ongoing operating responsibility. Source values change. Dropdown options drift. Lookup records go missing. API permissions shift. IP allowlists change. Destination systems add validation rules. Business teams update processes.
The integration has to survive that reality.
That means teams need clear remediation paths:
- What error conditions should trigger an alert?
- Who owns the investigation?
- Which failures can be retried automatically?
- Which failures require manual cleanup?
- How will the business know if the data is stale or incomplete?
- When should the issue be escalated?
If those questions are not answered, the integration may quietly erode confidence. People start checking the data manually. Teams create side spreadsheets. Users stop trusting the field. The technical connection still exists, but the operating value disappears.
Integrations Need an Operating Model
A useful integration is not just an extract, transform, and load process.
It is an operating model.
It needs a source of truth. It needs a destination that matches the workflow. It needs clear data definitions. It needs monitoring. It needs alerting. It needs ownership. It needs a remediation path when something breaks.
Most importantly, it needs a reason to exist that is tied to how the business works.
If the data is needed for fast action, put it where the action happens.
If the data is needed for recurring review, put it in the reporting layer.
If the data does not improve a decision, reduce a constraint, or remove a manual reconciliation step, the integration may not be worth the complexity.
The goal is not to connect every system.
The goal is to make the right data available at the right moment, in the right place, so teams can work from the same facts and make better decisions.