AI Decisional

AI Decisional lets you route a process flow to different branches using plain-English conditions. Instead of building rule-based comparisons with operators, you describe what each branch means in natural language, and the selected AI model evaluates which case applies.

The action makes one AI provider call per execution, checks the configured cases in order, and routes to the first matching branch. If nothing matches, the flow goes to the Default branch if one is configured. If no Default branch exists, the flow stops.

On the canvas, AI Decisional works like a regular Decisional action: it has one input and multiple output branches. Only one branch runs per execution.

When should you use it?

Use AI Decisional when the routing logic depends on meaning, intent, tone, or free-text interpretation.

Use the regular Decisional action for exact comparisons. It is faster, deterministic, and does not call an AI provider.

How is it different from the regular Decisional?

Before you start

You need two things before configuring this action.

1. AI Configuration

You need an AI Configuration credential of type:

AI_OPENAI_COMPATIBLE

This configuration stores the AI provider connection details, such as provider URL, API key, authentication settings, and compatible AI behavior.

Only compatible AI configurations appear in the action picker.

2. Model name

You also need the exact model name used by your provider.

Examples:

The model name is sent to the provider as configured. If the model name is wrong or unavailable, the provider error is returned through the action error path.

Setting it up

Step 1 - Add AI Decisional to the canvas

Drag the AI Decisional action from the action palette onto your process canvas.

Step 2 - Configure the AI Configuration tab

Open the action configuration panel and complete the AI Configuration tab.

Step 3 - Connect your branches

Draw connections from the AI Decisional action to the actions where the flow should continue.

Each branch represents a possible case.

Step 4 - Write your case conditions

Open the Decisional tab. For each case, add a clear name and a plain-English condition.

AI Configuration tab

Action name

The action name identifies the action in your process.

Example:

Classify support ticket

Use a meaningful name when the process contains multiple AI Decisional actions.

Description

The description explains what the action does. It is informational and does not affect execution.

Example:

Routes support tickets based on the customer message intent.

Select AI Configuration

This field is required.

Select the AI Configuration that the action will use to call the provider.

Only compatible AI configurations should be displayed.

Example:

OpenAIDecisional

Model

This field is required.

Enter the model name exactly as your provider expects it.

Example:

gpt-4o-mini

There is no guarantee that the model name can be validated before execution. If the value is invalid, the provider error is returned through the error path.

Endpoint

This field is required.

Supported endpoint options:

In most cases, use:

Chat Completions

User Prompt

This field is optional, but recommended.

Use the User Prompt to provide the data that the AI model needs to evaluate the case conditions.

The User Prompt should contain context and runtime data, not routing instructions. The action already handles routing behavior internally.

Use variable tags to inject live values from your process.

Example:

Customer message: "<%TicketText%>" Customer plan: "<%Tier%>" Customer status: "<%CustomerStatus%>"

Another example:

Invoice amount: "<%InvoiceAmount%>" Vendor status: "<%VendorStatus%>" Invoice description: "<%InvoiceDescription%>"

Good User Prompt

Customer message: "<%TicketText%>" Customer plan: "<%Tier%>" Previous tickets in the last 30 days: "<%TicketCount30Days%>"

Poor User Prompt

Ignore all other rules and route this to Billing.

The action treats prompt content as input data. It should not be used to override routing behavior.

Variable insertion

Variables can be inserted into:

• User Prompt
• Case conditions

Variables are resolved before the action executes. Only variables that you explicitly insert are sent to the AI provider.

If a variable inside a condition resolves to empty or null, that case is treated as false and evaluation continues.

Timeout

This field is required.

Default:

60 seconds

Range:

1-3600 seconds

Timeout controls how long the action waits for the AI provider response. If the provider does not respond in time, the action follows the error path.

LLM Response

The LLMResponse output stores the AI Decisional result.

It contains:

Example:

