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.

Permissions outside Reports

Not every permission is a reports.view.* child. My View's myView.view, metrics.view (the Metrics catalog and per-measure drill-downs), teams.viewOwn/teams.viewAll/people.viewTeam/ people.viewAll, Security Vulnerabilities's securityVulnerabilities.view, and the On-Call Registry's onCall.view are all standalone permissions with no parent — none of them live in the Reports section, so none require reports.view. A feature only gets a reports.view.* permission if it's an actual report (a comparative/ranked panel); a live roster or risk list like On-Call or Security Vulnerabilities gets its own standalone permission and root nav item instead.

securityVulnerabilities.manageSla is the one exception with a parent, but its parent is securityVulnerabilities.view, not reports.view — it gates the SLA form on Settings → Security, separate from the page that displays the resulting breach status. Requiring .view as a prerequisite means a role can't be given the ability to set SLA policy for a page it can't otherwise see.

metrics.view and people.viewTeam/people.viewAll both gate cross-person comparative views, the same category as reports.view.engineerVelocity — which is why the Engineer template holds none of the three. My View (myView.view) is the one exception: it's always scoped to just the signed-in user, so every template grants it regardless of what else they can compare.

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.