💃 Check Please! 🕺

Good morning, Salesforce Nerds! I’ve got a scenario for you today … 😎 

You’re deep in a two-way integration between Salesforce and a sprawling landscape of external systems.

Everything’s humming along… until your Apex heap size limit throws a tantrum. 💥 

👎️ Platform Events are groaning under payload bloat

👎️ Continuation callouts are limping through oversized JSON

👎️ Your carefully constructed integration suddenly starts to feel like a Jenga tower during an earthquake

This is your world before the Claim Check pattern.

But … let’s rewind and fix that, shall we?

TABLE OF CONTENTS

Check, Please!

• What is the Claim Check Pattern?

• Why Use It in Salesforce?

• Core Components

• A Two-Way Love Story

• Final Thoughts

WHEN YOUR PAYLOAD NEEDS A COAT CHECK

WHAT IS THE CLAIM CHECK PATTERN?

The Claim Check pattern is a classic enterprise integration design.

Shout out to Gregor Hohpe and Bobby Woolf! 📣 🎉 

Basically, it lets you offload large payloads to external storage and replace them in your workflow with a compact “claim check” (aka reference ID).

In Salesforce, that means …

Instead of stuffing your Platform Event, HTTP request, or Queueable job with the whole 8-course meal, you just drop in a valet ticket and let the system fetch the data when needed. 🤙 

It’s basically Salesforce's way of saying, "Hold my payload." 😅 

BECAUSE THE HEAP SIZE GODS ARE RUTHLESS

WHY USE IT IN SALESFORCE?

Salesforce is amazing… until it isn't. 🥹 

Governor limits are both a blessing (they keep us scalable) and a curse (they punch us in the heap when we try to do too much).

Here’s where the Claim Check patter should be a consideration in your next integration project: 👇️ 

THE SECRET SAUCE BEHIND THE CURTAIN

CORE COMPONENTS

Here’s how I’ve implemented the Claim Check pattern using some of the best toys in the Salesforce Architect’s toolbox: 🧰 

📦️ Amazon S3 for Payload Storage

Store large JSON/XML files or base64-encoded binaries securely and cheaply.

🔐 Named Credentials + Auth Providers

Simplify your callouts to S3 using external credential storage and avoid reinventing OAuth wheels.

⚡️ Platform Events for Decoupled Communication

Events contain only lightweight metadata + a claim check (like an S3 key).

📈 Apex Continuations for Async Callouts

Fetch those big payloads without blocking request threads or burning CPU.

⚙️ External Systems (Downstream + Upstream)

Push data to S3 before notifying Salesforce. Or let Salesforce drop the payload and notify the world it’s ready.

WHEN SALESFORCE AND EXTERNAL SYSTEMS SWIPE RIGHT

A TWO-WAY LOVE STORY

Let’s look at the end-to-end flow through a real-world scenario:

💌 Inbound Flow (External → Salesforce)

1. External system pushes the large payload to S3.

2. Then it sends a lightweight event to Salesforce with the claim check - in this case it’s the S3 key.

3. Salesforce receives the event and triggers an Apex class.

4. Using a Named Credential + Continuation, Apex reaches in S3 via a callout and fetches the payload.

5. Salesforce processes the data as needed (create/update records, etc.)

📤 Outbound Flow (Salesforce → External)

1. Apex prepares a massive payload (haha, “massive payload”)

2. Salesforce uploads it to S3 via Named Credential + Queueable Apex (it doubles your heap size!).

3. Then we pop a Platform Event or make a direct callout to notify the external system with the claim check - again the S3 key.

4. External system reaches into S3 with the key and fetches the data for processing.

CLAIM IT, CHECK IT, SCALE IT

FINAL THOUGHTS

The Claim Check pattern is your ticket to the big leagues. ⚾️ 

It's how you go from “We’re hitting heap limits!” to “Let’s scale this thing to five more external systems.” 😎 

With tools like Platform Events, Named Credentials, Continuations, and Amazon S3, you can build solutions that are elegant, performant, and governor-friendly.

💃 Happy Coding! 🕺 

SOUL FOOD

Today’s Principle

and now....Salesforce Memes