Where actions live

Every event has an Actions tile on its Confirmation card, and most start out empty, which is why the tile reads None until you build your first one. Open the event, go to Form and then click the Confirmation card, and click into Actions.

The Confirmation card on the Flow tab, before any actions are configured.

The drawer that opens says it plainly: actions fire automatically after each successful registration. It's split into two groups, and that split is the whole idea. Record actions change the registration itself. Integration actions tell something outside Express that a registration happened.

The empty drawer, split into Record Actions and Integration Actions.

Setting a status

Three record actions exist, and Set Status is the one most people reach for first. Static mode gives every registrant the same status: five come built in with the account (New, Invited, Cancelled, No-show, Attended), and you can add your own from there. Pick one and save.

Static mode: every registrant gets the same status.

Save lives inside the drawer, not up in the corner with the form's own Save button. Use the one inside the drawer, or your action won't stick.

Once it's saved, the row carries an ACTIVE badge, and hovering it reveals three controls: configure, pause, and delete.

A saved action shows an ACTIVE badge and joins the pipeline on the right.

Making status depend on the answer

Static mode covers most of what people need. When the status should depend on what a registrant typed, switch to Conditional. Rules run in order, first match wins, and a default underneath catches anyone who doesn't match a rule.

Conditional mode: rules run top to bottom, and the first match wins.

A rule reads like one sentence: a field, an operator, a value, then the status to set. The field list includes every question on your form, plus Registration Capacity, marked with a lightning bolt, which isn't a question at all. Six operators are on offer, the same six used in the form's own visibility logic, so anyone who's built a conditional field already knows the list.

Here's a working example: if the email address contains certain.com, set the status to New. Anyone who doesn't match falls through to the default, Invited in this case.

A built rule, read back as a sentence, with a default for everyone else.

Cancel discards whatever you were editing without touching what you already saved, so an action you built earlier keeps working even if you back out of a new one.

Setting the attendee type

Attendee Type is the second record action, and it works the same way as Set Status, with one addition. Five types come with the account (Staff, Attendee, Customer, User Group, Speaker), and you get Static and Conditional exactly as before, plus a third mode: Field Map.

Attendee Type adds a third mode alongside Static and Conditional.

Field Map takes one setting, a source field, and reads the attendee type straight off whatever a registrant answered, instead of you choosing it. It's useful when your form already asks people what they are.

Field Map reads the attendee type from an existing form answer.

Reopen a Field Map or Attendee Type action later, and the picker can come back looking empty even though the row and the pipeline still show the right value. The setting is still there. The editor doesn't display it back to you.

You get one of each record action per event, so there's no building two Set Status actions side by side. Once one's built, it shows up greyed out with a checkmark in the list.

Tagging who registered

Tags are the third and last record action, and they're the quiet one of the set. A tag doesn't change a registration's status or type. It labels it, which makes it useful for filtering a list or grouping a report later, without disturbing anything else Express already tracks.

Type a tag and press Enter to add it. A registration can carry more than one. Give tags names your colleagues will still recognize in six months, since they mostly turn up in filters and reports rather than anywhere they get explained.

Tags label a registration without changing its status or type.

Save all three, and the pipeline on the right shows the order they'll fire in: Set Status, Set Attendee Type, then Tag / Segment.

All three record actions built, each carrying an ACTIVE badge.

Telling other systems

Record actions change the registration. Integration actions reach outside Express to tell something else that a registration happened. Five are available: an additional email, a webhook, a Slack message, a calendar invite, and a delay for spacing the others out.

Additional Email

Additional Email is usually the first one people reach for. It isn't the confirmation email a registrant already gets. It's an extra message to any address you choose, which is how a colleague, a venue, or a catering team finds out someone has signed up. The To field defaults to the registrant's own address as a token, and you can add fixed addresses alongside it, separated by commas. CC and Reply-To are optional. From is your account's platform address, and it isn't editable here.

The Additional Email composer, separate from the standard confirmation email.

Webhook

A Webhook posts the registration to a web address you supply, so another system finds out without anyone re-keying anything. You'll usually set this one up together with whoever looks after that other system, since they're the ones who can tell you the address and what the payload needs to look like. Everything but the URL has a working default: POST, a ten-second timeout, no authentication, and a JSON body already written with the registrant's details in it.

A webhook's defaults cover everything except the destination URL.

Delay

Delay doesn't touch the registration or send anything anywhere. It waits, and everything after it in the pipeline waits with it, which keeps three messages from landing on someone in the same second. One setting controls it: how long, and in what unit.

Delay pauses the pipeline; everything below it waits too.

Slack messages and calendar invites follow the same pattern as the rest: open the Integration Actions group, pick the action, fill in what it asks for, and save inside the drawer.

Checking whether it ran

Every action you build sits above an execution log at the bottom of the drawer. It stays empty until a real registration comes through with these actions in place, since the log records firings, not settings. An empty log here isn't a fault. It's the honest answer.

Six actions built. The execution log fills in once a real registration comes through.

Knowing where the log is now is what matters. It's the first thing you'll want the moment you're wondering whether an email went out or a webhook fired.

Back on the Flow, the Confirmation card keeps up: its Actions tile no longer reads None, and the actions you built are listed underneath with a count.

The Confirmation card once actions are in place.

---

Quick reference