In the Bubble world, Database Privacy Rules are one of the topics that many Bubble users have not explored or do not understand.

Not only are they essential to properly secure access to your database, but they are also a powerful tool that underpins many advanced use cases for Bubble.

If privacy rules feel a bit beyond you now, don’t worry… it took me a good 12 months of using Bubble to properly grasp the power of privacy rules. And I’d been playing around with SQL databases and BI tools for a good 5 years before meeting Bubble in my previous job as a data-focused solution architect.

Ok so here they are! 10 use cases you can implement with Privacy Rules you may not know about and you should try today.

Secure your data

Yep, as the name would suggest, Privacy Rules enable you to maintain the privacy of the data in your database in several ways:

• By Table (or “data type”) — Whole data types can be made public, available for specific user roles, or kept entirely private.
• By Column (or “field” — “column level security”) — You can write rules that enable or disable users from viewing fields of data within tables.
• By Row (or “row level security”) — You can show or hide specific rows of data to specific users.

Privacy Rules must be implemented in any Bubble app to properly secure the app’s data. It is not enough to rely on front-end logic alone (e.g. “do a search for” expressions in the front-end with constraints applied).

In the worst case, Bubble apps with incorrectly configured privacy rules can expose the entire application database to the public, accessible to anyone with some web development skills.

Write fewer constraints in the frontend

By using Privacy Rules, you have the potential to lessen the amount of work writing constraints in the front end.

I’m a massive proponent of the “DRY — don’t repeat yourself” principle for creating maintainable, well-organized apps.

Applying privacy rules at a database level potentially limits the number of constraints you will need to write in multiple places in the front end, not only improving security but also the organization of your business logic.

Enable auto-binding

You’ve probably seen that little prompt after enabling auto-binding in an input element.

Auto binding is when changes to an input are automatically written oa database field, without needing to press a button and run a workflow.

It is a great choice for scenarios where you want to commit the data immediately, and not so great when you want to give the user the chance to review the changes before saving.

To use auto-binding, you will need to create a privacy rule.

Implement User Roles

Ok, this is where it gets a little exciting 😉. Using Privacy Rules, you can create an app with multiple user types. Create an option set with different roles (name it “User Role OS”)

• Admin
• Buyer
• Seller

Create a “User Role” field on the User table of type “User Role OS”.

When you create each User, set your User Role appropriately.

Then write your privacy rules to give each role different access to the tables, rows, and columns in your database according to your use case!

Role Switching

What if Users can switch between roles?

We build upon the previous example.

Create an “Allowed User Roles” field on the User, and make this a list of User Role OS’s

Create a “Current User Role” field on the User type, and make this a User Role OS (not a “list of”).

Make a workflow that assigns the appropriate value to “Current User Role” when the User switches their User Role via your UI.

Role switching implemented!

Accounts and multitenancy

Ok, this is where turn up the heat! 🔥

Building a SAAS app where you have multiple accounts that all have their own data hosted in a single database?

This is often the most efficient way to build, as you don’t need to maintain different apps for different customers. Changes made in your app do not need to be replicated in other apps, creating the maintenance nightmare of single tenancy.

Create an “Account” datatype. Every time a new user signs up, create an Account row.

Create an Account field on the User, and set this field to the value of the Account you created.

On every datatype that sits under an “Account”, create an “Account” field.

When you create each row of data under an Account, set the “Account” field to the value of the User’s Account.

Now write every privacy rule for every table under an “Account” to say:

Current User's Account = This Datatype's Account

Now this might also be really useful if you have an internal tool for your company, and you want to build a client portal where clients can only view their own data. Just switch “Account” for “Client”.

You could apply multiple tiers of this logic in your app as well.

Account Switching

What if users can belong to more than one account? Well, similar to Role Switching, you can implement Account Switching.

Just create the same fields:

Allowed Accounts and Current Account.

Then create frontend workflows to switch the Current User’s Account as required.

Soft Deletion

Want to delete data but not wipe it completely?

Create a deleted flag field on your data type.

Create a privacy rule that says “This datatype’s Deleted = no” that allows the data to be visible. For all other data, do not let it be visible to users in search or viewing fields.

Impersonation

Similar to Role or Account switching, create a field “Impersonating User” of data type User on the User table.

Create a workflow to set the User’s “Impersonating User” to that of another user.

Write your frontend logic and privacy rules to allow one user to see data as if they were another user if the “impersonating user” field is not empty.

Make sure you clear this field when they stop impersonating the user!

Secure your tokens

If you store access tokens and refresh tokens for an external API, try organizing workflows to perform these refreshes in the backend workflows.

Then try to only expose the temporary access token to the front end. Limit access to any sensitive token or API key data (stored in the database) to backend workflows that can be run “ignoring privacy rules”.

Conclusion

Not only should you try these out, but you should think about building an app that uses most if not all of these!

Using these techniques, you could build an enterprise SAAS platform with multiple user roles, multiple accounts, internal/external stakeholders, high data security, data preservation through soft deletion, the ability to switch or even access multiple accounts or roles from the one user, and have multiple users for each account.

Privacy rules stack on top of each other, so a particular user type will not see the data unless you explicitly allow them to do so (or you set the rule as “everyone can access”).

Wow, that’s not just a simple no-code tool for MVPs… that’s enterprise software capability!

In case you missed it, here is an article about security practices in Bubble

For this and more, follow me. Oh and check out MomentumGroup.tech and Momentum Academy if you’d like help architecting your complex Bubble app, or you’d like to learn how to do all of this in a supported environment!

Written By Will Ericksson

Managing Director of MomentumGroup.tech, Founder of Momentum Academy, and former Bubble Bootcamp/Bubble Immerse Instructor, created over 40+ apps with Bubble.io.