Skip to content
SteveTechArcSteveTechArc Courses

Where a Callout Can Run

Module 5 of 8 in the chapter Salesforce as an API Consumer, chapter 9 of the Integration Architect course. Each module stands on its own. Previous: Speed Limits · Next: AI in the Work

The question this module answers: Where in Salesforce can a callout run, and how do you choose between a page that waits, an asynchronous job, a flow, or not calling at all?

The six lines from module 2 work anywhere you can run Apex. Whether they’re allowed to run depends on what happened just before them, and whether anyone is waiting.

Call, Then Write

Section titled “Call, Then Write”

Here’s the rule, and it’s on the exam. You cannot write something and then make a callout in the same transaction. You can call, then write. But you can’t write, then call.

Salesforce wants to commit the save or roll it back, and it won’t hold a save open while it waits for another system. So it’s not only inserts and updates. Salesforce’s list of what blocks a callout: DML statements, starting asynchronous Apex, scheduling Apex, or sending an email (Callout Limits and Limitations (opens in a new tab), Apex Developer Guide, checked 2026-10-31). Queries are fine. Anything that changes something isn’t.

It catches you in places you don’t expect. I had a batch process making a series of callouts, and I wanted to call one and log it, call the next and log it. I couldn’t: the first log was a write, and the next call came after it. So I held the logs in memory, finished all the callouts, then wrote all the logs at the end. That works, but only with really good error handling. If an unhandled error hits before the end, every log you were holding is gone, and you have no record of what happened. That’s where you reach for something that survives the failure, like publishing a log event (chapter 14).

Chapter 4 showed the same rule from a flow, with the error message you’ll see and the flow’s fixes. Here’s the whole picture, by what starts the callout.

From a Page That Waits

Section titled “From a Page That Waits”

Sometimes a person must have the answer before they go on: they hit Save, and you need to check the customer’s account balance with the finance system first, and stop them with a message if it’s overdrawn. That’s synchronous: request and reply, with a person waiting.

You can’t do it from a trigger: the trigger runs after the save has started, so the callout would come after a write. There are two places it can run:

  • A Lightning web component with an Apex controller. The component’s button makes the call and shows the answer. For a long wait, an Apex continuation is Salesforce’s preferred way: “the preferred way to manage callouts because they can provide substantial improvements to the user experience”, and it can make callouts in parallel (Continuations (opens in a new tab), LWC Developer Guide, checked 2026-10-31).
  • A screen flow, making the call between one screen and the next.

And keep it short. If the answer is big, or the other system takes three, four, five seconds in production, it isn’t a good pattern. Users don’t wait three to five seconds. Before you agree to synchronous, ask: are the payloads small, and is the other system’s real response time a second or two? If not, it’s asynchronous, whatever the requirement says.

From a Save: Hand It Off

Section titled “From a Save: Hand It Off”

Most callouts start from a save. A delivery is marked delivered, and Redrock needs to hear. That save is a write, so the callout has to happen later, in a new transaction, after the save is committed. You write now and call later:

  • In Apex: a future method marked @Future(callout=true), or a Queueable class that implements Database.AllowsCallouts. Queueable is the more flexible one: it can carry objects, and its chained jobs can call out too (Queueable Apex (opens in a new tab), Apex Developer Guide, checked 2026-10-31). The exam asks about @Future(callout=true) at the highest level.
  • In a flow: a record-triggered flow’s asynchronous path, as chapter 4 built it.

There’s a cost to splitting them. The save and the callout no longer succeed or fail together. Salesforce has saved the delivery, and Redrock hasn’t heard yet, and for a while the two systems disagree. If the callout fails, they keep disagreeing until someone notices. So whoever designs the hand-off also owns that gap: the log, the retry, and the person who’s told (chapter 14).

And watch the numbers. A transaction can start up to 50 future methods, and none from inside another future method or a batch job (the governor limits from module 4). There’s a queue behind them, and it’s shared. If you have thousands or millions of these, don’t spawn all those individual future methods. I’ve had implementations where we saturated the future queue.

From a Job

Section titled “From a Job”

