Permissions

Reports can expose sensitive information — risk analyses, audit trails, compliance status — so who can view, generate, export, and schedule 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 mainly by role. 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. A rule can also list specific user ids as an optional addition, for the occasional individual who needs access outside their role. Allow and deny together let you grant broadly and carve out exceptions precisely. Organization administrators are exempt from these rules.

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.

Four actions

Rules govern four separate actions: view, generate, export, and schedule. A rule can deny any of them, so you can let a wider audience read a report while restricting who can generate it against live data, export it, or schedule it. This keeps control over both the information and the acts of producing and distributing 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.