Architect Salesforce Integrations With Defined Ownership

Choosing an integration pattern before choosing a tool

Integration projects often begin with a product name, a middleware platform or a connector, and the design questions arrive later. That order reverses the logic. The pattern decides how the systems talk, how failures surface and who must act when something goes wrong. Once the pattern is clear, the tool choice becomes a question of which product supports that pattern at the volume and security level the business needs.

Three patterns commonly appear in Salesforce integration work. Direct point-to-point connections are the quickest to build and the hardest to govern once several systems depend on each other. A middleware layer that routes, transforms and monitors messages centralizes that work, at the cost of another platform to run. Event-driven designs publish a change once and let interested systems react, which suits high-volume or loosely coupled processes but requires disciplined handling of ordering and duplicates.

Synchronous calls and the user who is waiting

A synchronous integration holds the user's screen until the other system replies. That is acceptable for a quick lookup, such as checking a customer reference, and it is a poor design for anything slow or unreliable. When an external service is down, a synchronous call either fails in front of the user or times out in a way that leaves a record half-updated. An asynchronous path lets the user finish the task while the integration completes in the background, but it creates a new question: how does the user learn that the background work failed?

The architecture should state, for each integration, whether the user must wait, what the user sees while work is pending, and what the user is told if the work never completes. Those statements are more useful to a business sponsor than any diagram of connectors.

Retries, duplicates and idempotent records

Retries are safe only when the receiving side can recognize a message it has already processed. Without that protection, a timeout followed by an automatic resend can create two accounts, two orders or two tasks for one event. A common remedy is an idempotency key: a stable identifier carried with each message so that the receiver can check whether it has already acted. Where a stable identifier does not exist, the design must match records on agreed business fields and define what happens when the match is ambiguous.

Ordering needs the same care. If an update arrives before the record it modifies has been created, the receiver should hold the update, reject it with a clear reason, or apply a rule the business has agreed. Silently applying it to the wrong record is the outcome to avoid. The design should name which of these behaviors applies to each integration rather than leaving the developer to decide during the build.

Monitoring, alerts and who responds

An integration that has no monitoring is discovered broken by the people who depend on it. Alerts should reach a named queue, and that queue should have an owner who can decide whether to retry, correct the data or escalate to the system owner on the other side.

• A dashboard that shows whether each integration is running and how far behind it is.
• A failure queue with a clear status for each item and a documented retry rule.
• A reconciliation report that compares counts or key fields between systems on a schedule.
• An escalation path with names and roles, not only a shared mailbox.

Security, integration users and data minimization

Integration users should hold only the permissions the integration needs. A shared administrator account used for every connection is convenient at the start and dangerous later, because it hides which system made which change and grants far more access than any single flow requires. Each integration should have its own user, a permission set that limits objects and fields, and a credential rotation process that the support team can operate.

Data minimization applies to integrations as much as to forms. Send only the fields the receiving workflow needs, and document the reason for each one. Personal data that is copied into a second system widens the set of places a correction must be made and the set of places that must be secured. A field-level data map, kept with the design, makes that trade-off visible to the people who approve it.

Documenting the design before the build starts

A usable integration design records, for each flow of data, the source, the target, the trigger, the authoritative system for each field, the error path, the owner on each side, and the evidence that the flow completed. It also records the decision that would be taken if the two systems disagreed. A design that answers those questions can be handed to a new team without a meeting, which is the real test of documentation.

Choosing batch and real-time timing for each flow

Real-time updates feel safer because the systems stay close together, but they are not always the right answer. A nightly batch that reconciles two systems can be easier to monitor and easier to correct than a stream of individual updates, especially when the source system produces bursts of changes at the end of a business day. The timing choice should follow the business need: a customer-facing status must be current, while a financial summary may only need to be correct by the next morning. Each flow should state its freshness requirement in agreed hours or minutes, and the design should show what happens when the flow falls behind that requirement.

Timing also affects platform limits. A large set of updates sent in one burst can compete with user activity and can exhaust the allowance the platform gives to integrations in a given period. Spreading work across the day, or grouping updates into batches sized for the receiving platform, is usually a better answer than trying to push everything at once.

Questions buyers ask about Salesforce integration

Do we need middleware for every integration?

No. A single stable connection between two systems may not justify a middleware platform. The need grows with the number of consumers, the volume of messages and the requirement for central monitoring.

How do we stop duplicate records when a message is resent?

Carry a stable identifier with each message and check it before creating a record. Where none exists, define the business fields used for matching and the rule for ambiguous matches.

Who should own an integration after go-live?

Name one owner for the flow and one for each connected system. The flow owner decides on failures, and the system owners approve changes to the data each side is allowed to write.

Can the data model change after an integration is live?

It can, but every change should be reviewed against the integration design. A renamed field or a changed picklist value is a common cause of silent failure.