After reading this article, you’ll know the following:

Ensuring data security and user access control is important for any organization. Whether it’s an internal or publicly available application, builders must ensure that some specific data and functionality are locked for certain types of users. In this article, we’ll dive into the practical approaches to securing your application pages, including authentication profiles, role-based access, and conditional components.

An authentication profile determines which entity will be used to validate users accessing protected pages in an application. Users must provide unique identifiers like email and password that match the authentication model’s records to log in successfully.

Our platform has a couple of options to choose from:

You can view authentication as the highest level of security of your application. When you create a new page, select first the type of the page (authenticated or public), and then (if the first type is chosen), you can select an authentication profile that you want this page to belong to. As you can see, Betty Blocks account login is the default one. You can select another option and create a new authentication profile straight from this configuration window.

Once a page is created, you can choose an authentication profile for it at any time. Open the page via the page builder then go to the settings tab at the top of the builder bar. Scroll down to the bottom of the page, press Authentication profiles, and follow the same steps as explained in the previous paragraph.

To access the additional settings for authentication profiles, navigate to Tools > Authentication profiles. Here, you can choose the default authentication profile, designate the login page for a specific profile, and adjust other advanced settings.

Roles and permissions play a huge role in your page and application security on different levels. To protect data on the page for specific user actions (like create, edit, delete, etc.), you have to make sure you know what roles are going to be created within an application.

Go to Tools > Roles and permissions. Here you can create new roles for your application and enable permissions to access data models for them. Also, you can apply filter rules for accessing a specific model.

As you can see, only Read permissions are assigned to models in the Roles and permissions overview. This is because the remaining permissions are accessible through the action builder. Roles and permissions are applied to various actions, ranging from the basic create or update record to complex action flows involving AI steps.

Let’s try it out in the example. We’ll open an action with the create record step and get to the action settings in the top right corner of the builder. Then we go to the Permissions tab to view the available options. Here you can:

Enable certain roles to perform the action in the Permissions tab:

If you’re interested in managing roles on the organizational level, check this document.

So far, it should be clear how to secure your pages with authentication and setting roles and permissions, but what if you want to make only certain components available for certain roles and make them invisible to others?

Well, there is a trick for such a case which includes using a conditional component along with a data container.

Let’s see how to secure a specific component for authenticated users. This is our homepage with a button to the Employee overview page. To ensure only authenticated users (those with a Betty Blocks account) can access it, simply make the Employee overview page authenticated. Users without a Betty Blocks account will be redirected to the login page automatically.

But if you want to hide it from one role (e.g. user), while enabling another (e.g. admin) to see it, there is a scenario for that.

This use-case example is based on the start-from-scratch application which already has the User management page prepared (read more about it here). From this page, we can add new users and assign roles to them that will be stored in the User and Role models.

1. The first thing we need to do is save the information about our user and its role without creating a ‘many to many’ relation between the User and Role models (that isn’t available at the moment). Go to your User model and create a new text (single line) property, let’s call it ‘user_concat’.

2. Then go to the ‘update user’ action of your application (Page action: User management > update user, by default) and add the expression step before the update record step.

3. Open the update record step from the same action. Add the user_concat property and set its value to the result variable from the expression step (e.g. secured_role).

4. Now let's return to the page builder and our page. Pick up the data container component and drop it beside the button you want to hide (Employee overview in our case):

5. Grab a conditional component and drop it onto the data container, then take the button and drop it on top of the conditional. Navigate back to the conditional and let’s set it up:

Number ‘1’ stands for the admin due to concatenation. Accordingly ‘2’ will be user’s.

It’s time to test our use case. Compile your page and try viewing it as both admin and user.

Here we go. As you can see, the button’s visibility now only depends on whether one is logged in as an admin or user.

Note: In case you failed to complete a similar use case, we highly recommend checking the ‘update user’ action with the log message step as shown below: