AI Decisional

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 good fit not a good fit is the customer asking for a refund? age > 18 does this message sound urgent? country = "ro" is this a complaint or a question? status = "active" classifying free text tickets or messages exact string, number, date, or boolean matches routing based on sentiment, intent, or document meaning simple deterministic comparisons 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? area decisional ai decisional how you write conditions rule builder plain english how it evaluates locally one ai provider call per run cost no ai call one ai call per run supports variables yes yes first match wins yes yes default branch optional optional output data none llmresponse 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 provider example model names openai gpt 4o mini, gpt 4o, o3 mini anthropic through an openai compatible gateway check the gateway model catalog together, fireworks, deepinfra, openrouter, other gateways check the provider model catalog 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 endpoint when to use chat completions recommended for most openai compatible providers responses use only if your selected provider and model support it 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 field description llmresponse structured output parsed structured result used for routing llmresponse raw provider response full unmodified provider response, useful for debugging 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 parameter recommended value accepted range / notes temperature 0 range 0 2 top p 1 range 0 1 max output tokens 1024 range 1 8192 presence penalty 0 range 2 2 frequency penalty 0 range 2 2 seed empty optional integer, provider dependent store off / false recommended off 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 field description name short label for the branch condition plain english condition that describes when this branch should be selected target the connected successor action for this branch 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 variables in the user prompt and conditions are resolved empty or null conditions are treated as false valid cases are sent to the ai model in one provider call the ai model returns true/false results procesio checks cases in the configured order the first case with is true true wins if no case is true, the default branch runs if configured 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 default configured? result yes flow routes to default no flow stops 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 case name condition expected billing/ payment issues the customer message is about billing, payment, invoice, duplicate charge, refund, or chargeback, and the tone indicates urgency or escalation true technical support the customer message is about a login issue, integration error, system failure, api problem, or technical defect false general support the customer message is a general question or support request that is not clearly billing related or technical false 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 case name condition expected enterprise lead the lead should be treated as enterprise if the company has more than 500 employees or asks for enterprise features such as sso, sla, audit logs, security controls, or dedicated support true small business lead the lead should be treated as small business if the company has fewer than 100 employees and does not ask for enterprise features false not qualified the lead is not qualified if the request is for personal use, student use, free usage only, or unrelated to business automation false expected route enterprise lead example 3 invoice approval user prompt invoice amount 50000 eur vendor status approved invoice description annual enterprise software renewal cases case name condition expected cfo approval the invoice requires cfo approval if the amount is greater than 10000 eur true manager approval the invoice requires manager approval if the amount is between 1000 eur and 10000 eur false auto approve the invoice can be automatically approved if the amount is less than 1000 eur and the vendor is approved false expected route cfo approval how it works internally each time the action runs variables in the user prompt and conditions are resolved empty or null conditions are dropped or treated as false if no valid cases remain, the action routes to default if configured, otherwise the flow stops input size is estimated the ai provider is called once the provider response is parsed the case results are checked in order the first is true true case wins if nothing matches, the default branch runs if configured 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 limit type behavior global safety cap if the estimated input is too large, the action fails before calling the provider credential context window if configured, the action checks that estimated input plus max output fits inside the provider context window provider context rejection if the provider still rejects the request, the provider error is returned 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 problem expected behavior invalid api key provider authentication error is returned invalid model name provider model error is returned wrong provider url connection or provider error is returned provider timeout timeout error is returned provider rate limit provider rate limit message is returned unsupported endpoint provider or configuration error is returned invalid advanced parameter validation error is returned input too large input size error is returned provider returns invalid json parsing error is returned provider returns is true as text instead of boolean invalid response error is returned 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 symptom what to check the wrong case wins check case order a broader case may be placed before a specific one the same case wins every time conditions may overlap make earlier cases more specific all cases are false check user prompt data, variable resolution, and condition clarity flow stops unexpectedly add a default branch credential is not available in the picker check that the ai configuration is compatible with ai decisional model is required fill in the model field provider returns 401 or 403 check api key and provider permissions provider returns 429 provider rate limit was reached retry later or adjust provider plan input too large shorten the user prompt, trim variables, or reduce cases routing feels inconsistent use temperature 0; avoid vague or overlapping conditions response cannot be parsed check that the provider/model supports the selected endpoint and structured output behavior 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