Roles and Permissions

This guide explains what each role can do and why some actions are intentionally restricted.

Community Roles

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
• Upload photos and videos to the event’s albums (photographer staff; albums restricted to admins only stay closed)

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_MEMBERS lets 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.
• OWNER and ADMIN can use this capability implicitly.
• MANAGER is not implicit.
• Only OWNER and ADMIN can 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 member to assign existing members to an event with a role.
• Use Invite by email to send an external invite that links the recipient to a chosen staff role; accepted invites become staff with the role attached.
• Choose Role defaults to inherit the role’s permissions automatically, or Custom to override permissions for a single person.
• Reset that person back to Role defaults once 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.

Staff dates on multi-date events

When an event has more than one scheduled date, staffing works per date rather than assuming everyone works every day.

• Each invitation carries the event dates it covers. You choose and review them per person before sending, and the invitation email and alert spell out the full date offer with times.
• Recipients accept only the dates they can do. Their inbox and the email invitation page show each date as accepted, awaiting, or declined.
• Access follows acceptance: live event and session access, Event Day, and staff tools honour the dates the person actually agreed to.
• Changing the event schedule preserves existing agreements. Adding a date never silently signs anyone up for it; you are linked back to review staffing after the change.
• The staff workspace groups each person’s accepted, awaiting, and declined dates so gaps are visible before event day.
• Roles with no assignments can be deleted, and archived roles can be restored from the role library.
• A multi-use email invite reserves staff capacity for every remaining use, so a shared link cannot oversubscribe your plan.

Who Should Have Which Role?

• Use OWNER for very small trusted count.
• Use multiple OWNER users only when they need equal governance authority.
• Use ADMIN for people responsible for hub governance.
• Use MANAGER for reliable event operators.
• Use event staff permissions when someone should operate one event only.

Practical Capability Matrix

Permissions still depend on feature state:

• /chat, Hub -> Chat, and Event -> Chat all 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.
• Scan only appears when the event attendance registration allows QR scanning.
• Event Day stays available for roster-capable roles when attendance registration is off, but it becomes read-only and Scan is hidden.
• Managers keep full Event Day controls for event operations.
• Roster-capable staff can use Event Day as a read-only roster workspace when their permissions allow it, while scan-only staff stay focused on Scanner.

Why You Sometimes See 404 Instead of 403

Hubbaly uses privacy-by-default for sensitive resources:

• 404 can mean “not found” or “not allowed to know this exists”.
• This prevents existence leakage of private hubs, events, and records.

Permission Debug Checklist

1. Confirm active hub context.
2. Confirm your hub role in that hub.
3. If event-scoped, confirm event staff permissions.
4. Confirm whether route is governance-level or operations-level.
5. Capture URL + role + exact error text if still blocked.

Related Guides

• Hubs and Community Setup
• Community Admin
• Required Forms and Waivers
• Troubleshooting