Running triggers: schedule, preview and execution log

Once your trigger rules are set up, everything about running them lives on the Delivery tab. This article covers the daily schedule, manual runs and single-member tests, the quiet-hours and frequency-cap guards, how Preview works, and the full execution log reference including columns, status values, and backend skip reasons.

Contents

• Schedule and run
• Quiet hours and frequency caps
• The full eligibility chain
• Preview
• Execution log reference
• Columns
• Status values
• Backend skip reasons

Schedule and run

Everything about running triggers lives on the Delivery tab: the daily schedule, quiet hours, frequency caps, and the Execute Triggers panel. Some elements inside the tab keep the wording Execution (for example Execution Results, Execution Run, and Executed At).

The Delivery tab: daily schedule, quiet hours, frequency caps, and manual runs in one place.

Daily schedule

• Set a time and timezone on the configuration and toggle the schedule on or off.
• The schedule is shared by all studios using the configuration.
• The scheduler checks every minute for configurations that are due and runs all active rules for all attached studios.
• A rule will not run twice on the same calendar day (in the studio's local timezone). If a rule already ran today, whether automatically or manually, it is not run again.

Manual run ("Run now")

• Immediately executes the rule for the current studio. This sends real messages. There is no undo for a sent message.
• A manual run stands alone: it does not dedup against other rules from the daily run.
• If the rule already ran today (automatically or manually), the manual run is blocked to prevent double-messaging.

Test with single member

• Runs the rule against one specific member you choose.
• You pick the member by their customer ID, not the member number. Copy it from the member’s profile: open the profile and take the number in the page URL — for example .../#/customermanagement/1562839240/overview means customer ID 1562839240.
• Bypasses condition matching: the member is processed regardless of whether they match the conditions.
• Always dispatches as Group A, without locking the member into a control bucket, so the test never silently lands in the control group.
• Use this to verify channel setup and templates end to end before activating a rule.

Quiet hours and frequency caps

Two of the messaging guards are global settings, configured on the Delivery tab and shared by all studios attached to the configuration. (The other two guards, the per-rule cooldown and the multi-match dedup, are covered in Creating and editing trigger rules.)

Quiet hours. Set a start and end time in the studio’s timezone. Overnight ranges work (22:00 to 07:00 wraps midnight). Quiet hours are disabled if only one of the two times is set, or if start and end are identical.

What happens during quiet hours. Messages that come due while the window is open are not dropped: they are queued and sent as soon as the quiet-hours window opens for sending (that is, once the window ends). The trigger editor warns you when a configured run time falls inside an active quiet-hours window, and the daily-schedule panel shows the same warning for the daily run. Event-driven lead triggers (the New-Lead welcome) are not subject to quiet hours and are sent immediately.

Guard order. For every run the guards are evaluated in a fixed order: quiet hours, then the daily cap, then the weekly cap, then the per-rule cooldown.

Daily and weekly frequency caps. Rolling limits per member: a maximum number of Engage messages per day (rolling 24-hour window) and per week (rolling 7-day window). Each cap has its own on/off toggle on the Delivery tab. If a member has already reached a cap, further messages are skipped.

The caps are global per member across all Engage triggers, not counted per trigger, so a member who already received a message from another rule earlier in the window can be capped out of this one. One run counts as one message even when it goes out on several channels. The windows are rolling (the last 24 hours and the last 7 days), not calendar days or weeks.

See also: Creating and editing trigger rules (Messaging guards, Priority and multi-match resolution).

The full eligibility chain

A member can match every condition you wrote and still receive nothing, because conditions are only one step. For every run, Engage applies this chain in order:

1. Audience — active member, former member, or lead.
2. Communication stop — members who opted out (no Newsletter consent) are removed.
3. Contract type — the rule’s include/exclude contract-type filter.
4. Your conditions — the condition fields on the rule.
5. Reachability on the selected channel — WhatsApp and SMS need a phone number, Email needs an email address.

Missing contact data on the selected channel is the most common reason a matching member gets nothing. One caveat on the conditions step: a condition only matches members who actually have a value for that field. A member with no value is excluded by every operator, including negations, so a member with no payment method does not match “payment method is not Direct Debit”. To reach members without a value, use an explicit “is empty” condition where the field offers one.

Preview

Preview checks a rule's reach before it sends anything.

• Preview evaluates the current draft of the rule as you have it in the editor, not the last saved version.
• It returns the total count of matching members and a sample list with name, churn risk band, and key visit metrics.
• Preview is a real-time snapshot: it only shows who matches the conditions right now, based on the current day's data snapshot (member metrics refresh once per day).
• You can load the full paginated list of matching members, which helps in large studios.

A count of 0 is not a problem. Preview showing 0 members only means nobody matches today. It does not mean the rule is broken or that nobody will match tomorrow: members move in and out of the conditions as their data changes, for example when a contract-expiry threshold is crossed overnight or a member crosses the dormancy threshold.

Use Preview to tune thresholds before activating. If a Dormancy rule matches half the studio, the threshold is probably too tight for a useful campaign; raise the days-since-last-visit value and preview again.

Preview shows who matches the conditions. It does not simulate guards, so the actual number of messages sent in a run can be lower once cooldowns, frequency caps, quiet hours, dedup, and the A/B control group are applied. Treat the preview as “who is eligible”, not “who will be messaged”.

Execution log reference

Every evaluated member gets a row, so you can always reconstruct why someone was or was not contacted. The Delivery tab shows summary cards (Total matched, Group A, Group B) and a per-member results table. Results can be filtered by date range, execution run, trigger, channel, and A/B group, and exported to CSV.

Delivery results: one row per evaluated member, with Path (One-way or Agent), channel, A/B group, and outcome.

Columns

Status values

Every dispatch attempt ends in exactly one of the outcomes below, shown in the Status column. The Path column next to it shows Agent (delivered via the MagicAI Chat agent) or One-way (sent directly), and is blank for skipped and control rows.

These are the delivery-log statuses confirmed by engineering (the ml-backend message-status set). Each evaluated member produces one row per run with its outcome. The "Skipped (backend)" status carries a second-level reason field that names the precise cause (see Backend skip reasons below). Richer per-send delivery reports (a Succeeded, Failed or Pending status per message with the failure reason) are planned for a later release, not for go-live. The exact on-screen wording for the less common statuses is confirmed against the GA UI.

Backend skip reasons

When the status is "Skipped (backend)", the reason field explains why the delivery system held the message back:

See also: Setting up WhatsApp for Engage. See also: Impact Analysis.