Dynamic Registrant Lists

Moving from Groups to Registrant Lists + What’s Changing

A guide for event teams

Brella is replacing Groups (previously "attendee groups") with Registrant Lists — a clearer, more flexible way to organise the people at your event and control what they can see and do. This guide explains what changes, what happens to your existing setup, and how to work with lists going forward.

In one sentence: Everything you used Groups for — gating content, targeting communications, configuring networking, segmenting registrants — now runs on Registrant Lists, and all of your existing groups are converted automatically. We’re also introducing brand new “Custom Lists” — which can be used for powerful, highly granular communication targeting (emails, push notifications, stories etc.) and permission set-ups for larger events.

1. What's changing, at a glance

There are now two kinds of lists, and understanding the difference is the key to everything else.

2. The two list types

Ticket Type Lists

The direct successor to your old groups. Membership is driven by which ticket a registrant holds — you don't add people one by one.

• Every event automatically has one default list called "All registrants" that cannot be deleted. Anyone not otherwise assigned lands here.
• Each registrant belongs to exactly one Ticket Type List at a time.
• You can create additional Ticket Type Lists and move registrants between them in bulk.
• You cannot hand-pick individual members the way you do with a Custom List — membership follows the ticket/registration.

Custom Lists (new)

Hand-curated lists you build for any purpose — speakers, VIPs, a shortlist for a special session, etc.

• You add and remove specific registrants yourself.
• A registrant can be in any number of Custom Lists at once — in addition to their one Ticket Type List.
• Custom Lists can be reordered by dragging — and the order is meaningful for settings

Side by side

3. What happens to your existing setup during migration

The switch-over runs as a one-time data migration. You don't have to do anything — your configuration is carried across automatically.

💡Note: This migration and release will include a maintenance window including downtime. Specifics are available to customers.

What maps to what

Note — your old "custom attendee groups" become Ticket Type Lists, not Custom Lists. Despite the similar name, the old "custom group" was still ticket-driven. The new Custom Lists feature is a separate, hand-curated tool that starts empty for you to build.

4. Working with lists day to day

You'll find Registrant Lists in the event admin panel, split into Ticket Type Lists and Custom Lists. Both share the same set of options.

Settings every list carries

A list is more than a bucket of people — it defines how those people experience the event:

• Name & display name (display name is what attendees see; falls back to the name)
• Description
• Attendance type — in person, hybrid, or virtual
• Networking enabled — can these people use networking
• Meeting requests — outgoing / incoming — Everyone, No one, or Specific lists (and which lists)
• Max outgoing meeting requests and max accepted meetings
• Lead scanning enabled
• QR code visible
• Profile badge — an optional label shown on attendee profiles
• Show invites in apps / show invited registrants / show booking-system join URL

List names must be unique within an event (case-insensitive). "VIP" and "vip" count as the same name.

Ticket Type Lists — managing membership

• Membership is automatic from each registrant's ticket/registration.
• To re-segment people, use Move registrants to shift them from one Ticket Type List to another in bulk. (Moving only works between Ticket Type Lists.)
• Deleting a Ticket Type List does not remove its people — everyone is reassigned to the default list so no one is ever left without a list. You cannot delete the default ("All registrants") list.

Custom Lists — managing membership

• Add or remove specific registrants whenever you like.
• Reorder lists by dragging the handle on each row. Order is saved instantly.
• Deleting a Custom List will remove all of its members from it.

5. Where you'll use lists instead of groups

Anywhere you previously pointed at a group, you now point at a list (Ticket Type or Custom).

6. How a registrant's access is decided across multiple lists

<aside>
💡

NOTE: This is still subject to changes. Please refer to the Help Center articles available upon launch for a finalized version.

</aside>

A registrant is almost always on more than one list — their single Ticket Type List plus any Custom Lists you've added them to. Brella resolves "what applies to this person" using two different models, depending on whether it's a setting or content access. The distinction is important, and it works differently between Custom Lists.

A. Settings & networking → precedence (one list wins)

For per-person settings — networking on/off, meeting-request rules and limits, lead scanning, QR visibility, profile badge, display name, attendance type, "show invites in apps" — Brella picks a single winning list and uses its value:

1. Custom Lists first, in their drag order (the one nearest the top wins).
2. Then the Ticket Type List.
3. Then the event default.

For each setting, the first list that specifies a value wins; a list that leaves it blank passes through to the next list down.

This is why Custom List order matters. If a person is on two Custom Lists with conflicting networking settings, the higher one decides. Reordering isn't cosmetic — it changes outcomes.

Networking targeting follows the same rule: the meeting-request policy (Everyone / No one / Specific lists) and the specific allowed lists come from whichever single list wins the precedence above — they are not merged across a registrant's lists.

B. Content access → additive (any list grants)

For content gating — sessions/timeslots, story groups, pages, stream links, networking-area access — the logic is the opposite: access is the union of all the registrant's lists.

• A registrant can see a gated item if any one of their lists (Ticket Type or any Custom List) is granted access to it.
• Content gated to no list is public — visible to everyone.
• Adding someone to more Custom Lists can therefore only widen what they can see — it never takes access away, and the order of their Custom Lists is irrelevant here.

Practical effect: use a Custom List as an access pass. Put a handful of people on a "Backstage" Custom List that's granted a private session, and they gain it on top of whatever their ticket already unlocks — without affecting anyone else.

Access is also evaluated per purpose: a session's visibility and its who-can-rate permission are separate grants, so a list can unlock seeing a session without unlocking rating it. (Networking-area gating can additionally use cross-list rules — "List A may meet List B".)

At a glance

Right after migration no one is on a Custom List, so settings come straight from the Ticket Type List and content access is whatever that one list grants. Both models only come into play once you start building Custom Lists.

7. Resolution reference: every setting, gate, and communication

This is the full reference for how Brella decides what applies to a registrant who belongs to several lists at once (one Ticket Type List plus any Custom Lists). Two rules cover everything below:

• Precedence — one list wins.
  • Walk the registrant's lists in order — Custom Lists by drag position (top first) → the Ticket Type List → a system default — and take the first list that sets a value.
  • Used for per-person settings and networking.
• Additive — any list grants.
  • Combine all the registrant's lists (Custom + Ticket Type); access or targeting is the union, order is irrelevant, and anything tied to no list is public/everyone.
  • Used for content gating and communications.

"Sets a value" means the field isn't blank on that list. A blank field is skipped — so a Custom List only overrides the specific settings it actually fills in, and a registrant's effective configuration can be assembled from several lists.

Release:

This will be a rolling-release, with Ticket Type and Custom Lists launching on July 4th - the Dynamic Automation and certain additional permissions (that are new, and not present in the current Groups system) will arrive later in the summer/ autumn.

When dynamic rules arrive, the membership priority will be: manual additions always win, then dynamic exclusions, then dynamic inclusions — so a person you add by hand can never be removed by a rule.