You can nest service containers to build a logical hierarchy that suits your business requirements. For example, you might have critical services for different organizations within an organization, all contained within a Critical Services container.
Note the following when viewing or creating a hierarchy of service containers:
Only device containers can contain other containers. So test containers can never have child containers.
With device containers, you have to drill into a device to see tests, and even then the tests you see are associated only with that selected device.
With test containers, you immediately see selected tests for selected devices in a single, merged list.
The status of each child container is reported to its parent, all the way up the hierarchy to the top level. By default, each parent container adopts the highest ranking severity status of any of its devices, tests or child containers. (This can be modified; see Controlling the Severity of Containers.)
Critical (Most Severe)
Warning
Unreachable
Unknown
Ok
Suspended
Unconfigured (least severe)
Your view of the container hierarchy depends on your level of access. The image above shows an example of what a superuser might see when viewing the Status > Containers page.
A superuser sees all the containers created by the SuperUsers group, all the containers created by any admin group, and all the containers created by any organization user.
An admin group user sees only the containers in his own admin group and any of the organization he manages.
An organization user sees only the containers in his or her own organization.
