Automation rules

Written by Aashiq, Founder, AskVault · Reviewed by Aashiq

Last updated: May 15, 2026 · 4 min read

TL;DR

Automation rules trigger actions when conversations match conditions. 6 trigger types, 12 conditions, 10 actions. Up to 25 rules per workspace on Growth, 100 on Business. Rules run in under 2 seconds. No-code builder. Available on Growth and above.

What an automation rule does

A rule has three parts:

1. Trigger. When the rule evaluates (new conversation, message added, status change, etc.).
2. Conditions. What must be true for the rule to fire (channel, tag, content keyword, etc.).
3. Actions. What happens (apply tag, set priority, notify Slack, etc.).

Rules run within 2 seconds of the trigger event. Use them to codify support patterns your team executes manually.

Six trigger types

When rules can fire:

1. Conversation created. A new conversation starts on any channel.
2. Message added. Customer sends a new message in an existing conversation.
3. Status changed. Conversation moves between open, claimed, resolved.
4. Tag added. A tag is applied (manually or by another rule).
5. Skill fired. A specific skill triggered (e.g., collect_lead, escalate_to_human).
6. Webhook received. An inbound webhook from a connected integration.

Most rules use "Conversation created" or "Message added".

Twelve condition types

The rule fires only if all conditions are met:

• Channel equals X. Widget, WhatsApp, Slack, etc.
• Audience tag equals X. public, paid_users, enterprise.
• Conversation tag equals X. Has tag refund, urgent, etc.
• Message contains X. Keyword or phrase match.
• Priority equals X. Urgent, high, normal, low.
• Status equals X. Open, claimed, resolved.
• Customer tag equals X. Contact-level tag.
• Customer plan equals X. From CRM sync.
• Time of day. Within or outside business hours.
• Day of week.
• Country. Geolocation-based.
• Custom attribute. Any attribute passed via identify() or API.

Combine conditions with AND logic. For OR, create two separate rules.

Ten action types

What the rule does when it fires:

1. Apply tag. Add a conversation or contact tag.
2. Remove tag.
3. Set priority. Urgent, high, normal, low.
4. Assign to agent. Specific team member or unclaimed pool.
5. Notify Slack channel. Post a message with conversation link.
6. Send canned response. Auto-reply with a pre-written message.
7. Fire webhook. Send to your endpoint.
8. Set audience tag. Update the contact's audience.
9. Change status. Resolve, snooze, archive.
10. Trigger skill. Force a skill to fire (e.g., escalate_to_human).

Combine multiple actions in one rule.

Creating a rule

About 5 minutes per rule:

1. Open Dashboard > Automation Rules > Create.
2. Name the rule (e.g., "Route urgent enterprise to senior agents").
3. Pick a trigger.
4. Add conditions.
5. Add actions.
6. Set rule priority (higher numbers run first when multiple rules match).
7. Enable.
8. Save.

Test by simulating in the Chat Playground or sending a real test message.

Common rule recipes

Recipe 1: Auto-escalate frustrated customers.

• Trigger: Message added.
• Conditions: Message contains "cancel", "refund now", "this is ridiculous", "talk to manager".
• Actions: Set priority = high. Trigger escalate_to_human skill. Notify #urgent-support Slack channel.

Recipe 2: VIP routing.

• Trigger: Conversation created.
• Conditions: Customer tag equals vip or enterprise.
• Actions: Set priority = high. Assign to senior-agent pool. Apply tag vip.

Recipe 3: After-hours auto-reply.

• Trigger: Message added.
• Conditions: Time of day outside business hours. Status equals open.
• Actions: Send canned response "Our team will respond by tomorrow 9 AM PT".

Recipe 4: Refund-mention routing.

• Trigger: Message added.
• Conditions: Message contains "refund", "money back", "chargeback".
• Actions: Apply tag refund. Assign to billing-agent pool.

Recipe 5: Lead-captured CRM notification.

• Trigger: Skill fired = collect_lead.
• Conditions: Lead score above 75.
• Actions: Notify #sales-hot-leads Slack channel. Fire webhook to internal CRM.

About 80% of teams use 5 to 12 rules covering these patterns.

Rule priority and ordering

When multiple rules match the same trigger:

