Workspace Rules and Trigger States
How the Rules tab works, what enabled or disabled rules mean, and how schedules, webhook rules, and system triggers are surfaced to end users.
Where you see this in the app
These controls appear in the Rules tab of Workspace config & automations.
This tab is where creators define trigger-driven runs and inspect the current rule list plus the Telegram and WhatsApp system-trigger state.
Creating rules
The create-rule form exposes the most important rule-building fields directly.
| Setting | Plain-English meaning |
|---|---|
| Trigger type | What kind of event can start the rule |
| Cooldown seconds | Minimum spacing between runs from this rule |
scheduleCron | The schedule expression for scheduled rules |
timezone | Optional timezone for schedule interpretation |
| Prompt template | The instruction text the automation run should start from |
| Workload profile | Optional runtime tier override for this rule |
| Env defaults / Secrets defaults | Optional default values added when runs start |
The rule form is not about describing the workflow in abstract terms. It is the place where you define what event starts the run and what default instructions/context the run receives.
Enabled vs disabled rules
The rule list shows each rule with a clear state label such as Enabled · SCHEDULE or Disabled · WEBHOOK_EVENT.
That state is meaningful:
| State | What the user should infer |
|---|---|
| Enabled | The rule is allowed to enqueue runs when its trigger happens |
| Disabled | The rule still exists, but it should not start new runs until re-enabled |
A disabled rule is not deleted. It remains part of the rule list, keeps its configuration, and can be turned back on later.
That makes Disabled a pause state, not a loss-of-configuration state.
Schedule, webhook, and system triggers
The rules system supports multiple trigger families.
| Trigger family | What it means |
|---|---|
| Schedule | Start runs on a recurring time pattern |
| Webhook event | Start runs from a signed inbound event |
| System triggers | Telegram or WhatsApp channel activity that can enqueue webhook-style runs independently |
The system-trigger cards for Telegram and WhatsApp are status panels, not the same thing as manually created rules. They summarize channel readiness and recent inbound/sync state.
If a channel is not configured, the panel can legitimately show that no system trigger state is found.
Defaults, workload profile, and prompt template
The advanced rule defaults are optional, but they materially change how a rule runs.
Prompt templatedefines the starting instruction set.Workload profilecan push a rule onto a different runtime tier.Env defaultsandSecrets defaultsprovide default values the run can use.
These are best understood as the rule's startup context.
If a rule exists but behaves in an unexpected way, the important places to inspect are:
- whether it is enabled,
- whether the trigger type matches the event you expect,
- whether the schedule or webhook token is correct,
- whether the prompt/defaults describe the run you actually wanted.
Related docs
See it in action
Previous
Workspace Billing, Access, and Collaboration
What author pays vs collaborator pays means, how purchase requirements work, and how edit collaborators are granted or restricted.
Next
Telegram and WhatsApp Channel Setup
How the profile-workspace Telegram and WhatsApp controls work, when the workspace is ready for each channel, and what the main channel states mean.