You need controlled data exchange through available APIs.
API integration →OXIAE / INTEGRATIONS & DATA
Software integrations.
Connect software so information does not have to be entered repeatedly.
Discuss your projectConnecting systems: where does your question start?
Your question starts with customer identity, contacts and updates between CRM and other systems.
CRM integration →You need consistent, complete and usable data from several sources for analysis.
Data integration →UNDERSTAND THE SERVICE
How do you connect software without entering the same data twice?
A software integration moves data from a source application to a destination and applies agreed changes there. An illustrative flow: an approved customer and order move from the CRM to scheduling; completed work supplies invoice data to accounting. The CRM owns customer details, scheduling owns the work status and accounting owns the invoice number. Each transfer has defined fields, a direction and a schedule. The technical connection may use an API integration; for existing customer software, it can form part of CRM integration.
When it is a good fit
This is useful when staff retype information or must check which application holds the correct version. I start with a bounded transfer and its exceptions. If multiple sources first need common meanings and quality rules, data integration can form part of the work.
When to take a different approach
An existing connector may be sufficient if it supports the required fields, permissions and failure handling. Without supported access, clear ownership or conflict rules, a custom connection is not yet a useful starting point.
PRACTICAL DECISION GUIDE
Software integrations need an owner for each data field
With several software integrations, the meaning of a change can become ambiguous. We assign an authoritative system to each object and field. Address changes may originate in CRM while payment status comes only from accounting; two-way synchronization is not a blanket setting for every field. [1]
Conflicts, deletions and retroactive changes get defined behavior. Integrations record what has processed and what needs recovery. Where sources support change tracking, we assess incremental synchronization; the mechanism must also support rebuilding when synchronization state is lost. [2][3]
Questions to settle first
- Which system wins when the same field changes concurrently?
- How are deletions and retroactive corrections handled?
Make acceptance measurable
- An ownership matrix by object and field with conflict rules.
- A synchronization test covering updates, deletions and rebuilding.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Existing connector | A supported connection covers the required data and process steps. | Check its limits for exceptions, logging, synchronisation and licensing. |
| Custom one-way integration | One application owns the data and other systems receive the relevant changes. | Keeps scope bounded; acknowledgements or corrections need an explicit return flow. |
| Two-way synchronisation | People need to edit the same information in both systems. | Requires field ownership, conflict rules and protection against repeated update loops. |
What I need to start
- A source and destination register with supported APIs, exports, licences and test access.
- A field mapping covering customer and order IDs, meanings, formats, required values and ownership.
- Agreements on creation, updates, deletion, transfer direction and acceptable delay.
- A service account with only the required read and write access, plus arrangements for storing and renewing credentials.
- An owner for alerts, manual corrections and maintenance after supplier changes.
How to assess the result
- An approved source record reaches the destination with the correct field values and source ID.
- Replaying a message does not create a second customer or order; an update changes the intended record.
- Temporary failures trigger bounded retries. Persistent failures produce alerts and remain available for controlled reprocessing.
- A comparison of source and destination for the same period exposes missing or inconsistent records.
- The agreed freshness is measured. Documentation covers access, alerts, recovery and maintenance responsibilities.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- Number of applications, record types, fields and transfer directions.
- A pilot for one data flow differs from production with migration, multiple exceptions and recovery procedures.
- API limits, data volume and the choice between scheduled batches and events after a change.
- Recurring licences, hosting, monitoring and maintenance when APIs, permissions or data formats change.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
Customer and order information diverges across applications.
An integration starts with rules for sources, destinations and ownership. API integration handles the technical exchange where systems offer a suitable API. Data integration examines field mapping, definitions and quality checks so the received information is usable in the next process.
THE QUESTION I ASK FIRST
Which system is authoritative for each field?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
Do connected applications always need real-time synchronisation?
No. A scheduled batch can be appropriate when a delay is acceptable. Events or webhooks can respond sooner but also require checks for missed, delayed or repeated messages. We agree how current the destination must be and test that requirement.
How do you prevent duplicate customers or orders?
A stable source ID and an agreed key determine whether a record should be created or updated. Repeated messages are checked against previous processing. Existing duplicates first require a decision about merging and ownership.
What happens when two systems contain different information?
We agree which system owns each field. Changes elsewhere follow those rules or are referred for review. For two-way synchronisation, we also define how simultaneous changes are handled.
What is included in the integration handover?
The agreed delivery includes field mappings, synchronisation rules, test results and monitoring and recovery documentation. We also define who manages access, follows up errors and reviews supplier changes.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- OpenAPI SpecificationOpenAPI Initiative
Basis for described data contracts between applications.
Link and relevance checked: - Use delta query to track changes in Microsoft Graph dataMicrosoft Learn
Platform example of change tracking and synchronization state.
Link and relevance checked: - Retry patternMicrosoft Azure Architecture Center
Considerations for resuming after temporary failures.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring Software integrations? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief