In general, information on Security settings can be found on the following pages:

  • Box Types - you are on this page - it contains information on configuring the default Security settings that work as a template when you create new Boxes and the Inheritance mode.
  • Global Roles - this page explains App Administration settings and how access to the App is granted to, for example, Jira users.
  • Box configuration - you are on this page. It explains what roles are available within the App and how to change them for an individual Box.
  • Configuration of the App - this page gives you information on how to activate/deactivate the use of roles within the App.
  • Security - this page explains the impact of setting up security Roles for the Home (root) Box and lists available roles.

In this section, you can configure default security roles and select an Inheritance mode. Those settings apply to all Boxes of a given type.

Security roles grant access to view and edit Boxes (their content, Box configuration, and sub-Box creation).

Access to a Box is based on:

  • Global roles defined in App Administration (application access settings - if a user isn't added to the App itself, they won't be able to access any Boxes because they won't even see the App's tab at the top)
  • Default roles specified for a Box type 
  • Roles configured for an individual Box
  • Roles inherited from upper-level Boxes

Keep in mind:

  • A "Box type" contains the default settings applicable to multiple Boxes (all Boxes of a given type). Those settings are adjusted in Box type administration.
  • Box configuration refers to the settings of a single, individual Box. They are dependent on the "Box type" settings. 

Security and access

  • Only users with the App admin security role can manage Box types and access Administration.
  • Access:

    • Click the "wrenchicon at the top right and select "Box types" from the drop-down list.
    • Click a Box type name to select it and open its settings.
    • On the left, go to Security > Basics tab.

Inheritance mode

There are two available Inheritance modes:

  • Own with inherited
  • Inherited only

In the case of security roles, there is no "Own" Inheritance mode - security roles are always inherited from an upper-level Box/es. This means you don't have to configure roles every time a new Box is created or moved in the Box hierarchy; you will never encounter a situation in which users of a Box don't have access to its sub-Boxes (such as Project Increments and Iterations). To learn more about this functionality, go to the Inheritance mode page. 

Assuming the inheritance mode is set to "Own with inherited," roles are inherited from upper-levels, but a Box Admin can additionally assign roles in Box configuration > Security section.

Select the "Inherited only" mode when you don't want anyone to make changes to user roles. The Security tab is hidden. Remember that the Inherited users and their roles are not displayed in a Box.  

Changing the Inheritance mode of a Box type impacts all Boxes of a given type (both existing and newly created). Changing the mode from "Own with inherited" to "Inherited only" overrides the setup of an individual Box - if a Box had a unique role assignment, it would be replaced with the setup of the upper-level Box. Reverting to "Own with inherited" restores the previously assigned roles. In the "Inherited only" mode, the Security tab of an individual Box is hidden (you can't access it in Box configuration).

Inherited security roles

Inherited security roles are not displayed on the Box configuration > Security page (even if the page is not hidden).

To know what user roles have been inherited but aren't being displayed, you have to check the upper levels of the hierarchy (technically, that would include all parent Boxes up to the root level)

For example, if Cassandra is a Box editor for "Date Filtering," she is also automatically a Box editor for "Month1" and "Week1". In the example below, "Week1" inherits security roles from "Month1", "Date Filtering," and "Home" Boxes.

For example, "alfa" is an Editor in the "New Portfolio" Box.

TS-37 is nested under the "New Portfolio."

In TS-37, "alfa" isn't visible on the user list in Box Configuration, even though user roles are inherited, which makes "alfa" an Editor in TS-37 Box.

Default security roles assignment

The permission template defines the default security configuration for all Boxes of a given type. Suppose Inheritance mode allows it (the inheritance mode is "Own with inherited"). In that case, a Box Admin can later change the assigned security roles of an individual Box in Box configuration > Security. 

For example, Calvin is a member of jira-developers group (a user group defined in JIRA). The entire group has been added under the "Box Editor" user category to a "Program" type. Every time a new Box of that type is created, all members of jira-developers group are automatically granted admin access to a Box. Calvin is effectively an editor in any Box of "Program" type that gets created. 

Sam has just created a new Box ("Expansion Project") using the "Program" type. He automatically became an admin of his Box. Sam was going through Configuration to adjust settings and decided he didn't want Jira-developers to have any access to his Box, so he deleted the whole group. Calvin contacted him to request viewer access since he won't be making any changes but needs to see how the project progresses. Sam has added Calvin as a viewer.

Changing the template (default security roles) affects Boxes you create from that point on only. Existing Boxes are not affected.

Restricting access

App and Jira administrators have access to all existing Boxes. Users who lack access to a particular Box or, in other words, are not assigned to any security role, will not see the Box in the Overview module an in 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.

Box Admin

Users or groups with this role have all the permissions granted, except for accessing the App's Administration page.

Sub-Boxes inherit the Box Admin role.

As a Box Admin, you can:

Besides editing the Box content as described in the Box editor role, you can change the Box configuration settings as a Box Admin.

Due to the Inheritance mode, some Box configuration settings might be disabled or hidden. To change the inheritance mode.

Box Editor

Sub-Boxes inherit this role. With this role, you 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. However, they can view the Box content in a 'read-only' way and use the export functionality.

Sub-Box Creator

Use it to, for example, let users create Project Boxes as Sub-Box to a Portfolio Box.

This role is not inherited.


  • Only a Box admin can create a sub-Box using a Box type with "Inherited only" security mode.
  • You cannot create a sub-Box if later on you won't be able to delete it.

For example, Angela has two roles in the AGILE project Box (editor + sub-Box creator). She tries to add an Iteration - she can't do it if the security mode of the "Iteration" Box type is set up as "Inherited only." Adding a sub-Box with "Inherited only" security mode means no new roles are granted for a sub-Box (a sub-Box admin can't be added during the creation process). She wouldn't be able to delete a sub-Box. Therefore, she cannot create a sub-Box.

If the "Iteration" Box type has the "Own with Inherited" security mode selected, she can create a sub-Box, because she will automatically become its admin. She can later delete it.

When Tom, a Box admin of the AGILE Box, tries to create a sub-Box, the security mode of the "Iteration" Box type doesn't restrict him. Even if a new Iteration will have the "Inherited only" mode selected for security, he can always delete a sub-Box, because he is the AGILE Box admin, which automatically makes him a sub-Box admin.

Recommended use:

You can grant users a sub-Box creator role on the Home (root) Box level. As a result, they will be able to create their own Project Boxes but won't be able to access or edit other Boxes nested in the Home Box. Sub-Box creators can then use Box types with the "Own with inherited" security mode to set up new Boxes. Then, when they create a Box, they automatically become its admin.

Resource Admin

The Resource Admin role is effectively an extended App User role, which means that such a user:

  • has basic access to the App (can access their user profile and sees the App dropdown in the header)
  • can access Boxes based on individual Box security settings - does not receive access to all Boxes automatically like App Admin
  • additionally is allowed to administer resource-related global configuration (Administration>Resources page with all subpages, no access to Box types, Security)
  • cannot access App configuration, unless the User is hostplatform Admin at the same time.