• Rules run in priority order (higher priority = earlier).
• Later rules see the changes from earlier rules (so a rule can apply a tag that another rule's condition checks).
• Use priority 1-100. Default new rules = 50.

Avoid circular dependencies (rule A triggers tag X; rule B checks tag X and removes it; rule A re-fires). The system has loop detection but it's better avoided by design.

Time-based rules

For rules that should run on a schedule rather than on event:

• SLA breach risk. Rule that checks SLA state every 5 minutes.
• Stale conversation cleanup. Auto-resolve conversations idle for 7 days.
• Recurring sync triggers. Re-sync knowledge sources weekly.

Today, scheduled rules are limited; event-based is the primary path. Native cron-style scheduling is planned for Business and above.

Disabling and editing rules

Rules can be:

• Disabled. Stop firing but config preserved. Re-enable any time.
• Edited. Save changes; new conversations apply the new logic.
• Versioned. Edit history retained 90 days; rollback via audit log.

Changes apply within 30 seconds.

Audit and metrics

Per rule:

• Times fired in the last 7 days.
• Last fire timestamp.
• Match rate (% of triggers where conditions matched).
• Action success rate (% where all actions completed).

Visible on the Automation Rules dashboard. Useful for spotting rules that fire too often or never (suggesting tuning).

API access

For programmatic rule management:

curl -X POST https://api.askvault.co/v1/automation-rules \
  -H "Authorization: Bearer ak_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "VIP routing",
    "trigger": "conversation_created",
    "conditions": [{"field": "customer.tags", "op": "contains", "value": "vip"}],
    "actions": [{"type": "set_priority", "value": "high"}],
    "enabled": true
  }'

Useful for version-controlling rules in git or syncing across workspaces.

Plan availability

• Free. No automation rules.
• Starter. Basic 1-condition, 1-action rules. Up to 5 rules. Starter+
• Growth. Full builder, up to 25 rules. Growth+
• Business. Up to 100 rules, webhook actions, advanced conditions. Business+
• Enterprise. Unlimited rules, custom actions via API.

Sample workflow

End-to-end:

1. Customer messages widget at 11 PM PT.
2. Rule "After-hours auto-reply" fires: "Our team will respond by 9 AM."
3. Customer's message contains "URGENT": Rule "Auto-escalate frustrated" also fires. Priority bumps to high. Slack alert posts.
4. On-call agent claims via Slack thread. Replies.
5. Customer responds with happy outcome.
6. Rule "Auto-resolve happy conversations": Detects "thanks" plus 5 minutes of no response. Auto-resolves.

Each rule does one thing. The orchestration emerges from the interaction.

Webhook actions

For integrating with external systems:

• Slack notifications. Built-in. Pick channel under action config.
• Custom webhook. Sends conversation payload to your endpoint.
• Email. Send a transactional email to a configured address.
• Zapier / Make. Trigger via webhook plus a Zapier hook URL.

See webhooks reference for payload schema.

Common pitfalls

Rules fire too often. Conditions too permissive. Add specificity (e.g., add channel + status combination).

Rules don't fire when expected. Wrong trigger type, or condition uses wrong field name. Use rule simulator to test.

Multiple rules conflict. Two rules set the same tag in opposite directions. Use priority to clarify order; or merge into one rule.

Rule loops. Rule A fires action that triggers rule B's condition, which fires rule A. Loop detection auto-disables after 5 cycles; investigate the design.

Planned features (on the roadmap)

Documented for accuracy:

• Cron-style schedules. Today, event-based only. Scheduled rules planned for Business.
• Multi-step rule flows. Today, all actions run in parallel. Sequential / conditional flows planned.
• Rule templates marketplace. Today, build from scratch. Library of pre-built common-pattern rules planned.
• Rule A/B testing. Today, one version. A/B versioning planned.

Limits

• Rules per workspace. 5 (Starter), 25 (Growth), 100 (Business), unlimited (Enterprise).
• Conditions per rule. Up to 10.
• Actions per rule. Up to 10.
• Rule execution time. Under 2 seconds.
• Loop detection. Auto-disable after 5 cycles.

FAQ

Can rules access conversation history?

Conditions can check recent message content. Full conversation history is available via webhook actions to your endpoint.

Can a rule edit the bot's response?

Not directly. Rules act on the conversation metadata (tags, priority, assignment) and external systems. To shape bot responses, use the system prompt or skill config.

Does the bot respect rule-applied tags?

Yes. Once a rule applies a tag, the bot's audience filter sees it on subsequent retrievals.

Can I share rules between workspaces?

Today, no native sharing. Export rule JSON via API; import into another workspace.

What's the latency between trigger and action?

Under 2 seconds typical. Webhook actions add the external endpoint's latency.

Related guides

• Conversation lifecycle
• Priority on conversations
• Tags
• Webhooks reference
• Canned responses

See RAG-grounded answers in action

Every AskVault answer is grounded in the source documents you upload. Never hallucinated.

Try AskVault Free → Read the API docs

Was this page helpful? Yes No