Skip to main content
Teams group people who share responsibility for domains (finance, product analytics, platform). Roles bundle permissions so you grant least privilege without hand-editing every pipeline.

​
Team creation

1

Create the team

In Organization → Teams, add a name, optional description, and owning manager.
2

Add members

Invite users or sync from your identity provider if group mapping is enabled.
3

Assign resources

Attach default connections, projects, or tags the team may use so new members inherit baseline access.

​
Role-based access

Common role patterns:
RoleTypical capabilities
ViewerRead pipelines, runs, and catalog entries; no edits
EditorCreate and edit drafts; cannot promote to production in locked environments
MaintainerEdit production pipelines, manage schedules, resolve DLQ for owned assets
AdminManage connections, secrets rotation, teams, billing contacts (varies by org policy)
Enterprise deployments often map SSO groups to custom roles with fine-grained toggles (for example, “run but not delete”).
Use non-human principals for CI and orchestration; scope their roles to a single project or connection namespace.

​
Sharing pipelines and connections

  • Pipelines can be private to a user, shared with a team, or workspace-wide. Explicit shares override defaults when you collaborate across teams.
  • Connections store credentials; sharing a pipeline does not automatically expose secrets—recipients still need connection use-permission.
Avoid workspace-wide Admin for contractors. Use time-bounded project roles and remove access when engagements end.

​
Auditing access

Review access reports periodically: who can use production warehouses, who can export data, and which API keys map to which teams. Pair with Session policy for IP and timeout rules.

API keys

Programmatic access for automation principals.

SSO

Group claims that drive team membership.