Tenant

Multy-Tenancy

Multy-Tenancy is an architectural tool that is relevant when one platform serves many customers. They are unaware of each other and their data is kept completely separate. The separation into a clean customer view is done using a tenant object.

Note that the tenant works independently of the object permissions.

The tenant can be defined as a user or customer wide scope containing custom masterdata objects.
When a user creates their own instances of a masterdata object such as status, type, category, product or manufacturer etc., the record will be linked to that user’s tenant.
This way we can ensure, that only members of that tenant will see their customised options in their dropdown lists.

Private tenant

Creating a masterdata object requires including your private tenant in the request. The request user has to have the tenant_admin role on it. Learn more about user roles in the section below. The benefit of having a tenant architecture is that it allows all customers to add their own masterdata options in addition to the built in ones.

To create your own tenant, you can go to
Netilion ID > Profile > Administration > Tenants.

Alternatively to the UI, the Netilion API offers tenant specific endpoints to create and maintain. See the API documentation for more details. .

The graph shows all mandatory objects (blue) required to create an asset. You can either use an official product and create an asset from it, or you can create your own product and company data.
In this case the tenant comes into play. The company and product have to be associated with it, as well as the asset when you create it from your own product.

See all available tenant-scoped objects in the Netilion Objects section.

User roles

When you create a private tenant in the UI of Netilion ID or via API the request user receives the tenant_admin role for it. Check out our code examples.

The following two user roles are relevant when using your own tenant and tenant scoped masterdata:

Tenant User
A user with tenant_user role can read and apply tenant specific masterdata to objects.

Tenant Admin
A user with the tenant_admin role can assign other users to be admins or tenant_users and apply the tenant to masterdata objects.

Maintain user roles

Netilion ID has a UI to maintain tenant related user roles.
When you are logged in to Netilion ID click on Administration > Tenant and navigate to your tenant’s details page - there you can maintain tenant_admins and tenant_users.

Tenant vs permission

Having a tenant architecture combined with object permissions can be confusing. The short explanation is:

Permissions regulate single resource access.
Tenants regulate masterdata catalogues.

User groups serve to give permissions to many at once.
User roles serve to share a tenant between users.

On the right are the permissions, that regulates access of a resource for a user (or user group) through a permission to an object like an asset.

On the left is the tenant side. Here the user needs a user role refering to a tenant (tenant_user or tenant_admin). The tenant groups custom masterdata like a special status. To assign that to the asset the user needs the user role and the asset needs the link to the same tenant.