Should Salesforce Send Case IDs Back to External Systems? A Design Perspective

🧩 Problem Statement

Salesforce is the entry point for case creation but acts as a consumer, not the system of record. Here's the simplified flow:

1. Salesforce sends a case creation request to a Middle Layer, which passes it to the External System (the system of truth).

2. The External System creates the case and synchronously sends back the case details (including an external case ID).

3. Salesforce creates the case and stores the external case ID for traceability.

4. Separately, the External System emits a webhook event upon case creation.

5. The Middle Layer pushes this event to Salesforce and other consumers.

6. Salesforce checks for deduplication using the external case ID and ignores if already present else creates the record.

7. You now face the decision:

   Should Salesforce send its own Case ID back to the External System after creation, especially when received via the async webhook?

🏗 Architectural Context

• External System is the source of truth for case creation.

• Salesforce is a consumer and stores the external_case_id for mapping.

• Middle Layer ensures delivery of events and acknowledgment.

• Retry logic for failed events lies with the External System.

🛠 Design Decision

✅ Decision: Do not send the Salesforce Case ID back to the External System.

🎯 Why?

🔹 1. Business Logic Doesn't Need It
The external system doesn’t rely on the Salesforce Case ID for any downstream processing. There's no reverse lookup or cross-system update from external using Salesforce ID.

🔹 2. Already In Sync via External Case ID
Salesforce stores the external_case_id upon creation. That ID is sufficient to trace, debug, or correlate any record between systems.

🔹 3. Avoid Unnecessary API Calls
Sending the Salesforce ID back adds an additional API call with no tangible benefit. Over time, this increases complexity, API cost, and potential for failure without business gain.

🔹 4. Responsibility Lies with the Event Producer
Any delivery failures (due to webhook issues or downstream errors) are retried by the external system, which is already handled via acknowledgments from the middle layer.

🔁 General Industry Patterns 

Scenario	Sync IDs Back?	Reason
Bidirectional Sync (CRM ↔ ERP)	✅ Yes	Each system needs to reference the other.
One-Way Sync + Traceability	❌ No	Source system doesn’t need the secondary system’s ID.
Audit/Compliance-heavy domains	✅ Sometimes	Used for full trace logs or incident tracking.
Event-Driven Systems with Deduplication	❌ No	Deduping is done using external ID or unique hash keys.