Access and permissions
ema controls access in two distinct ways: team roles decide what your staff can do in the admin portal, and the access-control engine decides which registration catalog items, sessions, or content a registrant or attendee can see. These two systems work independently.
Team roles
Team roles come in three tiers that stack additively: tenant roles grant operator staff access across every client organization, organization access roles cover a whole organization and its projects by default, and project roles cover one project. Every user on your project is assigned a role at one or more of these tiers. Roles are a set of named permissions — each permission is a combination of a resource and an action (for example: "create registration type" or "approve tasks"). See Tenant Roles for the top tier.
The three built-in roles cover most needs:
| Role | What they can do |
|---|---|
| Viewer | Read and list everything. Cannot create, edit, or delete. |
| Editor | Create and update most resources. Cannot manage team members or approve sensitive operations. |
| Admin | Full access including member management, approvals, and integrations. |
You can also create custom roles with exactly the permission set you need.
Roles are checked when a user submits an action — not just when buttons are shown. A user who cannot perform an action cannot sneak it through.
Create and configure team roles for your project.
The access-control engine: channels, visibility, and eligibility
For registrants and attendees, access is controlled by three layered mechanisms.
Channels
A channel is a named context that changes which registration types and add-ons are visible. Every registration page has a default channel — the public view. You can create additional channels activated by a secret code or a URL query parameter.
Common examples:
- A "Members" channel that shows member-priced registration types the public cannot see.
- An "Early bird" channel shared with a waiting list before general registration opens.
- A "Sponsors" channel giving exhibitor staff access to a specific registration type.
When a registrant activates a channel (by entering a code or arriving via a special link), the catalog updates to show only what that channel exposes. A channel can also automatically apply a discount code, or activate based on a registrant's membership designation from an external AMS.
Visibility rules
Within a channel, individual registration types and add-ons can be set to control their own visibility:
- Public — visible without any channel activation.
- Published window — visible only between a
publishAtandunpublishAttimestamp. Useful for time-gating early-bird pricing or closing ticket sales at a set time. - Hidden — exists in the system but never shown to registrants. Useful for staff-only registrations or back-office items.
Eligibility rules
Eligibility rules enforce prerequisites at the item level. They let you say: "you can only buy this add-on if you already hold this registration type", or "this ticket category is only available to people who answer 'Yes' to this form question."
Eligibility is distinct from channel visibility. A channel controls what someone can see. Eligibility controls what someone can buy, given what they already have.
How the two systems relate
The team role system and the access-control engine are separate and additive:
- A team member with an Admin role has full access to the admin portal but cannot register for a members-only ticket unless they also meet the channel and eligibility conditions.
- A registrant who activates a VIP channel can see VIP items, but has no access to the admin portal.
Design your access setup by asking two separate questions: "Who on my team needs to do what in the admin?" (roles), and "Who in my audience should see which catalog items?" (channels, visibility, eligibility).
Set up registration channels and activation codes.
Configure eligibility prerequisites on registration types and add-ons.
Control visibility windows per registration type.