Roles and permissions

Role and scope are separate

A role decides what a user may do; scope decides which records the role applies to. Two facility managers hold the same role with different facility assignments, and neither can reach a facility outside their assignment. The roles below are the roles the product actually implements — none has been renamed or added for documentation purposes.

Permission matrix

Note: "View / Create / Update / Submit in scope" means the role may perform those actions only on the organizations and facilities it is assigned to. "Not permitted" is enforced server-side, not by hiding a control.

How authorization is enforced

• Roles are stored in a dedicated role table, never on a user or profile record, so a user cannot change their own role by editing their profile.
• Every read and write is constrained to the signed-in user's organization and facility assignments in the database layer; changing a URL or calling the API directly does not widen access.
• Oversight roles are read-only for census data: census writes are refused server-side for state roles.
• Administrative roles must complete multi-factor enrolment before administrative surfaces become usable; an unenrolled account is held at the enrolment step rather than partially admitted.

Note: The detailed row-level policy implementation is a controlled document released under a qualified security review. Publishing policy predicates would add nothing to an evaluation and would enlarge the attack surface.

A separate platform administration role exists

OCRS also implements a platform administrator used to operate the service itself. It is out of scope for customer role administration, is not assignable by a customer, and its actions are written to the audit record like any other.