This documentation supports releases of BMC Helix Continuous Optimization up to December 31, 2021. To view the latest version, select the version from the Product version menu.


Hierarchies represent the relationships between BMC Helix Continuous Optimization entities. Use hierarchies to perform actions such as: grouping entities for assigning access rights to users, deriving metrics from related entities, creating reports for related entities.

Relationships can be made between any two entities, subject to these rules:

  • A domain can be a parent of a system, or of a business driver, or of another domain.
  • A system can be a parent of another system.
  • A business driver can be a parent of another business driver.

For more information, see Entity relationships.

Navigating the workspace tree

The workspace tree shows all of the visible parent-child relationships that are currently valid, by representing these relationships in hierarchies nested together under a single root domain named Domains, Services & Applications.

The workspace tree displays only those relationships that are useful for organizing the workspace. These relationships are marked as visible. The Hierarchy tab of an entity shows all relationships that the entity plays a role in, whether visible or invisible.

If an entity is a child of two different entities, then the child is shown twice in the tree, once under each of its parents. Hierarchies can be nested recursively at any level, and therefore the same entity might appear multiple times in the tree at different levels.

You can modify the workspace tree under Domains, Services & Applications by moving or importing entities from one parent domain into another. Moving an entity breaks its relationship to its parent and creates a new relationship to the new parent entity. Importing an entity into a domain adds a new parent-child relationship, while keeping the existing one intact.


Importing an entity does not create a copy of it, but adds a new parent-child relationship.

Viewing systems and business drivers

Below the Domains, Services & Applications folder, the All systems and business drivers folder contains systems and business drivers that do not fit into the hierarchies under Domains, Services & Applications:

  • Newly discovered entities are those that have been created by connectors, but have not been placed inside any domain as child entities.
  • Unassigned entities are those that once had been in the hierarchies under "All Domains", but whose connectors no longer place them inside any domain as child entities; nor are they imported into another domain as child entities.
  • Dismissed entities are those that have been explicitly deleted. This folder is analogous to a "trash bin" or "recycle bin". Once the Dismissed entities folder is emptied, these entities and all of their data will be forgotten by BMC Helix Continuous Optimization.
  • Unreachable entities are those whose connectors are no longer active.

To learn about the life cycle of entities, see Life cycle and status of entities.

Modifying the hierarchy

There are two ways to modify the hierarchy by creating or breaking parent-child relationships:

  • Automatic: BMC Helix Continuous Optimization automatically creates relationships based on a hierarchy rule that is applied either regularly or every time new data is added by a connector.
  • Manual: The user manually creates or breaks a relationship between two entities, for example, by adding or removing an entity from a domain.

An example of the automatic method is a hierarchy rule that places virtual machines under their virtual host. After the activation of this rule, a newly created virtual machine is automatically inserted into the hierarchy when new data is imported. Another example is a hierarchy rule added on behalf of a connector, which always inserts a host into a particular domain that stands for an owner, every time it runs and finds the host in its data source. If the connector finds the host no longer belongs to that owner, or that the host has been removed from its data source, then its hierarchy rule breaks the relationship, and the host disappears from its parent domain.

An example of the manual method is when a user moves a system from one domain to another domain. By default, BMC Helix Continuous Optimization will break the parent-child relationship with the first domain, and create a new parent-child relationship with the second. 

If an entity is manually added as a child to a domain, then a relationship is automatically created, and the entity appears in the console workspace tree at the indicated location.
Any entity may have multiple parents, and such an entity will appear underneath each of these parents along with its own children and their children.

If an entity being automatically added to domain A by a connector is also imported into a second domain B, it takes part in two separate relationships, and the workspace tree will continue to show the entity under both domains.


You may need to mark the system as "shared".

If an entity is no longer attached as a child to any other entity in the console workspace tree, it is moved into the special Unassigned folder. If subsequently the entity becomes attached to a domain in the console workspace tree, then the entity is moved back from the Unassigned folder into the tree at the appropriate location. See Life cycle and status of entities to understand these transitions.

Viewing a hierarchy

If an entity has parents or children in the hierarchical structure, its main page shows the additional Hierarchy tab. In this tab, you will find a table that lists all parents and all children (if any) for each hierarchy in which the entity is involved. In this case, the navigation tree displays the hierarchy name as an expandable node. The available relationship types are listed in Entity types.

To navigate to the corresponding entity, click each parent or child name.

Creating a hierarchy

Additional information

Automatic hierarchies are managed from the Administrative section of the navigation panel. For more information, see Administering.

How do ETL modules update a hierarchy

When an ETL modules runs, if it needs to create or maintain relationships between domains in the workspace tree and the entities that it is creating, an "Object relationships" hierarchy rule is created and activated on its behalf. Every time the connector runs, the hierarchy rule is scheduled to run after it in order to update the relationships that the connector asserted.

The assertions that a connector makes affect the hierarchy only indirectly.

The first time the connector asserts an entity and its relationship as a child of a domain or system in the tree, the hierarchy rule attaches the entity into the tree as asserted. For subsequent runs, the hierarchy rule compares the assertions made by the connector on the previous run with the assertions made on the last run. The hierarchy rule uses this comparison to modify the console workspace tree. This logic, called delta processing, makes the effect of automatic relationship assertions indirect.

  • For every relationship asserted both on the previous and the last run, the hierarchy rule makes no change to the hierarchy in the console workspace tree.
  • For every relationship asserted on the previous run but not asserted on the last run (presumably because the connector failed to find the entity or the relationship in its data source), the hierarchy rule breaks the relationship in the tree. If a relationship is broken and the child entity is no longer connected to any other entity in the console workspace tree, then the hierarchy rule disconnects the child entity from the tree and places it in the Unassigned folder.
  • If a subsequent run of the connector rediscovers and re-asserts the entity and its relationship, then the hierarchy rule reinstates the relationship, and the entity reappears in the tree as a child of the domain. If the entity had previously been added to the Unassigned folder, it now disappears out of that folder.

To understand how relationships are represented in the database, see Entity relationships.

If an ETL has completed running, it has only loaded its data into the stage area. If the ETL has also asserted relationships for the hierarchy, then this hierarchy is not built until the hierarchy rule actually runs.

Interfering with automatically updated relationships

If an entity E is moved from domain A, where it is being placed by a connector as a child, to a different domain B, then its relationship with domain A is broken. This break interferes with an automatic update of the same A-E relationship.

The automatic updates made by the connector will not revive this particular relationship. Because the connector will continue to assert the same relationship on every run, delta processing will not detect any change, and this relationship will remain broken.

If some unrelated cause in the connector's data source causes the entity to not be updated by a run of the connector, then delta processing detects that the relationship with domain A is broken, but because the tree already shows this relationship as broken, the hierarchy rule makes no changes. On the next run of the connector that re-asserts the relationship, its hierarchy rule will find a second delta, this time to recreate the relationship with A. From that point on, the entity will continue to appear as a child of both A and B.


ETLs often drop some entities temporarily and then re-assert them the next day. In this case, the dropped entities, if they are not duplicated anywhere in the tree, will automatically land in the Unassigned folder during the missing period.


Avoid adding or removing entities manually to domains to which they are also automatically being added by a connector and its hierarchy rule. The results of these conflicting actions will depend upon timing, data source changes, and delta processing.

Was this page helpful? Yes No Submitting... Thank you