Organisations with several departments, schools or business units can host them in one Innomesh tenancy, separated by role-based access control (RBAC), or give each department its own tenancy. This article explains what a shared tenancy keeps separate, what it shares, and when each approach works best.
Key Concepts
| Concept | Description |
|---|---|
| Tenancy | A separate instance of Innomesh, with its own users, settings, data and integrations. |
| Site | A label on a room, typically a campus, department or regional office. Innomesh uses it to control which rooms a user can see and to report consumption. |
| User group | A label on users and rooms, used with sites to control access. Each user belongs to at most one user group. |
| Zone | The high-availability server cluster that runs a set of rooms. |
| Role | Sets what a user can do, and which sites and user groups they can see. See How Access Works. |
What a Shared Tenancy Keeps Separate
In a shared tenancy, site and user group access keep each department to its own rooms in these areas:
- The Hotlist, Rooms, Information and Assets pages in Innomesh Portal
- Rooms in Innomesh Room Manager, and meshIQ chat
- Global Alert History, Q-SYS global views and the Microsoft Teams Rooms device list
Some configuration can also differ per department:
- Incident rules can target a site.
- Automation policies can be filtered to a site or user group.
- Room information can use a different information template for each department.
What a Shared Tenancy Shares
Everything in this table is common to every department in the tenancy.
| Area | What is shared |
|---|---|
| Administration | Administrators see users, roles, user groups, audit logs, App Clients and Sight device passwords for every department. |
| Templates and room names | One template list, visible to every template administrator. Room names must be unique across the tenancy. |
| Alert severity rules | One rule set. Rules can target a single room, but not a site. |
| Room and asset fields | One field list. Information templates choose which room fields apply, but a field added for one department is visible to every department. |
| Asset favourites | One favourites list, which also filters the device list in Room Manager. |
| Automation policies | One list with shared maintenance windows. An unfiltered policy applies to every matching asset in the tenancy. |
| Incident rules | One list, even though each rule can target a site. |
| Ops Actions files | Files an action deploys, such as touch panel interface files, are held per tenancy, so every department’s files are visible and selectable. |
| Platform settings | Change Mode and AI Enable apply to the whole tenancy. |
| Logo and timezone | One customer logo in the Portal header and one tenant timezone. |
| Integrations | The tenancy connects to one instance of each integration, for example one ServiceNow instance. |
| Notifications | Slack, Microsoft Teams and Mattermost notifications are routed by notification type and severity, not by department. |
| Dashboards | Vitals and Insights dashboards show the whole tenancy to anyone whose role grants access to them. |
| API and data exports | The Platform API, the meshIQ MCP server and scheduled data exports return data for the whole tenancy. |
📝 Note
Keeping every department’s rules in one list takes more coordination, and raises the chance that a change made for one department affects another.
Choosing an Approach
Choose one shared tenancy when
- One team administers audiovisual (AV) systems across the departments, and administrators do not need privacy from each other.
- The departments agree one set of AV standards: templates, alert severities, and room and asset fields.
- The departments can share any platforms integrated with Innomesh, such as an IT service management (ITSM) system or collaboration and device management tools.
- The policy on AI features, and any use of Change Mode, can be agreed jointly.
- A central team needs one view of dashboards and reports across every department’s rooms.
- Staff support several departments and benefit from one sign-in and one alert list.
Choose separate tenancies when
- Each department runs its own AV operations and administrators.
- Each department keeps its own standards, templates and alert severities.
- Each department manages its own alert, incident and automation rules, without the risk of a change affecting another department.
- The departments run separate instances of the platforms they want integrated, such as ServiceNow, Microsoft 365, Zoom or device management tools.
- The departments sign in through different identity providers. A tenancy supports only one.
- The departments need different policies on AI features.
- Each department’s data exports and API access must stay with that department.
Other Considerations
- Combined view. Only a shared tenancy gives a central team dashboards and reports across every department. Views cannot be combined across tenancies.
- Single sign-on. A tenancy supports one identity provider, so departments that sign in through different identity providers need separate tenancies. One identity provider can serve several tenancies, each registered as its own SAML application. See SSO Integration using SAML2.
- Staff across departments. In a shared tenancy, staff who support several departments use one sign-in, with a role that grants access to several user groups. With separate tenancies, they sign in to each tenancy.
- Network connectivity. Innomate confirms how Innomesh connects to each department’s network during onboarding.
- Changing approach later. Room and template configuration can be exported as JSON and loaded into another tenancy, but alert history and usage data stay in the original tenancy. Choose the approach before rooms go live. See Saving a Room to JSON.