Statamic Automations Laravel Package

Product Decisions This Supports

• Time-of-check vs. time-of-run correctness for lifecycle messaging. The entitlements.check_access node answers "does this address hold product X right now?" at the moment a flow executes, rather than inheriting the state captured when the run was triggered. For any flow with a delay between trigger and send — trial nudges, renewal reminders, win-back, drip onboarding — this is the difference between a correct message and an embarrassing one. It directly enables a class of products (delayed, state-aware communication) that was previously unreliable or required custom code.
• Suppression and offer-hygiene decisions. mode: forbid lets you encode product rules like "never pitch Product A to someone who already has it" without building segment refresh jobs. This is a revenue-protection and brand-safety decision as much as a technical one.
• Reactivation and dunning flows. mode: require ends the run when access is gone, so expiration/revocation messaging can be sequenced confidently: send the "your access has ended" message only to people who actually lost access, and the "you're still in grace" nudge only to those who still have it.
• Build vs. buy on entitlement logic. Access is delegated to the entitlements addon's own decide() (active or grace period; not revoked, expired, scheduled, or pending). That is a deliberate decision not to re-implement entitlement semantics in the flow layer — the PM avoids a second, drifting source of truth for "who has access."
• Fail-closed as the default product stance. When the check cannot be made (addon missing, bad address, addon throws), the node fails rather than passing; a forbid never passes because the check broke. This is a defensible default (don't grant, don't promise, don't upsell on unknown state) but it is a product choice worth documenting in flow runbooks, because it converts upstream addon instability into visible flow failures.
• Whether to trust canvas previews with real customer creative. Since 2.28.0 the canvas renders a photo of a send_email mail in a headless browser; 2.29.1 seals that browser off (sanitised HTML, JavaScript off, dead proxy, sandbox on, allow-listed URLs only). This is what makes it defensible to enable previews in an approval workflow for customer-facing mail: the preview surface now treats email HTML as hostile input rather than trusted markup. It also defines the fidelity trade-off — third-party images (CDN, tracking pixels, file://, relative paths) become transparent pixels, so the preview is an approximation, not a pixel-perfect proof.
• Data retention and asset lifecycle. Deleting an automation now deletes its thumbnails (automations/thumbs/{uuid}/) on both database and flat-file drivers. That turns "delete the automation" into a genuine cleanup operation, which supports retention/GDPR decisions and prevents orphaned screenshot storage from accumulating — a small but real operational-budget decision.
• Infrastructure cost of previews is now an explicit knob. automations.thumbnails.timeout (default 20s per mail) and the no_sandbox escape hatch are product-visible settings: they decide how long an editor waits and how a containerised/root deployment behaves. Preview availability becomes a hosting prerequisite, not a free feature.
• Roadmap sequencing. The entitlement action registers only when the entitlements addon is detected and requires no migration or new dependency; it can be adopted opportunistically per-flow rather than as a platform migration. The preview work similarly ships without migration and is gated by a Composer constraint on goldnead/statamic-flow-canvas ^1.6.1 — a dependency upgrade, not a re-platform.

When to Consider This Package

Adopt when all of the following hold:

• You are on Statamic and already running this flows addon and the entitlements addon. The node is inert without entitlements — the coupling is a hard prerequisite, not a soft integration.
• Your flows have a meaningful gap between trigger and action (delayed sends, multi-step drip, wait nodes) where trigger-time conditions go stale.
• Your entitlement questions map to the addon's model: a single product_slug, resolved via the Statamic user owning the address and via a subject of type email.
• You are comfortable with fail-closed behavior on lookup errors and are prepared to monitor flow failures as a signal.
• If you want mail previews on the canvas: your host can run headless Chromium, you accept that non-allow-listed images render blank (previews are for layout/approval, not pixel QA), and you can satisfy the goldnead/statamic-flow-canvas ^1.6.1 requirement. On root/container hosts Chromium runs unsandboxed unless you set automations.thumbnails.no_sandbox / STATAMIC_AUTOMATIONS_NO_SANDBOX — the HTML and network are still sanitised, but the sandbox is not there.

Look elsewhere or defer when:

• You are not on Statamic, or you do not run the entitlements addon (no amount of configuration will register the action).
• You need richer condition logic than one product per node: multi-product bundles, quantities, seat counts, or entitlement sources outside the addon.
• You need soft-fail semantics (continue anyway on error) or an explicit "unknown" branch — the model here is stop/fail, with forbid deliberately unable to pass on a broken check.
• You need a synchronous guard (middleware, API authorization, checkout gating) rather than a flow node.
• You need to check subjects other than an email address / the user who owns it.
• Adding a second addon to the critical path of customer-facing messaging is unacceptable for your reliability posture.
• You need exact visual fidelity in previews — remote imagery is intentionally stripped, so a mail that depends on a CDN-hosted hero will not preview as it sends.
• You cannot run Chromium or cannot accept an unsandboxed renderer on a root/container host; previews are optional, but the entitlement node has no such dependency.

How to Pitch It (Stakeholders)

To executives: This release closes a correctness gap in lifecycle messaging. Until now, a flow decided whether to send based on who the customer was when the flow started — which is wrong for a mail that goes out ten days later. The new action re-checks entitlement at send time using the entitlements system's own definition of access, so we stop pitching products to people who already bought them and stop telling lapsed customers they still have access. Alongside it, the canvas mail preview — the "photo" of an email shown to editors — is now hardened: the rendering browser runs with scripting off, a request-blocking proxy, an on-by-default sandbox, and sanitised HTML, so previewing customer mail no longer means trusting whatever that mail references. Deleting an automation now also deletes its stored preview images, so retention is handled for us. All of it ships with no migration and no new infrastructure beyond a headless Chromium for previews; the defaults are deliberately conservative, and if an entitlement check can't be made the run fails rather than guessing.

To engineering: Small, additive, opt-in. One new flow node, entitlements.check_access, with email, product_slug, and mode (require / forbid); it auto-registers only when the entitlements addon is detected. Access resolution delegates to the addon's decide() — no duplicated entitlement rules on our side. Failure semantics are explicit and worth instrumenting: unmet condition stops the run, uncheckable condition fails the node. Separately, 2.29.1 hardens the 2.28.0 thumbnail renderer: HTML is reduced before Chromium sees it (scripts, frames, plugins, SVG, stylesheets, <base>, meta refresh, image-set(), CSS escapes stripped; loadable URLs restricted to data:, cid:, or the app host, everything else becomes a 1px transparent pixel), JavaScript is off, a dead proxy catches all requests including loopback except the app host, and the sandbox stays on except under root or when automations.thumbnails.no_sandbox / STATAMIC_AUTOMATIONS_NO_SANDBOX is set. New automations.thumbnails.timeout (default 20s per mail) replaces the fixed 30. Deleting an automation deletes automations/thumbs/{uuid}/ on both drivers. Requires goldnead/statamic-flow-canvas ^1.6.1 (plain CSS canvas components, fixing installations that only have this addon). No migration; set STATAMIC_AUTOMATIONS_NO_SANDBOX=true only if Chromium fails to start sandboxed on a non-root user. Treat flow failure rates as a new operational metric, and watch thumbnail storage/timeouts as a second.