The User Waits

Module 2 of 8 in the chapter Integration Orchestration, chapter 15 of the Integration Architect course. Each module stands on its own. Previous: One Call, Many Steps · Next: There’s No Rollback Across Systems

The question this module answers: When a person on a Salesforce screen needs an answer from another system before they can go on, where does the orchestration run, and what does the screen have to do?

Someone Is on a Screen

Module 1’s orchestration ran behind the scenes. This one has a person in front of it.

A user is about to submit an order. Before they do, someone needs to check the customer’s balance in the accounting system. If the customer is over their limit, the order shouldn’t go. And the user is sitting there, waiting to find out.

So there are two kinds of orchestration. In one, Salesforce sends a request and the steps happen somewhere else, in the middleware or later, while nobody waits. In the other, it’s driven from the screen: Salesforce coordinates the steps, right now, with a person watching. This module is the second kind.

Why the Standard Save Can’t Do It

The natural place to put the check seems to be on Save. The user clicks Save, a trigger fires, it calls accounting, and if the balance is bad it stops the save. That’s what people ask for first.

You can’t do it that way. By the time a trigger runs, the save has started, and a callout can’t come after a write in the same transaction; a trigger can only hand the callout off to run later, asynchronously (chapter 9 module 5). And later is no use to a person waiting for a yes or no. The standard Save button can’t pause and wait for another system.

So a couple of years ago, on a project, we ended up building Lightning web components that would do the check, and Salesforce would orchestrate from the component. Today you have a second choice: a screen flow can do it too. Either way, the lesson is the same. If a person must wait for another system’s answer, you build the screen that waits.

Two Ways to Build It

A screen flow. Launch it from a quick action or a button on the record. The flow makes the call to accounting before it saves anything, shows the answer, and lets the user submit or stop. For the call itself, it uses the HTTP callout action from chapter 4, or External Services (chapter 4 module 3).

There’s a useful newer piece for this: the Action Button screen component. Salesforce describes it this way: “The screen action runs an active autolaunched flow, and the results of the autolaunched flow can be shown on the same screen as the button.” So the user clicks Check balance, and the answer appears on the same screen, without moving to the next one. Check in your own org that the callout behaves the way you expect inside a screen action.

A Lightning web component, with an Apex controller behind it. More work to build, and more control over the screen: exactly what the user sees while they wait, how long the wait can be, what happens on each answer. For a slow system, Apex’s continuation is Salesforce’s preferred way to wait (chapter 9 module 5).

Clicks or code is chapter 9’s question again: the flow is quicker to build and change, and the component handles more of the hard cases.

Where the Transaction Ends

One fact about screen flows matters more than any other here. Salesforce: “When a Screen element, local action, or Wait element is run, the existing transaction ends and a new one begins.”

That’s good news and a warning. The good news: each screen starts fresh, so a callout on the next step isn’t blocked by work from the last one, and chapter 4’s transaction control setting handles the rest (chapter 4 module 6). The warning: whatever the flow saved before a screen is committed when that screen appears. If the flow creates the order record first, then checks the balance, and the user cancels, the order is already saved.

So the order of the steps is a design decision. Check, then show, then save. Call accounting first. Show the user the answer. Only when they click Submit, save the order and send it on. That way, a user who stops leaves nothing behind.

The Screen Itself

Here’s the screen. It’s worth drawing before anyone builds it, because most of the design work is here.

Click to enlarge

The person waits for the screen, never for the system.

Walk through what has to be decided:

• What the user sees while they wait. Something that says it’s working, and a Submit button they can’t press twice. The Action Button gives you that: “When a user clicks an action button, the In Progress attribute for the associated screen action is set to true”, and you can set another component’s “Disabled field” to that attribute, so Submit stays greyed out until the answer arrives.
• How long they wait. Salesforce’s guidance is five to ten seconds where a person is waiting (chapter 14 module 4). Chapter 9 said it more bluntly: users don’t wait three to five seconds happily, so if accounting is slow in production, don’t make this synchronous at all.
• What each answer looks like on the screen. Approved, over the limit, and the one that’s easy to forget: no answer. Module 1’s five answers, shown to a person.
• Whether they may go ahead without the check. If accounting isn’t answering, can the user submit the order anyway, marked pending, with the balance checked later? That’s the same business decision as module 1’s “accounting down” square, now with a person asking it.
• What the screen is allowed to show. Salesforce adds a caution for the Action Button: “the outputs of the action associated with the component are available to the browser.” So the flow returns approved or over the limit, not the customer’s full account history. Send the screen only what the user is allowed to see.

None of these are coding questions. They’re questions for the business and the people who’ll use the screen, and they’re cheaper to answer on a drawing than after it’s built.

Test knowledge. Know that a callout can’t run while a user waits on a standard Save: a trigger can’t call out before the save finishes, so a synchronous check needs its own screen, a screen flow (calling out before it saves) or a Lightning web component with Apex (a continuation for long waits). Know that in a flow, a Screen, local action or Wait element ends the transaction and starts a new one.

When It’s Too Slow for a Screen

Sometimes the honest answer is that the user shouldn’t wait at all. If accounting takes eight seconds on a good day, or the check involves three systems, no screen design makes that pleasant.

Then flip it. The user submits the order, it’s saved as pending, and the balance check and the ERP submission happen in the background, the way module 1’s middleware does them. The user sees Pending now and Submitted or Over limit a minute later, on the record or as a notification. That’s not a failure of the design. For many orders, it’s the better design. The architect’s job is to tell the business which one they’re getting, and why.

Beyond the exam: what AI changes. An AI assistant can build either version of this screen quickly, a flow or a component. What it can’t do is sit with the people who’ll use it and ask what they should see when accounting doesn’t answer. Draw the screen with them first. Then give the AI the drawing.

What an Architect Decides Here

• Whether anyone should wait at all, from how fast the other system really is in production.
• Screen flow or Lightning web component, and where it’s launched from.
• The order of the steps: check, show, then save, so a user who stops leaves nothing behind.
• The screen’s answers, including no answer, and what each one lets the user do.
• The wait: what’s shown, how long, and that Submit can’t be pressed twice.
• What the screen receives, only what the user may see.

Explore

• Salesforce Help, How Flows Run in Transactions (opens in a new tab) (checked 2026-11-07).
• Salesforce Help, Action Button Screen Input Component (opens in a new tab) (checked 2026-11-07).
• Where a Callout Can Run: chapter 9, a page that waits, a save that hands off.
• What You’ll See When It Breaks: chapter 4, transaction control and fault paths in Flow.