Privacy rules for SaaS app

Hello, I have an app where the first users’ team is created when they create their account. They then can go to a team section and invite more users to their team (pretty typical SaaS team section). Those users should then be able to see all the users on their team but should not be able to see users on other teams.

The security issue I’m trying to avoid is someone on the client side being able to create an account then retrieve a list of all the users in our database regardless of whether they are on their team or not.

Essentially being able to say something like if this user is a part of a team they can view all users data who are a member of the same team.

Can someone help me out with this one? Thank you so much!

1 Like

yup, you can set “Privacy Rules” in your database tab.

You’ll be able to write a list of conditional statements there to limit different kinds of Users from accessing parts of your database :slight_smile:

The issue is I can’t figure out how to write the statement for the situation above or how to change my data structure to make it work. Can you provide an example of how this would be structured and written?

How is your database structured?

If each Team has a list of Users, or each User has a Team that they are a part of,

you can create the privacy rule on Teams: If Team's list of Users contains current user, Team is visible

1 Like

Hey Danny, Right now I have a User that has a list of teams they would be on. I think that was the problem if I make it so a user has 1 team then it works. Although i do wonder how I could in the future have a user belong to multiple teams and still have this work. Any thoughts on that? Thanks again.

It’s gonna be difficult as Bubble won’t let you set conditions on things of things, let’s say “This User’s Team’s Users” and it won’t let you refer to other data types other than the type you’re setting the privacy rule on. A possible way around it to allow them to be assigned to multiple Teams (in a Teams / List of Teams field on the User) and then allow the user to select a particular team that they’re currently working on and store that Team as a field on the User (eg CurrentTeam). You’d then set a privacy rule on the User to say This User’s Teams contains Current User’s CurrentTeam. It will only allow them to work on one team at a time (put a dropdown to change it whenever they want) but would help in your security concerns. Give it a go and see if it works for you.

1 Like

You could potentially create an additional data field on the user namely “All Team-Members”. This data field would be maintained and updated using back-end workflows and it would only be visible to the current user.
You can then use the privacy rule “Current user’s All team Members contains this user” and i think it should work

Hi @davehorne1989,

This article may be able to help you out: Structuring A SaaS Product In Bubble.io

1 Like

Interesting topic and article. How do you look at the following use case

A user signs up and is linked to a client. He uses the SaaS for projectmanagemt activities. He registers his own set of relations (customers and suppliers). A project is executed for a customer in collaboration with one ore more suppliers. Then the supplier agrees with the user hat he (supplier) also will use the SaaS to collaborate but to also be able the work on their own with SaaS managing their own Projects and Relations.

Would you seperate clients from relations, which I by myself would prefer. Or would you (from a performance and privacy rules perspective) consider relations to also be (potential) SaaS clients? Then, what about the possibility that different users having registered “the same” relation as a supplier either in its own context?

Then, how would the signup process be managed, letting everything be merged and linked accordingly?

For example: A supplier signs up by invite or without. He signs up with a company name (or other client identifier). Then the system could check if the client with this identifier already exists, if an an invite is pending and from who and trigger the required actions to onboard the supplier.

Just getting my head around this, but maybe I am overthinking this :slight_smile: