Quick answer: Before connecting ERP to ecommerce, CRM, banking or warehouse software, agree on seven things: which system owns each field, what moves in each direction, how records are identified, how quickly updates must arrive, how duplicates are prevented, who handles failures, and how completed business records will be reconciled. Put these decisions in an interface specification and test recovery—not just successful transfers.
Start with one business flow, such as an online order becoming an ERP sales order and receiving a shipment update. Ask the business process owner, integration developer and support lead to approve the same specification.
The plan below is product-neutral. Its examples are proposed design choices, not claims about the capabilities of a particular ERP or connector.
1. Assign ownership at the field and process level
For planning purposes, define a system of record as the application authorized to maintain a particular piece of information. Avoid assigning ownership only at the application level: “ERP owns customers” leaves unanswered who controls email preferences, credit limits or delivery addresses.
Build a matrix before choosing integration technology. This illustrative allocation shows the level of detail to aim for:
| Information | Proposed authority | Permitted direction or action |
|---|---|---|
| Product SKU and base unit | ERP | ERP supplies approved values to other systems |
| Marketing preferences | CRM | Other systems must not overwrite them |
| Online order as submitted | Ecommerce | Ecommerce sends the original order to ERP |
| Accepted order and accounting status | ERP | ERP returns acceptance and subsequent status |
| Picked and shipped quantities | Warehouse system | Warehouse reports fulfillment facts to ERP |
| Bank statement transaction | Bank feed | ERP imports it for matching and review |
Treat these as workshop prompts, not universal rules. Your warehouse or product information system may legitimately own different fields.
For each row, name a business decision-maker and document conflict handling. If a customer changes an address after picking starts, should the change be rejected, held for review or applied only to future orders?
Also separate reporting a fact from authorizing an action. A payment-status message should not silently grant permission to bypass an approval or credit-control step.
2. Define timing and the interface contract
Replace “real-time integration” with an operational requirement:
- Which business event starts the transfer?
- When must the destination finish processing it?
- How stale may the information become?
- What happens while the destination is unavailable?
- When must someone intervene?
Set different targets for different flows. For example, your team might require order acceptance before warehouse release while allowing a reporting export to run overnight. These are business choices, not default industry timings.
Then document an interface contract: the agreement about what is exchanged and how responses are interpreted. Microsoft’s API guidance emphasizes clear documentation and agreed exchange formats so clients and services can evolve independently. (learn.microsoft.com)
Include:
- Required fields, data types, allowed values and schema version.
- Currency, rounding, tax treatment and units of measure.
- Time zone and timestamp format.
- Meaning of missing, blank and explicitly cleared values.
- Line-level identifiers and rules for partial shipments.
- Valid status transitions, cancellations and amendments.
- Whether a response means received, validated or committed.
- Version-change notice, testing and support arrangements.
For the selected products, attach current official documentation for API limits, pagination, authentication, webhook verification and connector behavior. Record the product edition and API version; do not assume a connector covers every transaction or recovery scenario.
For REST connections, require HTTPS and appropriate endpoint-level authorization. OWASP also warns against placing passwords, tokens or API keys in URLs, where logs can capture them. Have qualified security staff review permissions, credential storage and renewal arrangements. (cheatsheetseries.owasp.org)
3. Use stable identifiers and prevent duplicate business actions
Keep three identifiers distinct:
- Business key: identifies the record, such as store plus order ID.
- Event or operation key: identifies one particular change.
- Correlation ID: groups related activity for troubleshooting.
A correlation ID is not automatically a safe duplicate-prevention key: several legitimate messages may share it. Microsoft recommends stable deduplication identifiers that survive redelivery and atomic recording of processing results where possible. (learn.microsoft.com)
Ask the implementer to explain what happens if two copies arrive together—or if ERP creates an order but its response is lost. A simple “search, then create” sequence needs protection against concurrent requests.
Require documented destination-side idempotency or enforceable uniqueness where available. Idempotent means repeating the same operation does not repeat its business effect. Do not assume an order-creation request is safe to resend merely because it uses HTTP; Microsoft notes that POST requests are not inherently idempotent. (learn.microsoft.com)
Keep legitimate amendments separate from repeated delivery of an earlier instruction.
4. Classify failures and give exceptions an owner
Do not apply one retry rule to every error. Microsoft distinguishes transient failures from problems that need correction and recommends bounded retries, appropriate delays and attention to server-provided retry guidance. Aggressive or layered retries can increase load on a failing service. (learn.microsoft.com)
Use a handling matrix such as this:
| Failure | Proposed handling | Accountable role |
|---|---|---|
| Temporary connection failure | Retry safely with a finite policy | Integration support |
| Rate limit reached | Follow documented limits and retry guidance | Integration support |
| Unknown item or invalid unit | Hold for data correction | Master-data owner |
| Invalid credentials | Alert and investigate access configuration | IT/security |
| Conflicting business instruction | Stop for a business decision | Process owner |
| Retry allowance exhausted | Move to a controlled exception queue | Named support lead |
A failure queue, sometimes called a dead-letter queue, should preserve failed work for investigation rather than discard it after retries end. (learn.microsoft.com)
Specify the exception record: business reference, event key, timestamps, error category, attempt count, responsible team and current disposition. Restrict access to sensitive payloads.
Finally, agree who may correct data, approve replay or close an exception. Define escalation by business impact—for example, an order blocked from fulfillment versus a delayed reporting update.
5. Work through an ecommerce order and a failed shipment update
Consider this hypothetical acceptance-test scenario, using synthetic references. It assumes the chosen ERP supports enforceable uniqueness for an external order reference; verify that before adopting the design.
The intended flow
- Ecommerce submits order
STORE-A/1042. - The integration validates item mappings and required fields.
- ERP creates sales order
SO-7001. - The integration records the relationship between both identifiers.
- The warehouse reports shipment
SHIP-88. - ERP records the shipment, and ecommerce receives the fulfillment update.
Test A: the order arrives twice
Submit the same create-order instruction twice. Both attempts must resolve to SO-7001, not create two sales orders. Also simulate losing the first response after creation.
If the destination lacks a verified uniqueness or idempotency mechanism, treat a timeout as an uncertain outcome requiring investigation—not permission to create again. This test applies Microsoft’s guidance that duplicate handling must protect the business side effect. (learn.microsoft.com)
Test B: ERP records the shipment, but ecommerce is unavailable
Preserve the outbound shipment update and retry it safely. Do not reverse the physical shipment merely because notification failed.
This exposes the dual-write problem: saving a business change and separately publishing its notification can leave the systems inconsistent if one succeeds and the other fails. AWS documents the transactional outbox pattern, which records the change and outbound event in one transaction before a separate process sends the event. (docs.aws.amazon.com)
For packaged software, ask whether a supported durable event mechanism, connector recovery feature or reconciliation process covers this gap. Do not assume direct database customization is supported.
Test C: an old update arrives after a newer one
Deliver a delayed “processing” update after “shipped.” Define the expected result: it must not move the order backward. Test partial shipments, cancellations and amendments against an explicit transition policy.
6. Reconcile business outcomes, not just message counts
A successful notification is not the same as a complete, correct business outcome. The dual-write failure scenarios documented by AWS are one reason to add an independent check between source and destination records. (docs.aws.amazon.com)
For the example above, design a reconciliation report that compares:
- Eligible ecommerce orders against mapped ERP sales orders.
- Expected line quantities against accepted quantities.
- Agreed monetary components, grouped by currency.
- ERP shipments against ecommerce fulfillment records.
- Unmatched records, duplicate mappings and exceptions awaiting action.
Define the comparison population carefully. Use the same cutoff, time zone, order states and cancellation rules. Separate records still within the agreed processing window from genuinely overdue differences.
A simple hypothetical control is:
100 eligible orders − 97 mapped ERP orders = 3 orders requiring explanation.
Those three could be queued, rejected or missing; the count alone does not establish which. Match individual business keys and document each disposition. Equal totals should not replace record-level matching.
Assign business sign-off to the team responsible for the outcome: operations for fulfillment, for example, and finance for monetary differences. Set the frequency according to business risk and processing deadlines.
7. Use an interface checklist before go-live
Create one approved checklist per interface. Keep it specific enough that a replacement support person could operate the connection.
Scope and ownership
- Business purpose, included transactions and exclusions are agreed.
- Field ownership, direction and conflict rules are recorded.
- Business owner, technical owner and support coverage are named.
Contract and access
- Identifiers, mappings, units, currencies and status rules are defined.
- Current official API and connector documentation is attached.
- Authentication, permissions, credential renewal and access removal are reviewed.
- Limits, peak volumes and outage-backlog recovery are tested.
Recovery and controls
- Duplicate delivery, concurrent requests and lost responses are tested.
- Retry boundaries and exception-queue procedures are approved.
- Replay authorization and audit evidence are defined.
- Missing events, out-of-order updates and partial completion are tested.
- Reconciliation has an owner, schedule and escalation path.
Release and operations
- Cutover defines how to pause, resume and identify the starting boundary.
- Support staff can find a transaction by business reference.
- Monitoring covers overdue work and unresolved exceptions.
- Acceptance evidence and the go/no-go decision are recorded.
Microsoft’s supplied go-live guidance calls for integration and performance testing, stakeholder sign-off, monitoring, troubleshooting readiness and a transition to support. Its testing guidance also calls for defined expected outcomes and accountable test owners.
Make those requirements concrete: approve the interface only when the team can demonstrate both a correct transfer and a controlled recovery from failure.