💃 Twice the fun? Not so fast! 🕺

Good morning, Salesforce Nerds! We’ve all been there.

You’re sipping your coffee, cruising through your logs, when you notice something odd: the same record just got created … again. 🤔 

And again. 😟 

And again. 😱 

Five invoices for one transaction. Three identical emails to the same customer. One very angry finance team.

This is the chaotic world of non-idempotent integrations - where the same message can wreak havoc on your Salesforce instance if your architecture isn’t ready for it. 🧩 

But fear not: idempotency is here to save your sanity (and your data).

Let’s dive into how to design Salesforce integrations that can handle repeat visitors with grace. 🤿 

TABLE OF CONTENTS

Twice the fun? Not so fast!

• What is Idempotency?

• Why Events Get Repeated

• Implement Idempotency in Salesforce

• Double-Edged Swoard of Idempotent Design

• Conclusion

PUSH THE BUTTON. JUST ONCE.

WHAT IS IDEMPOTENCY?

In the world of integrations, idempotency means one thing:

Repeatable calls without repeat consequences. 🔥 

Whether it's an external system retrying a call or Salesforce receiving the same event five times before lunch, an idempotent system says, “No problem, I’ve got this,” and calmly processes the request once - ignoring the duplicates.

Clean. 🤌 

It’s like pressing the elevator button. 🛗 

Pushing it again and again won’t get it to arrive faster. It’s the first press that sets it in motion and the redudant presses are ignored.

And if they’re not, congratulations - you’ve discovered a race condition in the building. 🎉 

SAME MESSAGE, DIFFERENT DAY

WHY EVENTS GET REPEATED

Salesforce is a platform built for asynchronous eventing - CDC, Platform Events, and Outbound Messages all embrace at-least-once delivery. 🚚 

That means your listener could get the same message multiple times, and if your Apex logic is trigger-happy, you might:

🔂 Insert the same record repeatedly

📤️ Fire off duplicate emails

💸 Invoice the customer twice (don’t expect a thank-you)

So, BOLO and design around the common culprits behind these repeated messages.

Things like 👇️ 

♻️ Network retries from external systems

⏳️ Timeouts that make clients assume the message wasn’t received

❌ Middleware failovers or batch replays

▶️ Event replay logic gone rogue

YOUR INTEGRATION’S ONE-WAY MIRROR

IMPLEMENT IDEMPOTENCY IN SALESFORCE

Making your Salesforce integration idempotent is less about brute force and more about smart filtering. 🧠 

Here are a few common strategies:

🗝️ Use External IDs with Upserts

External IDs let Salesforce uniquely identify records based on an external reference. This is integration gold. 🥇 

upsert recordsToInsert External_Id__c;

If a record with that External ID already exists, it’s updated - not duplicated. 👍️ 

🗝️ Store Custom Idempotency Keys

Sometimes the external system doesn’t send a nice External ID, but it does send enough data to generate one - like a transaction ID, message GUID, or hash.

Store this key in a custom object or field to prevent re-processing. 🚫 

if (!existingKeys.contains(incomingEvent.IdempotencyKey)) {
    processEvent(incomingEvent);
    storeKey(incomingEvent.IdempotencyKey);
}

Bonus points if you hash a payload signature and store that instead. #️⃣ 

🧠 Use Platform Cache or Custom Object for Deduping

For short-term storage (e.g., deduping Platform Events), Platform Cache works great - but remember it’s not durable across org restarts. 🙀 

For long-term deduplication, go with a custom object like Processed_Event__c that tracks processed IDs or hashes. 🎯 

This helps a lot for troubleshooting, too. If you don’t have a record retention policy yet, I’d recommend one here.

Storing event data can quickly consume storage. 🫠 

FEWER NIGHTMARES, MORE OVERHEAD

DOUBLE-EDGED SWORD OF IDEMPOTENT DESIGN

Idempotency might sound like the answer to all your integration prayers - and in many ways, it is.

But like any good architectural pattern, it comes with trade-offs. 💯 

For every duplicate event it helps you dodge, there’s a bit of complexity you’ll need to embrace. 🧩 

It’s not a magic spell - it’s a contract: "I promise to handle retries safely, but you promise to manage the baggage that comes with it." 

Let’s explore both sides of the blade - the wins, and the watchouts. 👇️ 

✅ Benefits

🚀 Data integrity: No more duplicate rows, rogue invoices, or apology emails.

🚀 Resilience: Safer retries, smoother error recovery.

🚀 Observability: Knowing whether a request was already handled can help with debugging and monitoring.

🚀 Less clean-up: No late-night queries to delete the same record five times.

⚠️ Risks & Gotchas

❌ False positives: What if you accidentally block a legit retry?

❌ Race conditions: Two threads check for a key, don’t find it, and both process.

❌ Key bloat: You’ll need to clean up your deduplication store eventually.

❌ Out-of-order events: Especially tricky when CDC events arrive late or out of sequence.

ONE AND DONE

CONCLUSION

Idempotency isn’t just a best practice - it’s a defensive pattern for Salesforce Architects and developers working in the wild west of event-driven systems. 🤠 

Done right, it keeps your org clean, your finance team calm, and your operations team out of panic mode. 😅 

So next time you’re building an integration, remember:

SOUL FOOD

Today’s Principle

and now....Salesforce Memes