How many automation rules can I create in AskVault?

There's no fixed cap today, and automation rules aren't gated to a specific plan. Every enabled rule is evaluated independently after each assistant turn — there's no rule ordering or 'first match wins' behavior, so a conversation can trigger more than one rule on the same turn.

What events can trigger an AskVault automation rule?

Three trigger types: the customer's message contains specific keyword(s), the bot's reply confidence drops below a threshold, or the conversation has been idle for N minutes. Each trigger's condition lives in its own config (e.g. the keyword list, or the threshold) rather than a separate conditions builder.

Can AskVault automation rules trigger other rules?

Rules don't chain off each other's actions today — there's no tag-applied or status-changed trigger for one rule to react to what another rule just did, so cascading loops aren't a concern in the current MVP.

Automation rules

Written by Joseph Russo, Principal Architect, Networks and Tech, AskVault · Reviewed by Allison Chan

Last updated: June 18, 2026 · 4 min read

What an automation rule does

A rule has two parts:

Trigger. The one condition that must be true for the rule to fire — a keyword match, a confidence threshold, or an idle timer. The trigger's parameters (keywords, threshold, minutes) live in the trigger's own config, not a separate conditions step.
Action. What happens when it fires — escalate, auto-resolve, or notify.

Rules evaluate after every assistant turn, against a single SELECT of the workspace's enabled rules — cheap, and with no LLM call involved.

Three trigger types

Customer says specific keyword(s). Match if the visitor's message contains any (or, with all: true in the config, every) keyword in your list.
Bot confidence drops below threshold. Match if the bot's last reply's confidence score is below the number you set (0–1).
Conversation idle for N minutes. Match if the time since the conversation's last message exceeds the minutes you set.

There's no "conversation created," "status changed," "tag added," "skill fired," or "webhook received" trigger today — these three cover the MVP.

Three action types

Escalate to human agent (live chat). Sets the conversation to escalated and marks it live for the Help Desk inbox.
Auto-resolve conversation. Sets the conversation to resolved.
Send notification (webhook/email). Records that the rule fired for delivery through AskVault's existing notification pipeline; pick webhook or email as the channel.

There's no built-in "apply tag," "assign to agent," "set priority," "change status" (beyond escalate/resolve), or "trigger skill" action today, and no separate Slack-specific action — route a Slack alert through the webhook channel of the notify action instead.

Creating a rule

A few clicks:

Open Dashboard > Automation Rules > Create.
Name the rule (e.g., "Escalate frustrated customers").
Pick a trigger and fill in its config (keywords, threshold, or minutes).
Pick an action and fill in its config (a reason for escalate/auto-resolve, or a channel for notify).
Save.

Send a real test message afterward to confirm it fires the way you expect — there isn't a separate dry-run simulator today.

Common rule recipes

Recipe 1: Escalate frustrated customers.

Trigger: Keyword match — "cancel", "refund now", "this is ridiculous", "talk to manager" (any).
Action: Escalate to human agent.

Recipe 2: Catch low-confidence answers before the customer notices.

Trigger: Bot confidence drops below 0.4.
Action: Escalate to human agent.

Recipe 3: Auto-resolve conversations nobody came back to.

Trigger: Conversation idle for 1,440 minutes (24 hours).
Action: Auto-resolve conversation.

Recipe 4: Alert the team on refund mentions.

Trigger: Keyword match — "refund", "money back", "chargeback" (any).
Action: Send notification via webhook to your Slack-connected endpoint.

How rules interact

There's no priority or ordering system — every enabled rule is checked independently on every turn, and a single turn can fire more than one rule (e.g., a keyword match that also happens to be a low-confidence reply). Rules also don't currently react to each other's actions, since there's no trigger for "another rule changed this conversation," so rule chains and infinite loops aren't something you need to design around in this MVP.

Disabling and editing rules

Rules can be:

Disabled. Stop firing but config preserved (is_enabled toggle). Re-enable any time.
Edited. Save changes; they apply to the very next turn evaluated — there's no propagation delay, since evaluation reads the current row from the database each time.

There's no version history or one-click rollback today — editing a rule overwrites its config.

Metrics per rule

Each rule tracks:

Fire count. Running total of times the rule has fired.
Last fired at. Timestamp of the most recent fire.

There isn't a match-rate or action-success-rate breakdown, or a 7-day fired-count window, in the current dashboard.

API access

Rules are workspace-scoped CRUD under the same path the dashboard uses:

curl -X POST https://api.askvault.co/api/workspaces/{workspace_id}/automation-rules \
  -H "Authorization: Bearer ak_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Escalate frustrated customers",
    "trigger_type": "keyword_match",
    "trigger_config": {"keywords": ["talk to manager", "cancel"], "all": false},
    "action_type": "escalate",
    "action_config": {"reason": "keyword match"},
    "is_enabled": true
  }'

trigger_type must be one of keyword_match, low_confidence, idle_timeout; action_type must be one of escalate, auto_resolve, notify.

Plan availability

Automation rules aren't gated by plan today — the create/list/update/delete endpoints and the dashboard page carry no plan check, and there's no enforced cap on the number of rules per workspace.

Planned features (on the roadmap)

Documented for accuracy — none of the following exist yet:

More trigger types. Conversation created, status changed, tag added, skill fired, inbound webhook.
More action types. Apply/remove tag, assign to agent, set priority, fire a custom webhook directly, trigger a skill.
A conditions builder. Combining multiple fields (channel, tag, time of day, custom attributes) with AND/OR logic, separate from the trigger itself.
Rule priority/ordering, cross-rule chaining, and loop detection.
Rule versioning and rollback.
Plan-based rule limits, if usage patterns show they're needed.

Common pitfalls

Rule fires too often. A keyword list that's too broad, or a confidence threshold set too high (remember: fires when confidence is below the threshold). Narrow the keyword list or lower the threshold.

Rule doesn't fire when expected. Wrong trigger type for what you're trying to catch, or a typo in the keyword list. Send a real test message and check the rule's fire count afterward.

Two rules both fire on the same turn. Expected — rules don't suppress each other. If that's not what you want, tighten each rule's trigger config so they don't overlap.

FAQ

Can rules access conversation history?

The keyword_match trigger only sees the visitor's latest message, and low_confidence only sees the latest bot reply's confidence score. There's no trigger that scans earlier turns in the conversation.

Can a rule edit the bot's response?

No. Rules only change the conversation's status (escalate/auto-resolve) or fire a notification. To shape bot responses, use the system prompt or skill config.

Does the bot respect rule-applied tags?

There's no tag action today, so this doesn't apply yet.

No native sharing today. Recreate the rule via the API in the other workspace.

What's the latency between trigger and action?

Rules evaluate synchronously right after the assistant's turn, with a single database query — no LLM call is involved.

Was this page helpful?