Skip to main content

Permissions (RBAC)

Permissions allow you to create and share resources to easily ensure what level of access each user has to your Applications, Workflows, Jobs, and Integrations.

With Permissions, Users are assigned to Groups which have Roles to access Applications, Workflows, Jobs, and Integrations. Each Role (Own, Build, or View) is permitted to perform a set of Actions (View, Clone, Delete, Deploy, etc.) that are associated with it.

On this page:

  1. Role-Based Access Control (RBAC) Glossary
  2. Permissions Table
  3. Adding Permissions (RBAC)
  4. Setting API Permissions
  5. Referencing Groups in Code
  6. Public Applications
  7. Requesting Access

Role-Based Access Control (RBAC) Glossary

  • Users - Each user is associated with an email and can belong to one or more Groups.
  • Groups - By default, there are two groups: All Users and Admins. Additionally, you can create custom groups like Support, Engineering, etc.
    • All Users - Contains all members in your organization. You can add members to the group, but cannot remove members from the group. New members invited to this group will receive an invitation email.
    • Admins - Contains all admins in your organization. Everyone added to this group will inherit the permissions of Own for all entities. This group must have at least one member.
  • Roles - See Permissions Table for more details by entity.
    • Own - The user who creates the entity inherits own permissions, by default. Owners inherit all Build and View permissions, as well as the ability to delete the entity. Own permissions are non-transferrable.
    • Build - Write access to most entities. Builders inherit all View permissions.
    • View - Read access to most entities.
  • Applications, Workflows, Jobs, Integrations - Entities that a user can set permissions on.
  • Actions - Clone, Delete, Add Editors, Rename, Deploy, Preview, Rollback, View Audit Logs, Use app etc.

Permissions Table

WorkflowsScheduled JobsIntegrations
Share/revoke build or view permissions
See on home pageN/A
See integration tile and in all lists in the product (Workflows, Apps, etc)N/AN/AN/A
Modify, rename, or clone entity
Deploy entityN/A
View related audit logsN/A
Use entity and see in lists in the productN/A

- yes, x - no, N/A - not applicable to this entity

Adding Permissions (RBAC)


Applications can be locked down to specific users within an organization through the Share modal. Users can be granted Build or View permissions.

By default, applications are read-only for all users within your organization. You can change this permission to lock down apps to only those users who you share the application with.

In addition to granting view or build permissions to users, you can also grant these privileges to groups.

Workflows and Scheduled Jobs

Define access controls for users per application, workflow, or job so only certain users or departments can access it once it is deployed.


Users are assigned to Groups which have Roles to access Applications, Workflows, Jobs, and Integrations. Groups are configured in the Permissions page. The default groups are All Users and Admins, where the Admin group has access to all Superblocks entities in your organization. Outside of the default groups, users can also create custom groups like Support, Engineering, etc.


Define which users and groups are able to query specific Databases, Cloud Data Warehouses, Cloud Storage, and Internal or External APIs. You can also configure which users and groups are able to see and modify credentials in the integrations page.

For example, you can create a Rest API integration with one of your external tools such as Zendesk. Then, grant access to a user to be able to use the credentials to make calls to the API, without them having access to those credentials directly.

User with Build permissions can use the integration, but the credentials are redacted

Users who have Build permissions to an Application, Workflow, or Scheduled Job, but do not have Configure permissions to an integration step, will have read-only access to the integration step. Due to this, there will be renaming conflicts if the user without integration Configure permissions attempts to rename a step or component that is referenced within the integration step.

Setting API Permissions

Permissions can also be set on the API directly per user or per group on the bottom of the API Configuration tab.

Referencing Groups in Code

You can leverage groups within your code to set permissions at the component level. In the following example, you can see that the button component is disabled since the user is not within the Support Managers group. Here's the code snippet used:

{{! =>"Solutions Managers")}}

Permissions to an API can be set as a step within a Python function by leveraging the current user's group (Global.user.groups):

userGroupNames = list(map(lambda group:, Global.user.groups))
if "Support Managers" not in userGroupNames:
raise Exception("You don't have sufficient permissions to perform this action. Please contact a Support Manager.")

Public Applications

Share your deployed applications with the public without needing users to log into Superblocks. From the Application build page, click "Share" in the top-right and select "Public to anyone on the internet" from the drop-down menu. Now your deployed application is accessible by anyone with the link.


Public Applications are disabled when using the On-premise Agent.

You can also embed your application on a website, see here for more details

Requesting Access

When a user attempts to access an Application, Workflow, or Scheduled Job that they don't have permissions for, they'll be presented with a request access page.

Once the user requests access, the owner of the Application, Workflow, or Scheduled Job will receive an email prompting them to grant access. Once access has been granted, the user who requested access will receive a confirmation email.