Revisited from the Foresaw archive. The argument and structure have been updated for this edition.
Connecting two applications is the easy part. Keeping their view of the business consistent when orders change, requests fail, and people correct mistakes is the real integration problem.
The original Foresaw guide explored the benefits of connecting ERP with other business systems. A useful implementation begins one level deeper: deciding what each system is responsible for and what should happen when they disagree.
Define the source of truth
For each important record, identify the system that owns it. Customer identity, inventory availability, order status, and financial postings may have different owners. Write those boundaries down before building the data flow.
A shared field name is not a shared definition. An “active customer” in a CRM may mean something different from an active account in finance. Resolve the meaning before transforming the format.
Design the unhappy path
Assume a request will time out, a message will arrive twice, or a dependency will be unavailable. The integration needs a way to retry safely, recognize duplicates, and surface records that require attention.
Not every workflow needs an immediate update. Decide which decisions require fresh information and which can tolerate a delay. That distinction can simplify the architecture considerably.
Make reconciliation part of delivery
A successful API response does not prove that the business transaction completed correctly. Compare the records that matter across the connected systems and give an accountable team a useful exception queue.
Start with one complete workflow
Choose a narrow path, such as an order moving from checkout to fulfillment. Test it with realistic exceptions and the people who handle them. A small integration that works end to end is a stronger foundation than a broad map of partially connected systems.
Adapted from “Mastering ERP Integrations: A Comprehensive Guide.”
First published on Foresaw. Reworked for this edition.