Velaro Workflows Guide
Velaro Workflows Guide
What is a workflow?
A workflow is an automated script that runs when a conversation starts (or on other triggers). It runs before any agent sees the conversation. It can send messages, ask questions, call APIs, route to teams, hand off to a bot, and more.
Use workflows to automate: routing by language or country, lead capture, support triage, appointment booking, FAQ answers, data lookup, and CRM updates.
---
Workflow triggers — when a workflow fires
| Trigger | When it fires | Common use |
|---|---|---|
| Conversation Opened | Fires once when a new conversation starts — first message from the visitor | Routing, greeting, bot handoff, data collection |
| Incoming Message | Fires on every message that arrives during an existing conversation | Keyword detection, mid-chat commands |
| Schedule | On a fixed timer (e.g. daily at 9am) | Batch jobs, proactive outreach |
| Webhook | An external system POSTs to the workflow URL | Shopify order events, form submissions |
| API Call | Another workflow calls this one as a sub-routine | Reusable shared logic |
Conversation Opened vs Incoming Message — which to use:
Use Conversation Opened for almost everything: routing, greetings, bot handoff, collecting visitor info before an agent responds. It fires exactly once per conversation so there is no risk of a workflow looping or re-triggering.
Use Incoming Message only when you need to react to what a visitor types mid-conversation — for example detecting the word "cancel" and running a cancellation flow, or detecting a keyword and firing a different bot. Be careful: this trigger fires on every single message, so your workflow needs a condition at the top that checks for the specific keyword or pattern before doing anything, otherwise it runs on every reply.
The two triggers do not conflict with each other. A Conversation Opened workflow runs once at the start. An Incoming Message workflow runs later, per message. They are separate workflows and do not loop back into each other unless you explicitly wire a jump between them.
---
Trigger node settings (New Conversation only)
When you click the trigger node on the canvas, a settings panel opens. These settings control which conversations this workflow applies to:
Channels — all channels are ON by default (the workflow fires for Web, SMS, WhatsApp, Facebook, Twitter/X, Email, RCS, IVR, Apple Messages). Click any channel pill to turn it off and exclude that channel. Only channels shown in blue (active) will trigger this workflow. If you exclude all channels the workflow never fires.
Routing Priority — when multiple workflows all match the same conversation, the one with the smallest number runs first (like a race — 1st place beats 10th place). Every workflow starts at 100. Only change it when you need one workflow to beat another:
- Set LOWER (e.g. 10) to make a workflow run before others
- Set HIGHER (e.g. 200) for a last-resort catch-all
- Leave at 100 if you only have one workflow per channel
After Workflow — controls what happens after the workflow finishes:
- Hand off to agent routing (default / OFF): agent assignment fires when the workflow completes. The recommended way to control which agent or team receives the conversation is to end your workflow with a Transfer To Agent or Transfer To Team node — that is the explicit, modern approach. If your workflow has no transfer node, the conversation falls through to your default team.
- Stay with bot — skip agent routing (ON): conversation stays with the bot, no human agent is ever assigned. Use this for fully automated flows (FAQ bots, booking bots) that never need a human.
- Note: if your workflow ends with a Transfer To AI or Transfer To Agent node, that always takes precedence over this toggle regardless of how it is set.
Conditions — optional filters. Leave blank to match every conversation on the selected channels. Add conditions to restrict which conversations trigger this workflow.
---
Trigger conditions — the full list
These are all the conditions you can use on the trigger node to control which conversations a workflow matches:
| Condition | What it checks | Example |
|---|---|---|
| Language | Visitor's browser language (auto-detected) | Language = French → matches fr, fr-CA, fr-BE |
| Country | Visitor's country from IP geolocation | Country = Canada |
| URL | Page the visitor was on when they started the chat | URL contains /pricing |
| Domain | The website domain | Domain = shop.example.com |
| Channel | Which channel the conversation came from | Channel = SMS |
| Day of week | Day when conversation started | Day = Saturday or Sunday |
| Time of day | Time when conversation started | Time is outside 9:00-17:00 |
| Deployment | Which chat widget deployment triggered it | Deployment = Support Widget |
| Contact attribute | Any saved contact property | plan = Enterprise |
| Team availability | Whether a specific team currently has available agents | Sales team = Busy |
| Team queue size | How many conversations are waiting in a team's queue | Sales queue > 3 |
| Return visitor | Whether the visitor has chatted before | Return visitor = true |
| Referrer | What site sent the visitor | Referrer contains google.com |
| UTM campaign | Marketing campaign parameter | UTM campaign = black-friday |
Multiple conditions in one workflow are AND by default (all must match). Use OR logic by adding condition groups.
---
The default setup — one workflow handles everything
For most sites, one workflow is all you need. It runs for every new conversation and uses Condition nodes internally to decide what to do.
Example — a single workflow that handles business hours, after-hours, and a prechat survey:
Trigger: New Conversation | Web | Priority 100 | (no conditions)
→ Condition: Team "Support" availability = Available?
YES → TransferToAgents: Support Team
NO → TransferToAI: After-Hours Bot
Or with a survey first:
Trigger: New Conversation | Web | Priority 100 | (no conditions)
→ Ask Question: "What do you need help with?" (options: Sales / Support / Billing)
→ Condition: answer = Sales → TransferToAgents: Sales Team
answer = Support → Condition: Support team available?
YES → TransferToAgents: Support Team
NO → TransferToAI: Support Bot
answer = Billing → TransferToAgents: Billing Team
No rules needed. All routing, survey questions, and availability checks live inside the one workflow.
---
Scoping a workflow to a specific chat button
Every widget you embed on a website has its own chat button with a unique ID. You can find these IDs in the admin under Deployments — each deployment is one chat button embed.
By default, a workflow fires for all of your chat buttons. To limit it to one button, expand "Scope to a specific chat button" in the trigger settings and check the button(s) you want.
When do you need this?
- You have multiple websites (e.g. support.yoursite.com and sales.yoursite.com) each with their own widget, and you want different routing or bot behavior per site
- You have multiple brands or white-label products from the same Velaro account, each with its own chat button
- You want a workflow that only fires for visitors from a specific landing page widget
Do you need a different deployment ID for each brand? Yes — each distinct chat button embed has its own deployment ID. Create a separate deployment under Deployments for each brand or site, then scope the workflow to that deployment's button.
Pattern for multiple sites or brands:
| Workflow | Chat Button | Priority | What it does |
|---|---|---|---|
| Site A Routing | Site A Widget | 10 | Routes Site A visitors |
| Site B Routing | Site B Widget | 10 | Routes Site B visitors |
| Default Catch-All | (all buttons) | 100 | Fallback for anything unmatched |
If you only have one website with one chat button, leave this setting empty — it has no effect and you do not need to configure it.
---
Availability-aware routing
Use a Condition node with "Team Availability" to route differently when agents are offline:
Condition: Team "Sales" = Available?
YES → TransferToAgents: Sales Team
NO → TransferToAI: Sales Bot (handles after-hours)
Combine with Team Queue Depth for overflow:
Condition: Team "Support" = Available?
YES → Condition: Support queue > 5?
YES → TransferToAI: Overflow Bot
NO → TransferToAgents: Support Team
NO → TransferToAI: After-Hours Bot
---
Prechat survey → routing
To collect information before routing, use Ask Question nodes. The answers become variables you can branch on:
Ask Question: "Are you an existing customer?" (Yes / No)
→ Condition: answer = Yes
YES → Ask Question: "Account number?"
→ TransferToAgents: Account Team
NO → TransferToAgents: Sales Team
Or use the prechat form (configured in Settings → Prechat Survey) and then match on survey answers in the trigger conditions of a downstream workflow.
---
Language routing — how to set it up
Language is detected automatically from the visitor's browser (navigator.language). You do not need to ask the visitor their language — it is already known when the chat starts. The Language condition uses family matching: setting "French" matches fr, fr-CA, fr-BE, fr-CH, and all other French locales automatically.
To route French visitors to a French team:
1. Create a workflow "French Routing" — Channels: Web, Priority: 10, Condition: Language = French
2. Add TransferToAgents → French Team
3. Activate
4. Create a workflow "General" — Channels: Web, Priority: 100, no conditions
5. Add TransferToAgents → General Team
6. Activate
French browser → French Routing (10) matches → French Team. Everyone else → French Routing conditions fail → General (100) runs → General Team.
To route multiple languages:
Create one workflow per language, all at priority 10. Each has one condition. Since a browser can only be one language, only one will match per visitor.
| Workflow | Priority | Condition | Team |
|---|---|---|---|
| French Routing | 10 | Language = French | French Team |
| Spanish Routing | 10 | Language = Spanish | Spanish Team |
| German Routing | 10 | Language = German | German Team |
| General | 100 | (none) | General Team |
To let visitors pick their language themselves (when browser language isn't reliable):
Use an Ask Question node instead of a trigger condition:
Trigger: New Conversation | Web | Priority 100 | no conditions
Ask Question: "Quelle langue? / Which language?" Options: Français / English
Condition: answer = Français → TransferToAgents → French Team
answer = English → TransferToAgents → English Team
---
Node types
| Node | What it does |
|---|---|
| Send Message | Sends text to the visitor. Use <<variableName>> to insert saved data. |
| Ask Question | Asks something and captures the reply into a named variable. |
| Condition | Branches on a variable value — like an if/else. |
| TransferToAgents | Routes to a specific team or agent. Workflow ends here. |
| TransferToAI | Hands off to an AI bot. AI takes over the conversation. |
| HTTP Request | Calls an external API. Save response fields as variables. |
| Set Data | Sets a variable silently — no question asked to visitor. |
| Time Delay | Waits N seconds before the next node. |
| Send Email | Sends a fixed-template email. |
| AI Compose Email | AI writes a personalized email from plain-language instructions. |
| CRM Push | Pushes conversation to HubSpot or Dynamics. |
| Close Conversation | Ends the conversation. |
| Call Workflow | Runs another workflow inline as a sub-routine, then returns. |
| ClassifyAndRoute | AI reads the conversation and picks which team to route to. |
| Dynamics 365 AI | AI handles the full Dynamics 365 conversation — looks up contacts, cases, leads, opportunities, and more. One node handles everything. |
| NetSuite AI | AI handles the full NetSuite conversation — orders, invoices, cases, customers, inventory. One node handles everything. |
| HubSpot AI | AI handles the full HubSpot CRM conversation — contacts, deals, tickets, tasks. One node handles everything. |
| Shopify AI | AI handles the full Shopify conversation — orders, products, customers, cart recovery. |
| BigCommerce AI | AI handles the full BigCommerce conversation — orders, products, accounts. |
| WooCommerce AI | AI handles the full WooCommerce conversation — orders, products, customers. |
---
Integration AI nodes — how they work
Integration AI nodes (Dynamics 365 AI, NetSuite AI, HubSpot AI, Shopify AI, etc.) are self-contained AI conversation nodes. A single integration AI node handles the entire conversation — you do NOT need to add Ask Question, Set Data, or Condition nodes before or after it.
What the AI node does internally:
- Greets the visitor and asks for the information it needs (email, order number, etc.)
- Calls the integration tools to look up or update records
- Handles multi-turn conversation naturally
- Responds based on what it finds
The standard 3-node workflow (all you need):
Trigger: New Conversation
→ Send Message: "Hi! How can I help you today?" ← optional greeting
→ Dynamics 365 AI (or NetSuite AI, HubSpot AI, etc.)
That's it. The wizard creates this for you automatically.
You do NOT need to add:
- Ask Question before the AI node to collect email — the AI asks for what it needs
- Set Data before the AI node — the AI collects data through conversation
- Condition nodes to branch on what the AI found — the AI handles branching through its prompt
When to add nodes AFTER the integration AI node:
- Transfer to Agents — if the AI can't resolve the issue and you want a human to take over
- Close Conversation — to explicitly end the chat after the AI finishes
- Send Email — to send a confirmation email after the AI completes the task
Using two techniques together: If you need both a general AI bot (for FAQs, greetings) AND a Dynamics specialist (for CRM lookups), set up two separate workflows or use a TransferToAI node (general bot) before the integration AI node. The general AI bot can decide when to hand off to the specialist. Ask a Velaro support agent if you need help with this pattern.
---
Variables in workflows
Variables let you personalize messages and make routing decisions based on data collected during the conversation.
<<firstName>>— contact's first name<<email>>— contact's email<<answer>>— whatever an Ask Question node captured (use the variable name you set)<<anyCustomField>>— any contact attribute by name
Variables from Ask Question nodes are available immediately in the next node. Variables saved with Set Data persist to the contact record.
---
Testing a workflow
1. Open the workflow in the editor
2. Click Test in the top toolbar
3. A chat panel slides in from the right — the workflow starts automatically
4. Interact as if you were the visitor — type replies, click quick-reply buttons
5. The workflow runs step by step
What you see in the test panel:
- Normal messages appear as chat bubbles — these are real
- Amber
[Test]lines are the simulator reporting what would happen in a real conversation:
- [Test] Would transfer to team #42. — this means a TransferToAgents node ran. The team number shown is where the real conversation would go. No actual transfer happens.
- [Test] Would send email to alex@example.com. — email node ran, no real email sent
- [Test] Would push conversation to CRM. — CRM node ran, nothing actually pushed
- [Test] Would wait 5m. — time delay node ran, did not actually wait
- "Workflow completed." means the workflow finished
The test panel tells you: do my messages read correctly, does my condition branch the right way, does Ask Question save to the right variable, which team would this conversation route to.
The test panel does NOT tell you: whether that team has agents available, whether queue mode works, whether Bot-Only Mode OFF fires agent routing correctly. For that, run a real conversation on staging and check Rules → Routing History.
Click ↺ Restart to run the test again from the beginning. Click "Not working as expected? Ask Copilot for help" to get Moshky's analysis of your test session.
---
Surveys — how they work (separate from workflows)
Pre-chat, post-chat, and unavailability surveys are controlled by rules, not by workflows. They run on a separate system.
Pre-chat survey — shown to the visitor BEFORE the workflow runs. The visitor fills it out, then routing and the workflow happen. Survey answers are available as workflow conditions (e.g. "survey answer equals Sales" → route to Sales team). Configure under Settings → Routing Rules → Pre-Chat Survey.
Post-chat survey — shown after the conversation ends. Nothing to do with routing workflows. Configure under Settings → Routing Rules → Post-Chat Survey.
Unavailability survey — shown when no agents are available instead of a "nobody available" error. Configure under Settings → Routing Rules → Unavailability Survey.
---
Auto-resolve — how it works (separate from workflows)
Auto-resolve rules fire on a background timer every minute. They are completely separate from conversation routing workflows. A conversation can:
1. Be handled by a workflow when it starts
2. Route to a team, agent and visitor chat
3. Go quiet for 30 minutes
4. Auto-resolve rule fires → marked Resolved
The auto-resolve rule has nothing to do with the routing workflow that ran at conversation start. Configure under Settings → Routing Rules → Auto-Resolve.
---
Common workflow patterns
Route by language (browser-detected)
Workflow "French" | Priority 10 | Condition: Language = French
TransferToAgents → French Team
Workflow "General" | Priority 100 | No conditions
TransferToAgents → General Team
Route by country
Workflow "Canada" | Priority 10 | Condition: Country = Canada
TransferToAgents → Canada Team
After-hours bot
Workflow "After Hours" | Priority 50 | Bot-Only ON | Conditions: Time outside 9am-5pm, Day Mon-Fri
Send Message: "We're closed. Leave your email and we'll reply tomorrow."
Ask Question: "Your email?" → save as <<email>>
Close Conversation
Pre-chat survey routing
[Pre-chat survey rule shows form with: Sales / Support / Billing]
Workflow "Survey Routing" | Priority 10 | Bot-Only OFF
Condition: survey answer = "Sales" → TransferToAgents → Sales Team
Condition: survey answer = "Support" → TransferToAgents → Support Team
Condition: survey answer = "Billing" → TransferToAgents → Billing Team
Collect info then hand to agent
Workflow | Bot-Only OFF
Send Message: "Hi! Let me get some info first."
Ask Question: "Your name?" → save as <<name>>
Ask Question: "Account number?" → save as <<accountNumber>>
[Workflow ends — Bot-Only OFF fires agent routing automatically]
[Agent sees conversation with <<name>> and <<accountNumber>> already filled in]
VIP fast-track
Workflow "VIP" | Priority 10 | Condition: contact.plan = "Enterprise"
Send Message: "Welcome! Connecting you to your dedicated team now."
TransferToAgents → VIP Team
---
Routing decisions and diagnostics
Every routing decision is logged. To see why a conversation went where it went:
- Rules → Routing History — every routing event logged with outcome, team, and reason
- Failed only filter — conversations where nothing matched (fell to default team)
- ↺ Retrigger button — re-evaluates today's rules against a past conversation's data (read-only, safe to use anytime). Use this to verify a fix works before the next real conversation.
- Ask Moshky — "why did conversation 99999 route to team X?" and Moshky will pull the log and explain
---
Bot-Only Mode
ON — workflow runs, conversation stays with bot. No agent assigned. Use for: full FAQ bots, after-hours capture, forms with no human follow-up needed.
OFF — workflow runs, then agent routing fires automatically when it finishes. Use for: greeting or data collection before handing to a human.
Exception: if a TransferToAgents node runs inside the workflow, that takes over — Bot-Only Mode is ignored.
---
Call Workflow (Sub-Workflows)
The Call Workflow node runs another workflow inline, then returns and continues. Use it to share common steps (collect contact info, check business hours, send confirmation email) across multiple workflows without duplicating nodes.
Limitations: Ask Question, Time Delay, and Request Payment nodes inside a called workflow are skipped — they cannot pause mid-execution in sub-workflow mode.
---
Organizing workflows
Categories — assign Lead Capture, Support, Sales, Onboarding, or Custom to any workflow. Filter by category in the workflow list.
Deprecated — when replacing an old workflow, mark it Deprecated instead of deleting it. It shows a gray badge and can link to its replacement. Hidden from the list by default. Use Mark as Deprecated (circle-slash icon) in the workflow action bar.
---
Route to Team node — availability-aware routing
The Route to Team node routes a conversation to a specific team and optionally branches based on whether agents are available right now. It makes availability decisions visible on the canvas instead of buried in team settings.
What it does: When a visitor starts a chat, this node checks the target team's availability and connects the conversation — or takes a different path if nobody is online.
The three availability branches — enable "Check availability" on the node to expose them:
| Branch | When it fires |
|---|---|
| Available | Agents are online and accepting chats. Visitor connects to the team queue. |
| Unavailable | Team is within business hours but no agents are currently online. |
| After Hours | Current time is outside the team's configured business hours schedule. |
With "Check availability" off, the node has one output and routes to the team regardless of state.
How to set one up:
1. Open a workflow in the canvas editor
2. Drag a Route to Team node from the node panel onto the canvas
3. Click the node → select the team from the dropdown
4. Toggle Check availability on if you want the three-branch behavior
5. Connect the Unavailable and After Hours branches to whatever should happen instead (a bot, a message, a different team, or close)
6. Save and activate
The prechat survey option — the node has an optional Pre-chat survey field. When set, the survey appears to the visitor after the routing decision is made but before they connect to the agent. This means: the system already knows which team the visitor is going to before asking the survey questions. The survey is for enriching the conversation (collecting name, account number, issue type), not for deciding where to route. The same survey can be reused across multiple Route to Team nodes — you don't need a separate survey per team.
Priority numbers — when you have multiple workflows that could all match the same conversation, the Routing Priority number on the trigger node controls which one runs. Lower number = higher priority (10 runs before 100). Set lower numbers on specialized workflows (VIP, language-specific) and higher numbers on general catch-all workflows. Leave at 100 if you only have one workflow.
When to use trigger conditions vs. building multiple workflows:
Use conditions on the trigger node when you want the workflow to only fire for certain visitors — for example, only French-speaking visitors, only Enterprise plan customers, only visitors on /pricing. The workflow is skipped entirely for visitors who don't match.
Use a single workflow with Condition nodes inside when all visitors should go through the same flow but branch differently based on their data — for example, everyone gets asked a question, then the answer determines which team they go to.
Both approaches work. Trigger conditions keep the workflow list organized when you have many distinct audiences. Internal Condition nodes keep the logic in one place when routing depends on collected answers.
---
Example: Language routing with availability
Workflow "French" | Priority 10 | Condition: Language = French
Route to Team: French Support (checkAvailability: on)
Available → French Support queue
Unavailable → TransferToAI: French Bot
After Hours → TransferToAI: French Bot
Workflow "General" | Priority 100 | (no conditions)
Route to Team: Support Team (checkAvailability: on)
Available → Support queue
Unavailable → TransferToAI: Support Bot
After Hours → TransferToAI: Support Bot
Example: URL routing (product pages get Sales)
Workflow "Product Pages" | Priority 20 | Condition: URL contains /products/
Route to Team: Sales Team (checkAvailability: on)
Available → Pre-chat survey: ProductInquiry → Sales queue
Unavailable → Send Message: "Sales is busy. Leave your info."
After Hours → TransferToAI: Sales Bot
Example: Time-based shift routing
Workflow "Day Shift" | Priority 10 | Condition: Time 08:00–17:00, Mon–Fri
Route to Team: Day Shift Team (checkAvailability: on)
Available → Day Shift queue
Unavailable → Route to Team: Night Shift Team (checkAvailability: off)
After Hours → [not reached — time condition already limits this]
Workflow "Night Shift" | Priority 20 | Condition: Time 17:00–24:00, Mon–Fri
Route to Team: Night Shift Team (checkAvailability: on) ...
Workflow "Weekend" | Priority 50 | Condition: Day = Sat or Sun
TransferToAI: Weekend Bot
Example: VIP routing
Workflow "Enterprise" | Priority 10 | Condition: contact.plan = Enterprise
Route to Team: Enterprise Success (checkAvailability: on)
Available → Pre-chat survey: VIPForm → Enterprise Success queue
Unavailable → Send Message: "Your team is engaged — estimated 5 min wait."
→ Route to Team: Enterprise Success (checkAvailability: off)
After Hours → Send Message: "Your CSM will respond within 2 hours."
→ Close Conversation
---
Apple Messages — how it works with workflows
Apple Messages for Business is just another channel. A customer sending you an iMessage starts a conversation in Velaro the same way a web chat or SMS does. No special trigger is needed.
What fires the workflow: Use Conversation Opened as your trigger. If you want this workflow to only fire for Apple Messages conversations, click all the other channel pills off in the trigger settings so only Apple Messages stays active (blue). If you leave all channels on, the workflow fires for every channel including Apple Messages — that is fine for most bots.
Do you need an Apple Messages node? No, not for AI responses. If your workflow hands off to an AI that uses skills (NetSuite, Dynamics, Shopify, etc.), the AI response is automatically formatted for the channel it is on — Apple Messages gets a clean readable response without any special node. You do not add an Apple Messages node just to make the AI work on that channel.
When you do use an Apple Messages node: Only when you want to send an Apple-native interactive UI element that does not exist on other channels:
| Apple control | How a workflow sends it |
|---|---|
| Multiple choice / quick reply | A plain Ask Question node — on Apple this renders as a tappable list automatically. No special node. |
| Time picker (tap to pick a date/time slot) | AI skill apple_send_time_picker via a TransferToAI node. |
| Rich link card (image + title, tappable) | AI skill apple_send_rich_link via a TransferToAI node. |
| Apple Pay sheet | AI skill apple_send_apple_pay via a TransferToAI node. |
| Auth request / form | AI skills apple_send_auth / apple_send_form via a TransferToAI node. |
So: three choices on an Ask Question node = three options in one node, not three separate Apple Messages nodes. The Apple Messages-specific skills are called by the AI inside a TransferToAI node — you do not wire them separately in the canvas.
Example — Apple Messages AI bot using Dynamics:
Trigger: Conversation Opened [Apple Messages only]
→ TransferToAI: Support Bot (has Dynamics 365 skills enabled)
That is the whole workflow. The AI answers using Dynamics data. Apple Messages gets a properly formatted response automatically. No Apple-specific node anywhere.
Example — Apple Messages with interactive choices:
Trigger: Conversation Opened [Apple Messages only]
→ Ask Question: "What do you need help with?"
"Order status" / "Book appointment" / "Talk to someone"
→ Order status → TransferToAI (Shopify/NetSuite skills)
→ Book appointment → TransferToAI (apple_send_time_picker skill)
→ Talk to someone → Transfer to Agent
Three branches come from one Ask Question node — not three Apple Messages nodes.
Smart topic switching (mid-conversation jumps)
If you want your bot to recognize when a visitor changes topics mid-flow and jump to the matching workflow section instead of staying stuck on the current question, turn on Smart topic switching in Account → AI Settings. It applies site-wide to all workflows.
See the Smart Topic Switching guide for what it does, when to use it, and how to read the activity-log trace.
---
Canvas editor — visual indicators and warnings
Trigger priority badges
Every trigger node on the canvas shows a #N pill in its top-right corner — for example #10 or #100. This is the Routing Priority number and tells you at a glance how workflows will compete if multiple ones match the same conversation. Lower number = fires first. Triggers in "always-on" mode (no conditions, fires for every conversation on the selected channels) show an amber "always" pill instead of a number.
Unreachable node warning (yellow popover)
If you add nodes to the canvas but don't connect them into the main flow, the editor marks them with a yellow warning popover: "Unreachable node — not connected to any flow." An unreachable node will never run because there is no path from the trigger node that leads to it.
Exception: nodes that are Smart Topic Switching targets are intentionally disconnected. When a node has an Intent Label set (in the node settings panel), it becomes a named jump target for the AI — the bot can jump to it mid-conversation when the visitor's intent matches. These nodes are valid without a canvas connection and do not show the warning.
To fix an unreachable node: connect it to another node on the canvas, or set an Intent Label to make it a Smart Topic target, or delete it if it is not needed.
Isolated action node banner (blue info banner)
When you drop a new action node onto the canvas and leave it disconnected for more than 1.5 seconds, a blue info banner appears at the bottom of the canvas: "This node can only be reached via intent matching." This is a hint, not an error. Either connect the node to the flow, or set an Intent Label on it if you intend it to be a Smart Topic target.
JumpTo node — preview card and Go to node button
The JumpTo node lets a workflow jump execution to a named node elsewhere on the canvas. When you click a JumpTo node, the editor shows:
- A dropdown listing every available target as "Node Name [type]" — for example "Booking Confirmation [Send Message]" or "Escalate to Agent [TransferToAgents]"
- A preview card below the dropdown showing the target node's details (its type, label, and key settings) so you can confirm you have the right one before saving
- A Go to node → button that scrolls the canvas and centers the view on the target node
- For Smart Topic targets, an amber label shows the Intent Label text that the AI uses to recognize when to jump there
Branch edge colors (multiple choice nodes)
When a node has many output branches (for example a Condition or multiple-choice node), each branch edge is drawn in a distinct color so you can trace paths across a complex canvas. For nodes with more than 6 branches the colors are generated dynamically across a full color arc. For nodes with 20 or more branches the edges fan out in curved bezier arcs rather than stacking on top of each other.
---
Routing priority — what the #N number means
Every New Conversation trigger node has a Routing Priority number. When a new conversation arrives and multiple workflows all have conditions that match, only one workflow runs — the one with the lowest priority number.
#10beats#100— lower = higher priority- Default is 100. Only change it when you need one workflow to always win over others.
- Ties (two workflows with the same number) are broken by workflow age — the older workflow wins.
The priority badge on the canvas node is the same number. You do not need to open the trigger settings to see it — it is always visible.
Only one trigger per workflow. Each workflow has exactly one trigger node. You cannot add a second trigger node — the editor will show a toast warning and block the action if you try.
---
Workflow capacity by plan
A conversation is any customer interaction — a web chat, an SMS thread, a WhatsApp message, a phone call, or an Apple Messages session. Each conversation is one unit regardless of how many messages it contains.
| Capacity | Starter | Professional | Enterprise |
|---|---|---|---|
| Workflow triggers / month | 1,000 | 10,000 | 50,000 |
| Workflow runs / month | 1,000 | 10,000 | 100,000 |
| Concurrent workflow runs | 3 | 10 | 50 |
| Concurrent event-wait steps (external webhooks/integrations) | 10 | 25 | 50 |
Concurrent event-wait steps applies only to the advanced "Wait for Event" node, which pauses a workflow until a specific external event fires — for example, waiting for a payment webhook from Stripe, or waiting for a system integration to complete. This is not the same as a bot asking a customer a question.
Ask Question nodes have no concurrent limit. When a bot pauses to wait for a customer reply, that uses a different mechanism with no cap — hundreds of conversations can be mid-question simultaneously without hitting any limit.
Resolved conversations are always visible to agents in their conversation history.
Conversation auto-close: Each team has a Bot Auto-Close Time setting (Settings → Teams → Routing). When a bot-only conversation is inactive for that many minutes, Velaro automatically resolves it. New teams default to 30 minutes. You can set any value from 1 to 1,440 minutes (24 hours). To disable auto-close for a team, clear the field — the conversation will then follow the team's standard idle-close rule instead.
Bot auto-close only fires when: (a) the conversation has never had a human agent respond, and (b) no visitor message has arrived within the configured window. It does not interrupt conversations that are actively in progress.
Resolved conversations remain visible to agents and visitors in their history.
---
Channel-aware AI skill responses
When a workflow uses a Transfer to AI node with a commerce integration (Shopify, BigCommerce, WooCommerce, Magento), the AI's responses to order lookups and product searches automatically adapt to the channel — you do not need to configure this.
| Channel | How order/product results appear |
|---|---|
| Web chat | Full markdown — order details with items, tracking link, product URLs |
| SMS | Compact plain text under 160 characters — tracking URL included if available |
| IVR (voice) | Spoken sentence only — no URLs, no markdown, safe for text-to-speech. E.g. "Your order 1001 has shipped with UPS. Your tracking number is 1Z999AA00X." |
This happens automatically for:
- Order status lookups (all 4 platforms)
- Product searches (all 4 platforms)
- Return confirmations (Shopify)
If you are building an IVR workflow that asks customers about their order, the AI will naturally speak a clean confirmation sentence rather than reading out a JSON blob or markdown.
Was this article helpful?