Skip to main content

Documentation Index

Fetch the complete documentation index at: https://www.courier.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

User tenant preferences enable user-driven notification control by allowing users to set different preference choices for each tenant they belong to. This creates a layered preference system where users can have fine-grained control over notifications across different organizational contexts. For example, a user might want to receive production alerts for their main project but opt out of development notifications for staging environments, or receive different types of notifications for different teams or organizations.
Availability: User-Tenant Preferences are available for Enterprise customers. Contact Courier Support for access or Request a Demo to learn more about how Courier could help you.

​
Key Features

Courier’s tenant preference system provides:
  • Per-Tenant Preferences - Users can set different preferences for each tenant relationship
  • Layered Defaults - Preferences inherit from tenant defaults but can be overridden by users
  • Hierarchical Inheritance - Parent tenant preferences flow down to child tenants
  • Flexible Opt-in/Out - Users can opt in to some tenants while opting out of others
  • Context-Aware Delivery - Notifications respect the preference context of the specific tenant

​
Preference Hierarchy

Adding tenant context creates multiple layers of preferences for a single user. For example, if you design tenants to map to your organizational structure (cloud provider with multiple projects), a user can have different preferences at each level: In this example, the same user receives alert notifications via email and Slack for prod-project but receives nothing for stage-project, even though the workspace default is alerts ON.

​
Preference Resolution Order

At send time, Courier merges preference layers top-to-bottom. Each layer overrides the one above it; only explicitly set fields are applied, and unset fields pass through.
  1. Workspace-level defaults — Global defaults set on the subscription topic or preference page
  2. Parent tenant defaults — Inherited from the tenant hierarchy
  3. Tenant defaults — Defaults configured on the specific tenant via default preferences
  4. User-level preferences — The user’s own global preference choices
  5. User-tenant preferences — The user’s per-tenant overrides (highest priority)
A user’s global preferences and their per-tenant preferences are independent. Setting a global preference does not propagate to tenant-specific contexts. If a user opts out globally but a tenant default opts them in, the tenant default wins for that tenant’s notifications unless the user also sets a per-tenant opt-out.

​
Tenant Defaults

If a user has not set their own preferences for a tenant, Courier uses the tenant’s defaults. Each tenant can configure its own defaults — see Default Preferences. Example tenant default behavior:
  • Tenant A defaults: Opted IN for alerts, Email + Slack channels
  • User has no preferences set for Tenant A
  • Result: User receives alerts via Email + Slack for Tenant A notifications

​
Parent Tenant Defaults

When using parent tenants, tenant preferences follow the same hierarchy loading technique described in Hierarchical Inheritance. Parent tenant default preferences are loaded first, then child tenants can override specific fields. Example inheritance:
  • Parent Tenant: Alerts OPTED_IN, channels: [email]
  • Child Tenant: Alerts OPTED_IN, channels: [email, slack]
  • User preference: None set
  • Result: User receives alerts via Email + Slack (child overrides parent’s channel list)
Courier may also be auto-inferring the Tenant based on a single-user tenant membership, so if you have created tenant memberships, you need to set up your Inbox and Toast SDKs with a tenantId. More details on auto-infer here

Tenants Overview

Learn about tenant hierarchies and default preferences

Preferences Overview

Complete preference management documentation