Cadence
Concepts

Spaces, teams, and who can do what

What a space and a team are, and the viewer, member, and admin roles that decide who configures a space and who only reads it.

Everything you do in Cadence happens inside a space. Before the other concepts and the guides make sense, it helps to know what a space holds, how teams sit inside it, and which of three roles a person needs to do a given thing.

Space

A space is the top-level container for your work. It holds your workflows and their stages, your pools and worker versions, the rules that gate and move work, the tasks themselves, and the credentials a worker uses. A space has a name and a short key — two to ten letters or digits, starting with a letter — and that key is the prefix of every task's id: a task in the OPS space is OPS-1, OPS-2, and so on.

Most operators work in one space. Nothing in one space reaches into another: a worker leased in one space never sees another's tasks, and a role you hold in one space grants you nothing in the next.

Team

Within a space, a team groups workflows. Every workflow belongs to exactly one team; the first workflow a space gets lands in a Default team, created for it then. Teams are how you keep a larger space's workflows organised — one team's workflows for delivery, another's for support — rather than a separate permission boundary: who can do what is decided by your role in the space, described next.

The three roles

Your access to a space is set by a role, and the roles form a strict ladder. Each one can do everything the one below it can, and more:

  • Viewer — reads, changes nothing. A viewer can see the workflows, the tasks and where they sit, the docs, and the running work, but cannot move or edit any of it.
  • Member — moves the work. On top of everything a viewer can see, a member creates and edits tasks, moves them from one stage to the next, resolves them, sets their properties, records a check result, writes and edits docs, and sends messages.
  • Admin — configures the space. On top of everything a member can do, an admin shapes the space itself: its workflows, stages, and teams; its pools, worker versions, and agent skills; every rule that gates or moves work — assignment, check, sentinel, resolution, and property rules, the rules that take work in from outside, and the rules that run work on a schedule; its tags and task types; its credentials; and who else holds a role in the space.

You hold a role per space, so the same person can be an admin of one space and a viewer of another. There is also a separate instance-admin setting for whoever runs the Cadence instance itself; it grants no access to any space's work — reaching a space's tasks, workflows, or settings always needs a role in that space.

Every guide and reference page assumes this split. Where a page says a step needs read, member, or admin, it is naming the lowest role on this ladder that can take it — the exact rule each call follows is set out in Authentication.

On this page