Members
Who is in your workspace and what each person may do there. Only an Owner sees this page.
Roles
Every member holds one of five roles. Each role holds everything the one before it holds, plus one more thing, so choosing a role is a single question: how much should this person be able to change?
Roles are listed here, and everywhere you pick one, from least able to most. Owner carries a ★ wherever it appears.
| Role | Can |
|---|---|
| Viewer | See the automations and everything they are built from, read-only—automations, runs and logs, the approvals queue, templates, agents, connections and their status, variables, content types. Change nothing. |
| Operator | Also run automations, stop runs, turn automations on and off, and answer approvals. |
| Builder | Also create and change automations, agents, content types, variables, secrets and templates, and use the Build page. |
| Admin | Also see and manage settings and savings rates, and manage connections and MCP servers—including connecting and disconnecting them. |
| Owner ★ | Also manage the members of the workspace: invite, change roles, archive and reinstate. |
A role applies to one workspace. Someone can be an Owner in one workspace and a Viewer in another.
Settings and Savings Rates appear only for an Admin or an Owner. They configure the workspace rather than describe any automation, so a role that cannot change them has nothing to read there.
Secret values are never shown to anyone, whatever their role. Connections show their status to every role, but only an Admin or Owner can connect, disconnect, or change one.
Inviting someone
Open + Invite, enter an email address, optionally a name, choose a role, and click Invite.
- Where the deployment signs people in through an external provider, the person simply signs in with that email; the invitation email says so.
- Where people sign in with a password, the email carries a single-use link to set one.
- If no mail sender is configured, the page shows you the link to pass on instead.
Someone who is already a member of another workspace on the same instance is added to yours without a second account. Their name is whatever they already had.
Access requests
Where the deployment signs people in through an identity provider, someone who signs in without having been invited is not given an account. Instead their sign-in is recorded as an access request, and they see a message saying so. Requests appear at the top of the Members page for every Owner, oldest first, with the person's name and email as the provider reported them.
Each request offers the two different things you might do about the person, kept apart:
- Add to this workspace—choose a role and click Add. They get a place here and an email saying so.
- Or give them a workspace of their own, named …—a system administrator only. The name defaults to the person's email and can be anything; Create makes the workspace and the requester its Owner.
- Decline, at the top right, turns the request down. A declined email stays declined: signing in again does not create a new request.
Who is emailed when a request arrives is decided per workspace by a system administrator, with a checkbox at the top of the request list that only they see: the Owners of every workspace marked to receive requests, or, when none is marked, the system administrators. The list itself is visible to every Owner regardless.
The table
| Column | What it shows |
|---|---|
| Member | Avatar and name. Until the person has signed in for the first time, the name is taken from their email. |
| The address they sign in with. | |
| Role | A select. Changing it takes effect at once. |
| Status | Invited until the person has signed in once, then Active. Archived when their access has been removed. |
| Last Active | When they last signed in. |
| Archive removes their access to this workspace. Reinstate gives it back, with the role they had. |
Show Archived lists former members alongside current ones, so they can be reinstated and so the workspace's history is visible.
What you cannot do
- Leave the workspace without an Owner. The last Owner cannot be demoted or archived. Make someone else an Owner first.
- Delete a person. Archiving removes access to this workspace and nothing else. The person keeps their other workspaces, and their name stays on the history of what they did here.
- Manage a system administrator. The people who run the deployment have access to every workspace and never appear in this list.
Related
- Settings—the workspace-wide settings an Admin manages.
- Connections—what an Admin connects for the workspace.