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 |
|---|---|---|
| New Conversation | The moment a visitor starts a chat, sends a first SMS, makes a call | Routing, greeting, data collection before an agent |
| Incoming Message | Every time a message arrives in an existing conversation | Keyword detection mid-chat |
| 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 |
For routing conversations — routing to teams, language routing, country routing, survey-based routing — always use New Conversation.
---
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 — which channels this workflow fires on. Select all that apply: Web, SMS, WhatsApp, Facebook, Twitter/X, Email, RCS, IVR. A workflow with nothing selected never triggers.
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. |
---
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.
Was this article helpful?