Multi-tenancy
Learn how to use context to implement multi-tenant notifications to support different organizations or workspaces within your application.
Multi-tenancy in Novu lets you isolate notifications for different organizations, environments, or workspaces within the same Novu project. Instead of creating separate subscribers or workflows for each tenant, you can use Contexts to define and manage tenant boundaries.
How multi-tenancy works in Novu
Multi-tenancy in Novu is built on top of Contexts, which act as lightweight tags that group notifications by logical boundaries such as tenants, workspaces, or environments.
When a notification is triggered with a tenant context, Novu automatically associates all notifications and preferences with that tenant. The same tenant context passed to the <Inbox /> filters notifications for that specific organization, ensuring users only see messages relevant to their workspace.
How to implement multi-tenancy in Novu
Implementing a multi-tenant system involves a few key steps:
Define a tenant context
A Tenant Context is a JSON object that identifies a specific tenant and can store any related data you need, such as company name, logo, or plan type.
You can create a tenant context using the Novu dashboard, API or from the <Inbox />. if it doesn’t already exist, Novu automatically creates it.
Here are ways you can pass context:
You can also manage all tenant contexts centrally from the Novu dashboard or API.
Applying tenant context in workflows
Once you’ve defined your tenant context, you can use it when triggering workflows. During workflow trigger, Novu first checks if that context already exists.
If not, Novu automatically creates it — but if it does exist, Novu reuses the existing record instead of updating it, to prevent accidental overwrites.
In this example:
- The tenant context identifies the organization (“Acme Corporation”).
- Notifications triggered with this tenant context will be isolated to that tenant’s workspace.
- The same tenant ID must be passed to the Inbox to display these notifications.
Filter the Inbox by tenant
Once your workflows are sending tenant-scoped notifications, you can filter the <Inbox /> so that each subscriber only sees notifications relevant to their tenant.
This is done by passing the same tenant context used in your workflow triggers to the <Inbox />.
In this setup:
- The <Inbox /> filters notifications based on an exact context match.
- Only notifications triggered with tenant:
{ id: 'acme-corp' }will appear in the <Inbox />. - Notifications from other tenants are automatically excluded.
Customize notification content based on tenant
With contexts, you can use tenant-level data to dynamically personalize notification content, branding, and workflow logic, all from a single workflow definition.
This eliminates the need to duplicate workflows or templates for each tenant while still keeping the experience distinct and relevant.
Using tenant data in templates
Once a tenant context is created, its data becomes accessible in all template editors (email, in-app, SMS, and push) through the {{context}} helper.
Dynamic logic per tenant
You can also use tenant context data to control conditional logic inside your workflows. For example, you may want to send certain updates only to enterprise tenants.