An integration moves data from one place to another. That can remove manual entry, reduce delay, and make information available to the people and systems that need it.
It does not decide which data is true.
When two applications disagree, the technical connection cannot resolve the business decision unless the organization has already defined the rule. Without that rule, an integration may copy the wrong value faster and more consistently than a person ever could.
Start with responsibility, not the connection
Before designing the integration, decide what each system is responsible for maintaining.
One application may own the approved contract terms. Another may calculate charges. Another may record posted accounting results. Several systems may display the same customer or product information, but they do not need equal authority to change it.
For every important field, identify:
- The system where the value is created
- The person or process that approves it
- The system that maintains the official value
- The systems that receive a copy
- The events that are allowed to change it
- The path for correcting an error
Only then can the integration have a reliable direction.
Matching fields does not preserve meaning
Two systems may use fields with similar names while applying different rules.
“Start date” might mean contract effective date in one application, access date in another, and billing date in a third. Mapping those fields directly would create a technically successful transfer and a business failure.
The integration design must preserve meaning, not just format. If the receiving system needs a different event, the transformation should be explicit and testable.
A successful response is not a successful business result
An integration platform may report that a record was sent successfully. That usually means the receiving application accepted the message. It does not prove that the record was complete, applied to the correct customer, used in the next process, or reflected in reporting.
Technical monitoring should be paired with business verification.
For example, do not stop at “all usage files were received.” Also ask whether all expected usage was received, whether it was assigned to the correct agreement, whether it produced the expected charge, and whether rejected records were resolved.
Plan for late events and corrections
Business information rarely arrives in a perfect sequence. An agreement may be corrected after billing begins. Usage may arrive late. A customer or product may be merged. A financial period may close before a source record is fixed.
The integration needs rules for these events:
- Should the new value replace the old value or create a new version?
- Should downstream systems recalculate earlier results?
- Which system initiates the correction?
- How will people know which records were affected?
- What happens if one system accepts the change and another rejects it?
Retry logic is useful for a temporary technical failure. It is not a correction policy.
Make failure visible to the person who can act
Logging an error is not enough if no one is responsible for resolving it.
Every important integration should have an owner, an expected frequency, a definition of success, and a practical response when something goes wrong. The people responsible should be able to distinguish a temporary connection problem from invalid business data or a missing decision.
Errors should retain enough context to investigate the source without exposing information unnecessarily or requiring someone to reconstruct the entire transaction.
Reconcile between systems
Reconciliation answers a question monitoring cannot: did the complete population arrive and produce the expected result?
Counts and totals can help, but they should be appropriate to the risk. A daily customer update may need record counts and exceptions. Billing may require agreement-to-charge reconciliation. Financial integrations may require control totals, posting status, and evidence of corrections.
The control should test the business outcome, not merely the movement of messages.
Integration is part of the process
Treating integration as plumbing separates it from the decisions it carries. The code may be technical. The consequences are operational and financial.
A reliable integration begins with clear ownership, preserves the meaning of the information, makes failures visible, and supports correction without creating competing versions of the truth.
The connection matters. The decisions around it matter more.