Skip to main content

​
Understanding tenants

Tenants (previously named as brands) represents a segment that a 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 preference categories - Block certain paid features / modules or channels for a tenant as they have not subscribed to them.
  • Custom template content per tenant - Go beyond variable substitution and give a tenant its own template content, layout, or channels. Create a template variant with a tenant_id condition — SuprSend picks the matching variant at send time and falls back to the default template for tenants without one.
  • Per-tenant user properties or channel identities - Users can have different roles per project or different push tokens, Slack tokens, or emails per app. Set per-tenant overrides on top of the user’s global profile; SuprSend merges them at send time.
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 layers the tenant’s configuration onto the send:
  1. Select the template variant whose condition matches the tenant_id, falling back to the default template if no variant matches — this is how a tenant gets its own content, layout, or channels rather than only variable substitution.
  2. Resolve the tenant’s branding properties and replace $tenant.* variables in workflows or $brand.* variables in your templates with tenant properties.
  3. Evaluate tenant-level admin preferences and default preference settings.
  4. Apply per-user, per-tenant preferences if the user has them set for that tenant.
  5. Shallow-merge the recipient’s per-tenant user profile on top of their global profile — per-tenant channel identities (push tokens, Slack tokens, email) and properties (role, plan) win for this send.
  6. 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.
  7. 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. Use user-tenant mapping to store tenant-specific channel identities (push tokens, Slack tokens, email) and properties per user, so notifications always deliver to the correct app.

​
FAQ

Not necessarily. You can simply pass tenant_id at trigger time and SuprSend will apply that tenant’s configuration.
Yes. With user-tenant mapping, you can associate a single distinct_id with any number of tenants and store a different set of properties and channel identities per tenant. At send time, SuprSend shallow-merges the user’s global profile with the per-tenant override for the triggering tenant_id. Workspaces can also be set to exclusive mode to restrict a user to at most one 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.
Yes. Use template variants with a tenant_id condition to give a tenant its own subject line, body, layout, or even a different set of channels enabled — anything variable substitution alone can’t cover. At send time, SuprSend picks the variant whose condition matches the trigger’s tenant_id; tenants without a matching variant fall through to the default template.
Reach for $brand.* variables when the content is the same and only tenant-specific values change (logo, primary color, product name, support email) — one shared template stays maintainable and every new tenant just needs its properties populated. Reach for a template variant when the content itself differs — a different CTA, an extra section, a tenant-specific layout, or a legal footer only one tenant needs. Most workspaces use variables broadly and reserve variants for the handful of tenants that need genuinely different content.
SuprSend evaluates variants top-to-bottom and picks the first one whose condition matches. If no variant matches, the default template is used — so you can add a variant for one specific tenant without affecting anyone else.
Yes. A variant’s condition can reference tenant_id, the user’s $preferred_language, trigger data properties, or any combination. Common pattern: one variant per tenant for content differences, plus multi-lingual translations inside each variant for language differences.
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 (for example, 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.

User-Tenant Mapping

Give a user different properties and channel identities per tenant.