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.

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​

Action
Applications
WorkflowsScheduled JobsIntegrations
Delete✓✓✓✓
Share/revoke build or view permissions✓✓✓✓
See on home page✓✓✓N/A
See integration tile and in all lists in the product (Workflows, Apps, etc)N/AN/AN/A✓
Modify, rename, or clone entity✓✓✓✓
Deploy entity✓✓✓N/A
View related audit logs✓✓✓N/A
Use entity and see in lists in the product✓✓N/A✓

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

Adding Permissions (RBAC)​

Applications​

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

Control which users and groups have access to view and edit an application within the share UI

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.

Chose who can build and who can view by email or group

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

Chose who can build and who can view by email or group

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.

Use Role Based Access Control to ensure only specific users and groups have access to workflows, applications and jobs

Groups​

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.

Create and manage user groups within permissions page

View users within a group

Integrations​

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.

Fine grained permissions down to individual integrations

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

caution

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.

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

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.

Share deployed application with the public
caution

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.

Request access to an application
Access request sent

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.

Grant access from email
Permission to application granted