User Types and Permissions

Every user in FMX has exactly one user type, and that user type determines nearly everything about their experience: which modules they see, what they can create or edit, whose records they can act on, and what their default notification settings are.

User types are defined by your organization, not by FMX — a school district might have "Requester", "Teacher", "Maintenance staff", and "Administrator", while a manufacturer has something entirely different. They're managed on the User Types page in your organization's admin settings, so if permissions need to change, that's where an administrator changes them (for everyone with that type at once).

How permissions are scoped

A user type doesn't just say whether someone can do something — it says on which records. Permissions on a user type are scoped, generally along these lines:

• None — the person can't do this at all.
• Own — only on records that belong to them (for example, requests they submitted or work assigned to them).
• Accessible buildings — on records in the buildings listed on their user record. This is why the Accessible buildings field on a user matters: it's the boundary many permissions are measured against.
• Any — on any record in the organization.

Some settings use a simpler view/edit choice instead ("No access" / "View only" / "Edit"). The exact options you see depend on the permission being configured.

This scoping exists per action, per module — reading, creating, updating, responding, approving, and deleting can each be scoped differently. That's how one user type can let technicians resolve work in their own buildings but only view work elsewhere.

What else a user type controls

Beyond module permissions, a user type can also determine:

• Default notification settings — new users start with the email preferences defined by their user type (each user can adjust their own afterward).
• Approval participation — approval steps can be defined in terms of user types, so belonging to a type can put requests in your approval queue. See the sections for Work Requests and Schedule Requests for how approval affects each request lifecycle.
• Administrative reach — whether people with this type can administer other users, and whether they can be administered themselves.

A worked example

A district creates a "Coach" user type for athletics staff: it can create schedule requests in accessible buildings, view (but not edit) the calendar for everything else, and can't see Work Requests at all. Each coach's user record lists only their own school under accessible buildings. When a coach logs in, FMX shows just the scheduling features, scoped to their school — and when the district later decides coaches may also submit work requests, an administrator edits the "Coach" user type once and every coach gets the new access.