Workflows
Route a domain to an agent, and choose between agents by page, country, sign-in state and more.
Workflows are configured in the Limio admin under AI → Workflows. A workflow decides which agent answers on a given domain, and it can choose between agents based on the page the visitor is on, where they are, whether they are signed in, and what they are.
An agent does not know where it runs. Publishing an agent does not put it on your site: until a workflow routes a domain to it, chat on that domain does not start. The chat window still opens, with default chrome and no greeting; the visitor is told chat is not configured when they send their first message.
The model
A workflow is a list of domains plus a flow. The flow is a small diagram that starts at the Domain node and ends at an agent. When a visitor opens the chat, Limio walks the diagram from the Domain node, following the branch each test resolves to, and the first agent it reaches answers.
The simplest useful flow is the Domain node connected straight to an agent: everyone on those domains gets that agent.
Domains
Enter the bare host, shop.example.com, not https://shop.example.com/pages. A scheme or path is trimmed for you. Include the port if there is one, as in localhost:8003.
The host has to be the one the chat request arrives on. For chat on your Limio shop that is your shop domain. The chat embed sends its requests to your chat API host rather than to the site the visitor is reading, so ask your Limio contact which host to enter.
One workflow can list several domains, and they all get the same flow. Do not list the same domain on two workflows: one of them wins, and which one is not defined.
Nodes
Domain
Where every visit begins. It lists the workflow's domains and has one outgoing connection.
Condition
One test, two branches: match and else.
Router
One test with several cases, for fanning out without stacking conditions. The first case that matches wins; the no-match branch catches the rest.
Agent
An endpoint. The walk stops here and this agent answers.
An agent node with nothing connected into it is the workflow's fallback. If the walk ends without reaching an agent, because a test sent the visitor down a branch you left empty, the fallback answers. Without one, chat does not start for that visitor.
Conditions
Page
The page the visitor is on. A value matches that path and anything below it: /checkout matches /checkout and /checkout/payment, but not /checkoutxyz. A trailing slash makes no difference.
Country
The visitor's country.
Authentication
Whether the visitor is signed in. Enter validJwtWithUserId to match signed-in visitors, noValidJwt for signed-out.
Subscription Status
Whether the visitor is an active subscriber. Enter activeSub to match active subscribers, noActiveSub for everyone else.
Segment
A segment the visitor belongs to.
Query String
Text anywhere in the page's query string, so you can route a campaign link.
Cookie Exists
Whether a named cookie is present.
Condition values are entered as a comma-separated list; the condition matches when any value does.
The editor also offers Region, City, Device, Subscription Offer Label, Subscription Billing Country and JSON Web Token. Limio does not evaluate these yet. A test on one never matches, so every visitor takes its else branch. The editor marks them, and they are listed here so you do not build a flow that routes everyone the same way without meaning to.
Page and Query String tests rely on the address of the page the visitor is reading. On your Limio shop that is always available. For the chat embed on another site, the browser sends Limio only the embedding page's origin, not its path — so a Page or Query String test never matches there, and every embed visitor takes its else branch.
Saving
Save publishes the workflow. There is no separate publish step, unlike an agent, where you publish a version. Build the flow before you point a production domain at it.
A change takes up to a minute to reach visitors.
An example
Sales questions on the pricing pages, support everywhere else, and a specialist for subscribers in checkout:
The Domain node into a Condition on Page, value
/checkout.Its match branch goes to a Condition on Subscription Status, value
activeSub. Match goes to your renewals agent, else to your sales agent.Its else branch goes to a Router on Page, with a case for
/pricingto your sales agent and the no-match branch to your support agent.
A visitor reading /checkout/payment with an active subscription gets the renewals agent, because /checkout matches anything below it.
When chat does not start
If visitors are told chat is not configured for the domain, one of these is true:
No published workflow lists that domain. Check the spelling, and that you entered a bare host with no
https://and no path.The walk reached no agent: a branch is empty and there is no fallback agent.
You saved less than a minute ago.
Last updated
Was this helpful?

