Chapter 14 — Who Gets In: Gating & Account Groups
Attend onboarding guide · ~7 min read · ↑ Back to contents
Not every program is open to everyone. A student program should only admit .edu emails; a credit
program should only admit people who bought credit. The mechanism for "who is allowed to purchase" is
gating, and it leans on a vendor concept called account groups. This chapter also covers who can
log into Cortex itself.
Account groups: defined in the vendor, mirrored in Attend for gating
An account group is a bucket of customer accounts. Teams create the groups and assign customer
accounts in the ticketing vendor's system — that's the source of truth. But Attend doesn't re-hit
the vendor on every request: each fan's group membership is stored locally in tbl_user_account_groups
(userId → accountGroupId) and is joined into the session at login, so gating checks run against
Attend's own table. (There's no separate tbl_account_groups table of group definitions — only these
per-user membership rows; accountGroupId is a plain varchar with no FK.)
What Attend does with them is gating — deciding who's allowed through.
The three gating types
| Type | Mechanism |
|---|---|
| Account group gating | Only users in the specified account group(s) can purchase. |
| Email domain gating | Only certain domains allowed — e.g. .edu for a college program. |
| Direct email gating | An explicit allowlist or blocklist of individual addresses. |
⚠️ Status: only account-group gating is live today. Email-domain and direct-email gating (and the Cortex gating-config table) are in active development.
Example: the Warriors run a season-ticket-holder presale. They gate the program to the "STH-2026" account group, so only existing holders can buy before it opens to the public.
The credit bank flow — gating + account groups together
The most common combined use is a credit bank: a team sells a credit pack, then only lets credit buyers purchase events.
- The team sells a credit pack on the Attend platform.
- On purchase, Attend drops the fan into a specific account group.
- Account-group gating is switched on, so only those credit purchasers can buy events.
- Attend reads the credit amount from the vendor API and shows it in the UI.
(How that credit then gets spent is the next chapter.)
Account groups for discounts (MSG use case — not yet implemented)
Account groups can also drive different prices for different buyers. The classic example is MSG, which sells three credit tiers:
| Spend | Account group | Discount |
|---|---|---|
| $2,500 | A1 | 10% |
| $5,000 | A2 | 20% |
| $10,000 | A3 | 30% |
All three groups are allowed to purchase (that's gating), but each gets a different discount (that's pricing). This account-group-based pricing isn't built yet — note it and move on.
Who can use Cortex: user roles
Separate from fan gating is who can log into the admin tool. Cortex has four roles:
| Role | Scope | Permissions |
|---|---|---|
| Attend staff | Global | Super admin — everything, every workspace |
| Client Admin | Their team workspace | Everything in that workspace, including inviting users |
| Editor | Their team workspace | Everything except inviting users |
| Viewer | Their team workspace | Read-only |
Editor and Viewer are fully defined and enforced; some older workspaces may still have only Admins.
Recap
- Account groups are a vendor concept; Attend reads them via API and uses them for gating.
- Three gating types: account group, email domain (e.g.
.edu), and direct email (allow/blocklist). - The credit bank flow combines them: buy credit → land in a group → group gating limits purchases.
- Account-group-based discounts (MSG tiers) are planned, not built.
- Cortex roles: Attend staff (global super admin) · Client Admin · Editor (no inviting) · Viewer (read-only).