Skip to main content

​
Understanding tenants

Tenants (previously named as brands) represents a segment that user belongs to. It can be organizations, teams within an organization, projects, workspaces, subsidiary companies or different product lines in the same business, and so on. Tenants in SuprSend are used to design custom notification experience based on these segments.

​
Possible customizations and usage

Each tenant can have its own properties, preferences, vendors, and custom template design or content. You can use tenants to:
  • White-label notifications — Send notifications to your customers’ end users with their branding, colors, logos, and social links. One shared template; $brand.* variables are replaced with tenant-specific values at runtime.
  • Set admin-level preference defaults — Define default notification preferences at the account or project level that apply to all users within it.
  • Per-tenant user preferences — Let users have different notification preferences for each tenant they belong to. For example, a user might mute Slack notifications for one project but keep them on for another. Just pass tenant_id while saving per-tenant preferences for a user.
  • Route via tenant vendors — Send notifications through your customers’ own email domain, SMS sender ID, or WhatsApp provider instead of yours. If no tenant vendor is set, the default vendor is used.
  • Scope in-app feeds — Show a separate notification inbox per tenant so users only see what’s relevant to their current context. Messages are tagged with tenant_id; badge counts are scoped automatically.
  • Block notification categories — Block certain paid features / modules or channels for a tenant as they have not subscribed to them.
  • Custom template content — Tenants can modify template content or have the option to add new notifications for their end users. (coming soon)
  • Per-tenant user properties or channel identities — Users can have different roles per project or have different push tokens for different applications of your product. (coming soon)
A single user can belong to multiple tenants and have different notification preferences for each.
Every workspace includes a default tenant that represents your own organization. If no tenant_id is passed in a workflow or event trigger, the default tenant’s properties are applied.

​
How tenants work

By default, tenancy is a trigger-time concept. You pass tenant_id at trigger time and SuprSend applies that tenant’s configuration at runtime to your notifications. When a workflow is triggered with a tenant_id, SuprSend will:
  1. Resolve the tenant’s branding properties and replace $tenant.* variable in workflows or $brand.* variable in your templates with tenant properties.
  2. Evaluate tenant-level admin preferences and default preference settings.
  3. Apply per-user, per-tenant preferences if the user has them set for that tenant.
  4. Route the notification through the tenant’s configured vendor, falling back to the default vendor if none is set. If no tenant vendor is set, the default vendor is used.
  5. Tag the message with the tenant_id so in-app inbox feeds can be scoped per tenant.

​
Real-world examples

Multi-tenant B2B2X applications

You send notifications to your customers’ end users — each customer wants their own branding and vendors(email domain, SMS sender ID, etc.).In SuprSend: Each customer is a tenant. Store their logo, colors, and social links as tenant properties. Override tenant vendors to send from their email domain, SMS sender ID, or WhatsApp number.

Admin preferences in SaaS Applications

You are a SAAS product and your customers’ admins want to control which notifications reach their internal team, on which channels and which categories are relevant to which roles in their organization.In SuprSend: Each customer org is a tenant. Admins set tenant default preferences to control categories and channels. Use tags on categories to map to roles, then filter what each user sees based on their role.

Project Management App with per-project preference settings

Your app has multi-level preference settings: global preferences, project-level defaults, and per-user overrides. Preferences cascade: global → project → user.In SuprSend: Each customer will be mapped to workspaces. Global Preferences are set as category level defaults. Each project is a tenant. Set category-level defaults as tenant preferences — they cascade down to users within that project. Users can then override with their own per-tenant preferences.

Multiple apps with per-app user identities

Your company has multiple product lines and the same user has different push tokens, Slack tokens, or email addresses across each app. Notifications need to route to the right identity for the right app.In SuprSend: Each app or product line is a tenant. Store tenant-specific channel identities (push tokens, Slack tokens, email) per user so notifications always deliver to the correct app. This feature is coming soon.

​
FAQ

Not necessarily. You can simply pass tenant_id at trigger time and SuprSend will apply that tenant’s configuration.
Right now, there is no explicit relation between a user and a tenant. Tenant is a trigger-time concept, which applies per-tenant user preferences, tenant specific branding or vendor routing at the time of sending. We’re working on a feature to allow users to be associated with multiple tenants. Here, user’s channel identities or properties can be different for each tenant.
The default tenant is used. Every workspace has one, representing your organization’s own branding and settings.
No. You can create as many tenants as your application requires.
You can, but it’s usually not needed. Use $tenant.* variables, per-tenant preferences, and step conditions to customize behavior within a single shared workflow. This keeps your notification logic manageable as you scale.
Use separate workspaces instead of tenants. Workspaces provide full isolation of users, workflows, templates, vendors and other data points.
No. Passing tenant_id in a workflow trigger does not send the notification to all users in that tenant. It only applies that tenant’s configuration (branding, preferences, vendors) to the notification. You still need to specify the recipients explicitly in your trigger call.
Yes. You can update tenant properties (logo, colors, social links, and any custom properties) at any time via the dashboard, SDKs, or API. Use $brand.<property> variables in your templates to render them dynamically. See Tenant Templates for details.
Multi-tenancy is available on enterprise plan and as add-on for business plan.
The inbox can be scoped to a single tenant using tenantId. For further filtering within a tenant (e.g., by project or asset type), you can pass tags in your Inbox template and filter the feed on your frontend using store filters.

​
Next steps

Tenant Quick Start

Create a tenant and send your first tenant-scoped notification.

Tenant Templates

Use tenant variables and pre-built components in your templates to customize the look and feel of your notifications per-tenant.

Tenant Workflows

Trigger workflows for a tenant to apply tenant level customization in notifications.

Tenant Preferences

Set admin controls and default opt-in/opt-out per tenant.

Tenant Vendors

Route notifications through each tenant’s own email/SMS providers.