People, roles & permissions
How the roles matrix, member types, and per-person permissions decide who can do what in your space.
Everything in MakerOps that matters — who can edit equipment, approve requests, see reports, run a machine — traces back to roles and permissions. It pays to set these up deliberately before inviting the whole membership.
Roles and the permissions matrix
Settings → Roles & People has two tabs:
- Roles — the permissions matrix. Each role (Administrator, Staff, Instructor, Member, Student, Guest, and any you add) is a column; each permission is a row. A person can hold multiple roles, and their effective permissions are the union of everything their roles grant.
- People — the per-role drill-down: who holds each role, and where role assignment happens. Lists are built to handle thousands of people, so a university-scale student body is fine.
Roles come with sensible defaults per audience — staff-type roles carry operational permissions, patron-type roles (member, student, guest) carry participation ones — and every default can be changed for your space.
Member types and seats
Each person has a member type (staff, member, student, guest) that determines how they’re counted and defaulted. Staff whose roles carry operational permissions occupy platform seats per your plan; patron-type members do not. Note that “billable seat” here means your MakerOps subscription — it has nothing to do with what you charge your own members.
Invitations and accounts
- Invites are per-person emails carrying the intended roles; they expire and can be re-sent. Accepting an invite in the mobile app signs the person in immediately.
- Provisioned accounts (created directly by staff) set a password on first login.
- SSO (SAML) can be enabled so campus/company accounts sign in directly; domain detection can route people to the right login automatically.
Visitors and minors
Visitors who only need to sign a waiver or attend an event don’t need full accounts — public token links handle waivers and event signups without a login (see Events, tours & the public side). Waivers support a guardian signing for a minor.
Good practice
- Grant operational permissions through roles, not ad-hoc — audits stay legible.
- Keep the Administrator set small; almost everything staff do day-to-day fits in a Staff-type role.
- Review the matrix whenever you enable a new module: new permissions arrive with it and default conservatively.