Recipes and authority
/app/<orgSlug>/automation shows the person's responsibility, contributing work
areas, recipes, approval inbox, exceptions and run evidence.
automation.view, automation.manage and automation.approve are distinct.
Target products must be enabled and the actor must retain their source authority.
Unsupported effects are unavailable until their delivery and review paths exist.
The general builder creates internal work using a manual trigger, periodic schedule or authenticated connector signal. It includes recipe name/description, interval or connector key, optional signal-text condition, delay, per-run approval, daily run limit, optional stop-after count/date, and task title/summary/priority. The chosen effect uses the applicable legacy or explicitly adopted Tasks backend.
- Create or edit a draft recipe.
- Test the draft and inspect the proposed internal effect.
- Publish the tested version.
- Trigger manually, wait for its schedule or send an authorized connector signal.
- Review any required approval and inspect run evidence.
- Pause the recipe if exceptions need investigation; resume or retire deliberately.
Published versions remain frozen. Changes require a new draft version, test and publication. New Tasks adoption does not rewrite old published versions or retries. Connector keys are shown when created/rotated; rotation invalidates the previous inbound key immediately. A connector signal does not bypass conditions or approval.
Approval and recovery
An approval card shows requester, owner, scope, trigger facts, frozen action, delay and limits. Approve frozen run approves that exact proposal; rejection requires a reason and creates no effect. Managers and approvers may be different people under the relevant policy.
Runs show their outcome and evidence. Exceptions are grouped by root cause to avoid a wall of identical alerts. Safe replay uses retained run identity and source semantics; compensation is an explicit supported recovery action, not an arbitrary reversal. A paused/invalid owner or policy does not trigger a backlog of uncontrolled missed runs.
Ticketing's built-in confirmation, waiting-list and attendee communications remain Ticketing-owned and do not require Automation subscription. The existing Ticketing-rule table retains earlier undersold-Event discount rules for operation and audit. An eligible active legacy rule can only be paused; new creation, reactivation, editing and deletion are unavailable there. New work uses versioned recipes. Customer event recipes retain CRM eligibility and current source consent. Automation Orders routes expose authorized contributed commerce records, not a new seller or independent payment ledger.
The native Automation home presents current runs and permitted approval decisions. Recipe authoring and specialist settings continue through the authorized web workspace. Native approval requires an online connection and the same displayed frozen version.