Teams and permissions

Team creation

Create the team

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

Add members

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

Assign resources

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

Role-based access

Common role patterns:

Role	Typical capabilities
Viewer	Read pipelines, runs, and catalog entries; no edits
Editor	Create and edit drafts; cannot promote to production in locked environments
Maintainer	Edit production pipelines, manage schedules, resolve DLQ for owned assets
Admin	Manage connections, secrets rotation, teams, billing contacts (varies by org policy)

Custom roles

Enterprise deployments often map SSO groups to custom roles with fine-grained toggles (for example, “run but not delete”).

Service accounts

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.

API keys

Programmatic access for automation principals.

Group claims that drive team membership.