Teams

Let more people run workflows, safely.

dagweave gives the rest of your team a way into the Argo Workflows you already run. Control who sees what, down to a single workflow, and what their workflows can touch once they reach your cluster.

The problem

Who gets in, and what they can do once they're in.

You want more of the team running workflows without handing out cluster access.

That means deciding who each person is and what they are allowed to run.

Shared work

One workspace the whole team shares

Workflows, templates, connectors and triggers belong to the team, not whoever built them.

A new joiner sees the whole workspace on day one.
Folders and labels keep a workspace organized as it grows.

scope text

private      ->  just you
team         ->  everyone in the workspace
marketplace  ->  published for other teams to install

Roles

Open it up without opening everything

Most people need to build workflows and run them. Deleting things and managing members stays with whoever already owns the account.

A new joiner gets editor and is useful the same day.
You never have to make someone an admin just to let them work.

roles text

viewer  ->  read the canvas and the run history
editor  ->  build workflows and dispatch runs
admin   ->  editor, plus delete and manage members
owner   ->  admin, plus the account itself

Granular access

Give a group exactly what it needs

Roles cover the whole workspace. Groups and grants cover everything narrower than that: the data team on three pipelines, one contractor on one connector.

Use the groups your identity provider already has, or make your own in dagweave.
Someone joins the group and gets what the group has. They leave and it goes with them.
Nobody gets promoted to admin just to see one pipeline.

who gets what text

role   ->  what someone can do across the whole workspace
group  ->  the data team, the on-call rota, whoever you like
grant  ->  read or edit, to a person or a group, on one object

Cluster access

Set cluster permissions without writing RBAC

Seeing a workflow in dagweave is one thing. What it can touch once it lands on your cluster is another. Scope a group to the namespaces it needs, running as a service account you built in dagweave rather than one somebody hand-wrote.

Pick the namespaces a group can dispatch to. Anywhere else is refused.
Nobody has to write a Role or a RoleBinding.
Give a group its own namespace, or give every run its own. Either way dagweave cleans up after itself.
Put it through an approval step before it reaches the cluster, if you want one.
dagweave installs it through the connector you already enrolled.

what a group is allowed text

namespaces       ->  where their workflows are allowed to run
service account  ->  what those workflows can touch once there
lifetime         ->  namespace and account, created and removed with the run
approval         ->  optional, before any of it reaches the cluster

Sign-in

SAML or OIDC, your identity provider

Your team signs in through your identity provider, with the credentials your directory already issues.

Joiners get in on the account they already have.
Disable someone in your directory, and their dagweave access goes with it.
TOTP and WebAuthn passkeys cover accounts that sign in directly.

access text

identity provider  ->  SAML or OIDC, who is allowed in
team membership    ->  which workspace they land in
role + grants      ->  what they can do once there

Accountability

A record of who did what

A production job starts failing. The audit log says who changed it, and when.

Every action is logged, whether it succeeded or was refused.
Export as CSV for a reviewer, or read the full detail through the API.

audit log text

workflow changed  ->  who, when, which one
run dispatched    ->  who, when, which cluster
member added      ->  who joined, and at what role

Give the whole team access.

dagweave is in early access. Leave an email and we will bring you on as we open it up.