Skip to content

User Roles

Roles determine what a user can do in the admin system.

  • Can book resources
  • Can view events and register
  • Cannot access admin features
  • Assigned to new users automatically
  • Same as Guest
  • Represents users with an active membership
  • For tracking membership status separate from permissions
  • Can view admin dashboard
  • Can check in users
  • Can view bookings and sell items
  • Can view users and reports
  • Can edit events in admin view
  • Everything Staff can do
  • Can manage bookings and store items
  • Can view financials
  • Can manage equipment and workspaces
  • Can create and delete events
  • Full access to everything
  • Can manage roles, designations, and memberships
  • Can manage billing and makerspace settings
  • Can assign and change other users’ roles and designations

Roles follow a strict hierarchy where higher roles include all permissions of lower roles:

Admin (Level 5)
Manager (Level 4)
Staff (Level 3)
Member (Level 2)
Guest (Level 1)

To change a user’s role, you need the edit_user_access permission (typically Admin-only).

  1. Go to PeopleUsers
  2. Click on a user
  3. In the Role dropdown, select the new role
  4. Click Save

The system enforces hierarchy rules when assigning roles:

  • You can only assign roles at or below your own level. For example, a Manager can set someone to Guest, Member, Staff, or Manager — but not Admin.
  • You can only change the role of users at or below your own level. A Manager cannot demote an Admin.
  • Admins can assign any role, including promoting someone to Admin.

Every makerspace has one Account Owner. The Account Owner is always an Admin, and their role cannot be demoted by anyone — not even other Admins. This ensures the makerspace always has at least one Admin and prevents accidental lockouts.

The Account Owner is typically the person who created the makerspace.

  • Users can only have one role at a time
  • Changing a role takes effect immediately
  • For special capabilities (like teaching classes), use Designations instead
  • Roles are scoped per makerspace — a user could have different roles at different makerspaces
  • Some sensitive permissions (like managing roles and billing) are only available through roles, not designations