In a multi-tenant SaaS model, where multiple domains point to a single application, effective database design is crucial. This approach allows for a shared database infrastructure while ensuring that data is segregated and secure for each domain/account. The key is in how you structure and manage your data within Bubble to achieve this separation seamlessly.

 

Account

These are the fields I propose to add to the Account Data Type:

  • Name: Contains the name of the account

  • Domain: Contains the domain that the account belongs to

  • Users (optional): You can add the users that have access to the account here

  1. Creating the Account Data Type: Begin by creating a new data type named Account. This entity will represent different accounts or domains within your SaaS application.

  2. Linking Accounts to Domains: For each account, set a field named domain to store the domain name. This unique identifier connects the account to its corresponding domain.

  3. Privacy Rules for Account Identification: Implement privacy rules in Bubble to allow the domain field to be visible to all users. This ensures that any account can be identified using its domain name, enhancing the data structure's clarity and usability.

User Access to Data

This is the extra field I propose to add to the User Data Type

  • accounts: contains list of accounts

  • active_account: current account that the user is logged in to

  1. User accounts: On signup the accounts object should be added to a field with list of Accounts. That way you can prevent someone from signin in when they don't belong to an account.

  2. Account Selection on Login: Upon user login, provide a mechanism for users to select an account. If there's only one account associated with the user, automatically set this as the active account in the active_account field of the User data type.

  3. Linking User Access to Accounts: Extend the concept of the active account by adding the active_account field to all relevant data types. This setup allows you to create privacy rules like "if user’s account is Thing’s account," thereby controlling access based on the user’s active account.

Storing Domain Information

Domain Information Fields: In the Account data type, include fields to track domain information. Suggested fields are:

  • domain_name (text type) for storing the domain.

  • domain_dns_valid (yes/no type) to indicate if the domain's DNS settings are correctly configured.

  • domain_verify_valid (yes/no type) to confirm the domain's verification status.

  • domain_ssl (yes/no type) to track whether SSL is enabled for the domain.

Utilizing Domain Fields: These fields allow you to record the outcomes of domain additions and checks. By maintaining this information, you can swiftly display and manage domain-related statuses, enhancing administrative efficiency and domain management within your application.

 

Conclusion

This structured approach to database design in Bubble ensures that even in a shared environment, data is effectively separated and secured for each domain or account. By leveraging the power of Bubble's no-code platform, you can build a robust, multi-tenant SaaS application that scales efficiently while maintaining high levels of data integrity and security.