A few weeks ago I caught myself about to replace a working guided flow in one of my demo orgs with an agent conversation. I had the design half-sketched before I stopped and asked myself the obvious question: why? Not “would it work” — it probably would. Why was I doing it?

The honest answer was embarrassing. Because agents are what everyone is building this year, and the guided flow felt old.

That is not a reason. It is a fashion. So I put the sketch down and went back to the question I should have asked first: what does this particular process actually need? I want to give you that question in a form you can use on Monday morning, because “which one is newer” is a terrible way to answer it.

Two tools, two different jobs

Let me define both plainly, in case one is new to you.

An OmniScript is OmniStudio’s guided flow: a sequence of screens that walks a person through a process one step at a time. You design the steps, the fields, the validation on those fields, and the order. At runtime everybody gets that sequence, because everything was decided at design time.

An agent — an Agentforce agent, say — is conversational. The user types whatever they like, in whatever order occurs to them, and the agent works out what they want and what to do about it. Nothing is fixed in advance except the topics and actions you gave it.

Now the sentence that does most of the work:

An agent is good at open-ended conversation. A guided flow is good at making sure nothing was skipped.

Read that twice. It is not a statement about which tool is more advanced. It is a statement about what each one guarantees.

The word that decides it: skipped

When a process has to be provable — a consent screen that must be seen before a signature, disclosures that must appear in a set order, a set of details that must all be collected before a case can be worked — the requirement is not really “help the user through it.” The requirement is nothing may be omitted, and you must be able to show that afterwards.

A guided flow gives you that structurally. Step three cannot be reached without passing step two. The validation on a field fires for every user, every time, because it is part of the screen rather than part of a decision. If the flow completed, the sequence happened. That is not a claim about the average case; it is a property of the design.

A conversation gives you flexibility instead, which is the opposite property. A good agent will usually gather everything. “Usually” is a wonderful word in a support chat and a terrible word in a compliance conversation.

So my first question about any requirement is now: if someone asks me in six months to prove this step happened, what is my evidence? If the honest answer is “the transcript, probably,” and the step matters, I want a guided flow doing that part.

Where the agent is plainly better

I do not want to leave you with the impression that guided flows win by default. They lose badly in one very common situation: when you do not know what the user wants.

A form can only help someone who already knows which form they need. If a customer arrives with “why has my bill gone up?”, no wizard on earth serves them, because you cannot show a person the right screen when you cannot yet tell which screen is right. Understanding an unpredictable request in the user’s own words is precisely what agents are for.

That gives a clean division. Unpredictable input, open-ended goal → conversation. Known process, known required inputs, validation at each step → guided flow. Most real requirements contain both, which brings us to the useful part.

They compose better than they compete

The pattern I keep landing on is a handoff, and once you see it you will see it everywhere.

The agent takes the front door: it works out what the person actually wants, answers the questions around it, looks things up, explains options in plain language — all the parts where a fixed sequence would be an obstacle. Then, at the moment the process becomes a procedure — “yes, go ahead and change it” — it hands the person into an OmniScript that walks the change through the exact steps, with the validation on each one.

Notice what each tool is doing. The agent is doing comprehension. The flow is doing completeness. Neither pretends to be the other, and the user experiences one journey.

There is a second, quieter composition underneath the screens. The Integration Procedures and DataRaptors you built to feed your OmniScripts — server-side orchestration and declarative data shaping — do not care who is asking. An agent action can call the very same Integration Procedure your flow calls, and when it does, the two can never contradict each other, because they read through one pipeline. That consistency is worth more than it sounds on the day someone notices the chat and the screen disagreeing.

The question I ask before I choose

Four questions, in this order. They take about a minute.

  1. Must the outcome be identical every time? If a compliance team, an auditor or a regulator will ever ask about this step: guided flow.
  2. Do I know in advance exactly what must be collected? If yes, a flow collects it faster and more reliably than a conversation will. If no, you are not ready to build either one.
  3. Is the user’s starting point unpredictable? If they arrive with a question rather than a task, put an agent at the front.
  4. Is this really a bespoke interface problem? A scheduler, a custom visualisation — then neither tool fits and you should write a Lightning web component.

None of those questions mention which technology is newer, and that is deliberate.

A word to anyone learning OmniStudio right now

If you are part way through learning this toolset and wondering whether you picked the wrong year: no. You are learning the deterministic layer, the part that guarantees a sequence happened, and agents make it more valuable rather than less — someone has to build the provable ground a conversation hands off to. The durable skill is judgement about which parts of a process must be identical every time.

Your next step

Take one process you own — an onboarding, a change request, a claim — and split it on paper into two columns: parts where the user might say anything, and parts where nothing may be skipped.

If both columns have entries, you have found a handoff, and designed something better than either tool alone would have given you. If only one column has entries, your decision is already made and you can stop debating it.

If OmniScripts are new, start with OmniScripts explained, then Integration Procedures — the layer both consumers share. The wider series lives in OmniStudio.

Mustafa Aksu

Salesforce developer & ISV builder focused on Revenue Cloud, Agentforce, and Data Cloud. I write from real, shipped work.