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

1. Create a workflow "General" — Channels: Web, Priority: 100, no conditions
2. Add TransferToAgents → General Team
3. 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. Any JSON response comes back as workflow variables automatically.
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.
Select Chat Window	Serves a specific chat window design to the visitor when this workflow matches on page load, overriding your account's default chat window for that visitor.
Hide Widget	Suppresses the widget entirely for visitors matching this workflow — nothing renders, not even the launcher bubble.

---

Widget loads on page — hiding the widget vs picking its design (two separate decisions)

Widget loads on page is NOT the trigger most people build routing on. It is a narrow, early trigger that fires the instant the page loads — before the chat button even renders, and (for a brand-new visitor) before any contact record exists. It only ever affects pre-conversation, page-level decisions: hide/show the widget and which chat window design to display. Team assignment, agent availability handoff, AI transfer, surveys, data collection — all of that lives on the Conversation Opened trigger instead, which fires once the visitor actually starts chatting. If you're building "route this group of visitors to this team" logic, you want a Conversation Opened workflow (or a Routing Rule), not a Widget loads on page workflow. See "Workflow triggers" above for the full trigger list.

Hide Widget and Select Chat Window are independent nodes — you don't need both. "Whether to show the widget at all" and "which design to show if it IS shown" are two separate questions, each with its own node:

• Just want to hide the widget when nobody's available, sitewide, no exceptions? You don't need a workflow at all. There's a built-in toggle: Chat Window → Appearance → Offline Status → "Hide launcher when unavailable." Turn it on and the launcher hides itself whenever no agents are available — zero workflow setup.
• Want something more conditional — hide only for a specific team's availability, only on certain pages, or only for certain visitor segments? Then build a Widget loads on page workflow: add a Team Availability condition (or URL/deployment/etc.) on the trigger node, and end the matching branch with a Hide Widget node. No Select Chat Window node needed anywhere in this flow — Hide Widget stands alone.
• Want to change which design shows (but never hide it)? Use Select Chat Window as covered below — Hide Widget is irrelevant here.
• Want both — e.g. hide entirely after hours, but show a different design for VIP visitors during business hours? One workflow can branch: a Condition node checking Team Availability leads one branch to Hide Widget, and the other branch continues on to a Select Chat Window node. They compose, but neither requires the other.

The full chat-window resolution order (4 tiers)

Velaro checks these in order, every time the widget loads, and uses the first one that resolves to a real, non-deleted chat window on your site:

1. Workflow override — Select Chat Window node (a canvas node on a Widget loads on page workflow). Explicit, per-page/per-visitor, evaluated fresh on every page load using only page-level signals (URL, referrer, deployment, day/time, UTM, channel, country/language) plus live team-availability/queue-size checks — no contact record needed.
2. Chat Experience Bundle. Every account has exactly one Default bundle (this is what "the Chat Embed default chat window" really is under the hood) plus, optionally, other named bundles (e.g. "VIP", "Support"). If a Determine Experience Bundle rule matches a visitor, that bundle's chat window is used instead of Default. This is the tier built for segment/group-based selection — because it can key off saved contact attributes, tags, and other identity-based data that isn't available yet at raw page-load time for a first-time visitor.
3. Legacy "Determine Chat Window" rule (Settings → Routing Rules). Only ever reached on older accounts that have no Experience Bundles configured at all — modern accounts always have a Default bundle, so this tier is effectively legacy-only.
4. Hard-coded blank default. A last-resort safety net that should never actually trigger in practice, since every account is guaranteed a Default bundle.

Where each piece lives:

• Select Chat Window = a node on the Workflow canvas, only usable on a Widget loads on page trigger.
• Determine Experience Bundle / Determine Chat Window = Rule triggers under Settings → Routing Rules — dropdown options when creating a rule, not canvas nodes (Rules have no node editor).

Thorough example — combining a segment override with a page-specific override

Say you want two things at once:

• Enterprise customers (identified from a saved contact attribute) should always see your "VIP" chat window, with a dedicated persona and Sales team — everywhere on your site.
• Everyone, VIP or not, who lands on /black-friday should see a promo chat window for that campaign, no exceptions.

Step 1 — group/segment override (tier 2, Experience Bundle):

1. Go to Chat Experience → Bundles, create a new bundle named "VIP", and set its chat window to your VIP design (plus whichever persona/team/AI config you want bundled with it).
2. Go to Settings → Routing Rules, create a rule with trigger Determine Experience Bundle.
3. Condition: Contact attribute accountTier equals Enterprise.
4. Result of the rule: bundle = "VIP".
5. Save and activate.

Now every Enterprise contact who has previously been identified (returning visitor, logged-in, or identify() called) sees the VIP chat window sitewide — no workflow needed for this part.

Step 2 — page-specific override (tier 1, workflow, wins over everything else):

1. Create a workflow, trigger = Widget loads on page.
2. Trigger condition: URL contains /black-friday.
3. Drag a Select Chat Window node onto the canvas, pick the promo design.
4. Save and activate.

What actually happens for different visitors:

Visitor	Page	Result	Why
Enterprise contact	/pricing	VIP chat window	Tier 1 workflow doesn't match (wrong URL) → falls to tier 2 → Determine Experience Bundle rule matches accountTier = Enterprise → VIP bundle
Enterprise contact	/black-friday	Promo chat window	Tier 1 workflow's URL condition matches → wins outright, tier 2/3/4 never evaluated
First-time anonymous visitor	/pricing	Account default	Tier 1 doesn't match. Tier 2: no determine-experience-bundle rule matches (no contact attribute to check yet) → falls to the site's Default bundle
First-time anonymous visitor	/black-friday	Promo chat window	Tier 1 workflow's URL condition doesn't require an identified contact — it matches purely on URL

If you just want a workflow to use the account default: don't add a Select Chat Window node to it — there is nothing to configure or turn off. No node reached, no tier-1 override, resolution falls straight through to tier 2/whatever your Experience Bundle setup resolves to (Default bundle if you haven't built segment-specific bundles).

---

HTTP Request node — calling your own API

The HTTP Request node calls any endpoint you control (or a public third-party API) and pulls data straight back into workflow variables. You do not need to shape your response in any special way.

Point the node at your endpoint and whatever JSON it returns is read automatically:

• A flat JSON object — each top-level field becomes a variable with a matching name (e.g. {"orderStatus": "shipped"} gives you <<orderStatus>> with no extra setup).
• Nested objects or arrays are captured too — they come back as raw JSON you can pass to a message, an AI node, or another HTTP Request node.
• Velaro's structured response format (a list of named fields, each with its own value) is still supported and takes priority if you want finer control over saving a field to the contact vs. the conversation vs. just the workflow run.

Connect your existing API as-is — there is no pre-approved response contract to build toward.

Typical setup: add an HTTP Request node, set method/URL/headers/body (<<variableName>> inserts earlier data), turn on Wait for response, then reference any returned field as a variable in later nodes (e.g. <<orderStatus>>). Enable the error branch to route to a fallback like Transfer to Agent if the call fails.

---

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 <a href="/article/smart-topic-switching-guide">Smart Topic Switching guide</a> 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.

• #10 beats #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.