A business can have several perfectly functional applications and still operate through spreadsheets. Sales records a won opportunity in one CRM, another region maintains the same customer in a different CRM, and finance creates a separate account in the ERP. Staff reconcile names, chase missing details, and manually confirm whether the order can proceed.
The difficulty is rarely solved by copying every field between every application. Different systems represent different stages of the business relationship. An opportunity, accepted order, invoice, and payment are connected, but they are not interchangeable. Effective orchestration preserves those meanings while coordinating the handoffs between them.
Define the business journey first
Select a process such as opportunity-to-order, customer-onboarding-to-invoice, or supplier-approval-to-purchase. Document its trigger, required information, approvals, and completed outcome. Identify where staff currently reconcile records or interpret ambiguous data. This process boundary gives the integration a purpose and a meaningful acceptance test.
For example, a won opportunity may trigger an order-preparation workflow. It should not automatically imply that finance has approved credit or that the ERP has accepted the order. Define the intermediate states and the responsible owner of each decision before discussing connectors.
XP Solutions' end-to-end process mapping establishes these operating requirements. The integration architecture can then be evaluated against actual work instead of a list of application logos.
Assign ownership at the field level
A single phrase such as the CRM is the source of truth is often too broad. Sales may own relationship information, finance may own credit status, and the ERP may own posted transactions. Create an ownership matrix that identifies which system and business role can originate or approve each important field.
| Business information | Potential authoritative owner | Integration behavior |
|---|---|---|
| Relationship contact | Regional sales operations | Share permitted contact updates with defined scope |
| Legal billing identity | Finance or customer master team | Require validation before overwriting |
| Credit status | Finance-controlled system | Expose status; preserve approval authority |
| Posted invoice | ERP finance ledger | Publish reference and status to other systems |
| Opportunity stage | Relevant CRM sales process | Trigger workflow without impersonating order acceptance |
Define conflict resolution explicitly. The most recently modified record is not always the most authoritative one. A late import can contain old information, and a user may edit a display field without intending to change an approved billing identity.
Resolve identity before synchronization
Establish stable mappings between each application's identifiers and the business entity they represent. A customer name or email address alone may not distinguish a legal entity, branch, subsidiary, or shared contact. Preserve original source identifiers and record the evidence supporting a match.
Microsoft Dataverse supports alternate keys that identify rows using business columns rather than only its primary GUID. This illustrates a useful integration principle: external identity needs an explicit representation. Each system's key constraints must be checked before choosing the implementation.
Use exact, validated identifiers for automatic matches where possible. If fuzzy matching or AI proposes a relationship, send uncertain cases to an owner rather than merging records silently. A false merge can be harder to repair than a temporarily unmatched account.
Create a small canonical contract
Define the minimum shared representation required for the workflow. Include identifiers, event type, source, version, timestamp, and the fields needed for the intended action. Avoid a giant universal customer schema that attempts to settle every future requirement before delivering one useful handoff.
Document units, currencies, time zones, enumerations, and required fields. Define what a missing value means and whether it differs from an explicit request to clear a field. Version contracts so a connector can reject or route an unfamiliar payload safely rather than partially interpreting it.
A mapping is a business rule, not merely a technical assignment. A tax-inclusive total and a tax-exclusive total should not share a field just because both are named amount. Have business owners review mappings that affect commercial or financial meaning.
Design an architecture with observable states
A durable queue helps decouple systems with different availability and throughput. The orchestrator tracks what is pending, completed, or awaiting review. Destination connectors translate the shared contract into system-specific operations. Verification confirms that a submitted request produced the expected record or state.
Keep a correlation identifier across the journey so support can trace a case through its events and actions. Provide an operational view that business owners can understand: which customers or orders are affected, what is blocked, who owns the next step, and when information was last confirmed.
Handle duplicates, order, and partial failure
A connector may time out after the destination has already accepted a request. Retrying without checking can create a duplicate. AWS's guidance on idempotent APIs discusses using request identifiers to make retries safer. The actual guarantee still depends on the destination and the integration's implementation.
Track event identifiers and processing outcomes. Where the destination supports an idempotency key or unique external reference, use it deliberately. Where it does not, design a reconciliation method and account for concurrency. Avoid promising that an entire cross-system process is exactly once merely because one connector deduplicates messages.
Events can arrive out of order. Use source versions or supported state-transition rules where available, and define how stale updates are detected. If an order is cancelled while an earlier create event is still queued, the workflow needs an explicit resolution rather than a blind last-write rule.
Separate technical and business exceptions
A temporary API outage may be retried according to a controlled policy. A rejected tax code or unapproved customer account requires a business decision. Distinguish these categories so retries do not endlessly repeat a request that cannot succeed without changed information.
Assign each exception type to a support or business owner. Show the source data, validation result, attempted action, and next permitted step. Provide a safe replay process after correction, preserving the history of what happened. An exception queue with no active owner is a new silo, even when it lives inside a modern platform.
Use AI at the interpretation boundary
AI may help classify an inbound request, extract information from an attachment, explain an integration error in plain language, or propose a mapping for review. These applications should return evidence and distinguish inferred information from verified fields.
Keep authoritative calculations, access checks, and approved business rules in controlled code or the relevant system. Treat incoming text and retrieved records as untrusted inputs. A document that asks the assistant to ignore policy should have no effect on connector permissions or approval requirements.
Consider custom AI components only where they address a real interpretation gap. Straightforward field transfer should not require a reasoning loop simply to make the architecture appear more advanced.
Calculate integration value carefully
Hypothetical worked example, not a client outcome: assume a team reconciles 300 customer or order handoffs weekly at 6 minutes each, consuming 30 hours. If a redesigned integration leaves 2 minutes of human review per handoff, direct handling becomes 10 hours. Subtract an additional 3 hours of weekly exception administration, leaving 17 hours of illustrative net capacity.
This calculation excludes implementation and financial running costs. It also excludes speculative gains from fewer billing errors or faster cash collection. If those outcomes matter, establish separate baselines and attribution methods rather than adding an unsupported uplift to the time-saving estimate.
Roll out with reconciliation and ownership
Begin with representative test records and a dry run that produces proposed actions. Plan historical backfill separately from live events, including duplicate detection and the point where the two streams meet. Validate record counts, key totals where relevant, and unresolved mismatches before expanding writes.
Test expired credentials, rate limits, schema changes, missing identifiers, duplicate delivery, and downstream downtime. Confirm how the business continues during a pause and how changes are replayed afterward. Assign responsibility for monitoring, access reviews, contract changes, and incident resolution.
A successful orchestration makes the business journey more visible and dependable. It preserves useful systems while giving information and decisions a clear route between them. Explore XP Solutions' CRM and ERP orchestration service, read our workflow audit guide, or book a strategy call around a cross-system handoff your team currently reconciles by hand.
