Roles & permissions
The Viewer role model — permission domains, the standard roles and what each grants, and how to assign roles and edit what a role can see.
A user holds one or more roles; the sum of their roles is their effective access. Access is deny-by-default: a user with no recognized role sees nothing, and access is only ever granted by assigning a role — explicitly by an administrator, or automatically through an IdP group→role mapping.
Roles vs. domains: a domain is a category of data (clinical, financial, and so on); a role is a named bundle of domains. You grant access by assigning roles to people, not domains directly — the domains below are what each role grants out of the box, and you can change which domains a role includes (see Editing what a role can see).
Permission domains
| Domain | Covers |
|---|---|
| CLINICAL | Patient clinical records |
| FINANCIAL | Billing and financial data |
| PAYROLL | Payroll / compensation data |
| DOCUMENTS | Stored documents, release-of-information |
| REPORTS | Generated reports |
| AUDIT | Audit logs and compliance review |
| ADMIN | User, role, and SSO administration |
The standard roles
| Role | Type | Grants access to |
|---|---|---|
| FULL_ACCESS | Primary | Clinical, financial, documents, reports. (Not payroll.) |
| RESTRICTED_ACCESS | Primary | Clinical only. Acts as the common safety default. |
| HR_PAYROLL | Primary | Payroll. |
| BILLING | Primary | Financial and reports. |
| HIM_ROI | Primary | Health Information Management / Release-of-Information (clinical, documents, reports). |
| COMPLIANCE_AUDITOR | Primary | Audit and oversight — read across clinical, financial, documents, reports plus audit. |
| ADMIN | Additive | Administration (user / role / SSO management). Layers on top of a data role. |
| NO_ACCESS | Sole | No access (suspended). Assigned automatically to new users until a role is granted; cannot be combined with any other role and cannot be edited. |
- Primary — a user's main data role. A user normally holds one.
- Additive —
ADMINonly; it layers administrative capability on top of a primary data role. - Sole —
NO_ACCESSonly; it stands alone and is the deny floor.
Assigning roles
- Manually — open Admin → Users (
/dashboard/admin/users), find the user, and assign a role. Use this for ad-hoc grants and to lift a suspension. - From your IdP groups — if you've configured a group→role mapping on the SSO connection, a user's IdP group memberships assign their roles automatically at sign-in.
Editing what a role can see (Access Controls)
- Go to Admin → Access Controls (
/dashboard/admin/roles). - The matrix shows roles as rows and data domains as columns. Toggle a cell to grant or revoke a domain for that role.
- Some changes require a short justification before they save — this is recorded for audit.
- Every change is versioned; open the history view on a role to see prior versions, who changed them, and why.
Related
- New accounts start in
NO_ACCESSuntil you assign a role — see User provisioning. - A user who "sees nothing" usually just needs a role — see Troubleshooting.
Connect single sign-on
A one-time, three-step setup to connect your identity provider to Viewer — exchange identifiers, hand over metadata, then verify and enable.
User provisioning
How Viewer decides whether someone who signs in through your IdP gets an account, and what access they start with — invite-only vs. just-in-time (JIT).