Workspace System-Trigger Status
How the System triggers status cards work, what Telegram and WhatsApp status fields mean, and how those channel states relate to webhook-style automation runs.
Where you see this in the app
These status cards appear in the Rules tab of Workspace config & automations under the heading System triggers.
They summarize the current channel state for Telegram and WhatsApp separately from the manually created rules list.
Telegram status fields
The Telegram card is a readiness and health summary.
| Field | What it means for the creator |
|---|---|
enabled | Whether Telegram-trigger handling is turned on |
mode | Whether Telegram is using polling or webhook delivery |
auto-reply | Whether inbound activity can produce automatic responses |
last inbound | When the app last saw a Telegram event |
last sync | When the channel state was last refreshed |
cursor | Internal progress marker showing the last processed Telegram update position |
| error box | The latest known Telegram-side problem, if any |
From an end-user standpoint, the important fields are enabled, mode, recent activity timestamps, and any visible error.
WhatsApp status fields
The WhatsApp card exposes a broader connection-state model because login and session state matter more.
| Field | Plain-English meaning |
|---|---|
enabled | Whether WhatsApp-trigger handling is turned on |
driver | Which WhatsApp connection mechanism is currently active |
auto-reply | Whether inbound events can produce automatic responses |
chat scope | Whether the system listens to direct messages only or also group chats |
sender scope | Which senders are allowed to trigger the channel |
status | The current WhatsApp connection state |
last inbound | When the system last received a WhatsApp event |
last sync | When the WhatsApp status was last refreshed |
| error box | The latest known WhatsApp problem, if any |
The status line is the field most users will care about first because it explains whether the channel is ready, waiting for QR, or in an error/logout state.
No state found vs error vs disabled
These are different states and should not be conflated.
| UI outcome | What to infer |
|---|---|
No ... system trigger state found | The app does not currently have a channel-status record to show |
enabled: false | The channel exists but is intentionally not active |
| Visible error message | The channel tried to run but hit a problem |
So no state found is usually an unconfigured or not-yet-initialized situation, while disabled means a known channel is intentionally inactive.
How system triggers relate to rules
System triggers are channel-status surfaces that can enqueue WEBHOOK_EVENT style runs independently of scheduled rules.
The practical model is:
- configure channel credentials and login state in
Settings → Profile, - check the
System triggerscards for readiness, - use the
Rulestab to control how inbound events should actually start runs.
That is why channel status and rule configuration are shown next to each other but not merged into the same object.
Related docs
See it in action
Previous
Signed WEBHOOK_EVENT Automation Triggers
How WEBHOOK_EVENT rules are configured, what token and secret fields mean, how signed inbound payloads trigger runs, and how users should troubleshoot rejected webhook events.
Next
Workspace Preview Embed vs New-Tab Fallback
How the app chooses between embedded workspace preview and opening a separate preview tab, and what users should infer when the workspace starts but the inline embed is unavailable.