Granular Permissions

Beyond the coarse reports.view toggle (which just gates the Reports section and nav link), each individual report has its own permission key — reports.view.engineerVelocity, reports.view.serviceRepoHealth, reports.view.kanbanFlow, and so on.

Parent and child permissions

A report-specific permission always requires its parent (reports.view) to also be granted — that's a prerequisite, not an implication. Granting reports.view on its own does not automatically unlock every report; each one still has to be enabled individually. This is what lets a role like Team Lead hold reports.view while only exposing Kanban Flow, Repo Health and Code Review Health, not the full report library.

If you try to save a role with a child permission enabled but its parent missing, the role editor blocks the save with an explanation of which parent is required.

Team-scoped visibility

Separately from report access, teams.viewOwn vs. teams.viewAll controls whose data a report shows. Someone with reports.view.engineerVelocity and teams.viewOwn sees Engineer Velocity numbers for their own team only; the same permission paired with teams.viewAll sees the whole org. This is why Director and Engineering Manager roles can share a report permission but see very different amounts of data.

Building a custom role

From Settings → Roles, use Add role to start from scratch, or Add from template to start from one of the four default templates and adjust from there. Either way, the editor groups report permissions under their parent so the prerequisite relationship stays visible while you're building the role, not just at save time.