Overview
What it does
Section titled “What it does”Automation Studio connects supported Capell events to ordered actions. A rule matches one trigger and optional payload conditions, then can send email, submit a Public Action, update a contact, subscribe a user, or prepare an Agent Bridge capability. Each action receives its own run record so retries do not repeat actions that already completed for the same event.
Setup requirements
Section titled “Setup requirements”Run the package migrations and keep a queue worker running. Package listeners enqueue trigger jobs rather than completing workflows in the visitor or admin request. A queued trigger is attempted up to three times and is deduplicated by its source and site for one hour.
Keep Laravel’s scheduler running as well. The package declares capell:automation-studio:reap-stale every ten minutes; by default it marks pending runs older than 15 minutes as failed, in batches of 250. This makes abandoned worker state visible but does not execute the action again.
There is no Automation Studio settings page. Recovery limits and the ten-step automation-lineage limit come from capell-automation-studio configuration. Actions supplied by companion packages work only when those packages and their own providers, templates, or definitions are configured.
Build and test a rule
Section titled “Build and test a rule”Open Automation Studio > Automation rules. Give the rule a stable key and name, select Active or Paused, then choose one of the registered triggers: form submitted, access approved, page published, or campaign converted.
Conditions read named fields from the trigger payload and support equals, does not equal, filled, and blank. Field names must match the producing package’s payload, including dotted paths. Add one or more actions in the order they should run and configure only the keys required by that action. The available native action types are send email, webhook, tag contact, create note, subscribe user, queue agent capability, and Public Action.
The action labelled Webhook submits a configured Public Actions key; it is not a field for an arbitrary remote URL. Email, contact, newsletter, Agent Bridge, and Public Actions operations fail safely when their companion integration is missing or incomplete.
Use Dry run active rules with a representative trigger and payload before activation. Dry run reports how many active rules and actions would match; it does not call handlers, send messages, change contacts, create run records, or prove that a downstream provider will succeed. Persisted rules may be global or site-specific; a site event loads both its site rules and global rules.
Monitor, recover, and replay
Section titled “Monitor, recover, and replay”Open Automation Studio > Automation runs to review rule/action keys, trigger and action type, status, message, and timing. Rules and runs are restricted to the account’s assigned sites; global administrators can see global and cross-site records.
On a queue retry, completed action records are recognised and skipped, while failed actions can be attempted again. Signed lineage metadata prevents a rule cycle and stops a chain after the configured maximum number of automation hops.
If the run list offers Recover stale runs, confirm it to mark abandoned pending records as failed immediately instead of waiting for the scheduler. This changes audit state only. Inspect the run message and application log, correct the missing handler, provider, template, payload, queue, or companion-package setup, then decide whether replay is safe.
Replay is available only for failed, pending, or skipped records and requires update access to that run’s site. It runs the recorded action again with the stored event payload and the action’s current rule configuration, without re-evaluating the original rule conditions. It can therefore resend email, repeat a Public Action, or apply another contact change. Review the current action settings and downstream idempotency before confirming.
Permissions and sensitive data
Section titled “Permissions and sensitive data”Rules use View:AutomationRule, Create:AutomationRule, Update:AutomationRule, and Delete:AutomationRule. Run history uses View:AutomationRun; replay uses Update:AutomationRun. The admin queries and replay action enforce site scope in addition to those permissions.
Rule conditions, actions, and settings are encrypted in the database. Run payloads and action context are also encrypted, but rule/action keys, source type and ID, statuses, messages, idempotency keys, and timestamps remain operational metadata. Trigger payloads can contain form submissions, email addresses, contact details, or campaign data, and the package has no automatic run-retention task. Limit run access, avoid copying secrets into action settings, and define database/backup retention that matches the connected workflows’ privacy obligations.
For how to use Automation Studio, see the admin guide. For developers: see the README.