Skip to main content

Groups

Overview​

Groups are an access control mechanism in BuiltAPI that allows you to organize users and define their access rights to various system resources. Groups are only available for the User role, as administrative roles have predefined access to all system components.

Core Concepts​

What is a Group​

A group is a named entity that defines:

  • Which Entities users in the group can access
  • Which Views users in the group can access
  • What operations are allowed on these resources

Permission Structure​

Each permission in a group is defined by three components:

  1. Resource Type the type of resource:

    • Entity
    • View

  2. Resource the specific resource (selected entity or view)

  3. Operations allowed operations:

    • Read read data
    • Write create and modify data
    • Delete delete data

Working with Groups​

Creating a Group​

  1. Navigate to the "Groups" tab in the Settings panel
  2. Click the "Create Group" button
  3. Fill out the group creation form:
    • Name unique name for the group

Configuring Permissions​

After creating a group, you need to configure permissions:

  1. Open the created group
  2. In the "Permissions" section, click "Add Permission"
  3. Select:
    • Resource type (Entity or View)
    • Specific resource from the dropdown list
    • Click "Add"
  4. Specify allowed operations for the resource:
    • Check the boxes for Read, Write, and/or Delete as needed
  5. Click "Create"/"Save" to apply the permissions

Adding Member to a Group​

  1. In the group settings, go to the "Members" section
  2. Click "Add Members"
  3. Select users from the list
  4. Confirm the addition

or

  1. Navigate to the "Members" tab in the Settings panel
  2. For members with role "User" you can select Group in the "Groups" column

Use Case Examples​

Example 1: Analysts Group​

Create an "Analysts" group with permissions:

  • Read access to all Views for report viewing
  • Read access to "Sales" and "Customers" entities
  • No write or delete permissions

Example 2: Sales Managers Group​

Create a "Sales Managers" group with permissions:

  • Read, Write access to "Customers", "Orders", "Products" entities
  • Read access to "Sales Dashboard" view
  • Delete access only to "Orders" entity (for order cancellation)

Example 3: Integration Developers Group​

Create an "Integration Developers" group with permissions:

  • Read, Write, Delete access to "Integration_Logs" entity
  • Read access to all entities for testing
  • Read access to "API_Usage_Statistics" view

Important Notes​

  1. Principle of Least Privilege: Grant only the permissions necessary for performing work tasks

  2. Permission Inheritance: Users receive all permissions from all groups they belong to

  3. Permission Priority: When a user belongs to multiple groups, all permissions are combined (broader permissions take precedence)

  4. Administrative Roles: Owner, Admin or Pipeline operator roles are not limited by groups and have access according to their role

Best Practices for Group Organization​

  1. Use Clear Names: Group names should reflect their purpose (e.g., "Sales_Team", "Financial_Analysts")

  2. Document Purpose: Use the description field to specify the group's goals and objectives

  3. Regular Auditing: Periodically review group membership and permission relevance

  4. Separation by Function: Create separate groups for different functional areas instead of one large group with all permissions