If you’re building an app that requires users to have different roles and permissions, then this guide. In this post, you will learn everything you need to know about creating multiple user roles.
The steps to creating user roles include:
- Understanding what roles and permissions are used for
- Setting up your database to support multiple role types
- Restricting features to users who have been granted permission
- Allowing admins to update the role type of each use
Full Transcript of Tutorial
In our guide today, we’ll build a team dashboard. On this page, an admin can view a long list of all the members of their team. In this list, each of these team members will have a dedicated role.
As an admin, you’ll have the ability to update the role permissions for each individual team member. You can make them a Coordinator, a Manager, or an Admin.
You’ll also notice that the admin will have access to view exclusive sales data. This feature is restricted to only those with a certain permission level.
Now, if you were to log in to the same dashboard as a user who is not an admin, you wouldn’t be able to change the roles of team members, nor would you have access to the sales data.
1. Understanding what roles and permissions are used for
When it comes to creating roles, we’re essentially just creating a hierarchy of a kind. Within our app, we’re going to allocate roles to certain users. Of course, it’s also possible to restrict features based on the permission that each user has. This is perfect for things like internal tools, project management tools, or even things like marketplaces.
If you’re building a product like Uber, which is a two-sided marketplace, you will want to restrict certain features for those users who are riders and users who are drivers. This means they’ll see two different types of apps.
2. How to correctly set up your database to support multiple role types
Before building a user permissions feature, you’ll need to take the time to set up and configure your own custom database.
Within Bubble, open the data tab, then select the data types menu.
In my example today, you’ll see that I have two main data types.
First, there’s my user data type. This is going to house all of the information for each of my team members.
The other data type is known as sales. This isn’t really relevant to our tutorial today, but this is just where I’m storing and pulling all of the data for the chart you saw on my dashboard page.
The main thing I want to highlight when it comes to my data types here is that you’ll notice that I don’t have a separate data type for each type of user role.
This is a mistake I see time and time again that people make when they’re brand new to Bubble. I’ve been down that road before as well. It’s easy to think that when you need to create a new type of user role, it should be its own data type.
In my example today, I have three different types of user roles. There’s a Coordinator, a Manager, and an Admin. If you’re brand new to Bubble, I completely understand why you might think that you need to create three separate data types, but that couldn’t be any further from the truth.
The thing about creating separate data types is that they won’t be able to replicate the user data type. The user data type in Bubble is very special. It’s the only data type that allows users to actually log in or register an account.
So if you were to create another data type for a Coordinator, a Manager, or an Admin – those users wouldn’t be able to log in through these data types. They can only do it through your User data type.
Under no circumstances should you ever create a separate data type as a means of registering a different type of user. All of this will be under a single user data type.
Within the main user type, you’ll instead create a series of data fields that allow you to determine which type of user an account should be.
In our example today, I’ll rebuild this data field from scratch.
Under your user data type, I recommend creating a field called ‘Role Permission’. This field will determine what type of permission someone’s going to have inside of a team.
Now for this field type, this is where things get interesting.
If you’ve used Bubble before, you might be familiar with the concept of option sets. Option sets are kind of like a data type. Unlike a data type – which is something that users inside of your app create – an option set is something that only you as the owner of your app can create. Your end users don’t have control over these.
This means that as the owner of your app, you have complete control over all of the data you’re going to pre-store in your database. This is perfect for a feature like user permissions or roles.
As you see here, I’ve created an Option set known as the ‘Role’. Inside this list, I need to add all of my different types of users. There’s going to be the Coordinator, the Manager, and finally an Admin.
The beautiful thing about option sets is that a user can only select from one of these three options. They’re unable to create new options themselves. This helps create governance and control over the different types of roles inside of your app.
After creating the list of option sets, we can now revert back to our main user data type.
Under our ‘Role Permission’ data field, we can link this to the list of options that were just added.
When creating this field, I won’t select that this should be a list with multiple entries. The reason for this is that a user should only have one role at a time. They shouldn’t have access to multiple options.
After creating this data field, I’m also going to set a default value in my database. A default value is just a pre-stored value that’s going to sit under your user data type every single time someone creates an account. This means that whenever someone registers for my app, what I’d like, by default, is to give them the role of a Coordinator. This means they’ll have the most basic level of permission.
3. How to restrict features to users that have been granted permission
Once you’ve learned how to set up and configure the database to support all of these different types of roles, let’s get into the fun part. We’ll now learn how to limit certain features to users that have a specific type of role or permission.
Inside of my Bubble editor, I’ve created a demo page that works as a dashboard for my app. This dashboard is similar to example I’d shown you at the beginning of this guide.
On this page, I have a repeating group that’s searching for a list of users. Inside each repeating group, I have a group element that displays information about each user. One of these elements is a text field that displays the users current role. This field displays the ‘Role Permission’ data field stored within each user’s account.
Now, as it currently stands, if I were to run a preview of this page logged in as someone who’s a coordinator, they would currently see the ability to edit all of the user’s information as well as view the sales data.
Let me show you what that looks like. If I head to my Data tab, open up my App data and scroll down, I’ll then head to my second user here. If I select this little pencil icon, I’m going to update their Role Permission to be a Coordinator.
As I mentioned before, by default, when someone registers an account, they should automatically be a Coordinator. Because I’ve already created this account in the past, that default value was not applied. This means I’ll need to add this manually. While I’m here, I’m going to explain how you as the owner of your app can also manually edit the permissions of each individual user.
As you can see, we can make any changes to the data fields that this user has. And when it comes to the role permission, you could set them to be a Coordinator, a Manager, or an Admin. You, as the owner, have the ability to manually change these values.
Now, I’m going to choose to save this user as a Coordinator. Then, if I run a preview of my page logged in as this user, what you’re going to see is that even though I only have the role of a coordinator, I still have access to edit the role of any other user inside of my team. If I scroll down the page, I also have access to view all of the sales data.
Now none of this should be possible as a coordinator I want to make sure that only my managers and my admins have the ability to view the sales data. I also want to make sure that only my admins can make changes to each team member.
So how can we do this?
Let’s jump back into our Bubble editor and open up our design tab. When it comes to restricting features from users, we need to hide them on our page, then create a condition that allows them to be shown when a user has a certain role type.
So, if I select the edit button, what we’re going to do is jump over to the layout tab. Now, within the layout tab, I can see by default this element is visible on page load. This means that every single time this page is loaded, anyone can see this element. Obviously, we don’t want that to be the case.
What I’m going to do is uncheck that this element should be visible on page load. I’m also going to check the option to ‘collapse this when it’s hidden’. Now, this means when this element is hidden, it won’t take up any empty space on our page. It’s going to disappear.
Then from here, because this element is currently invisible to every single user, we just need to open the conditional tab, then define a condition that will recognize when this button should be shown to specific users.
I’m going to define a condition for the ‘current user’. The current user is the person who would be logged in viewing this dashboard page. So when the ‘current user’s, role permission’ is in fact an admin, I’m going to define that this element should be visible.
Now, if I was to jump back into the preview of my page and hit refresh, what you’ll see is that when I’m logged in as this user who is only a Coordinator, they no longer have the ability to view that edit button. If I was to then jump into my database and set this user to be an Admin, they would have access to view this.
From here, there’s one last feature we need to restrict on this page, and that is our sales data. As I mentioned, I only want this to be visible to users who are either an admin or a manager, but not users who are a coordinator.
If we jump back into my Bubble editor, I’m just going to double-click on the group that contains both my heading as well as my chart element. In order to restrict this feature, we’ll replicate the same condition we created before.
The first thing we’ll need to do is make sure that this element is not visible on page load. It should be hidden from all users by default. If I select my Layout tab here, I’m going to scroll down and just uncheck this element is visible on page load. I’m also going to select the option to ‘collapse this element when it’s hidden’. Then I’ll open my conditional tab and define a new condition.
Within this condition, I’m just going to recognize when the ‘current user – if their role permission is, in fact, an admin’, they should have access to view this.
But if you remember, I also mentioned that when a user is a manager, they should also be able to access this chart. So I’m now going to select the ‘OR’ option, then I’ll also identify when the ‘current user’ is an admin OR a manager.
When this condition is true, we’ll select that this element should become visible.
So when it comes to restricting features in your app, this is the exact condition you’ll need to create.
If you’ve got five different types of roles and you want three of those five to have access to this feature, you’d just need to add another ‘OR’ option.
4. How to allow admins to update the role type of each use
We’re at the very last thing that I want to cover in this guide, and that is creating a way for the admins inside of our app to update the roles and permissions that team members have within their organization.
Up to this point, I’ve explained how you as the owner of your app could do this manually within your database. What I’d like to do today, however, is create some sort of autonomous way for admins to change this within their own accounts.
Inside my Bubble editor under the design tab, I’ve taken the time to create a pop-up. When the ‘edit’ button is clicked, I want this pop-up to be shown.
Before we move forward, I’d like to quickly highlight how I’ve set up this pop-up.
When it comes to this popup, I’ve set the type of content to be a user. This will allow me to store the details of a specific user whenever it’s displayed.
Inside the popup itself, I’m displaying some details about the user. This includes their profile photo, name, job, and their role type.
Below these elements, I’ve also added a dropdown menu that allows an admin to select which type of role a user should have.
If I open this dropdown menu, you’ll see that I’ve set the ‘choices style’ to be a list of dynamic choices. This means it will display a list of options from your database.
The options it will display, are of course, the options we created in our ‘Roles’ option set list.
I’ve also set a default value of this field. For the value, it will display the current role of the user being displayed within our popup.
When the value of this dropdown menu is changed, I’d like to run a workflow that makes changes to some information in my database.
The data I’ll be changing is the ‘parent groups user’. This is the user stored within the popup. The field I’d like to change for this user is their ‘role permission’. I’d like this field to now equal the same value as the option selected from our dropdown menu.
If I were to jump back into the preview of my app and refresh this page, I’ll see that my popup element is now fully functional.
Within the repeating group on my page, there’s a user named John Wilson. At this point in time, his role type is a coordinator, however, when open my popup, I now have the ability to update his permission to be a manager. Once I select this change, it will automatically update in our database.
And just like that, you now know how to build your own permissions feature inside of Bubble. As you could see, it’s never been easier to create powerful software, all without having to write a single line of code.