¶ Automation And Scheduler Patterns
Use event automations for immediate reactions and scheduler-backed automations for deferred or recurring work.
- let event automations react quickly to object or action changes
- move delayed follow-up into scheduled tasks
- use variables to name important intermediate concepts
- use secrets for external integration credentials
- decide whether the automation is auto-driven by a resource event or caller-driven by a button, form, view action, canvas, webhook, or scheduler
- choose the narrowest resource and selector set that still expresses the real business trigger
- keep trigger descriptions readable enough that another implementer can tell why the automation runs
- handle immediate validation, assignment, and object updates in event-driven automations
- hand off reminders, retries, follow-up checks, and recurring routines to scheduler-backed execution
- use scheduled arguments when the later step needs object-specific context
- turn on run logging for business-critical scheduled work
- use variables when several actions depend on the same derived business value
- store credentials in the secret store and reference them from automation logic instead of embedding them directly
- use Local Storage when automations need reusable helper files, generated artifacts, or intermediate exported outputs
- pair every webhook-triggered flow with a clearly owned automation path
- document what a public route or webhook is expected to trigger
- review webhook exposure together with links, public modules, public canvases, and release checks
- create follow-up tasks immediately, but send reminders later
- assign ownership on create, then schedule escalation checks
- process webhook input through a focused automation and hand off longer work to a scheduled routine
- build reusable helper code in Local Storage and include it from several automation steps
- use a permission-aware button automation for a user action and a separate scheduled routine for later compliance checks
- keep automations small and composable
- use Local Storage for shared helper files only when several automations or scripts truly reuse them
- use the scheduler intentionally instead of simulating delay inside one large automation
- keep scheduled automations stable without UI-only context
- keep secrets, trigger selectors, and scheduler arguments documented as part of the workflow contract
- log scheduled work that matters operationally