How can we help you?

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?