To fully benefit from the available security options, multiple settings have to be changed. This article is just an overview of the configuration. To get more details regarding any subject, follow a link to the dedicated page.
| Tip |
|---|
Keep in mind; no user can ever see anything they can't see in the connected tool (such as Jira) - those items will be greyed out. If Jira permissions don't allow a user to see or edit an issue, they won't be able to do it using the App. If a user has access only to half the issues in a Box/Program, the other half can't be viewed. This means there is no possibility of a person accidentally accessing or editing items they don't already have permission for in the external tool (such as Jira). |
| Info |
|---|
JIRA Admins always have full, unrestricted access to all Boxes and the App. |
Available User Security Roles
App Administration
You can find the detailed description here.
- App User (has access to the App - sees the App dropdown at the top. This doesn't translate into actual access to Boxes/Programs! User security roles have to be specified on Box level)
- App Admin
User Roles in Boxes
...
Contents:
|
|---|
About security roles in BigPicture
Security roles define a specific set of user privileges. They control access to the app and boxes and determine the actions that users or groups with certain roles are allowed to perform.
By using roles, you can streamline the process of managing permissions, making it easier to add, remove, or modify access rights compared to assigning permissions individually to each user. This approach becomes particularly valuable as your user base grows in size and complexity.
Additionally, user roles and permissions help safeguard the app and boxes against unintended or unauthorized changes by stakeholders.
Jira permissions in BigPicture
| Info |
|---|
Jira Admins have full and unrestricted access to all boxes and BigPicture. |
BigPicture respects Jira security settings.
It means no user (or Jira group) can view and edit data in BigPicture they are not permitted to view and edit in a connected tool, such as Jira.
In case of insufficient security permissions in Jira, the data in BigPicture is grayed out.
If Jira permissions prevent users from editing an issue, they will not be able to edit it in BigPicture.
If a user can access only part of the issues in a box, the remaining part of the scope will not be visible to them. For example, if you add several Jira projects to the scope of one box, users will see only issues from a project they are allowed to view in Jira.
Available security roles
In BigPicture, you can assign roles on the app level (global roles determining access to the app) and on the box level (roles determining access to individual boxes and box types).
Global (app-level) security roles
Global roles are assigned and managed on the Administration > Security page.
App admin (just like Jira admin, app admins have full administrative access to the app and all boxes)
App user (app users can see and open the BigPicture app on their instances and access their profile but cannot view and edit individual boxes until they are assigned a relevant role on the box level)
Box-level security roles
Box roles are assigned and managed on the box configuration > Security page (roles for the individual boxes and specific box types are managed separately).
Box Viewer
Box Editor
Box Admin
...
Sub-Box Creator
Enabling Roles
The App gives you a lot of flexibility when it comes to setting up roles, but to utilize that, you have to first enable the use of roles in general. Make sure that you have enabled the use of roles in the configuration of the App.
Access to the App
Users need access to the App itself. This is configured in App Administration (App's drop-down at the top > Administration).
There are only two types of App access:
- App Admin (gets full Administrative access to the App and all Boxes)
- App User (sees the App drop-down in the header and can access their own profile, but to see and edit Boxes, they must be assigned additional roles within Box hierarchy)
| Warning |
|---|
If a user has not been added to the App itself, they won't be able to access it. Even if they have been assigned roles within individual Boxes. |
...
Access to Boxes
Role Inheritance
...
| Info |
|---|
To access BigPicture, users first need to be assigned one of the global security roles. Otherwise, they will have no access to particular boxes, even if they were granted relevant permissions on the box level and in Jira. |
Security role inheritance
The Inheritance mode allows the sub-boxes to inherit (replicate) some of the parent box's configuration elements, including security settings. Security roles are always inherited from the upper-level boxes, starting with the root box.
For example, Program Increments (in the picture belowsub-boxes) inherit security roles from their direct parent ("OMEGA"SAFe ART), from the " Portfolio " Boxbox, and from the "Home" (root) Boxroot box.
...
| Info |
|---|
User Security roles inherited from the upper-level boxes are not listed in on the Box Configuration > Security page. They can be viewed only at on the Security page in the upper-level of the hierarchy, in the Box where they have been box where those security roles were added. |
When you create a sub-Boxesbox, the following roles are inherited:
Box Admin
Box Editor
Box Viewer
The sub-Box role of the Sub-box Creator is not inherited, as it would potentially allow users to create sub-Boxes they can't boxes they could not delete.
| Info |
|---|
In general, roles are always inherited, but depending on the Box type:
Read more about Box Type settings. |
Home (root) Box
...
Inheritance mode on the root-box level
Security roles are always inherited from upper-level Boxes - therefore, security roles granted in the Home (root) Box apply to all sub-Boxes in the hierarchy (all sub-Boxes and their children nested under the Home Box). For example, if someone is boxes. This means that the security roles granted in the root box apply to all boxes in the box hierarchy (boxes nested under the root box).
For example, if you are a Box Admin of the Home ( root ) Boxbox, they you automatically have become the same permissions in all sub-Boxes thought the hierarchy.
| Tip |
|---|
If you want to grant a user the same role in all Boxes, assign it within the Home (root) Box. It will be inherited throughout the Box hierarchy. |
Individual Box
To change the assigned security roles within a given Box, go to Box configuration > Security.
Box Type
In BigPicture 8, we have introduced Box types - a Box type is akin to a template; it allows you to define various default Box settings, including security roles.
In Box Type settings, you Box Admin in all boxes in the box hierarchy.
Box type
A box type allows you to customize various default box settings, including security settings.
On the box configuration > Security page, a Box Admin can create a security role template (grant users various roles). Thenby adding users to their respective roles. As a result, each time you create a new Box box of that type, the roles are copied from the template into and users will be replicated in your new Box. A box.
...
Individual box
When a new box is created, a Box Admin can later manage those users in Box Configuration.
Read more about Box Type settings.
Why this many settings options?
...
manage user and group access by adding or removing them from their assigned security roles within the box. They can do so on the box configuration > Security page.
Different settings options
Box Admin vs. Box Viewer (root box)
You may want some people of the users or groups in your organization to be able to view all the Boxes, boxes but not to be able to make changes to them. If you add a user as App Admin, they have full access to everything. But, if you add someone as a Viewer to the "Home" (root) Box, they can see all the Boxes and their contents but can't
By adding them as a Box Admin to the root box, they will gain full access to all boxes within the hierarchy and be able to make changes across them. That is not what you want.
Instead, add them to the Box Viewer role in the root box. This way, they will be able to view all the boxes in the box hierarchy and the contents of those boxes, but they will not be permitted to edit them.
App Admin vs. Box Admin (root box)
You may also might want someone to have Admin admin access to all Boxes, but not to the App itself. An App admin can, for example, edit Box types. If you want a person to be able to carry out all possible operations on Boxes but not change the App setup itself, making them a Box Admin of the "Home" (root) Box accomplishes exactly that. A user will see all the Boxes, can configure them, delete them, move them, etc. but won't be able to alter the App setup.
Inheritance Mode
In general, roles are always inherited, but depending on the Box boxes in your organization without allowing them to edit app settings.
To enable someone to perform all box-related operations without modifying the app configuration, assign them the Box Admin role for the root box. This will give them full visibility and control over all boxes, including the ability to configure, delete, and move them, while preventing any changes to the app setup itself.
Inheritance mode (box types)
Sub-boxes always inherit security roles from their parents but depend on the following inheritance settings of the box type:
Own with inherited: A sub-
a Boxbox inherits roles from the upper-level
Boxesboxes, but
users can also be grantedAdmins can assign additional users and roles within that particular
Boxbox.
Example
A
...
Portfolio
...
Manager
...
needs access to multiple projects
...
stored in a Portfolio box. An App Admin (or another Box Admin) can assign them a Box Admin role in the Portfolio box.
As a result, the Portfolio Manager becomes the Admin of all the projects and initiatives under the Portfolio box. When a Project Manager creates a new project under the Portfolio box, the new box automatically inherits the Portfolio Manager as the Box Admin.
Box Admins can add new users and groups and remove the existing ones in the individual boxes that belong to the Portfolio box. For instance, they can grant a Box Editor permissions to a user or group but only in a specific box (“Ongoing agile project” in the screenshots below).
In such a case, a Box Editor in the “Ongoing agile project” is the box’s own, non-inherited editor. For that reason, their role will not be inherited by another project box in the portfolio, like the “Smart house” project box.
...
Inherited only: - Admins cannot add more users to their respective roles directly in a box.
Example
Program Increments and Iterations boxes are typically used to organize tasks within the scope of the parent box. There is no need to add a separate set of users to those boxes. That’s because everyone who is meant to work on a project is already added to the
...
All those security options combined make sure you can grant users exactly the access they need.
Matching Security Roles
...
parent box.
...
Assign and match security roles
Security roles should match. If someone can edit a
...
project in Jira, make sure they
...
can also
...
edit a box with a corresponding
...
Lack of access within the App
For example, Tom is a JIRA user.
project in BigPicture. Likewise, if you assigned a user to manage a box in BigPicture as Box Editor, check if they also have the required permissions in Jira.
User was granted the required permissions in Jira but not in BigPicture’s box
Tom Anderson, in this example, is a Jira user.
...
He is an Administrator of the "Aggregation" JIRA Projectproject in Jira. 
...
In BigPicture, there is a box corresponding Boxto the “Aggregation” project. The JIRA Jira project has been added to its scope. However, Tom hasn't been granted any roles within that Box. Therefore, when Tom logs in, he can't even see the Box within the App.
Below, you can see the setup of the Box.
.png?version=1&modificationDate=1725628419769&cacheVersion=1&api=v2)
When Tom logs in, he can't find the Box.
.png?version=1&modificationDate=1725628419290&cacheVersion=1&api=v2)
Lack of access in JIRA
Sarah is an App Admin. This means she can see and manage all the Boxes and configure the App itself. However, if she tries to edit a JIRA issue and she doesn't have sufficient permissions within a JIRA project, she can't do it. In other words, permissions within JIRA limit possible user operations in the App.
For example, in JIRA, Sarah can't even browse the "Allocation Details" project. Because she is an App Admin, she can access a corresponding "Allocation Details" Box in BigPicture (and configure it); however, she can't view the tasks. She doesn't have the necessary JIRA permissions, so she can't see them in the App.
.png?version=2&modificationDate=1725628418681&cacheVersion=1&api=v2)
Cloud version of the App
Permissions
If you see the following message whilst trying to access either BigGantt or BigPicture the box's scope.
Although Tom is an App User (he can access BigPicture), he was not granted any roles in the “Aggregation” box (or any other box). As a result, when he logs in to BigPicture, he will not see any box in the Overview module on the root box level.
...
User was granted the required permissions in BigPicture but not in Jira
In the second case, the Jira Admin assigned Tom Anderson an App Admin role so that he could see and manage all the boxes in the organization and configure BigPicture.
However, although Tom can access and configure the settings of any box in the box hierarchy, he cannot edit Jira issues. That is because Tom does not have sufficient permissions in the corresponding Jira projects. In other words, Jira security permissions limit Tom’s actions in BigPicture.
...
BigPicture cloud
Permissions
If you see a message in Jira about insufficient permissions while trying to access BigPicture or BigGantt for Jira Cloud, follow the steps described in this articleon the following page: Insufficient JIRA permissions in BigPicture/BigGantt.