Permissions

Reports can expose sensitive information — risk analyses, audit trails, compliance status — so who can run and see them is controlled. Report permissions govern access by role, so the right people get the reports they need and others don’t.

Role-based access

Report access is granted by role rather than by naming individuals. Each report or report category carries allowed roles and, where needed, denied roles, so access stays consistent as your team changes — give someone a role and they get the report access that goes with it. Allow and deny together let you grant broadly and carve out exceptions precisely.

Scope: category or specific report

Permissions can be set at two scopes. A category scope applies a rule to a whole class of reports at once — convenient when a type of report should be available to the same audience. A specific report scope targets a single report, for the cases where one report needs tighter or looser access than its peers. You use the broad scope for the common case and the narrow one for the exceptions.

Run and view

Permissions distinguish who can produce a report from who can simply see its output, so you can let a wider audience read a report while restricting who can run it against live data. This keeps control over both the information and the act of generating it.

Part of the same access model

Report permissions work alongside the rest of the platform’s access control — project roles and module access — so a person’s reach into reporting is consistent with their reach into the underlying records. The broader access-control model is covered in the Administration and Identity Portal sections.