Skip to main content
Retab has two role systems that stack:
  1. Organization RBAC — coarse, organization-wide roles for account authority (billing, members, keys, secrets, environments).
  2. Fine-Grained Authorization (FGA) — per-project and per-workflow roles for product access (view, run, edit, review, publish a workflow).
An organization Member role is the baseline; the ability to touch a specific workflow comes from an FGA role on the project that owns it.

​
Organization roles (RBAC)

Three organization-wide roles, with inheritance — each row includes everything below it.
Member is intentionally thin. Its description says it plainly: product access comes from environment membership and project/workflow FGA, not broad organization RBAC. Being a Member lets you use the account; it does not, by itself, grant you any particular workflow.
Organization roles are assigned from the dashboard and are global — they are not per-environment.

​
Fine-grained roles (FGA)

FGA roles are granted on a project (or, internally, a workflow) and carry a bundle of permissions. There are four roles at each level, from most to least privileged.

​
Project roles

Grant these on a project; they apply to the project and, by inheritance, to every workflow it owns. The person who creates a project (or the environment’s Default Project) becomes its Project Owner.

​
Workflow roles

The same four shapes exist at the workflow level — Workflow Owner / Editor / Operator / Viewer — carrying the matching subset of workflow:* permissions. In practice you grant at the project level; see inheritance below.

​
The permission vocabulary

Every FGA role is just a set of these permissions. This is what the capabilities array on API responses is drawn from. delete and manage are deliberately not grantable to scoped access tokens — a token can operate a workflow but cannot hand out access or tear resources down.

​
Capabilities on responses

Rather than resolving roles on the client, read the capabilities array Retab computes for the current caller:
A Project Operator, for example, sees ["workflow:view", "workflow:run", "workflow:review"] — enough to run and review, not to edit or publish. Drive UI affordances off this array instead of hard-coding role names.

​
Project-to-workflow inheritance

A workflow’s authorization resource is created with its project as the parent. Access flows down that parent link: a role on the project applies to every workflow inside it. This is why FGA is granted at the project level.
Assigning a person a role on a single workflow is not a first-class surface today. The system can model direct workflow-level roles (Workflow Owner / Editor / …), and workflow responses carry capabilities and authz_status — but there is no dashboard flow to grant one member a role on one workflow. When a workflow is created, no separate owner is assigned to it; it simply inherits from its project. To control who can touch a workflow, grant a role on the project that owns it, or move the workflow to a project with the right membership.The exception is access tokens: a token’s grants can target a single workflow (view / edit / run / review / publish), which is how workflow-scoped access is exposed today.

​
Scoped access tokens

A scoped access token (acctk_…) acts as the user who created it, but only through the project and workflow grants placed on it. Unlike an API key (which has full access within its environment), a token can be limited to, say, workflow:run on a single project — or on a single workflow — which makes it the right credential for AI agents and narrow automation.
  • A token grant is rejected unless you already hold that permission on the target — you cannot escalate through a token.
  • Only the grantable permissions above can be placed on a token; the non-grantable ones (*:delete, *:manage) never can.
See Access tokens for how to create, use, and revoke them.

​
How a request is authorized

  1. The request is authenticated to an identity — a dashboard user, or an environment-bound API key.
  2. A dashboard user resolves to an organization membership, which is the subject FGA checks against. An API key has no membership and is treated as full-access within its environment.
  3. For a member, the requested action (e.g. workflow:run on wf_…) is checked against the roles granted on the workflow’s project.
  4. The resolved permissions are returned to you as the capabilities array.

​
Where to go next

Projects

The container these roles are granted on.

Access tokens

Delegate a subset of these permissions to an agent or job.

Access control

The organization → environment → project → workflow model.