Skip to main content

Roles: Member, Admin, Owner

Every member of an organization holds one of three roles. Role decides what you can do at the org level -- it does not, by itself, grant access to other people's projects or workflows.

The three roles​

RoleWhat it adds
MemberCreate your own projects, workflows, triggers, credentials. Share what you own.
AdminEverything a member can do, plus: install Apps, configure org infrastructure, manage members, and audit-view other members' work.
OwnerEverything an admin can do, plus: billing, plan changes, ownership transfer, organization deletion.

Roles are cumulative -- an admin is a member, and an owner is an admin.

What each role can do​

Member (default)​

A member can:

  • Create and edit their own projects, workflows, triggers, and credentials
  • Share their own resources with specific teammates (see Visibility and Sharing)
  • Run any workflow they own or have been given access to
  • Install workflow templates from the org marketplace into their own projects
  • Export their own workflows as templates

A member cannot see another member's private projects, install org-wide Apps, or change billing.

Admin (adds org-level configuration)​

An admin can do everything a member can, plus configure the organization itself:

  • Install Apps and MCP servers -- the integrations everyone in the org can use
  • Manage LLM configurations -- which models are available, with which credentials
  • Manage runtimes -- the execution environments workflows run in
  • Manage routing rules -- how inbound messages reach workflows
  • Manage org-shared credentials -- secrets that any workflow can read
  • Set branding -- logos, colors, organization profile
  • Manage members -- invite, change roles, remove (with heir transfer)

Admins also get audit-view: read-only visibility into every project, workflow, and trigger in the org, even those marked private. This exists for compliance and incident response.

Owner (adds billing and the nuclear options)​

An owner can do everything an admin can, plus:

  • Change the subscription plan
  • Manage billing details and invoices
  • Transfer ownership to another member
  • Delete the organization

There is exactly one owner per organization.

Important: admin gives audit-view, not edit override​

This is the part most people get wrong on first read.

An admin can see another member's project, but cannot edit it.

Only the creator of a project, workflow, or trigger can edit it. Admin visibility is a read-only window for audit and oversight -- it does not grant authority to rename, rewire, or delete someone else's work.

If an admin needs to take over a resource (because the creator left, or to consolidate ownership), the correct paths today are:

  • Member leaving the org? Use the member removal flow -- it transfers everything to a chosen heir.
  • Member still here but stepping back? Have them share the resource with the admin, or export it as a template the admin re-installs.
Coming soon

A dedicated ownership transfer flow is planned so admins can hand off resources without removing the member. Until then, use the patterns above.

Why the split?​

Audit-view-without-edit-override is deliberate. Two reasons:

  1. Predictability. When you build a workflow, you want certainty that no one else can change it underneath you. If an admin could edit your workflow without telling you, your runs would become non-deterministic from your perspective.
  2. Audit posture. Admin oversight should look like oversight, not like silent editing. The activity feed records share and access events; admin edits would muddy that signal.

Learn more​