Why does this matter more than it looks?
Because the starting point in the region is shakier than people assume. According to figures from the Colombian Chamber of E-Commerce and Confecámaras cited in the sector's public discussion, only 35% of companies in Colombia run a full ERP: the remaining 65% still work with spreadsheets or isolated systems.
Which means that, in most cases, “integrating the CRM with the ERP” is really the moment the company formalizes for the first time where each piece of data lives. The integration is the excuse; the real work is information governance.
What has to be decided before choosing a method?
Three things, and none of them is technical. Skipping them is the most common reason integrations have to be rebuilt:
- What is the source of truth for each piece of data? A product's price probably lives in the ERP; an opportunity's status, in the CRM. Every field needs a single owner.
- Which direction does it flow? A two-way integration costs considerably more than a one-way one and multiplies the conflict cases. Plenty of real needs are met in one direction.
- What happens on a conflict? The same customer with a different address in each system. Without a written rule, the integration invents one, and it is usually the wrong one.
Which methods exist, and when do you use each?
| Method | When it works | Where it breaks |
|---|---|---|
| Off-the-shelf connector | Both systems standard, no customization, fields that line up | As soon as there is a custom object or field |
| No-code automation platform | Simple flows, moderate volume, little data transformation | At high volume, with complex conditional logic, or when retries are needed |
| Custom middleware on APIs | Your own business logic, data transformation, error handling | It needs maintenance: it is software, not configuration |
| Scheduled file sync | Legacy systems with no API, tolerance for delay | No good if you need real time |
The honest choice is usually a mix: a standard connector for what fits and custom development for the 20% that does not. Forcing everything through one method is what makes these projects expensive.
What syncs in real time and what does not?
Real-time syncing is expensive and fragile; scheduled syncing is cheap and robust. It is worth deciding field by field rather than applying one policy to everything.
Real time makes sense for whatever blocks somebody: a customer's credit status while the rep is quoting, inventory when a delivery date is being promised. Scheduled — hourly, nightly — is enough for almost everything else: customer masters, catalogs, billing history.
Asking “what happens if this arrives two hours late?” eliminates half the real-time requirements that come up in the first meetings.
Which mistakes force a rebuild?
- Integrating without cleaning first. If the CRM holds three versions of the same customer, the integration propagates them to the ERP. Now you have the problem in two systems.
- Not logging errors. An integration with no log fails silently, and you find out weeks later through an accounting discrepancy.
- No test environment. Testing against production is like learning to drive on the motorway.
- Syncing everything “just in case.” Every synced field is a permanent point of failure. Sync what somebody is going to use.
- Not defining what happens if a system is down. Does it queue and retry, or is it lost? That decision has to be explicit.
How do you approach an integration project in phases?
By starting with the most painful flow and one direction only. It is usually the customer master or moving a won opportunity into an order: the point where somebody copies data by hand today and where the error shows.
Once that flow has been stable for a few weeks, the next one goes in. The advantage is not project management: it is that each phase surfaces data quality problems that were invisible before, and finding them one at a time is far cheaper than finding them all on launch day. We build custom middleware precisely when that phasing and conflict logic does not fit in a standard connector.