Team access
Everyone in a workspace is either an admin, who may do everything, or a member whose access is set per area of a project: scripts, flows, runs, schedules and the rest, each at None, Read, Edit or Delete. The same rule answers every request — the web app, live streams, MCP tokens and the Desk — so nobody gets further through one door than through another.
- Tell an admin, a project’s creator and a member apart
- Add a person and set their access per area on the Users tab
- Limit someone to a single project
- Read the two refusals: a 404 for what you cannot reach, a 403 for what you cannot do
Who may do what
Three kinds of people work in a workspace. An admin may do everything in every project of the workspace. The person who created a project may do everything in that project, whatever their access says. Everyone else is a member, and a member’s access is a grid: one level per area, the same in every project they reach.
The levels build on each other: Read lets a person see an area; Edit adds creating, changing and running; Delete adds removing. None hides the area: its page tells the person You don’t have access to … in this project.
The areas
These are the rows of the Access per area grid, with the description the grid shows under each one.
| Area | What it covers |
|---|---|
| Scripts | Code, folders, running a script |
| Flows | Flows and their runs |
| Runs | History, output and logs |
| Schedules | When things run on their own |
| APIs | Endpoints and tokens |
| Integrations | Connections, S3, proxies |
| Variables | Project variables (values of secrets stay hidden) |
| Providers, templates, sending | |
| AI scrapers | Building and running scrapers |
Reserved for admins and the creator
- Revealing a secret’s value — a project variable marked secret, an integration’s credential. Members with Edit use secrets in what they run; they never read them.
- The project’s settings, and connecting or disconnecting its Git repository.
- The Users tab itself: only admins add people and change their access, and nobody changes their own.
Add a person
- Open the Users tab
On the Projects page, open Users and press Add user.
- Fill in who they are
Under Basic information give the full name and e-mail, and a first password of at least 8 characters. The person is asked to change it on their first login.
- Set their access
Turn on Admin for someone who may do everything — the grid goes inert. Otherwise pick None, Read, Edit or Delete on each row. The line under the grid says whether the choice takes a seat.
- Optionally limit them to one project
Under Project Access, Restrict to a single project keeps the person inside one project, where they land after login. An admin cannot be limited.
- Create the user
Press Create user. To change access later, open the person and press Edit user; Deactivate user blocks their sign-in without deleting anything they made.
The two refusals
A project a person cannot reach — one that does not exist, one in another workspace, or one outside their single-project limit — answers 404, and the three look exactly alike, so nobody can probe for project ids. A project they reach but an action their level does not cover answers 403 with the code access_denied, the area, the level they have and the level the action needs.
The app asks first instead of failing after the click: a control the person cannot use is shown disabled, with a sentence such as Your account can view scripts in this project, but not change them. An admin of the workspace can give you more access.
Seats
On a licensed self-hosted installation, people count against the license’s seats. A person occupies a seat when they are an admin or have Edit or Delete on at least one area, and they are active or invited. Read-only people are free, and so are deactivated or suspended accounts. When every seat is taken, giving someone more than Read is refused until a seat frees up.