Skip to main content
Teams page showing hierarchical graph visualization of teams

​
Overview

Teams control which users can access which workflows, contents, and datasources. They act as the team-scoping layer of the permission system — a user’s role defines what they can do, while their teams define which resources they can do it on. Every user must belong to at least one team. Teams can be organized into a hierarchy with parent-child relationships, enabling automatic access inheritance.

​
How Team Scoping Works

Team-scoped resources (workflows, contents, datasources, datagraph schemas, datagraph entities) are assigned to one or more teams when they are created. A user can only interact with a team-scoped resource if:
  1. Their role grants the required action on that resource type.
  2. They are a member of at least one team that the resource belongs to (directly or through inheritance).
Company-scoped resources (users, roles, company settings, billing, etc.) are not affected by team membership — they are accessible to any user whose role permits the action.

​
Teams Listing

The Teams page displays all teams with a hierarchical graph visualization and a list view. You can switch between two graph rendering algorithms: Use the search bar to find specific teams.

​
Team Information

Each team node in the graph shows:

​
Creating a Team

1

Open the creation modal

Click Create team to open the creation form.
2

Fill in the team details

3

Create

Click Create to save the new team. The team starts with no parent-child relationships — you can add them later.

​
Creating a Sub-Team

To create a team as a child of an existing team:
  1. Click the actions menu on a team and select Create sub-team.
  2. The form pre-fills the parent team.
  3. Enter the sub-team name and users.
  4. Click Create.

​
Team Hierarchy

Teams support parent-child relationships that form a hierarchy. This hierarchy controls how access is inherited across teams.

​
How Inheritance Works

When a user is assigned to a team, they automatically gain access to resources in all descendant teams (children, grandchildren, etc.) below it. For example, consider this hierarchy:
  • A user assigned to Engineering can access resources in Engineering, Backend Team, API Team, and Frontend Team.
  • A user assigned to Backend Team can access resources in Backend Team and API Team, but not Engineering or Frontend Team.
  • A user assigned to API Team can only access resources in API Team.
Assign users to the most specific team that matches their role. The system handles broader access automatically through the hierarchy.
Do not assign a user to both a parent team and one of its child teams. The parent assignment already provides access to the child team through inheritance.

​
Exclude from Ancestor Inheritance

By default, team inheritance only flows downward (from parent to child). The Exclude from ancestor inheritance toggle changes this behavior:
Enabling ancestor inheritance broadens access significantly. Use this only when users in a child team genuinely need access to resources managed at higher levels of the hierarchy.

​
Circular Reference Protection

The system prevents circular references in the team hierarchy. If Team A is a parent of Team B, then Team B cannot be set as a parent of Team A. This check applies transitively across the entire hierarchy.

​
Editing a Team

Click the actions menu and select Edit to update: Click Save to apply.

​
Managing Team Members

Click the actions menu and select Members to open the members drawer:

​
Detaching Teams

To remove a parent-child relationship without deleting either team:
  1. Open the team’s edit form or the relationships management view.
  2. Remove the parent or child link.
  3. Click Save.
The team continues to exist independently — only the hierarchical relationship is removed.

​
Deleting a Team

  1. Click the actions menu and select Delete team.
  2. A confirmation dialog asks you to confirm.
  3. Click Delete to remove the team.
Before deleting a team, you must first remove or reassign all child teams and resources (workflows, contents, etc.) that belong to it. The system enforces these requirements to prevent accidental data loss. Users in the team will lose access to resources that were scoped to that team only.