Event-driven automation
Configure bounded trigger-condition-action rules and verify their governed effects.
Configure bounded trigger-condition-action rules and verify their governed effects.
Use an automation rule for deterministic reactions to platform events: record a notification, emit a webhook event, propose a role change, or notify a permitted audience. Use the Operator for analysis and findings; use repository code for contract changes. A rule is data, not an arbitrary-code runtime or cron service.
A rule belongs to one business and can be environment-scoped. Its trigger names
one event from the closed catalog and optionally narrows subject type or id.
Zero to twenty conditions are ANDed. Conditions read allowed envelope fields or
a single-level payload.<key>; nested traversal, JavaScript expressions, and
regular expressions are not supported. path_prefix tests whether any path in
an array starts with the literal prefix.
The generated rule schemas contain all event, operator, field and action shapes. Treat names and bounds as exact. An unknown event or extra body key is rejected, not silently ignored.
| Action | Observable effect | Important boundary |
|---|---|---|
emit_webhook_event | Delivery through the webhook channel | Event must be webhook-deliverable; normal signing and retries apply |
create_notification | An automation.notification fact | Not a promise of an email or SMS |
propose_change_set | Draft governed role-permission proposal | Proposer only; does not approve or apply it |
notify_audience | Audience-delivery request | Only product-update or transactional bases; audience and consent are revalidated |
A rule has one to ten actions. Governance and native permissions still apply when the rule fires; creating a rule does not bypass action authorization.
Read current rules and the exact input before writing:
farthershore automation list <business> --format json
farthershore automation create --help
farthershore operations list --format json
Prepare a body using the generated schema with enabled: false. Use the
command's dry-run and retain a stable idempotency key for the logical create.
After approval, create the rule, record its returned identity, and compare the
stored trigger, conditions, actions and environment with the intended scope.
Enable with an update only when its external effects are intended.
The create schema defaults enabled to true, so omitting it is not a safe
draft. For partial updates, omitted fields are retained; explicitly set
enabled: false to stop future matching.
Observe the triggering event and the resulting notification, webhook delivery, proposal, or audience receipt. A successful rule-create response proves storage, not that an event matched or every downstream effect completed. Correlate identifiers and audit evidence before retrying an uncertain write.
Disable a mistaken rule to prevent future matches. Disabling or deleting it does not retract delivered messages, remove created proposals, or undo earlier effects. Do not repeatedly generate real events as a test against customers; use the intended preview environment and a bounded audience.