Permissions

Purpose: give admins a practical model: who can view, edit, and configure the system, so you can answer why a user may not see a page, without opening a ticket for every question.

Who can use this

Site and organization administrators. Non-admins can read the high-level description here but cannot change settings.

What the app is doing (in user terms)

Role: bundle of allowed actions (for example, run checkout, edit items, manage billing).
Scope: which facility or program the role applies to. A person can belong to more than one site in a district.
Module: area of the product (drama inventory, music, reports). Your subscription may not include every module.

Steps (for admins)

List jobs in your program (director, TD, student aide, read-only teacher).
Map each job to a role you see in the Users screen. Keep least privilege - start tight, and add access when someone really needs it.
When someone cannot open a page, check role, then facility assignment, then module (drama vs. music), before assuming a bug.

Expected result

You can predict who can do what, and you can document the mapping for the next person who takes your job.

What happens next

System settings for options that change behavior for everyone.
User management to apply changes to real people.

Common problems

One-off admin access: if the product does not allow narrow exceptions, use a second account only in rare cases, and never share passwords.
Parent or student logins - use dedicated limited roles when the product offers them; do not give students full inventory delete rights.

Roles and permissions (reference)