Some large customers may require a hierarchy of tenants on the platform (i.e. a tree of multiple enterprises). These tenants can have their own scope hierarchy with the customer's scope and their departments, and their scopes and sub-departments, and so on, in scopes underneath the customer's scope. An example of this would be customer that is a chain of retail stores with a head office and regional offices, as well as the stores themselves. The head office may manage the regional offices, and the regional offices may manage the stores.
The following diagram shows an example of a scope hierarchy.
A user with the scope "National1" would manage the users of "Nat1 Reseller 1" to "Nat1 Reseller N". And they could also share templates and blueprints with users in the scopes beneath their scope, which would be "N1 Reseller1" and "N1R1Ent1".
To create this structure, first create the "National1" scope and add the enterprises (Nat 1 Reseller 1"...). Then create the next scope "N1 Reseller1" and set its parent scope as "National1". Then add the enterprises ("N1R1 Ent1 IT team"...). And so on.
Note that it is possible that a customer's administrator will not need to have their own enterprise in scope. In this case they will still be able to access the enterprise's Apps library but they won't be able to edit the enterprise's public cloud credentials or users.
The enterprise at the top of the hierarchy will be the key node for data aggregation. In the above example, National 1 would be a key node.
To mark the key node, edit the tenant that represents the head office or equivalent, at the top of the scope hierarchy, and set its scope as the default scope for the enterprise. Then select the Key node option.
This tenant will be marked with a (K) in the tenant list, indicating that the enterprise is a key node.