Meet the new BigPicture navigation
A faster, smarter, and more intuitive way to work is here. We’ve redesigned BigPicture navigation to give you a smoother experience and better access to what matters most.
→ Discover what’s new, explore key improvements, and review feature name updates on the New navigation page.
→ The rollout will happen gradually, and the previous navigation will be retired in September 2026.
Box security roles
Box security roles
Operations available to a user depend on their security roles.
Security role | Description |
|---|---|
| Users or groups with this role have all the permissions granted except for accessing the App Administration page. Sub-boxes inherit the Box Admin role. A Box Admin can:
|
Box Editor | Sub-boxes inherit the Box Editor role. A Box Editor can:
|
Box Viewer | This role is inherited when you create sub-boxes. Users or groups with this role will not have access to the box configuration. They can view the box content in a read-only way and use the export functionality. |
Sub-box Creator | The Sub-box Creator role is not inherited. Sub-Box Creator can create Project boxes as sub-boxes under a Portfolio box. Sub-box Creators cannot create a sub-box they cannot delete later. If you grant users a Sub-box Creator role on the Home (root) box level, they will be able to create their own Project boxes but will not be permitted to access or edit other boxes nested under the Home box. In the example below, a user is a Sub-box creator in the Portfolio box. This role is insufficient to grant them access to the Portfolio box itself. That is why this box is greyed out, but they can still create a sub-box under the Portfolio. The Sub-box Creator user is also a Box Admin in ALFA and OMEGA boxes, which is why they have access to those boxes. They cannot see any other boxes nested in the Portfolio if they do not have an appropriate security role assigned to them. It means that there could be several boxes nested under the Portfolio the Sub-box Creator will not see unless they have been assigned a role in each of them (or a role at an upper-level box, since security roles are inherited. If you are an Admin of a box, you are an Admin in all its sub-boxes. All roles are inherited, except the Sub-box Creator). |
Resource Admin | The Resource Admin role is effectively an extended App User role, which means that such a user:
|
Risk Management
| Box Admin | Box Editor | Box Viewer |
|---|---|---|---|
View risks within existing registers | |||
View reports | |||
Create risks | |||
Assess risks | |||
Create new risk register | |||
Edit calculations/ add new calculations | |||
Manage General settings | |||
Archive/ unarchive RRs | |||
Delete RRs |
Permissions
In addition to the Jira permissions and security settings, which the app always respects, you can grant security roles to individual users or to Jira user groups.
Creating groups requires Jira admin permissions.
The roles can be defined for each Box separately or inherited automatically when you create sub-level Boxes.
Security and access
The Box security settings can be configured only when the 'Default Roles' option is selected in the App's configuration. Otherwise, all users will be granted the highest level permissions.
To change the assigned security roles of a given Box, go to Box Configuration > Security.
Important: Only a user with a minimum Box admin security role can access and manage the Box configuration.
This configuration page will not be visible if the inheritance mode is set to "Inherited only" in the App's administration > Box types > Security.
The Inheritance mode depends on the box type. When creating a new Box, you must select a type—security settings, including the Inheritance mode and the role template, are copied.
Inheritance of roles
Security roles are always inherited from the upper-level boxes, starting from the Home (root) box. When you create a new box, it will inherit the security roles so that you do not need to assign them from scratch.
When you create sub-boxes, the following roles are inherited:
Box Admin
Box Editor
Box Viewer
The Sub-Box Creator role is not inherited, as it would allow users to create sub-boxes they could not delete.
User roles inherited from upper-level boxes are not listed in Box Configuration > Security. They can be viewed only at the upper level.
Default box type roles
When you create a new Box, security roles are copied from a Box-type role template. In the settings of each Box type, you can assign roles to users. Then, when you create a new Box, those user roles are copied. Users added based on the template are visible in the Box Configuration > Security section.
You can assign default roles in the box type configuration to save time when assigning the security roles.
Restricting access
App and Jira administrators have access to all existing boxes. Users who have no access to a particular box or are not assigned to any security role will not see the box in the Overview module and the box switcher unless a user has access to a sub-box (but not to the upper-level box). The upper-level box will be displayed as a greyed-out row (without links) to show the box structure properly:
Security roles
Roles can be assigned to individual users or entire Jira user groups.
The "Access Status" column can display two statuses:
Granted - informs that a role has been assigned to a user successfully.
No access - informs that a role has been assigned to a user, but global App permissions are missing. The user doesn't have general access to the App. To grant global permissions to the user, go to Administration > Security and add the user to AppAdmin or AppUser global permissions.
"Access Status" is shown for added users, not for groups.