Long Waits and People
Module 7 of 8 in the chapter Integration Orchestration, chapter 15 of the Integration Architect course. Each module stands on its own. Previous: Where the Conductor Lives · Next: Orchestrating Agents
The question this module answers: When a step in a process waits hours or weeks, for a person or another system, how do you design the wait so it doesn’t break, and so it ends?
Some Steps Take Days
Section titled “Some Steps Take Days”Everything so far in this chapter happened in seconds. Check the balance, place the order, update inventory. But many real processes have a step that waits.
A discount over 20% needs a sales manager’s approval, and the manager is travelling. A contract waits for the customer’s signature. A partner’s system accepts a request and says it will call back when the work is done, sometime later today. The process can’t go on until the answer comes, and the answer might take a day, a week, or never come at all.
Those waits are where long processes break. Not because anything fails, but because nobody designed what happens while they wait, and what happens if the wait never ends.
A Wait Is Saved State, Not an Open Call
Section titled “A Wait Is Saved State, Not an Open Call”The first rule: nothing should be held open while you wait. Not a transaction, not a callout, not a screen. A callout that waits a week isn’t a design; it’s a timeout waiting to happen.
Instead, the conductor saves where it is, and stops. Then something wakes it up: the approval, the callback, or a time. In Salesforce, Flow does exactly this. When a flow reaches a Wait element, “the existing transaction ends and a new one begins”, and the flow interview is paused, saved, until a resume event arrives. The paused interviews show up on the Automation app’s Monitor tab, so someone can see what’s waiting (chapter 14 module 7).
Wait by saving where you are.
For a person, the step becomes a task. Flow Orchestration’s interactive steps work that way: “When an orchestration runs an interactive step, the designated user receives an email with a link to their assigned action” (module 6). The manager approves when they get to it, and that’s the resume event.
Every Wait Needs a Deadline
Section titled “Every Wait Needs a Deadline”Here’s the design rule that matters most: every wait has two ways out, the answer and the deadline. If you only design for the answer, the process waits forever the day the answer doesn’t come.
Salesforce’s Wait element is built for this. It can wait for more than one thing at once, and “For the first resume event that occurs, the flow resumes and runs the connector for the associated pause configuration.” So you give it two: the manager’s decision, and a date three days from now. Whichever comes first wins.
Every wait has two ways out.
What happens at the deadline is a business decision, and there are only a few choices:
- Remind, and wait again.
- Escalate to someone else: the manager’s manager, the integration’s owner.
- Decide by default: approve small things automatically, refuse large ones.
- Stop, and undo what the process already did, with module 5’s undo steps.
The business picks, for each wait. The architect makes sure there’s a pick.
The Step That Never Answers
Section titled “The Step That Never Answers”A person who doesn’t answer is one kind of silence. A system that doesn’t call back is another, and it’s sneakier.
A partner’s system accepts your request with a 202 Accepted, module 1’s noncommittal answer, and promises to call back when it’s done (chapter 8 told you how to receive the callback: When Someone Calls You Back). The process waits. The callback never comes. Maybe their job failed. Maybe the callback was sent and lost on the way. Either way, your process is waiting for news that will never arrive.
The deadline handles it, the same as for a person. When the deadline comes:
- Ask before you act. Call the partner and ask what happened to request 1042, by its own key. Module 1’s unknown outcome: the callback may be lost, not the work.
- Then decide. If it was done, carry on as if the callback had come. If it failed, send it again, safely, or undo.
- If you can’t find out, hand it to a person. Chapter 14’s silence alert: “none” is a number too (chapter 14 module 6).
While You Wait, the World Changes
Section titled “While You Wait, the World Changes”One more thing that catches long processes. When the manager finally approves the discount on Thursday, is the order still the order they’re approving?
The customer may have added items on Tuesday. The price list may have changed on Wednesday. Stock reserved on Monday may have been released by a nightly job. The longer the wait, the more likely something under the process has moved.
Two habits help:
- Lock what must not change. Module 3’s in-between status works as a lock: while the order is Awaiting approval, it can’t be edited.
- Check again before you go on. When the wait ends, re-read what the next step depends on, and stop if it’s changed. Don’t act on Monday’s picture of the world on Thursday.
Test knowledge. Know how to design a multi-step process that waits on people or external systems: save the state and pause (in Salesforce, a flow’s Wait element, or an orchestration’s interactive step), never hold a transaction or a callout open; give every wait a deadline; and when a callback doesn’t arrive, check the outcome before resending.
Beyond the exam: what AI changes. Agents bring a new kind of wait: the agent asks a person to confirm before it acts. It’s the same design. The agent saves where it is, the person’s answer or a deadline wakes it, and on the deadline the default is the safe one, not the hopeful one. An agent that waits forever for a “yes”, or acts after a week on a picture of the world that’s out of date, has the same bugs as any long process.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- Which steps wait, for whom, and how long they usually take.
- How each wait is saved, never as an open call or transaction.
- The deadline for every wait, and what happens on it: remind, escalate, decide by default, or undo.
- For callbacks that may never come: how to ask what happened, by the request’s key.
- What’s locked while the process waits, and what’s checked again before it goes on.
Explore
Section titled “Explore”- Salesforce Help, Wait for Conditions Element (opens in a new tab) (checked 2026-11-07).
- Salesforce Help, Automate Complex Processes with Orchestrations (opens in a new tab): interactive steps (checked 2026-11-07).
- When Someone Calls You Back: chapter 8, receiving a callback.
