Tenant Hierarchy and Blueprint Inheritance

Explore the ways that Visier defines tenant relationships in a hierarchy.

The following table defines key terms for understanding Visier's tenant hierarchy.

Term	Definition
Administrating tenant	A tenant that manages one or more analytic tenants. Administrating tenants are capable of creating further analytic tenants and navigating to existing analytic tenants to support them.
Analytic tenant	A tenant that represents an organization associated with an instance of Visier that has loaded a solution such as Visier People. Each tenant has a unique code and a user-friendly display name.
Blueprint	A complete set of content. All blueprints originate from the Visier blueprint. A blueprint encapsulates all the available content objects, including guidebooks, analyses, metrics, and concepts.
Hierarchy	A system used to arrange and define the relationship between members.

Visier's tenant hierarchy structure

Visier models tenant relationships in two ways:

Tenant management hierarchy: Grants overarching ownership to one tenant for several analytic tenants.
Content hierarchy: Shares the administrating tenant’s blueprint with other tenants.

These two structures have differing uses and overlap throughout the onboarding process and tenant maintenance lifecycle.

Tenant management hierarchy

The tenant management hierarchy is about tenant creation, tenant management, and user access definition. User access defines who can access a tenant at which point and for how long.

In this hierarchy, each administrating tenant has a set of analytic tenants. Each analytic tenant has administrators that can authorize access to that tenant.

Visier is the root of the hierarchy and branches out into an administrating tenants level. Administrating tenants are capable of creating further analytic tenants.

Note: Each tenant can only give rights to other tenants of an equal or lesser value to their own level.

Example: Tenant management hierarchy

Administrating tenants: Hamilton and Jupiter are administrating tenants and support their associated analytic tenants.
Analytic tenants: Example Inc., Callisto, Io, and any other tenants at this level are analytic tenants.

Content hierarchy

The content hierarchy is about content inheritance, content creation, and content consumption in the tenants. This hierarchy is blueprint-based—an administrating tenant shares its content and the analytic tenants inherit that blueprint.

Today, each administrating tenant begins with the Visier blueprint. You can then make changes to the blueprint at the administrating tenant level and push those changes to your analytic tenants by publishing to production within the administrating tenant. For more information about publishing changes, see Publish Project Changes.

At the analytic tenant level, changes can be made to each tenant's blueprint to override the inherited blueprint or create new customized content within the analytic tenant.

Caution: We don't recommend that Embedded Partner Administrators make changes at the analytic tenant blueprint level because you must maintain those modifications across time and it may become different to manage.

The analytic tenant's blueprint can be one of three types:

Default: An exact copy of the administrating tenant's blueprint.
Tenant override: A modified version of the administrating tenant's blueprint.
Customized: An administrating tenant's blueprint with net new objects.

Example: Content hierarchy

In the following image, three blueprints are shown:

Visier Core Blueprint: The Visier blueprint that all blueprints originate from. It contains all the base content objects that every tenant receives.
Your Blueprint: The administrating tenant blueprint that pushes changes to your analytic tenants. Any changes made to this blueprint are copied to your analytic tenants.
Your Customer's Blueprint: The analytic tenant blueprint that your end users see while conducting analysis in Visier. Any changes made to this blueprint only persist within that analytic tenant.

In the above image, there are some modifications that differentiate each blueprint type.

The following table describes the blueprint inheritance taking place across these blueprints.

Blueprint	Notes
Visier Core Blueprint	Contains all the content that is inherited by every administrating and analytic tenant.
Your Blueprint	Contains all the content from the preceding blueprint with some changes. The Absence_Reason dimension member changed from "SCK" to "Sick". A new concept was created called Non-Seasonal.
Your Customer's Blueprint	Contains all the content from the administrating tenant's blueprint with additional modifications. The Absence_Reason dimension gained an additional member called "Unwell".

Best practices

During initial onboarding, we recommend that you set up users and tenant access in your analytic tenants first before moving on to content setup within the solution. Content setup includes defining blueprint content such as guidebooks, analyses, subjects, properties, and metrics. However, an analytic tenant may already have content due to blueprint inheritance, allowing you to configure content before setting up users.

Note: These hierarchies are continuous throughout the tenant's lifecycle because more tenants and users may need to be added, removed, and configured at any time and the production of blueprint content is frequently updated and improved.