Belltastic Documentation

Multi-Tenancy

If your application utilises multi-tenancy, where a single user belongs to multiple teams/projects/etc, you may need to deliver several Notification Components for the same user ID, but different teams/projects.

Below are some strategies you can implement to achieve this, along with their pros and cons.

Strategy #1: Compound user IDs

In Belltastic, the user ID can be any type of value as long as it's passed as a string to the Notification Component. Therefore, you can technically use compound keys, such as {TEAM_ID}:{USER_ID}:

<!-- This displays notifications for a user ID 45000 in team ID 2004 -->
<belltastic-notifications
    user-id="2004:45000"
></belltastic-notifications>

You could make up your own compound key, as long as it can be converted to a string and is no longer than 255 characters.

Here are pros and cons compared to the next strategy:

Pros

  • Easy to get started with
  • Only a single Belltastic project to manage
  • Accurate and full app-level notification statistics Belltastic

Cons

  • Searching for users in Belltastic can be harder
  • No tenant-level statistics available in Belltastic due to fragmentation
  • Cleaning up data can be more difficult. When a tenant in your app gets deleted, you'll need to find all compound keys that include that tenancy ID
  • Incomplete data separation. Easily resolved by enabling HMAC Authorization

Strategy #2: Multiple Belltastic Projects

With this strategy, you would create new Belltastic projects for each of the tenants in your app, greatly separating the data and allowing to re-use the same user identifier across multiple tenants/projects.

This comes with more setup involved, but once implemented it can run on itself. You can utilise the Projects API to programmatically create new projects as new tenants are created in your app.

You will then have to store Belltastic Project IDs and their API keys in your app to dynamically insert the correct Belltastic Project ID when setting up the Notification Component:

<!-- This is Belltastic's Project ID, not your app tenant's ID -->
<belltastic-notifications
    api-key="project-1234-api-key-goes-here"
    project-id="1234"
    user-id="45000"
></belltastic-notifications>

Here are pros and cons compared to the previous strategy:

Pros

  • Complete data separation. API keys cannot access other projects
  • Easier data cleanup. If a tenant in your app gets deleted, you only need to delete the project from Belltastic, not the individual users/notifications.
  • Accurate and full tenant-level statistics in Belltastic, since each tenant has its own Belltastic Project

Cons

  • More setup needed upfront to implement this strategy
  • Multiple Belltastic Projects to manage
  • You have to manage multiple API keys and secrets due to working with multiple projects