Decision Step
A Decision step asks several small questions about the conversation in a single request, then picks the next step from a table of rules. Use it when a branch depends on more than one thing, or when you want the workflow to know how sure it is.
It sits alongside Condition and Switch in the Workflow Designer, directly below Switch in the step palette. It appears there only when the step has been enabled for your platform, so ask your administrator if you cannot see it. Workflows that already use a Decision step keep working either way.
When to use which
| Step | Use it when |
|---|---|
| Condition | One yes or no test decides between two paths. |
| Switch | One value selects among several paths. |
| Decision | Several judgments combine ("technical AND angry"), you need a confidence level, or you want the answers available to later steps. |
A Decision step does not run a full agent turn, so it is quicker and cheaper than reaching the same branch through a Condition or a Switch. It reads the recent conversation and the latest user message. It does not see the agent's system instructions, knowledge base or tools.
Questions
Add up to 10 questions. All of them are answered together in one request.
| Type | Ask it like | You get back |
|---|---|---|
| Yes or no | "Is the customer asking for a refund?" | A number from 0 (no) to 1 (yes). |
| Choice | "Which team should handle this?" with 2 to 255 named options, each with a note on when it applies | The chosen option, and a confidence from 0 to 1. |
| Score | "How upset is the customer?" with 2 to 10 described levels | A position on the scale, starting at 0, and a confidence. |
Each question has an id as well as its wording. The id must be lowercase letters, digits and underscores, starting with a letter, and at most 40 characters long, because it becomes part of a variable name.
Tips for good questions:
- Ask for a judgment a knowledgeable person makes in a second. Split a big question into small ones.
- Questions are read literally. State the exact condition you mean.
- For a Score, describe a situation at each level ("Threatening to leave"), not a degree ("Very").
- Do arithmetic and date comparisons in other steps. This step is for meaning, not maths.
Rules and output ports
Rules are checked top to bottom and the first match wins. Each rule becomes an output port on the step. A rule holds one or more clauses, and all of them must be true. A step can have up to 8 rules.
| Rule | Goes to port |
|---|---|
department is technical_support AND sentiment is at least 3 |
Urgent technical |
department is technical_support |
Technical |
| wants_refund is at least 0.8 | Billing |
| anything else | Otherwise |
A clause compares one answer to a fixed value. Which operators you can pick depends on the question type:
| Question type | Operators |
|---|---|
| Yes or no, Score | is at least, is below |
| Choice | is, is not, is one of |
- The Otherwise port is always present and always last. You can rename it in the Otherwise
port label box. No rule may take that label or the label
Unsure, and no two rules may share a label. - The scale is shown next to each threshold box (0 to 1 for Yes or no, 0 to the top level for a Score). A threshold from one question type does not carry over to another.
- To express "A or B", give each its own rule and connect both ports to the same next step.
- Reordering rules keeps each connection with its label. A rule that you rename and move in the same edit can lose its connection, so check the canvas afterwards and re-wire it if needed.
The Unsure port
Set Take an Unsure port when confidence is below to add an amber Unsure port. The value must be above 0 and at most 1. If any question a rule uses comes back with a confidence lower than that value, the step takes Unsure before checking any rule. Connect it to a clarifying question or a hand-off to a person. A value around 0.5 is a reasonable start. Tune it with the Test panel.
Using the answers later
Every answer is saved as a workflow variable under the step's Node name, which must be lowercase
letters, digits and underscores, starting with a letter, and at most 40 characters long. For a step
named triage:
| Variable | Example value |
|---|---|
{{triage.department}} |
technical_support |
{{triage.department.confidence}} |
0.91 |
{{triage.sentiment}} |
3.4 |
{{triage.wants_refund}} |
0.12 |
{{triage.port}} |
Urgent technical |
{{triage.outcome}} |
Ok |
The outcome variable is set on every run, and it exists so that a later step can tell "no rule
matched" apart from "the questions could not be asked", because both of those take the Otherwise
port. It holds one of six values:
| Outcome | What happened |
|---|---|
Ok |
The questions were answered. |
Failed |
The decision service was slow or unavailable. |
Denied |
The agent is over its budget. |
Blocked |
The agent's data guard blocked the content. |
Disabled |
The feature is not enabled on your environment. |
RateLimited |
The decision was skipped because the platform was pacing its requests. |
Numbers are rounded to at most four decimal places. Use the variables in Message steps and MCP Call instructions. Asking several questions once at the top of a workflow, then reading the variables further down, is cheaper than asking again.
Testing
Open the step, paste a customer message into Test (up to 8000 characters) and choose Run test. You see the port the step would take and why, every answer with its confidence and the probabilities behind it, the input token count and how long the call took. The cost appears as well when the model it used has a price set. A test is a real, billed call. The agent's owner can run one, and so can anyone else in the agent's organisation.
The panel also shows where the time went, stage by stage, so a slow test tells you which part of it was slow.
Save the workflow once before the first test. Until you do, the panel answers Save the workflow once before testing.
If something goes wrong
The step takes the Otherwise port and the conversation continues when:
- the decision service is slow or unavailable,
- the agent is over its budget,
- the agent's data guard blocks the content (for example a password or API key in the message),
- the platform is pacing its requests at a very busy moment and skips the decision,
- the feature is not enabled on your environment.
No answers are published in that case. The port variable is set to the Otherwise label and the outcome variable names which of these happened. The full reason is recorded on the workflow step and can be reviewed with the conversation.
The outcome variable records which of these happened, so a later step can treat them differently.
A decision skipped because the platform was pacing its requests reads RateLimited, and it is rare.
Privacy
Before the conversation text is sent for evaluation, personal data such as identity numbers, card numbers and contact details is removed, even if the agent's own PII Guard is switched off.
Your own wording is not treated that way. What you type into questions, options and levels is sent exactly as you wrote it and is never scanned or masked, so do not put real customer details into a question.
Credentials are handled by the agent's Secrets Guard. On its default setting a message that contains one is refused rather than redacted, so the step takes the Otherwise port. Set Secrets Guard to redact instead if you would rather the credential be masked and the decision go ahead.
Decision calls appear in usage reports with the call type decision.
Next steps
- Steps, Branching & Tools for the other step types.
- Testing & Conversations to exercise the flow end to end.