💃 A guide to making callouts from a trigger 🕺

Technical Salesforce tools for your tool belt

Good morning, Salesforce Nerds! The past couple of months I’ve been interviewing for various levels of Salesforce developers.

I typically dedicate half the interview to asking technical questions. 🧑‍💻 

I’ve been getting mixed answers on one of them in particular …

“If business requirements dictate we make a callout to an external system from a trigger, how would you implement the solution?”

So, I thought I’d write a bit about it. 🤷 

TABLE OF CONTENTS

GETTING ON THE SAME PAGE

Trigger Recap

First, let’s level set. I don’t want to get too in-depth here, but we should all understand how triggers work. 🧑‍🎓 

Triggers are blocks of code that execute automatically in response to certain DML operations on an SObject.

What’s a DML operation? 🤔 

Easy - an INSERT, UPDATE, or DELETE is a DML operation.

So, a trigger is just code that runs when these operations occur in your org.

Allowing you you can automate tasks/processes! 💪 

Each operation has two main types of triggers:

 Before trigger - these run before the records are inserted, updated, or deleted.

 After trigger - these run after the records are inserted, updated, or deleted.

A trigger can cause other triggers to fire and even cause itself to re-fire! That’s called recursion. 👎️ 

WHAT’S THE DEAL

A little background

Cool, so now we’re all on the same page let’s see what the deal is with performing a callout from a trigger.

Long story, short - you can’t do it. 😡 

For good reason, actually …

What if the external service you called from a trigger took 2 minutes to do it’s thing and return a response? 😲 

This means we’re blocked, right?

When the business comes to you and says “we need to update the ERP in real-time when the deal closes” …

Do we tell Brad we can’t do it and to take a hike?

Well, not so fast. There are options … 👇️ 

WHAT ARE OUR OPTIONS

Potential solutions

While we may love the idea of telling Brad NO 🚫, we really do need to meet the needs of the business.

And we actually can in this scenario.

So, let’s examine what we can do here.

Here’s a hint - we’re going asynchronous!! 🔀 

👉️ @future method - a method that executes in the background. These are regularly used for long-running processes. Which a callout to an external system can be.

👉️ Batch Apex - a block of code that also runs asynchronously. These can perform callouts, but that’s not the main use case. Primarily, these are for processing large volumes of data. Which could converge with our requirement.

👉️ Queueable Apex - again, a block of code that runs asynchronously. Different than Batch Apex though. This one isn’t for processing millions of records. It also gives us much more control over our code than a simple @future method.

👉️ Platform Event - a communication mechanism for apps built within Salesforce and outside of Salesforce. These are based on a pub/sub model and work with a message bus that handles a queue of events.

PICKING THE BEST ONE

Preferred solution

Every solution on the platform is unique. Tailored to meet the unique need of your business and this specific use case. 💯 

With that in mind it’s impossible to say you should always do THIS and never do THAT.

If I had to rank the above solutions somehow then I’d go with this:

🥇 Platform Event - I mean, I love me some event-driven architecture. So if this is an option then I’d take it. Is the external system capable of receiving an event? If it’s on AWS, then maybe configuring an Event Relay with a Platform Event would be all you need to do? Or you could subscribe to the event with Apex and just perform a callout from there … You’d burn a PE & an API call but think of the experience! 😆 

🥈 Queueable Apex - probably the path I’d take the most for just making a REST callout from a trigger. Queueable’s are much more elegant and come with more control than @future methods.

🥉 @future method - not a bad choice for a quick & dirty callout, I guess. Just remember, you can’t monitor the job. You can only pass it primitive data types. Queueable > @future.

 Batch Apex - every org on the planet is running Batch Apex. But, it’s not the best choice for making callouts from triggers. If you see this in your org (and I have seen it out there in the wild) then refactor this. You have our permission to add it to your next sprint.

SOUL FOOD

Today’s Principle

"I have not failed. I've just found 10,000 ways that won't work.”

Thomas Edison

and now....Salesforce Memes

What did you think about today's newsletter?

Login or Subscribe to participate in polls.