Actions builder

When you just need "when X happens, do Y", the actions builder is faster than a full workflow. It maps one event to one action.

Plan availability

Basic interactions are on every plan (including Free): menu and drawer open/close, show/hide an element, toggle a CSS class, sticky nav, navigation, and site alerts — pure in-page effects with no server cost and no metering.

The automations engine — server-side steps, custom JS, analytics events, and Marketing overlays — is Pro+, with metered runs. You build both in the same place; steps that need a higher plan are labelled in the editor.

Create an action

1. Open the actions builder from Workflows.
2. Choose the event (the trigger).
3. Choose the steps to run in response.
4. Save.

That's it — no multi-step logic to manage. Reach for a workflow when you need several steps, branching, or composition.

Triggers

Beyond server events (form submissions, page views, sign-ins, leads, bookings), actions can fire on visitor behavior in the page:

• Scroll depth — the visitor scrolls past a percentage.
• Scroll to / element visible — a CSS-selected element enters the viewport.
• Element click — a CSS-selected element is clicked.
• Exit intent — the pointer leaves toward the top of the window.
• Time on page — a dwell-time threshold passes.
• Page visit — the page loads.

Page triggers can be limited to certain paths (/pricing, /blog/*), and a Frequency setting controls re-fires: every matching pageview, once per session, once per visitor, or with a cooldown (a minimum number of minutes between fires for the same browser).

Only run when a field matches

Every action can carry a condition over the event's payload — for form submissions, that's the submitted field values. Pick an operator in the "Only run when" select:

• A field is not empty — e.g. the subscribe checkbox was ticked.
• A field equals… — an exact match (trimmed, case-insensitive), e.g. plan equals Pro.
• A field contains… — a partial match, handy for checkbox groups that submit all ticked options joined with , (e.g. topics contains Pricing).

When the condition isn't met the action is skipped, and the skip is recorded: the run history gets a Skipped row naming the field or fields whose condition stopped it — "Condition on subscribe, plan not met". That row is the answer to "why didn't my automation fire?", and it sits in the same place as the runs that did fire. A skip still doesn't count as a metered run: nothing executed, so nothing is charged.

Conditions are the no-code sibling of the free-text Filter expression; use whichever reads better (both must pass when both are set). One difference worth knowing: only a condition writes a Skipped row. A Filter expression that evaluates false — or that throws, which also stops the action — records nothing at all, so an automation that never fires because of a broken filter has an empty run history rather than an explanation. Prefer a condition when you want the skip on the record.

Example — grow an email list from a signup form: add a Checkboxes field named subscribe with a single option Yes, keep me posted to your form. Then create an action on formSubmission with the condition "A field is not empty" → subscribe and one step: Enroll in a list, picking your audience. Visitors who tick the box join the list; everyone else just submits the form.

Chain multiple conditions (AND/OR)

One condition rarely tells the whole story, so a condition can be a chain: click Add condition to append another row (up to five), and remove a row with its × button. With two or more rows a Match select appears:

• All conditions match (AND) — the default; the action runs only when every row passes. E.g. subscribe is not empty and plan equals Pro.
• Any condition matches (OR) — the action runs when at least one row passes. E.g. topics contains Pricing or topics contains Billing.

Each row keeps the single-condition operators and semantics unchanged (trimmed, case-insensitive matching). Existing automations with a single condition keep working exactly as before — editing one simply shows it as a one-row chain.

Each automation row offers a Runs log — its recent executions, including the skipped ones, described under Run history below — and, for page triggers, a Test button that exercises the server-side steps immediately.

Steps

Steps run in order and mix in-page effects with server-side work:

• Basic in-page effects (all plans): open/close/toggle a menu or drawer, show/hide or toggle an element, add/remove/toggle a CSS class, make the navigation sticky, redirect, show a site alert. These are pure DOM choreography — they run everywhere and are never metered.
• Advanced in-page effects (Pro+): show a popup or bar from your Marketing overlays, show custom HTML, track an analytics event, and run custom JS (Business).
• On the server (Pro+): run a workflow, write to or update a dataset, send a webhook (Business), send an email, notify site admins, enroll the contact in a list, assign a campaign, fire a custom event to chain more actions.

On plans without the automations entitlement, an automation that mixes tiers still runs its basic in-page steps — the Pro+ steps are simply skipped until you upgrade.

Every reference (workflow, dataset, webhook, overlay, list, campaign) is picked from a list and stored by id — renaming things never breaks an automation. Deleting can, though, so the Logic page's Reference health card audits every automation, workflow, and computed-variable reference and lists any that point at something that no longer exists.

Run history

Every automation row has a Runs button. It opens Runs — your automation with a Recent runs table of that one automation's executions, in four columns:

Column	What's in it
Time	The clock time of the run; hover it for the full date and time.
Trigger	The event, in words — formSubmission shows as Form submitted. A custom event keeps the name you gave it.
Result	Succeeded, Failed, or Skipped.
What happened	For a run, what each step did, joined with ·. For a failure, the errors. For a skip, which condition stopped it.

Skipped is a result, not an absence — see Only run when a field matches. A run that fired but whose steps errored is Failed, and the errors are in the last column rather than in a log you have to go and find.

At the top of the Actions tab — and again on the Workflows tab, counting workflow runs — a line reads 1,284 action runs this month · 50,000 included: how many metered runs this site has used this calendar month, against the number your plan includes. This line is the only place action runs are counted for you — the billing usage meters meter workflow runs, not action runs. Watch it: once the month's runs reach the limit, triggered automations stop running rather than queueing or billing on. The line renders nothing at all while the counter or the plan is still loading — 0 runs this month on a site that has run thousands is the one reading that would make you stop debugging.

What is and isn't recorded

Reference detail. Runs and skips are recorded on different rules, and the gaps are deliberate:

• A skip on pageView is never logged. Page-view actions run on every visit to every published page, so a record per visitor per non-matching action would be a write storm, not a run history. A pageView run that does execute is logged like any other. Page-view conditions are tuned by watching the site, not by reading this table.
• A skip is only recorded for server events — form submissions, sign-ups, bookings, leads. An action dispatched from an in-page trigger (scroll depth, element click, exit intent, time on page) logs its runs, but a condition that stops one of those writes nothing.
• A Filter expression rejection writes nothing, as above.
• The table is a recent sample, not a guaranteed tail. It reads a bounded window of the site's activity records — which also carry publishes, media saves and member changes — keeps this automation's runs from that window, sorts them newest-first and shows up to 25. On a quiet site that is your last 25 runs. On a busy one the window can fill with other activity, and the newest runs are not guaranteed to be in it. There's no paging in the dialog.
• Nothing prunes run records on a schedule, so an automation's history keeps accumulating in the site's activity log even though this dialog only ever shows a window of it. Setup → Activity is the full log, ordered newest-first and paginated — go there when the Runs dialog doesn't show the run you're looking for.

Interactions from the Besigner

Select any element in the Besigner and use the Interactions section of the attributes panel to attach a when clicked, when hovered, or when scrolled into view trigger to that exact element — no CSS selectors to write. Pairing a when hovered trigger with an open menu or open drawer step is how you build hover-to-reveal navigation, and — like all basic in-page effects — it works on every plan. The interaction is created disabled with a placeholder step; finish and enable it on the Workflows page. The same panel lists the element's existing interactions with an enable switch and a remove button — so you can pause or retire one without leaving the canvas — and offers "A/B test this section", which creates a draft section experiment for the element.

When to use which

Use the actions builder	Use a workflow
One event → one action	Several ordered steps
Simple, no branching	Composes functions/variables
Fastest to set up	More control

Related

• Build a workflow
• Webhooks