Introduction
A task can be in the scope of more than one Box. Below, you can find two ways of finding out if a given task is in more than one Box.
You can't see Boxes if you lack permissions. If you do not have at least viewing access to a given Box, it will not be shown to you on any list. If your access is limited, contact your administrator.
Gantt
Go to the Gantt module.
Click on a task on the Gantt timeline (don't click on the task key, as it is a link). You will see a list of all Box IDs related to a given task in a pop-up - the task is in the scope of those Boxes.
You can locate Boxes using their IDs:
The IDs function as links - they will take you to the Overview module of a given Box.
You can also use the search functionality:
In the Box switcher.
In the Overview module of the root (Home) Box.
WBS
When the WBS widget is enabled, you can see the Boxes the task is in scope of on a Jira issue page.
Make sure WBS widget is enabled.
Go to issue page in Jira.
If needed, expand the WBS widget.
Use the Box dropdown of a widget to see list of Boxes the task is in.
Does scope type matter?
The App will list all Boxes a task is in the scope of (regardless of the scope type of those Boxes).
Using the Gantt module provides you with a list of Box IDs. It doesn't provide any information on:
how those Boxes are related to each other (nested).
if the Boxes have Own or Sub scope.
WBS provides you with information on Box hierarchy:
you can see the Box tree.
All Boxes that are part of the tree path are shown.
Boxes that are a part of the structure, but don't contain the task, are greyed out.
Task in multiple Boxes
A single task cannot have different values in different Boxes. It has to be displayed identically in all Boxes.
Boxes display tasks based on field values in a connected tool. The App may show a Jira issue in two different Boxes, but it is still the same Jira issue, and it has the same field values. An assignee can't be a different person in one Box and different in another - assignee is simply a value of a Jira issue displayed in a Box.
Changing the start/end date in one Box will cause an adjustment of the task period in another Box:
Scheduling mode of a task is always the same in all Boxes:
Even settings independent from a connected tool (such as a task color) are the same in all Boxes. Task color is stored directly in the App and isn't in any way related to Jira.
Potential Scheduling Conflicts
If you are experiencing erratic task behavior, check if the task is in scope of multiple Boxes. Conflicting scheduling rules applied to a single task in different Boxes (such as task scheduling mode, WBS structure, and dependencies) can make the behavior of the App seem inexplicable:
stop you from making changes in the Box you're in
cause a seemingly strange behavior of the App
cause an indirect circular relationship
Below you can find a few simple examples of possible situations. Keep in mind, this is not an exhaustive list but is instead meant to demonstrate possible problems.
Situation: task can't be moved
In the example:
scheduling mode - auto top-down
same task has different parent tasks in two separate Boxes
Period of a child task can't be changed in ALFA Box because of restrictions imposed by a parent task in BETA Box.
Situation: task duration can't be extended
In the example:
scheduling mode - auto bottom-up
Task is a child in one Box, a parent in another Box
Task ALFA-9 can be moved without any problems, but its duration can't be extended. Additionally, changes of period of ALFA-12 result in identical period changes of ALFA-9.
Situation: dependency + parent relationship conflict
Sometimes a task may stay in a position that defies validation rules because a new validation hasn't been triggered yet. Still, if you try to move/adjust a task (or perform any other action that is a trigger), validation will happen.
Two validation rules apply in this case:
ALFA-9 is in auto bottom-up scheduling mode (child period dictates its period)
Strong ASAP dependency from ALFA-1 to ALFA-9
Behavior:
Dependency created
Moving the child task
Moving the target task of the dependency