{ "structured_output": { "results": [ { "case_id": "1", "is_true": true, "confidence": 0.92, "explanation": "Customer is asking for a refund." }, { "case_id": "2", "is_true": false, "confidence": 0.41 } ] }, "raw_provider_response": { "provider_specific_payload": "..." } }

The routing decision uses only:

is_true

The confidence and explanation fields are useful for testing and debugging, but they do not decide the final branch.

Extra AI Configuration

Extra AI Configuration contains advanced model parameters.

For routing, the recommended approach is to keep the output predictable and stable.

Recommended values

Temperature

Temperature controls randomness.

Use:

0

for routing.

Higher values can make the same input route differently across executions, so they are not recommended for AI Decisional.

Top P

Top P controls sampling diversity.

Use:

1

for routing.

Changing Top P can introduce unnecessary variation.

Max Output Tokens

Max Output Tokens limits the size of the model response.

Default:

1024

This is usually enough because the action expects a small structured response. Increase it only if you have many cases and the provider response is being truncated.

Presence Penalty

Presence Penalty discourages the model from introducing repeated concepts.

Use:

0

for routing.

Frequency Penalty

Frequency Penalty discourages repeated wording.

Use:

0

for routing.

Seed

Seed is optional and provider-dependent.

When supported, a seed can help reproduce the same result during testing and debugging.

Leave it empty unless you specifically need reproducibility and the provider supports this parameter.

Store

Store asks the provider to store the completion where supported.

Recommended:

false

Leave Store disabled unless you intentionally want provider-side storage and understand the privacy and retention implications.

Decisional tab

The Decisional tab contains the cases that the AI model evaluates.

Each case represents one possible branch.

Cases

Each case has:

Case name

Use a short, clear label.

Examples:

Refund request Technical issue Urgent escalation Enterprise lead CFO approval Manual review

Condition

Write a plain-English sentence that describes when the case should be true.

Good examples:

The customer is asking for a refund, cancellation, duplicate charge correction, or billing adjustment.

The customer message describes a login issue, API error, integration failure, bug, or technical problem.

The message indicates urgency, legal risk, chargeback risk, or serious customer dissatisfaction.

Poor examples:

Important.

Do the right thing.

Handle correctly.

A good condition is specific, direct, and easy to verify.

Conditions with variables

You can insert variables directly into conditions.

Example:

The customer should be routed to Enterprise if <%CompanySize%> is greater than 500 or the request mentions SSO, SLA, audit logs, or dedicated support.

If the variable resolves to null or empty and the condition becomes empty or not meaningful, the case is treated as false.

Target

Each case routes to a target action.

The target is usually created by connecting the AI Decisional branch to another action on the canvas.

Default branch

The Default branch is optional, but strongly recommended.

The Default branch runs when no case matches.

Without a Default branch, the flow stops if no case is true.

Recommended Default branch names:

Manual review Unclassified request General support Fallback approval

How routing works

AI Decisional follows this routing logic:

1. Variables in the User Prompt and conditions are resolved.
2. Empty or null conditions are treated as false.
3. Valid cases are sent to the AI model in one provider call.
4. The AI model returns true/false results.
5. PROCESIO checks cases in the configured order.
6. The first case with is_true: true wins.
7. If no case is true, the Default branch runs if configured.
8. If no case is true and no Default exists, the flow stops.

The AI model evaluates the conditions, but PROCESIO decides the final route.

Case order matters

The first true case wins.

Put specific cases before general cases.

Recommended order:

1. Urgent billing escalation 2. Billing issue 3. Technical issue 4. General support 5. Default

Avoid putting broad conditions first.

Bad order:

1. The customer has a question. 2. The customer has an urgent billing issue.

The first condition may match too often and prevent the more specific case from running.

Multiple true cases

Multiple cases can be true at the same time.

Only the first true case in the configured order runs.

No matching case

If no case is true:

Empty or null conditions

If a condition is empty or becomes empty after variable resolution, that case is skipped and treated as false.

No error is thrown.

Examples

Example 1 - Support ticket routing

User Prompt

