Multitenancy allows separate entities - or tenants - to coexist on a single instance of the platform. Each tenant is a group of users who share common access with specific privileges to the software without being able to interact (or interrupt) the other tenants, their users, their related activities and their content
If you have no use for multitenancy, deploy Pyramid using the single default tenant created in the system at the product's initialization. The settings for the tenant are fairly irrelevant and will not impact the application.
Note that hiding or showing the group folder is still operational in a single tenant deployment.
By using multiple tenants in Pyramid, admins can more easily segment the applications users, roles, profiles, licenses and content into discrete manageable units.
- From the end-users' perspective, a multitenant environment has little impact, as they are typically limited to the rights and access of roles which is the primary mechanism for governing the application and its content.
- For admins, however, there are tremendous benefits from using multiple tenants: enterprise admins can delegate tenant management to 'domain admins', who can freely manage all the users, roles, data sources, profiles, logs and licensing within their tenant domains.
Examples of multitenant deployments include:
- SaaS providers offering data analytic solutions from a single instance with multiple customers: Each customer would be a separate tenant.
- Large organizations that have multiple departments sharing a single instance : Each department would be a separate tenant.
Multi-tenancy is disabled by default. It must be enabled in the multitenancy page first. Once enabled, use the tenant editor to create multiple tenancies within the platform - this capability is limited to enterprise admins only. The multitenancy options allow for a variety of choices including "cross-tenancy" options.
Click the Add Tenant button to add a new tenant to the system. For each tenant , provide:
- Tenant Name: this the name as it appears throughout the system
- Total Viewer Seats:: set the initial number of seat licenses that will be allocated to this tenancy for Viewer licenses.
- Total Pro Seats:: set the initial number of seat licenses that will be allocated to this tenancy for Pro licenses.
- Default Theme: set the default theme that will be used for this tenant. If not set, the system default theme will be used instead.
- Default DS/ML Server: set the default AI server that will be used to process Python, R and NLQ requests from tenant users.
- User Defaults: set which user defaults definition will be used as the default "package" for all users within the tenancy.
- Default Page Size: set the default paper size that will be used.
- First Workday: set the first weekly working day for scheduling.
- Show Group Folder: set whether this tenant will be able to use the shared work group folder feature.
- Allow end users to create webhook channels: let end users add new Webhook channels for distribution of publications, alerts, and subscriptions.
Note that private and public folders are always on regardless of the tenant and its roles.
Once a tenant is created, all users, roles, profiles and data sources added subsequently to the platform, can be added to the existing platform tenants in the relevant editors.
- Any user, attached to a given tenant, elevated to the role of domain admin becomes a domain admin for that tenancy.
- Enterprise admins can change the license allocations to specific tenants after the tenant is created if edits are required.
All logs are tracked by tenant. This allows domain admins to review system logs within their domains without seeing the details of other tenants.