Statamic Automations Laravel Package

Getting Started

The entitlements.check_access action is a flow/automation node for Statamic that answers a live question: does this email address hold this product right now? It exists specifically for runs that span time — a mail queued today but delivered ten days later — where a trigger-time condition has already gone stale.

Minimal setup:

1. Confirm the entitlements addon is installed and enabled. The action registers itself only when that addon is detected; there is no migration or config publish for it.
2. Open the flow/automation editor in the Control Panel and look for Check Access in the action palette. If it is absent, the addon detection is the first thing to verify — not the action configuration.
3. Configure the three settings: email (usually a value from the run's context/subject), product_slug, and mode (require or forbid).
4. Place it immediately before the node whose outcome depends on access — typically a delayed mail or a fulfilment step.

A good first use case: a win-back or expiry flow that waits N days, then uses check_access with mode: require before sending a re-purchase email, so someone who renewed in the meantime is not emailed as lapsed.

Second thing to check after upgrading (as of v2.29.1): open an automation that contains a send_email node and confirm its mail tile still draws. Since 2.28.0 the canvas renders a screenshot of the mail in a sandboxed browser, and v2.29.1 hardens that heavily. If the tile renders blank or unstyled, that is almost always the sanitizer doing its job — not a broken email.

Upgrade path for v2.29.1: run composer update so goldnead/statamic-flow-canvas resolves to ^1.6.1 (required; 1.6.1 ships plain CSS instead of Tailwind utilities so the canvas draws on installs without Tailwind). No migration for this addon.

Implementation Patterns

Use the action, not the trigger condition, for anything delayed. Trigger conditions snapshot state at run start. Any flow with a wait, delay, or scheduled send should re-check at the point of decision. Treat the action as the authoritative gate and the trigger condition as a cheap pre-filter.

require vs forbid map to two distinct flow shapes. require is the common case: stop the run unless access exists. forbid is the inverse — useful for "only contact people who do not own X" (upsell, cross-sell, exclusion lists). Choose based on which outcome is the exception you want to short-circuit.

Read the stop/fail distinction as a design contract. When the condition legitimately does not hold, the run stops — that is a successful, expected outcome and should not page anyone. When the check cannot be performed (addon missing, malformed address, the entitlements addon throws), the node fails. Route failed runs to alerting/retry; route stopped runs to nothing. Conflating the two produces noisy on-call and hides real integration breakage.

Never rely on forbid as a safety net. A broken check fails the node; it does not silently pass. This is deliberate — a forbid that passed on error would let flows spray messages at people whose access state is unknown. Do not wrap the node in error-swallowing logic to "keep the flow moving."

Email resolution is narrow by design. The address is looked up as the Statamic user who owns it and as a subject of type email. Flows keyed on addresses that do not correspond to a Statamic user will fail rather than guess. If your flow sources emails from a CRM or order record, ensure the address is also represented as a user, or accept the fail-and-alert behaviour.

Access semantics come from the addon's own decide(). Active and in-grace-period both count as access; revoked, expired, scheduled, and pending do not. Do not reimplement this logic in your own conditions — you will drift from the addon, especially around grace periods.

Compose with delay nodes rather than scheduling separate flows. Keeping the wait and the check in one run preserves context and makes the stop-vs-fail signal observable in one place.

Treat the mail thumbnail as a preview, never as a source of truth. As of v2.29.1 the screenshot browser loads sanitized HTML with JavaScript off and a dead proxy; every src, srcset, background, poster, CSS url() and @import survives only as data:, cid: or on the app's own host. Design for that: host logo/brand assets on the application's own domain so they appear in the tile, or accept an empty frame. Remote CDN, tracking-pixel and third-party hosted images will all render as a transparent pixel — this is the intended outcome and is not a signal that the real mail is broken.

Sanitization applies only to the canvas render. The delivered email is unchanged. Keep that split explicit when reviewing content with marketing: "the tile is stripped, the inbox is not." Do not use the thumbnail to QA that a script, tracker or <base> tag works.

Let automation lifecycle own the assets. Deleting an automation deletes automations/thumbs/{uuid}/ on both the database and flat-file drivers. Do not link to, cache, or export those paths — treat thumbnails as disposable derived data and re-render rather than archive.

Gotchas and Tips

• Missing from the palette? The action is conditional on entitlements addon detection. Check the addon is actually loaded (and clear caches after deploys) before debugging the action class itself.
• Failed ≠ stopped. Dashboards and alerting that count "non-completed runs" will lump these together. Separate them, or you will chase expected stops.
• Malformed or unknown addresses fail the node. Validate/normalise email upstream, and make sure the address exists as a Statamic user. This is the most likely cause of unexpected node failures.
• Grace period counts as access. If product wants "only fully paid, not grace" behaviour, check_access alone will not express it — you need an additional signal.
• The addon throwing fails the node. Upstream entitlement data problems surface here, not at trigger time. Watch failed runs after entitlement data imports or sync jobs.
• Chromium won't start as root with the sandbox on. v2.29.1 keeps the sandbox on and disables it automatically only when running as root (the usual container case) or when automations.thumbnails.no_sandbox / STATAMIC_AUTOMATIONS_NO_SANDBOX=true is set. A sandbox-less host still runs Chromium unsandboxed — but now against sanitized HTML with no network. Set the env flag only if Chromium fails to start with the sandbox on a non-root user.
• Tune the render budget instead of retrying blindly. automations.thumbnails.timeout (default 20 seconds per mail) replaces the old fixed 30. Large or image-heavy mails that never finish belong on a longer timeout, not in a retry loop.
• Blank tiles have three usual causes, in order: the image is remote/relative/file:// (sanitized to a transparent pixel), the mail relies on CSS escapes — any style block or attribute containing a CSS escape is stripped whole, so the tile can look unstyled while the email looks fine — or Chromium could not start. Distinguish before touching config.
• cid: URLs survive sanitization but will not load in a browser outside a real mail client. An inline-image logo will still be blank in the tile even though recipients see it.
• Dependency floor matters on lean installs. v2.29.1 requires goldnead/statamic-flow-canvas ^1.6.1; 1.6.1 moves canvas components to plain CSS so the canvas draws correctly when Tailwind is not installed. Pin the floor — an older canvas package is the fastest way to reproduce "canvas renders unstyled" reports.
• Translations: do not re-add the Success key to de.json. statamic/cms owns that key and translates it identically; the fix in v2.25.0 removed the duplicate because TranslationKeyOwnershipTest fails when an addon claims a CMS-owned key. If you maintain your own translation files, run that test before release.
• Upgrade from 2.25.0 to 2.29.1 is a no-op operationally — no migration, no new dependency beyond the flow-canvas floor. The risk surface is the translation key removal (matters only if you were overriding it downstream), the canvas dependency bump, and the fact that previously-rendered thumbnails will look different now that sanitization is stricter.
• Testing: exercise all three paths of check_access at least once — condition holds (run continues), condition does not hold (run stops cleanly), check impossible (node fails). Disabling the entitlements addon is the quickest way to simulate the failure path. Separately, render one mail tile whose assets are all self-hosted (should draw) and one with a remote image (should show a transparent pixel) to confirm you understand which bucket your templates fall into.