Forum Academy Marketplace Showcase Pricing Features

Privacy feature - questions

This post refers to Privacy feature providing back-end security (
I’ve several questions since some points are not clear for me and the documentation didn’t help me.

  1. How do the rules apply when two are met ?
    The last one is applied ? if yes, it will it be nice to be able to change the order with a Move up/down like for Conditional formatting or having a copy/paste feature so we don’t have to start again for making a change in the priority order.

  2. An exemple : I wish a client can add himself to the Seller’s list of clients but I don’t want any client to modify any profile information about the seller.
    With the “Modify this”, it’s a sort of all-or-nothing. Couldn’t we select the allowed fields for modification like for “View field” ?

  3. Another exemple for a seller who has a List of Products associated.
    In the Product privacy tab, there is no restriction. In the Seller privacy tab, if I uncheck “View the field : List of products”, will the user be able to see the products’s attributes ?

  4. Can I consider conditions in the workflow tab as secured ? I mean, conditions are checked on you side right ?

Thanks in advance for enlightening me !

1 Like
  1. If any rule grants access to an object, the user can modify it (the rules are logically ORed)
  2. There is no per-field permission for Modify. We will consider adding this feature if good use cases appear.
    You could allow a client to modify the list of Sellers (I’d do this by defining a custom type Sellers that has one field, a List of Users). If you allow users to modify the list via a workflow, they can do that but not modify actual User information. You can ensure they can only add to the list (and that there are no duplicates) through the workflow.
  3. If you allow them to find the Product via a workflow, yes they will be able to see the Product. The rights for List of Products and Product are separate - i.e. If you enable access to the List of Products but remove all rights for the Product itself, the user can only modify the list.
  4. Yes. Workflows are in fact the preferred mechanism for enforcing security rules. The Privacy tab is a fallback - if/when the app becomes very complex, these rules will ensure everything is safe.

If you don’t give users access to something via a workflow, they can’t access it.

Thanks for asking, we’ll update the documentation to reflect this information.

1 Like

Thanks for this comprehensive answer. It gets clearer now and I’ll do as you suggest for 2/.

There are tons of good use cases to warrant the creation of a per-field permission. Here is just a few…

A user may be able to see basic information on a client, but not his balance

A user may be able to see that a criminal case exists, but cannot see the client’s name, address, phone, etc… since he/she is a minor

Hiding the SSN field.

and on and on…

I also believe Bubble could vastly improve by making the roles like workflows. A lot of other Application development tools actually advertise this as their strength ( comes to mind)…

They call it “business rules” where you create rules at the data level. You just need it to create it once and never have to worry again about it throughout your application design.

Can it be dangerous? Anything we develop can be dangerous if we are not careful.

Can it be hard to debug? I think it actually makes it easier (in my experience with other tools) since it is only one place to look.

Example of a business rule I would like to create in the Privacy Tab:

If Case.Client_Age < 18, no one can see this client’s name, address, phone.

No matter what querie, screen, report I build, the info on these fields for matching cases (where client was a minor when arrested) would never appear. It is part of my business rules.


I agree on having security on individual fields. I believe that security should be implemented on objects (such as search filters), roles (which is already provided), and even on workflows (roles and/or object ownership based). In addition to having assurances, it makes it simpler for users to implement security.

1 Like

Thank you Marcos and Scott! We will gladly add these features as they become necessary.

1 Like

I echo the responses by @Scott and @macro101. Having the ability to provide row/record-level security on the database, field-level security – by providing an attribute on the fields that allows you to specify a role (e.g. public, admin, subscriber), or individual, and workflow-level security (read, write, execute, etc.) would really help as we try to build more complex apps.

Hi @Kfawcett. Just curiosity.

What is the use case you can’t do right now with the actual privacy feature about this ?

1 Like

@NicolasDap I don’t have a specific use case at this time as I’m still in the initial process of designing the logic in my current app, but there will be certain applications that could benefit, or require, these types of security features.

One possible use case I will have is how to allow multiple levels of subscription (i.e basic, standard, professional) access to an increasing level of features. Ideally if someone subscribes at the standard level then they may see more fields on a page or be able to run additional workflow, than the basic subscription.

Another use case: If I was to build some type of HR application, then I would like to be able to limit the visibility to PII. An end user, or their manager, should only be allowed to see certain fields on the end user’s profile, whereas the HR professional should be able to see the end user’s SSN.

What you are describing is a very common practice called Access Control List (ACL) that I hope is implemented as well. To achieve this, there might need to be a different set of roles, as roles on ACLs don’t use the object in question to see if the individual has access, but rather the other way around.

A benefit of having this would allow us to check security in the workflow, as it may be easy to forget about the privacy tab.

I don’t see why we can’t do that with current Bubble’s features. You can just set user types, for example, if user is “manager” (yes/no) some text elements that displays the information he is supposed to see is shown. If he is not (set to no), some stuff will simply not appear if you set them to hide or redirect him to another screen. Redirecting to another screen is something more radical, but may be a second layer of security. Use that with data roles and you’re great. Bubble only shows what we TELL it to show, if there’s something you dont want a specific type of user to see, just dont create elements to show it to him. It is not like someone can brute-force something out of your database.

Same goes with workflow security settings, read-write-execute (I smell FTP haha), you can just set a workflow not to be run if certain condition is not met, like “user is Manager (yes/no)”. Or just hide the element that triggers the workflow from that user, like I mentioned in the above paragraph.

On my view, if they add FTP-like codes (777; 775; etc) and other things like that we’ll be closing in to normal code, not getting away from them.

1 Like

Ah yes, this is definitely true. I shall start doing this as well. Separating it out does give users at least one benefit, which is making it obvious that security should be implemented. If you saw a default field on an object or condition on a workflow called security and it was currently empty, you would start wondering if you forgot to do something.

It’s very easy to miss adding security if it’s not restricted by default. I would rather have all workflow, fields, and data be restricted to only admin view/execution without explicitly defining a specific role to access/execute it. This makes it easy to test with a lower level role to determine if it is missing rights to a specific object/workflow.

I would rather have someone complain because something isn’t working, or they cannot see something, versus forgetting to restrict something and having someone view the data of another person.

1 Like

So far, I think I’ve bee able to define all the security rules I needed. I’ve got different types of Users : Admin, Seller, Organiser, Participant… And each of them have different rights : read only some fields, do a global search or not, read and modify only things they own. And I’ve got also another lever. Sellers subscribe to plans which give them access to different level of features.

@Kfawcett. To be very strict on your security implementation, why don’t you define for all your newly created tables only an admin access and then open it more & more ? Same for newly created workflows.

1 Like