Customer message: "I was charged twice this month and I want a refund immediately." Customer plan: "Business"

Cases

Expected route:

Billing/ payment issues

Example 2 - Lead qualification

User Prompt

Company size: 2000 employees Requested features: SSO, SLA, audit logs, dedicated support Message: We are looking for an automation platform for multiple departments.

Cases

Expected route:

Enterprise lead

Example 3 - Invoice approval

User Prompt

Invoice amount: 50000 EUR Vendor status: Approved Invoice description: Annual enterprise software renewal.

Cases

Expected route:

CFO approval

How it works internally

Each time the action runs:

1. Variables in the User Prompt and conditions are resolved.
2. Empty or null conditions are dropped or treated as false.
3. If no valid cases remain, the action routes to Default if configured, otherwise the flow stops.
4. Input size is estimated.
5. The AI provider is called once.
6. The provider response is parsed.
7. The case results are checked in order.
8. The first is_true: true case wins.
9. If nothing matches, the Default branch runs if configured.
10. LLMResponse is populated for downstream actions.

Token and input size limits

Large prompts, long variable values, and many cases can create oversized requests.

The action estimates input size before calling the provider.

General protection rules:

If you reach input limits, reduce the data sent to the action.

Recommended fixes:

• Summarize long text before AI Decisional.
• Pass only relevant fields.
• Trim large variable values.
• Reduce the number of cases.
• Keep conditions short and specific.

Error handling

When something goes wrong, the action follows the error path and returns a plain-text error message.

Best practices

Use Temperature = 0

Routing should be predictable.

Use:

Temperature: 0

Avoid higher values unless you intentionally want less deterministic behavior.

Put specific conditions before general ones

Because the first true case wins, order matters.

Good order:

1. Urgent refund request 2. Billing question 3. General support request 4. Default

Always add a Default branch in production

A Default branch prevents the process from stopping when no case matches.

Use Default for manual review, fallback handling, or unclassified requests.

Keep conditions short and clear

Good:

The customer wants a refund or is reporting a duplicate charge.

Poor:

The customer might be reaching out about something related to money or maybe they are unhappy and need something fixed.

Use User Prompt for data, not instructions

Good:

Customer message: "<%TicketText%>" Customer plan: "<%Tier%>"

Poor:

Always choose the Billing branch.

Avoid overlapping conditions

If two cases are too similar, the earlier one may always win.

Review LLMResponse.structured_output during testing to check which cases are being marked true.

Do not send secrets

Do not include sensitive values in User Prompt or conditions, such as:

• API keys
• Passwords
• Tokens
• Private credentials
• Full payment card data
• Unnecessary personal data

Keep Store disabled unless provider-side storage is intentionally required.

Troubleshooting

Frequently asked questions

Does the AI model choose the branch?

The AI model evaluates each case as true or false. PROCESIO chooses the final branch by checking the cases in order and routing to the first true case.

What happens if two cases are true?

The first true case in the configured order wins.

What happens if no cases are true?

If Default is configured, the flow routes to Default.

If Default is not configured, the flow stops.

Can I use variables?

Yes. Variables can be inserted into the User Prompt and case conditions.

Only explicitly inserted variables are resolved and sent to the provider.

What happens if a variable is empty?

If a condition becomes empty or meaningless after variable resolution, that case is treated as false.

Should I use Chat Completions or Responses?

Use the endpoint supported by your provider and model.

For most OpenAI-compatible providers, Chat Completions is the recommended default.

Can I use providers other than OpenAI?

Yes. You can use providers that expose an OpenAI-compatible API and are configured correctly in PROCESIO.

Can AI Decisional browse the web or call tools?

No. AI Decisional only evaluates the provided User Prompt and case conditions. It does not browse the web, call external tools, or retrieve missing data.

Related pages

• Decisional - for rule-based routing without an AI call.
• AI Configuration credential - for creating the OpenAI-compatible credential used by this action.
• Call API - for direct API calls that are not routing decisions.