Roles and Permissions
This guide explains what each role can do and why some actions are intentionally restricted.
Community Roles
| Role | Main Use | Key Powers | Key Restrictions |
|---|---|---|---|
OWNER | Final authority set | Full control, owner-role management, ownership transfer, destructive actions | Cannot leave as the last owner; can step down to admin only when another owner remains |
ADMIN | Governance operator | Settings, branding, roles, invites, moderation | Cannot grant/remove owner status or use ownership transfer |
MANAGER | Event operations lead | Event lifecycle, tickets, attendance ops, updates, channel setup | No full hub governance |
MEMBER | Standard participant | Join events, hold/transfer tickets, chat where allowed | No admin controls |
Event Staff Permissions (Event-Scoped)
Event staff can be assigned explicit permissions per event, such as:
- Scan tickets
- View attendee list
- Edit event
- Manage tickets
- Issue comp tickets
- Override required ticket docs
- Verify members
This allows event-day delegation without granting full hub governance.
Sensitive Event Permissions
VERIFY_MEMBERS and the required-docs override permission are intentionally stricter than normal event operations.
VERIFY_MEMBERSlets staff review a member’s private door-check details: legal name and, if present, an optional private photo.- The required-docs override lets staff bypass required document checks on tickets at the scanner when policy allows.
OWNERandADMINcan use this capability implicitly.MANAGERis not implicit.- Only
OWNERandADMINcan grant these sensitive permissions on staff roles, per-person staff overrides, or event-staff invites.
Hubs can have more than one OWNER, but use that sparingly. Treat OWNER as a very small trusted set of people who genuinely need equal governance and destructive control.
If another owner already exists, an owner can use Hub -> Admin -> Settings -> Step down to admin to remove their own owner access while staying in the hub as an admin.
Event Staff Setup
Event -> Admin -> Staff is the canonical workspace for event staff. Manage roles, invite hub members, send external email invites, and review pending invites all from one page.
- Create reusable staff roles in the role library so the same permission bundle can be shared across events in a hub.
- Use
Add hub memberto assign existing members to an event with a role. - Use
Invite by emailto send an external invite that links the recipient to a chosen staff role; accepted invites become staff with the role attached. - Choose
Role defaultsto inherit the role’s permissions automatically, orCustomto override permissions for a single person. - Reset that person back to
Role defaultsonce the exception is no longer needed. - Review pending member and email invites before event day so no one arrives without access.
- Prefer event staff permissions over broader hub roles when the need is operational, temporary, or event-specific.
Hub admins can launch into the event staff workspace from Hub -> Admin -> Invites. Pick an event and click Manage staff or Invite staff by email. Hub admins do not maintain a separate event-staff role/permission form anymore.
Who Should Have Which Role?
- Use
OWNERfor very small trusted count. - Use multiple
OWNERusers only when they need equal governance authority. - Use
ADMINfor people responsible for hub governance. - Use
MANAGERfor reliable event operators. - Use event staff permissions when someone should operate one event only.
Practical Capability Matrix
| Capability | OWNER | ADMIN | MANAGER | Event Staff (with permission) |
|---|---|---|---|---|
| Hub branding/settings/roles | Yes | Yes | No | No |
| Hub invite governance | Yes | Yes | Limited by policy | No |
| Event create/edit/publish | Yes | Yes | Yes | Limited |
| Hub/event chat channel management | Yes | Yes | Yes | No |
| Ticket operations/refunds/comps | Yes | Yes | Yes | Limited |
| Scanner validation | Yes | Yes | Yes | Yes (SCAN_TICKETS) |
| Required ticket docs override | Yes | Yes | No | Yes (owner/admin granted) |
| Door-check detail review | Yes | Yes | No | Yes (VERIFY_MEMBERS, owner/admin granted) |
Permissions still depend on feature state:
/chat,Hub -> Chat, andEvent -> Chatall use the same shared channel creator now, but the member-facing pages still stay join/open-first.- Owners, admins, and managers can create or manage hub/event channels from those surfaces where policy allows.
Scanonly appears when the event attendance registration allows QR scanning.Event Daystays available for roster-capable roles when attendance registration is off, but it becomes read-only andScanis hidden.- Managers keep full
Event Daycontrols for event operations. - Roster-capable staff can use
Event Dayas a read-only roster workspace when their permissions allow it, while scan-only staff stay focused onScanner.
Why You Sometimes See 404 Instead of 403
Hubbaly uses privacy-by-default for sensitive resources:
404can mean “not found” or “not allowed to know this exists”.- This prevents existence leakage of private hubs, events, and records.
Permission Debug Checklist
- Confirm active hub context.
- Confirm your hub role in that hub.
- If event-scoped, confirm event staff permissions.
- Confirm whether route is governance-level or operations-level.
- Capture URL + role + exact error text if still blocked.