Per-rule: notify_on_execution toggle + channels (in_app / telegram / email). Fires when entities_acted > 0. Sent inline by the evaluator (not via an SQS queue). Default channels: telegram + in_app.

Rule notifications — get alerted when actions fire

Per-rule settings: notify_on_execution toggle + notify_channels (any of in_app, telegram, email). Notification fires when notify_on_execution is true and entities_acted > 0 (i.e. the rule actually did something). The evaluator sends the notification inline — directly to in-app, Telegram, and email — not through a separate SQS queue. If notify_channels is not set, the default is {telegram: true, in_app: true} (email is off unless you enable it explicitly).

Who is this for

Anyone running rules that change live spend. Notifications are the "did something just happen?" channel — paired with execution history (which is the "what happened?" channel).

The settings

In the rule builder (Step 9) or rule edit:

• notify_on_execution: boolean
• notify_channels: object with booleans for each channel: {in_app: true, telegram: false, email: true}. When unset, the default is {telegram: true, in_app: true} (email off).

Both settings are stored in the automation_rule row.

The three channels

in_app

Always available. Notification shows in the in-app notification center (sidebar bell icon). Live polling means it appears within seconds of dispatch.

No setup needed — works out of the box.

telegram

Requires the workspace's Telegram bot to be connected. See team-116 notifications for setup.

Notification format: short message with rule name + entity count + a link back to /rules/:id.

email

Off by default — only sent when you explicitly enable email in notify_channels. Sent to the rule creator's account email.

Format: a rule-execution email with the rule name, matched entities, and metric values.

When notifications fire

Notification fires only when:

• notify_on_execution = true
• entities_acted > 0 (the rule actually changed at least one entity)

Notifications do not fire when:

• Rule evaluated but nothing matched (entities_matched = 0)
• All matches were skipped (cooldown, daily cap, pending check, entity state conflict)
• Action is notify_only and nothing matched

For notify_only action + matches > 0: notification fires (because notify is the action).

Dispatch pipeline

After a rule execution with notify_on_execution = true and entities_acted > 0, the evaluator sends the notification inline (no separate SQS queue):

1. The evaluator builds a consolidated payload from the matched entities
2. It sends per enabled channel, directly:
   • in_app — creates a notification row (type automation)
   • telegram — sends a consolidated Telegram message
   • email — sends a rule-execution email (only if email is enabled)

Each channel is wrapped in its own try/catch, so a failure on one channel doesn't block the others.

Payload contents

Notification payload includes:

• Rule name + ID
• Execution start / end times
• Counts: entities_evaluated / matched / acted / skipped / errored
• Matched entities (first 20 inline by name + id + metric values + action applied; remainder summarized as "+N more")
• Link back to /rules/:id + the specific execution entry
• Metric snapshot used for the evaluation

Use cases

Daily monitoring

notify_on_execution: true + email + in_app channels. Standard for any production rule. You see what happened without polling the dashboard.

Critical rule (extra eyes)

Important rule (e.g. high-budget scale): also add telegram for instant ping on phone.

notify_only (alerting only)

Rule with action = notify_only. Notifications are the entire output. Used when:

• Learning a new rule's behavior before letting it act
• Reporting / alerting on metrics without changing state
• Compliance: notify when threshold reached, even if action requires manual approval

Quieting notifications

If a rule fires too often + notifications become noisy:

• Raise thresholds (rule fires less)
• Lower notify_channels (e.g. drop email, keep in_app only)
• Or accept the noise as signal of an over-tuned rule and adjust

Don't blanket-disable notify_on_execution — you'll lose visibility into automation behavior.

Channel-specific caveats

telegram

• Requires bot connected at workspace level
• Per-user subscription via Telegram chat (covered in team-116)
• Falls back silently if bot disconnected; check Telegram setup if expecting alerts

email

• Goes to spam if domain isn't allowlisted at the recipient mail server
• Allowlist noreply@wevion.ai in your email provider
• Email may be delayed by recipient's spam filter (out of Wevion's control)

in_app

• Visible only when logged in to Wevion
• Cleared on read; check before clearing if you need to reference

Common mistakes

• notify_on_execution: false on production rules — you're flying blind on automation
• All three channels enabled for every rule — noisy; pick channels based on rule criticality
• Expecting notifications on skipped matches — only fires when entities_acted > 0
• Telegram bot not connected — settings show telegram on, but no messages arrive

FAQ

When do Wevion rule notifications actually fire?

A Wevion rule notification fires only when notify_on_execution is true and entities_acted > 0 — meaning the rule actually changed at least one entity. It does not fire when nothing matched, when all matches were skipped by cooldown or daily cap, or for a notify_only action with no matches.

Which notification channels can a rule use?

Each Wevion rule can send to any combination of three channels via notify_channels: in_app (the notification center bell, no setup needed), telegram (requires the workspace bot connected), and email (off unless explicitly enabled; sent to the rule creator's account email). If notify_channels is unset the default is telegram + in_app. The evaluator sends notifications inline (not via an SQS queue).

Why aren't my Telegram rule alerts arriving?

Telegram alerts require the workspace's Telegram bot to be connected; if it's disconnected, Wevion falls back silently even though the channel shows as on. Check your Telegram setup if you expect alerts. Email can also land in spam — allowlist noreply@wevion.ai in your mail provider.

How do I reduce noisy rule notifications?

If a rule fires too often, raise its thresholds so it fires less, or lower notify_channels (for example drop email and keep in_app only). Wevion advises against blanket-disabling notify_on_execution on production rules, since that leaves you flying blind on what your automation did.

Related articles

• Customize notification preferences
• Execution history and audit
• Protections — cooldown, backoff, limits