Salesforce Integrations: What to Decide Before You Start Building

The technical act of connecting Salesforce to another system is often the easy part. The difficult part is deciding what the integration is supposed to mean for the business.

Before writing code or choosing middleware, a few architecture decisions should be clear.

1. Which System Owns the Data?

For every major record or transaction, define the system of record. Salesforce may own the customer relationship while an ERP owns invoices, inventory, or financial transactions. A product system may own product data. An ecommerce platform may own orders. If ownership is unclear, integrations can create conflicting updates and unreliable data.

2. What Direction Should Data Move?

Not every integration needs to be bi-directional. One-way synchronization is often simpler and safer. Only create two-way updates when the business actually needs both systems to edit the same information.

3. How Fast Does It Need to Move?

Real time sounds attractive, but many processes do not require it. Batch or event-driven approaches may be more reliable and less expensive. The timing should reflect the business requirement rather than a default preference for immediacy.

4. What Happens When Something Fails?

Integrations fail. Credentials expire, source data is invalid, APIs time out, and downstream systems become unavailable. A production integration needs logging, retries, alerting, and a clear process for resolving failures. 'We will check the logs if someone notices' is not an operating model.

5. How Will Records Be Matched?

Identity problems create some of the ugliest integration issues. Decide which unique identifiers connect records across systems and how duplicates, merges, deletes, and ownership changes should behave.

6. Do You Need Middleware?

Some integrations are simple enough for direct APIs, Salesforce automation, or packaged connectors. Others benefit from a platform such as MuleSoft that can centralize APIs, transformation, orchestration, security, and reuse across multiple systems.

The decision should reflect the number of systems, complexity, transaction volume, need for reuse, and long-term integration strategy. Middleware is valuable when it solves a real architecture problem, not when it adds another layer without a reason.

Design the Business Process Before the Integration

A technically perfect integration can still automate a broken process. Map what should happen from the user's perspective first. Which event starts the process? What data is required? Who owns exceptions? What should the user see in Salesforce? Then design the integration around that process.

Good integrations make systems feel connected without making users think about the plumbing. That outcome starts with architecture long before the first API request is sent.