Access and permissions

Permissions in Strategy Hub combine two scopes: an app-level role that sets what you can do across Strategy Hub, and item-level roles that set what you can do on a single Item. Each Item also carries an Access level that decides whether your app-level role counts on it at all.

The four system roles#

The same four roles name what someone can do, whether granted across Strategy Hub or on one Item.

Role	Scope	Typical holder	What it allows
Admin	app-level	Jira site admin	Every permission, on every Item; manages workspace data
Manager	app or item	Strategy lead, Item Owner	Edit Item content, manage access, archive
Collaborator	app or item	Team member, contributor	Edit progress and comments
Viewer	app or item	Stakeholder, leadership viewer	Read-only

App-level roles are granted on the Settings → Permissions page.
Item-level roles are granted on a single Item from its Manage access dialog.
Admin is app-level only. It can’t be assigned on a single Item because it already carries every item permission.

Default access#

Most Items use Default access. When an Item’s Access level is Default, permission to see and edit it comes from three sources combined:

Your app-level role — an Admin can see and edit every Item; a Viewer can read it.
Owner auto-grant — the Item’s Owner is auto-granted Manager-level permissions on it.
Team auto-grant — members of the Item’s assigned Teams are auto-granted Collaborator-level permissions on it.

This is how most work behaves. A leadership Objective is visible to the org through everyone’s Viewer role, while the Owner and the contributing Teams get edit rights without anyone granting them by hand.

Custom access#

Switch an Item to Custom access when its content is sensitive — exec planning, performance objectives, an M&A initiative. Under Custom access, app-level roles count for nothing and the auto-grants no longer apply on their own. Only the grants you set on the Item decide who gets in. You make every change from the Item’s Manage access dialog, which offers two views: Simple for the common case and Advanced for fine-grained control. Strategy Hub keeps you on as a Manager when you lock an Item down and blocks removing its last Manager, so you can’t shut yourself out.

Tip — turn on Apply to nested items before you save to push the same access change down the whole branch. A child you don’t touch stays Default.

The simple view#

The Simple view turns access into a few switches. Turn on Make this item private to lock the Item down — its Access level becomes Custom, global Collaborators and Viewers lose access, and only the people listed below keep it. The switches beneath decide whether the convenience auto-grants still hold:

Admins and Managers can manage this item — on by default. While it’s on, anyone with an app-level Admin or Manager role keeps access.
Owner is a manager — keep the Item’s Owner as a Manager, or turn it off to drop them.
Team members are collaborators — keep the linked Teams’ members as Collaborators, or turn it off to drop them.

The Manage access dialog's Simple view, with the Make this item private switch above the Owner and Team auto-grant switches

The advanced view#

The Advanced view is for handing access to specific people and Teams. Start from a preset, then tune the individual grants:

Access preset — Default follows each person’s app-level role, Private grants only the Owner and the linked Teams, and Open lets everyone collaborate while Owners, Admins, and Managers manage.
Three tiers — everyone with access sits in one of manage, collaborate, or view, matching the Manager, Collaborator, and Viewer roles. Use Change role on a row to move someone between tiers.
Add people and teams — find a person or Team in Add people or teams, pick the tier, and choose Add access to grant it.

The Manage access dialog's Advanced view, showing the Default access preset above the people and teams who can manage or view the Item

Restricted Items#

An Item is a Restricted Item for a given person when it’s Custom-access and that person holds no grant that lets them see it.

In the tree views it appears as a stub row — its key, Type icon, and a lock marker, and nothing else. The name, value, and content stay hidden. Open it and you get a lock screen instead of the Item.
“Restricted” is always relative to the viewer. The same Item can be restricted from one teammate and fully visible to another.
Because an Admin carries every item permission, an Item is restricted from an Admin only when it’s Custom-access. That is the intended escape hatch — see Emergency access below.

A lock icon over the message "No access to this item — you don't have permission to view this item, ask item manager to grant you access"

Restricted Items registry#

An Item’s content can be hidden from an Admin, but its existence never is. The Restricted Items registry on the Settings → Data page lists every Restricted Item by key and Type, and offers an Emergency access action on each row. See Manage workspace data for the full page.

The Restricted items section of the Settings → Data page, listing Restricted Items by key and Type with a row menu that holds the Emergency access action

Emergency access#

An Admin can grant themselves Manager-level access to a Restricted Item they otherwise can’t see. This is Emergency access, and it’s what keeps Custom-access Items hidden-by-default rather than unrecoverably private. Reach it from the Emergency access action on the Item’s registry row, then confirm.

The "Grant emergency access?" confirmation, explaining that the grant gives Manager access, is recorded in the item's history, sends no notification, and does not unlock the item for other users

It is audited — the grant is recorded in the Item’s history — but quiet: no notification is sent and no justification is asked for.
It adds an ordinary Manager grant for the acting Admin on that one Item. Revoke it from the same Manage access dialog as any other grant.
It unlocks the Item for that Admin alone. It does nothing for anyone else — surgical, reversible, single-actor.

Worked examples#

A leadership Objective — keep it Default. Org-wide Viewers see it; the Owner and the assigned Strategy Team edit it.
A confidential M&A initiative — switch it to Custom. Grant Manager to the project lead and two execs. Other Admins see only the stub row, with Emergency access available if they ever need in.
A Key Result under a confidential Objective — set it to Custom too. Default access would leak the child’s name and value to anyone with an org-wide Viewer role, even while its parent stays hidden.

Strategic Items — the Access level field sits with the rest of an Item’s classification.
Manage workspace data — the Restricted Items registry and the workspace audit trail.
Configure Teams and Labels — set up the Teams whose members earn auto-granted access.