Role-based application access

Application development roles, their capabilities, and level of access.

Updated over a week ago

After reading this article you’ll know:

  • The kinds of applications development roles

  • What role-based application development access is

  • How to assign roles and permissions for certain users

Providing access to certain users to build, configure, update, and maintain applications is based on three roles: citizen developer, business technologist, and low-code developer. In this article, we are going to break down these roles explaining what they are capable of doing and what level of access or limitations you can set for these roles in your application providing a clearer, more secure, and efficient development process, facilitating better collaboration and productivity.

Application roles explained

Currently, there are three application roles that can be assigned and used on the Betty Blocks platform:

  • Citizen developer is responsible for configuring, updating, and maintaining the application. This person usually is a business user, working on the platform every now and then.

  • Business technologist is a more experienced builder who can build more complex applications. This persona also has a business background, making them the ideal practitioner to build business applications.

  • Low-code developer has the highest level of expertise and is responsible for customizing and supporting other builders. From now on, everyone who was assigned to the builder role will be a low-code developer.

Roles and permissions management

In order to view and manage roles and permissions in your organization, go to My Betty Blocks, choose your organization, and click on Roles & Permissions.

Here you’ll see both organization roles and application development roles. First comes the low-code developer role which by default has all levels of access to the following permissions, for instance:

  • Unlock wrapper permission - allows builders to change individual components inside a wrapper. This permission is particularly useful for low-code developers who are customizing the application. We recommend disabling this permission for citizen developers, to ensure governance. Learn more about wrappers in this article.

  • Manage data model permissions per user role permissions gives you the flexibility to manage which builder role can adjust the permissions for the data model. It’s recommended to disable this permission for citizen developers and business technologists, to make sure they will not be able to grant themself access to certain data model data. Learn more about data model permissions in this article.

As for business technologist and citizen developer roles, they are provided permissions manually by an organization’s admin. You can enable each permission separately or use the checkbox on top to allow or cancel all permissions in the list (see the image below).

Note: Press User management button in the top right corner to manage users and their organization roles (Admin or Member by default). More info is available in this article.

Keep in mind that all permissions set here will be applied to all applications in your organization. Nevertheless, you can assign these roles in each of your applications separately. To do this, choose your application from your current organization, press button, and proceed to User management overview.

As an organization admin, you can assign roles and permissions in My Betty Blocks. By default, all existing builders for all applications have been transformed to low-code developers and will have access to all permissions.

Invite new users to your application by pressing the Invite users button in the top right corner. A new dialog window will open and you will be able to type in a new user’s email address and assign the role to them. This ensures the builder will land on the platform in the correct role and will directly have access to what they need to use. Click Send invite when you’re done adding new users.

Note: As you may have noticed, the User role is still present and available when assigning roles. It is used to allow application end users to interact with the front end of an application (in combination with the Betty Blocks authentication profile). More about this here.

Did this answer your question?