Connecting Custom Software to ERP, CRM and OA: Who Owns the Data?
Before promising an ERP, CRM or OA integration, establish which system owns each business object, what the new application may read or write, and who resolves failures. A responsibility matrix should come before interface development; then use one traceable record to verify field mapping, permissions, write-back and recovery.
On this page 6 sections
Decide what can be integrated and what needs investigation
Do not begin with “Can you connect to ERP?” Choose a real business action first: a salesperson starts an order in a new workbench, a manager approves it in OA, and finance checks the final record in ERP. Follow that record and list every object to be read, created, changed or written back. For each action, identify the existing system's interface, account permissions and decision owner.
If an approved API or formal exchange mechanism exists, ownership and authorization are clear, and a test environment with sample records is available, integration design can begin. If the team can only see the old system's screens, lacks API documents or access, or has conflicting owners for the same field, start with system discovery. You can assess options, but cannot yet promise bidirectional synchronization. Read-only views and writes to a system of record carry different risks and acceptance criteria.
Business-object ownership differs from field origin. CRM may maintain the customer profile while ERP supplies credit status; showing both on one screen does not grant the new application equal edit rights over both fields. During planning, record roles, fields and workflows with the software requirements checklist.
Use a responsibility matrix to assign data ownership
Consider a company where CRM maintains customers, ERP maintains orders, OA runs approvals and a separate workbench lets staff view records and start actions. The table demonstrates the questions to answer; system owners must confirm each row for the actual project, including whether similarly named fields mean the same thing.
Scroll horizontally to view the full responsibility matrix.
| Business object | System of record | Workbench action | Write-back and failure rule | Who confirms |
|---|---|---|---|---|
| Customer profile | CRM customer ID and master record | Read as authorized; route edits through CRM. | Keep the original value if an update fails; do not create a second master record. | Sales owner and CRM owner |
| Order | ERP order number and final state | Start a draft; display the ERP number when returned. | After a timeout, check whether ERP created the order before retrying. | Order owner and ERP owner |
| Approval task | OA process instance and decision | Start or open approval; display the OA response. | If a callback is missing, show “pending verification,” not “approved.” | Process owner and OA owner |
| Cross-system link | Original IDs in each system plus a controlled mapping table | Show related customer, order and approval to permitted roles. | Put unmatched IDs in a review queue; do not merge them automatically. | Data owner and integration lead |
For each row, also confirm who may view changes, who approves corrections and how long records are retained. This matrix is a business agreement before it is a technical diagram: which result is authoritative, who may alter it and who resolves conflicts?
Specify the API contract so teams can test it
For every interface, document direction, trigger, request and response fields, original-system keys, an idempotency or business identifier, code values, time and amount rules, authentication, and the meaning of accepted, rejected, timed out and unknown results. Query interfaces need pagination and freshness rules. Write interfaces need duplicate-submission, cancellation and version-change rules.
A field list alone is insufficient. Prepare a reproducible test record linking the customer ID, order number and OA process-instance ID. Define what happens if a field is absent, a role lacks permission or the target system is unavailable. For HTTP APIs, the OpenAPI Specification can structure operations, parameters and responses. Server-side authorization should be verified on every request; see OWASP's authorization guidance rather than relying on a hidden button.
Some legacy systems only support scheduled export or human approval, with no real-time write-back. That may be a valid phase-one solution, but the interface must show data freshness and processing state accurately.
Trace one record through the entire flow
Begin integration testing with read-only comparisons, then test writes and state return. Preserve the record IDs and observed outcomes at each step; a screenshot of the final page cannot prove the original system changed.
- Check the sources: find an authorized test record in CRM, ERP and OA; compare identifiers, field meanings and time conventions.
- Check the mapping: inspect the same object in the workbench and verify that each field comes from the agreed source.
- Perform an action: use an authorized role, retaining the request ID, original-system response ID and screen state.
- Verify the return path: find the record in the original system and confirm the workbench updates through a callback or controlled query.
- Replay failures: test timeout, duplicate requests, denied access and unmatched IDs; check that no record is wrongly overwritten or duplicated.
If the task begins with an abnormal dashboard metric, the anomaly-to-work-order guide addresses that specific path. The matrix here applies to cross-system collaboration more generally.
Make failure states and response ownership explicit
The most damaging mismatch is an API failure paired with a page that says “success.” A timeout is not proof of failure, and an accepted response is not always proof that the full business task is complete. The UI should distinguish accepted, processing, complete, clearly failed and awaiting verification, with a traceable record identifier.
- Duplicate submission: query the original system by business identifier before another create request when the first outcome is unknown.
- Data conflict: retain the source value and update time; let the agreed data owner decide rather than assuming the last-arriving value is authoritative.
- Permission denial: stop the write and show the supported route; do not bypass the original system's controls to make a demo work.
- Missing callback: recover through a controlled query or manual check, recording who investigates and when to escalate.
Put these rules in the API contract, UI specification and operations handoff. Otherwise users can only send an error screenshot while developers lack the system and record details needed to diagnose it.
Agree on the exact acceptance boundary
At acceptance, answer five questions: Does each object come from the agreed system of record? Can each role perform only authorized actions? Can a written record be found in the original system? Can a timeout or failure return to a verifiable state? Have mappings, accounts, API versions and incident owners been handed over? A verbal explanation in a demo environment is not production evidence.
List read-only access, one-way writes, two-way status return and historical-data migration separately. Delivering the first two does not mean the last two are included. Business users can build cross-system cases with the user acceptance testing guide; for technical handover, use the source-code and interface handover checklist to verify maintainability.