Connecting CRM, ERP and your store without lost orders or duplicates

1. What does “integrated” actually cover?

One connector may transfer only new orders, while another includes changes, cancellations, payments and returns. A connection between applications does not establish equal operational coverage. List the business events and required outcome for each, distinguishing automated work from what remains manual.

Describe one complete journey: a customer orders, a manager confirms, the warehouse receives a task and status returns to the work list. State the integration’s boundaries. It can transfer data without making a commercial decision or performing a physical operation. Record creation is not proof that the entire process finished.

Begin acceptance with scenarios, not successful HTTP response counts. A technical acknowledgement may precede actual processing. Establish which state it confirms and where the final outcome can be verified. Otherwise a green connection indicator can conceal unfinished business work.

2. Who owns each field?

For every object, define its creating system and rules for important field changes. Price, address, payment status and stock location can have different authoritative sources. “ERP is primary” is too broad if a manager edits an address in CRM while the store keeps sending an earlier value.

Agree the point until which automatic changes are allowed. A different size after picking begins may need warehouse approval. An address change after dispatch is no longer ordinary field editing. Integration should support that sequence rather than overwrite values merely because a message arrived later.

Make a small matrix: field, source, direction, update condition and conflict behaviour. Unknowns belong to the process owner. Developers can implement a rule but should not silently decide whose change matters more to the business. Keep the decision understandable to the people handling exceptions.

3. How are customers, items and orders matched?

Preserve stable identifiers and cross-system mappings. Product names and customer names can change and do not guarantee uniqueness. Match a product’s specific colour and size, not just its style. Check whether an order number is unique across channels or only within one channel.

Distinguish object identifiers from event identifiers. One order can have many updates; two events need not mean two orders. Conversely, identical products and amounts do not prove that a customer did not place a second legitimate order.

Do not silently substitute a similar item for an unknown code or create uncontrolled duplicates. Define a clarification queue and directory owner. Ambiguous customer matches need an agreed review procedure rather than automatic merging on one uncertain field. Retain enough provenance to explain how the correspondence was established.

4. What if the response disappears?

Teaching scenario: an order-creation request reaches the destination and is saved, but the response never arrives. The sender sees a timeout and cannot determine the outcome. Safe behaviour is not unconditional creation of another order; it needs a defined retry or outcome-check procedure.

Amazon Builders’ Library discusses idempotent APIs and request identifiers for safer retries. Here, idempotency means repeating the same logical operation does not add another effect. Verify each API’s actual contract rather than assuming support.

For business acceptance, define the observable result: after a lost response and the agreed retry, one corresponding order exists and its state can be established. Do not promise universal exactly-once execution across every system. Ask the technical owner to explain the guarantee’s limits and the procedure beyond them. A feature label without a tested scenario is insufficient evidence.

5. How are late and conflicting updates handled?

Messages can arrive in a different order from the business changes. Confirmation and cancellation may travel through different paths, with an older event arriving last. Blindly applying the last received message can put a cancelled order back into work.

Agree how freshness is established using object versions, permitted transitions or other source capabilities. Receipt time and event time differ; timestamps require interpretation too. Do not adopt date comparison without checking formats, timezones and source precision.

When two systems independently edit one field, define conflict resolution. Some cases can be automated while others need a person. Users should see that a change was not applied and why. Silent rejection creates false confidence that both systems agree. Include the responsible role and a way to record the resolution rather than relying on an informal message.

6. When should an operation retry or stop?

Temporary service unavailability and an invalid item code need different responses. Repeating unchanged input might help the first but cannot correct the second. Agree error categories and owners: technical failure, invalid data, insufficient permissions or business conflict.

Automated retries need limits and pauses compatible with the supplier’s capabilities. An uncontrolled loop can increase load and complicate recovery. Avoid prescribing one frequency for every API. Check limits, behaviour when exceeded and visibility of unfinished attempts.

After automatic attempts end, the record must remain visible rather than disappear. It needs a cause, identifier, next owner and resumption condition. Manual replay also needs rules: who may initiate it, what must be checked first and how duplication is ruled out. Escalation is a valid outcome when the result cannot safely be established.

7. What should the operational owner see?

An operational log should answer what remains unfinished, since when and which work is affected. Useful context includes source and destination identifiers, event type, current state and an understandable error category. Technical text without an order relationship may be unusable for a manager.

Do not expose credentials or unnecessary personal information in logs. Agree roles, retention and access to technical detail. First-line support often needs operational context and an escalation route rather than a complete request payload.

Separate notifications from the work queue. A chat alert draws attention but does not track resolution. When several people respond to one failure, assign an owner to avoid conflicting corrections. Define acknowledgement, work in progress and confirmed recovery. The record should remain understandable to the next person taking over the incident.

8. How do you verify completeness without reported errors?

No reported errors does not prove that the sender detected every event. A source might never produce a message, or part of a selection might be omitted. Independently reconcile which objects should have transferred during a defined period with those present at the destination.

Do not compare counts alone. Ten expected and ten received records can contain different identifiers. For important fields, compare content, state and inclusion rules. Explain legitimate exclusions instead of classifying them as failures or ignoring them without documentation.

Choose reconciliation frequency according to delay consequences and traffic. An occasional supporting operation and daily customer orders may need different schedules. Reconciliation is not a backup: it detects disagreement between sources but does not automatically restore all lost data. Define who investigates mismatches and how the result returns to the operating queue.

9. Which scenarios belong in acceptance?

Prepare reference cases in a test environment. Besides ordinary creation, include retries, unknown items, changes after handover, unavailable services and recovery. For each, record expected states in both systems and the message to the responsible person.

Do not trigger real payments, shipments or customer messages for testing. Where a service lacks a test environment, agree a safe method and limitations before starting. Test records should be recognizable and kept out of operational performance measures.

Ask the future support owner, not only the developer, to perform recovery. If only the author knows how to find and replay an operation, handover is incomplete. Document steps, permissions and conditions requiring a stop and technical decision. Preserve evidence that the expected outcome was achieved, not merely that the retry button was pressed.

10. How do you maintain integration after launch?

Assign business-rule and technical-support ownership. Field, status, plan or version changes can affect exchange. Before upgrades, rerun reference scenarios and check dependencies rather than only opening the service homepage. Maintain a current data map and change history.

Start expansion with a new requirement and its consequences. An extra direction can create an update loop if both systems react to each other’s changes. Agree boundaries, tests and stopping conditions before applying it to production data. Treat small configuration changes as potentially meaningful when they affect shared identifiers or status rules.

After the pilot, assess unfinished operations, detection and recovery time, and manual effort. Message volume alone is not success. Integration is useful when the team completes work and explains exceptions, not merely when a connection indicator stays green.

• Sources, identifiers, update rules and conflicts are defined.
• Retries and ambiguous outcomes have separate tests.
• Unfinished operations remain visible and owned.
• Completeness is checked independently of error logs.
• The team knows recovery and post-upgrade verification procedures.