Scheduled and batch work can call out too. A Batch Apex class that implements Database.AllowsCallouts can make callouts in its batches (Using Batch Apex (opens in a new tab), checked 2026-10-31). The limits from module 4 apply to each batch, and the rule from the start of this module applies inside it: call first, then write.

Or Don’t Call at All

Section titled “Or Don’t Call at All”

When the volume is large, Salesforce’s own architects say to stop calling from Apex. For large-scale outbound work, “use platform events and robust middleware instead of callouts via asynchronous Apex”, because the asynchronous threads are finite (Asynchronous Processing on the Lightning Platform (opens in a new tab), Salesforce Architects, checked 2026-11-07). Salesforce publishes once; the integration layer does the calling, the retrying and the waiting. That’s Steve Trucking’s status design from Checkpoint 1, and it’s the “publishes; others subscribe” set on the map.

Where a callout can run Where a callout can run, by what starts it, in four rows: what starts it, where the callout runs, and what it means. A person on a page who must have the answer to go on calls now, from a component or a screen flow, synchronously, with a continuation for a long wait; the person waits, so only if it answers in a second or two. A save, in a trigger or record-triggered flow, hands off to a Queueable, a future method, or the flow's asynchronous path, a new transaction after the commit, in amber; it means saved first, heard later, also amber: someone owns the gap, with a log, a retry and someone told. A scheduled or batch job calls in batches, with Batch Apex that allows callouts, calling first and then writing in each batch; it means holding the logs and then writing them, with error handling that survives. Thousands of changes publish an event, so Salesforce doesn't call at all; middleware makes the calls, the calling, retrying and waiting. The legend: amber means the save and the callout succeed or fail apart. Underneath: call, then write; you can't write, then call, in one transaction. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-INT-SC-05", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} WHAT STARTS IT WHERE THE CALLOUT RUNS WHAT IT MEANS A person on a page must have the answer to go on A component or a screen flow synchronous; a continuation for a long wait The person waits only if it answers in a second or two A save a trigger or record-triggered flow Queueable, @future, or the flow's asynchronous path a new transaction, after the commit Saved first, heard later someone owns the gap: log, retry, tell A scheduled or batch job work in the background Batch Apex that allows callouts call first, then write, in each batch Hold the logs, then write with error handling that survives Thousands of changes more than Apex should call Publish an event Salesforce doesn't call at all Middleware makes the calls the calling, retrying and waiting calls now means hands off means calls in batches means publishes means Call, then write. You can't write, then call, in one transaction. HOW TO READ IT the save and the callout succeed or fail apart © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Where a callout can run, by what starts it.

Clicks or Code

Section titled “Clicks or Code”

Every one of these has a version in clicks. A screen flow can call out between screens; a record-triggered flow can call out on its asynchronous path; External Services and Flow HTTP callouts make the call without Apex (chapter 4). So when do you move from the flow to Apex?

In my experience: clicks are simpler, but they may not handle the complexities, the complicated mapping and the intricate steps. Code has more complexity, but it can handle more. Move to Apex when:

  • The answer needs real parsing: a shape module 3 would put past the first card.
  • Failures need real handling: retries with a wait, different actions for different status codes, a log that must survive the failure.
  • The volume is high: many records, many calls, where you have to count every limit yourself.
  • The work has many steps that depend on each other, across several calls.

And then ask who will look after it. The best choice is the one the team that owns it can maintain.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • Whether anyone waits. If a person must have the answer, a component or a screen flow, and only if the other system answers in a second or two. Otherwise, asynchronous.
  • Where the hand-off happens: a Queueable or future method, a flow’s asynchronous path, a batch, or an event for middleware.
  • Who owns the gap between the save and the callout: the log, the retry, the person told.
  • Clicks or code, by the parsing, the failures, the volume, and the team that will maintain it.

Test knowledge. Know that a callout can’t follow DML in the same transaction, and the ways around it: call before you write, or move the callout to asynchronous Apex, such as a method marked @future(callout=true). Know that a synchronous callout with a person waiting comes from a Lightning web component or a screen flow, not from a trigger.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.