Tenancies are individual instances of Advance within your Advance deployment. Tenancies are separate from one another: they have their own databases, configuration settings, allocated users, templates, work groups, and so on. This enables you to organize and separate the data for different areas of an organization. For example, a department within your organization may have their own tenancy, which other departments do not have permission to access. This is possible because users that can access one tenancy cannot automatically access another tenancy. In this way, you can define broad areas of user access in Advance.
In this topic Hide
Tenancies are managed using the Advance root application. Logging into this application provides you with a user interface to manage the tenancies and Site Administrators in your Advance deployment. Only Root Administrators can create and edit tenancies.
There are two types of tenancy in Advance. The type of tenancy selected determines how users authenticate with Advance. The tenancy types are:
The tenancy type is selected during tenancy creation. It cannot be changed after the tenancy is created.
Site Administrators are users with permissions to create, edit, and delete resources inside tenancies. The resources they can administer include:
A Root Administrator can create, edit, and delete Site Administrators in the Advance root application.
Each tenancy has its own database containing data specific to that tenancy. This includes data for work groups, templates, assembled documents, and so on. By default, tenancy databases are named using the format HDAdvance{tenancy}, where the tenancy moniker set when creating the database replace the {tenancy} placeholder. When installing Advance, the default format of databases names can be customized by changing the ApiSiteSettings.ConnectionStrings.TenancyDefaults setting in the Advance installer configuration settings file.
When you create a tenancy, you can select where you want Advance to create the database. You have the following options:
The Same as root option should be suitable for the majority of tenancies. The Customer specific option is recommended when it is necessary to separate the tenancy data from the root data. For example, if it is necessary to store tenancy data in a particular country.
After a tenancy is created, you must activate the tenancy it to make it available to users. If a tenancy is not activated, users may not log into the tenancy.
You can also deactivate a tenancy to make it unavailable to users. Deactivating a tenancy does not delete it: all tenancy data is retained. This includes databases, configuration settings, users, documents, and so on. You can re-activate a tenancy at any time.