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 a registrant or attendee can see or buy. 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 default project roles cover most needs:
| Role | What they can do |
|---|---|
| Viewer | Read-only access to project resources. A curated set of sensitive areas — financial audit trails, staff cost rates, budget actuals, and similar — is excluded even from read access. |
| Editor | Create and update most resources, plus day-to-day actions like sending documents and running check-in scans. Cannot delete sensitive records or manage approvals. |
| Manager | Everything Editor can do, plus deciding and delegating approval requests and proposing changes to sensitive billing configuration. |
| Admin | Full access to all project resources. Tenant- and organization-wide settings such as reporting, branding, and access roles stay out of scope even for a project Admin. |
Two further narrow roles exist for onsite staffing — Check-In Staff (gate scanning only) and Session Monitor (session attendance scanning only) — and are not assigned by default.
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.
Track convenor responsibilities
Track convenorship routes programme work and notifications. A convenor's existing team roles control access to submissions and review actions. The My tracks filter starts selected in the relevant programme views and can be cleared; assigning responsibility leaves those role permissions unchanged. See Track Convenors for assignment and day-to-day work.
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 during a configured publish window, between its start and end date and time. Useful for time-gating early-bird pricing or closing ticket sales at a set time.
- Hidden — not shown on the public registration page. Useful for staff-only registrations or back-office items — though a channel can still expose a hidden item to registrants who activate that channel.
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 which catalog someone sees. Eligibility enforces prerequisites on the item itself — depending on the rule's effect, it either blocks the purchase (the item stays visible but not purchasable) or hides the item entirely until the attendee qualifies.
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.