Two connectors, samedata: why duplicateintegrations are moredangerous than missingones

In short

In one inquiry, a store was to be connected to both the ERP and Amazon at the same time. There are connectors for both. The risk: both write the same inventory or the same orders without knowing about each other. Then the store counts double, or one update overwrites the other. So before any installation, we defined which system is responsible for which data. Responsibility first, then the app.

The case

Each connector works on its own. The problem arises when they interact. If the ERP reports an inventory level to Shopify while the Amazon integration changes the same inventory, the last update wins. The result is a number that has nothing to do with the warehouse anymore. With orders, it can get even more unpleasant: created twice or shipped twice.

One leading system per data type

This table looks a little different in every project. What matters is that every row has exactly one answer in the “Who leads?” column.

What we define before installation

• A map of the data flows. Which data flows from where to where?
• One leading system per data type. Never two writers for the same value.
• Which connector features get switched off. Many connectors can do more than they're allowed to in this setup.
• How it's tested. With test products and test orders, before real data flows.

What to take away

• Duplicate integrations are more dangerous than missing ones. A missing feature gets noticed, a silent conflict doesn't.
• Pick one leading system. One each for inventory, product data and orders.
• Diagram first, then the app. If you install first, you usually only notice the conflict from wrong numbers.
• Switch off what's duplicated. You don't have to use every feature of a connector.

Got several systems hooked up to your store? We map the data flows and make sure each system only does what it's responsible for.