Automation and flows, documented against the product as it works today.
This guide documents the current automation and flow implementation: supported setup, AI chat usage, variables, saved results, {{variable_name}} usage, and returned-value mapping.
What an automation action means in the current product
An automation action is one reusable tenant-owned HTTP action. It can then be used in AI chat, in flows, or both when the right availability settings are on.
What it contains
- Name and Action ID
- HTTP method
- Full endpoint URL
- Authentication details
- Customer details to collect
- Policy controls like approval and sensitivity
Current method support
The current UI supports GET, POST, PUT, and PATCH. DELETE is not exposed in the automation UI or direct flow API-call UI.
Create an automation from scratch
Choose a use case
Start with a common use case like Track Order or Check Account Status, or choose Custom Action if the tenant API does something different.
Enter the action details
Give the action a clear name, review the generated Action ID, and optionally set a description and timeout.
Set the connection
Choose the method, add the full endpoint URL, and choose how the API should authenticate.
Choose what Luran should ask for
Add customer-facing details like Order number or Customer email. For GET actions, these are sent in the URL path or query string. For POST, PUT, and PATCH actions, they are sent in the body.
Review and save
Review the generated request shape, then decide whether the action should be available in AI chat or in flows after testing.
How AI chat uses automation
What must be true
- The action must be active.
- Available in AI Chat must be turned on.
- The tenant action must be configured correctly.
- If the action needs a lookup step, the lookup dependency must exist.
What the system does today
- Identifies a likely action from the conversation.
- Asks for missing customer details.
- Runs an optional lookup action first when configured.
- Runs the target action and turns the result into a customer-facing reply.
Approval still applies
If the action requires approval, AI chat will not complete it directly. It will move into the approval-aware path instead.
How flow creation works from start to finish
Create the flow shell
Create the flow, choose its name, description, and trigger. It stays draft until activated.
Choose the first step
Most flows start with a Message step or a Collect Input step.
Add the rest of the journey
Use Message, Question, Collect Input, Knowledge Lookup, AI Reply, Automation Action, Direct API Call, Condition, Escalate, and End Conversation steps as needed.
Save values intentionally
Where later steps need a result, give it a clear save name instead of leaving generic defaults.
Route the next steps
Every step needs a next path, and automation steps can also branch by success, failure, timeout, or approval-required outcomes.
How an automation action works inside a flow
Store result as
This stores the full action result under a name you choose, such as order_lookup_result. Later steps can reuse the complete result if they need it.
Send flow data into this action
This tells Luran which saved flow value should be sent into the automation. You usually need it only when the flow saved the value under one name, but the automation expects a different name.
Save returned values for later steps
This saves specific parts of the action response under simple names like final_order_status so later steps can show or evaluate them.
Where variables come from and how they are used
Variables are created by steps
- Collect Input can save a typed value like
tax_id. - Question can save a selected answer like
issue_type. - Automation Action can save the full result and separate returned values.
- Knowledge Lookup, AI Reply, and Direct API Call can also save results.
Variables should be named clearly
- Good examples:
customer_order_number,final_order_status,tax_id,account_status. - These names are chosen by the tenant and later become the values reused across the flow.
What the returned-value choices mean
Success result
Saves whether the action succeeded or failed.
Returned status
Saves a common status field such as processing, active, or suspended.
Returned ETA date
Saves a common eta_date field from the action response.
Returned order ID
Saves a common order_id field returned by the action.
Returned account ID
Saves a common account_id field returned by the action.
Returned error detail
Saves a common response.detail value when an API returns an error.
Important note
These choices are convenience presets, not limits on what a tenant API can return. If the API returns something different, use the custom path option.
How {{variable_name}} works in customer-facing messages
The current backend flow engine supports double-curly-brace interpolation such as {{final_order_status}}. If the variable exists in the flow’s collected data, Luran replaces the placeholder before the customer sees the message.
Best practice
Most teams should save a simple value name first, then use that simpler name in the final message instead of reaching directly into a large nested result.
What custom returned-value paths support today
Supported
Luran currently accepts plain dot paths and the same paths with a leading $..
Not supported
- Array indexes like
items[0].status - Wildcard JSONPath expressions
- Advanced filters from full JSONPath libraries
Track order in a flow
- Collect Input asks for the order number and saves it as
customer_order_number. - Automation Action runs Track Order Status.
- Input mapping sends
customer_order_numberintoorder_reference. - Output mapping saves Returned status as
final_order_statusand Returned ETA date asfinal_eta_date. - End Conversation shows:
Your order is {{final_order_status}} and the ETA is {{final_eta_date}}.