The connection works. Salesforce sends the record. The other system returns a response. Everyone moves on, until an order is missing, someone clicks Retry, and finance finds two of them.
An integration strategy needs to describe what happens to the business transaction, including when a system is slow, a request is repeated, or the answer never comes back. A successful connection test doesn't settle those questions.
We start with one workflow and make its decisions explicit. Here's a hypothetical company that sends approved orders from Salesforce to an ERP. It's a design exercise, not a claim about a client's implementation or a ready-made configuration for every ERP.
Define the outcome before choosing the connector
Our example has a simple business requirement: an approved order should reach the ERP, receive an ERP order number, and show a trustworthy status in Salesforce. A salesperson should be able to distinguish "waiting" from "created" without opening a support ticket.
Write the acceptance statement before shopping for middleware:
"For each approved order version, create at most one corresponding ERP order, record the confirmed ERP identifier, and expose unresolved failures to an assigned operator."
That sentence raises useful questions. Can an approved order change? Does a revision amend the existing ERP order or create a new one? What if billing information is invalid? Who can cancel after fulfillment begins?
Those decisions belong to the business process. A connector can carry them out once we've defined them.
This is where revenue systems architecture earns its place: deciding how the process crosses systems before the team hardens assumptions into code.
Assign ownership by field and transition
"Salesforce is the source of truth" is too broad for this workflow. We need a more precise agreement:
Salesforce owns the submitted commercial order version and approval evidence.
The ERP owns the assigned ERP order number and fulfillment status.
The integration records attempts, external references, and processing outcomes.
An operations owner resolves rejected or ambiguous transactions.
For billing terms, decide which system is authoritative and when changes are allowed. If both systems can edit the same value, define the conflict rule. "Whichever update arrives last" is a rule, but it might not be the one finance intended.
Treat a cancellation as a business transition with eligibility rules, not a generic delete. A request to cancel isn't proof that the ERP accepted it.
Document these decisions with the people responsible for revenue operations. Otherwise, an engineer ends up deciding commercial policy from an error message.
Choose the timing the workflow actually needs
Salesforce's integration patterns distinguish synchronous request-and-reply, asynchronous messaging, and batch approaches. The appropriate choice depends on whether the caller needs an immediate response and how the work should run. Salesforce's Integration Patterns guide provides the architectural reference.
For our example, assume the business accepts a short delay between approval and ERP confirmation. We can propose an asynchronous submission and show Pending in Salesforce while processing continues.
If a salesperson must receive a live credit decision before approving the order, that is a different requirement. It may justify an immediate request, with an explicit experience for timeouts or service unavailability.
Choose an acceptable delay with the business owner. Then measure against it. "Near real time" is not an operating target if nobody can say when waiting becomes a problem.
Separate record identity from request identity
Our hypothetical order is ORD-2048. Its initial approved submission is operation ORD-2048:create:v1. These are proposed identifiers, not Salesforce API fields or an ERP convention.
The order key identifies the business record. The operation key identifies a particular action. Retrying the first submission keeps the same operation key. An approved amendment gets a distinct operation identity under the agreed amendment process.
Consider this failure: the ERP creates the order, but its response is lost. Salesforce still shows Pending. If the next attempt blindly creates another order, the retry becomes a duplicate sale in the downstream system.
Our proposed contract requires the receiver to recognize repeated operation keys and return the existing outcome. The key check and creation must be coordinated safely under concurrent requests; a preliminary "does it exist?" query alone can race with another request. Verify what the ERP or middleware actually guarantees.
For records written back into Salesforce, external-ID upsert can match and update an existing record. Use an appropriate uniqueness constraint where the business key must be unique. Salesforce's REST upsert reference documents that behavior. Upsert doesn't, by itself, prevent repeated side effects in another system.
If the receiver offers neither safe deduplication nor a reliable lookup by operation, don't advertise automatic retry as solved. Route ambiguous outcomes for reconciliation until a safe recovery mechanism exists.
Make business status more useful than transport status
A request being accepted for processing isn't the same as an order being created. In our example, use explicitly defined states:
Ready: the version passed approval and required-data checks.
Pending: processing has started, but creation isn't confirmed.
Confirmed: the ERP returned or reconciliation found the corresponding order identifier.
Needs attention: an operator must resolve a rejection or uncertain outcome.
Keep technical attempt details separately: operation key, attempt time, response category, and the external reference when available. Store only the payload and diagnostic data you actually need, with suitable access and retention controls.
Also decide how to handle late updates. If an older status arrives after a newer one, arrival time alone shouldn't make it authoritative. Use the source's supported version or sequencing information, or retrieve authoritative current state. Specify the rule in the contract and test it against the actual endpoint.
Design recovery beyond the replay window
For integrations using Salesforce platform events or change data capture through Pub/Sub API, Salesforce documents a 72-hour event retention window. Replay can help a disconnected consumer catch up within that window; it isn't an indefinite transaction archive. See Event Message Durability.
Our order workflow therefore needs a separate reconciliation procedure. Compare approved source orders with confirmed ERP identifiers. Investigate missing, conflicting, and unexpected records using the agreed keys.
For a temporary service failure, define bounded retries and an escalation point. For invalid billing data, send the record to the owner who can correct it. For an ambiguous timeout, establish whether the order exists before issuing an action that might duplicate it.
Give the queue an owner and an age threshold. In this example, the business might require review before the day's fulfillment cutoff. That threshold is an operating decision to validate, not a universal Salesforce best practice.
Track unresolved business transactions and their age alongside API failures. An integration can have a reassuring success rate while the one order that matters is still missing.
Make access and change ownership explicit
For outbound Salesforce callouts, named credentials and external credentials help separate endpoint and authentication configuration from application logic. Salesforce also documents how principals are mapped to permissions. The named credentials reference explains those components.
For our design, identify who owns credential rotation, who can use the integration, and which records and fields it may read or change. Test loss of authentication and restoration in a nonproduction environment. A shared administrator credential is not an ownership plan.
Version the integration contract when field meanings, required values, or state transitions change. Name the teams that must review it. Our CRM governance framework offers a practical place to put that responsibility.
Test the uncomfortable cases before launch
Run the complete workflow with both system owners present. Demonstrate a normal submission, a duplicate concurrent submission, a lost response after ERP creation, invalid billing data, a late status update, an expired credential, and an outage longer than the event replay window if events are used.
For each case, record the expected business outcome, actual records in both systems, visible Salesforce status, and recovery owner. Check that operators can resolve the problem using the runbook without guessing whether it's safe to click Retry.
The deliverable is a working contract plus evidence: field ownership, operation identity, timing, state transitions, failure handling, and reconciliation. That gives the next integration something useful to inherit besides an old password and a diagram nobody trusts.
About CRM Hacker
We help teams connect Salesforce, revenue operations, and the systems that keep customer work moving. Our Salesforce consulting work includes the process and data decisions that make integrations maintainable.
If your integrations move data but leave people chasing the outcome, let's untangle this. Contact CRM Hacker for a free initial conversation. Detailed audits and implementation work are scoped separately as paid engagements.