Permissions
Quartz has two kinds of permission — manage (configure SLAs, calendars and fields, restricted by default) and view (see the Radar and Reports, open by default) — and every view is still scoped to the issues each user can already browse in Jira.
Two kinds of permission
Permissions in Quartz fall into two families with opposite defaults. Manage capabilities are locked down until you grant them; view capabilities are open to everyone until you deliberately restrict them. Understanding this split is the key to setting up access correctly.
| Family | Default | What it covers |
|---|---|---|
| Manage | Restricted — only Jira admins and explicitly granted groups | Creating and editing SLAs, calendars and field mappings; extending and muting goals on issues |
| View | Open — everyone may view, optionally restrictable | Opening the Radar and Reports consoles |
Jira admins always have every capability. The matrix lets you grant capabilities to non-admin groups; it cannot take anything away from a Jira administrator.
Manage capabilities
Manage capabilities are restricted by default: a group has none of them unless a Jira admin, the "Full configuration" umbrella, or an explicitly checked group grants it. Granular grants are additive.
| Capability | Lets a group… |
|---|---|
| Full configuration | The umbrella grant — everything below, and any future manage capability |
| Manage SLAs | Create, edit, clone, enable and disable SLA definitions |
| Manage calendars | Define working-hours calendars and company-wide holidays |
| Manage fields | Map SLA values onto Jira fields and run the write-back |
| Extend | Extend and mute SLA goals on individual issues |
The "Full configuration" umbrella grants every manage capability, including each granular one. A group with the umbrella does not also need the individual checkboxes.
Creating new Jira fields stays admin-only
Mapping an SLA value to an existing Jira field needs only the Manage fields capability. But creating a brand-new Jira custom field is an instance-wide operation, so it stays Jira-admin-only — a Manage fields user without admin is told to map an existing field instead. See SLA Fields for the field-mapping flow.
View capabilities
View capabilities are open by default: every user may open the Radar and Reports consoles. This is the opposite default of the manage family. An admin can optionally restrict a view to specific groups by checking them in the matrix — once any group is checked for a view, only those groups (plus Jira admins) keep access.
| Capability | Default | Restrict to… |
|---|---|---|
| View Radar | Open to everyone | Check specific groups to limit the Radar console |
| View Reports | Open to everyone | Check specific groups to limit the Reports console |
"Open" does not mean everyone sees every issue. Every Radar, Reports, Forecast and gadget scan runs as the calling user via user-scoped Jira search, so Jira itself filters results to the issues that user can already browse. Opening a view never exposes issues across projects a user has no access to.
Why "empty" means different things
The same blank state — a row with no groups checked — means opposite things depending on the family. This is deliberate, and it matches what each family is for.
| Row state | Manage capability | View capability |
|---|---|---|
| No groups checked (empty) | Restricted — only Jira admins | Open — everyone may view |
| One or more groups checked | Those groups gain the capability | The view is now limited to those groups |
If you want every team member to see the Radar and Reports, leave those rows empty — that is already open. Only check view groups when you need to narrow access.
The permission matrix
Permissions live under CONFIGURE → Permissions in the Quartz hub. The screen is a group × capability matrix and is admin-only to edit: only a Jira administrator can open and change it.
Granting a capability
Open Permissions
From the Quartz hub, go to CONFIGURE → Permissions. You must be a Jira admin to edit the matrix.
Find the capability row
Locate the manage capability you want to grant — for example Manage SLAs, or the Full configuration umbrella.
Check the group
Tick the box for each group that should hold the capability. Granular grants stack, so a group can hold several capabilities at once.
Restricting a view
Open the view row
Find the View Radar or View Reports row. While it is empty, every user can open that console.
Check the allowed groups
Tick the groups that should keep access. As soon as one group is checked, the view is limited to those groups plus Jira admins; everyone else sees a friendly no-access state.
Per-user data scoping
Whatever a user is granted, Quartz never widens their view of issue data. Every user-facing scan — Radar, Reports, Forecast, the dashboard gadget — runs as that caller, so Jira enforces issue-level visibility. Config and metadata are read with app credentials, but anything that surfaces issues is read as the user. See Security & data posture for the full read/write model.
If an admin restricts every console view away from a user, that user sees a friendly no-access state in the hub — but their per-issue SLA panel still works on issues they can open. The panel is driven by the issue context, not by console view permissions.
Advanced sections and permissions
The Advanced sections sit on top of the same model but add an edition gate. Forecast and Governance require both a configure-level grant and the Advanced edition; on Standard installs they appear locked. The AI features are Advanced-only too. Edition is separate from these group permissions — see Editions.
Permission changes are audited
Every change to the matrix is recorded to the audit log — actor, action, target and timestamp — so you can see who granted or restricted what, and when. The log is immutable and recorded in Atlassian; it is never sent anywhere.
Was this page helpful? Yes · No · Contact support