People
A workspace starts with one person in it: whoever created it. That person is the Owner. Everybody else is invited in, at a role you choose and can change later.
Nobody in your workspace is a seat you pay for. The plan is one price a month, whether you work alone or with four other people.
How many people a workspace holds
Section titled “How many people a workspace holds”Your plan holds a number of people, set well clear of what a real team needs:
| Plan | People |
|---|---|
| Free | 1 |
| Solo | 5 |
| Studio | 15 |
| Agency | 50 |
The number counts everybody who is here plus every invitation you have sent that nobody has answered yet, so a queue of invitations cannot take you past it. Take an invitation back and its place is free at once, as it is for an invitation that ran out or for somebody you remove.
A free workspace holds one person, so it cannot invite anybody. The number is there to stop a hundred accounts sharing one workspace, and it moves nobody’s invoice.
Over the number, an invitation is turned down when you send it, and again if your plan moved while the link was out there. Clients do not count. They are in no workspace, so inviting one changes nothing here.
Invite somebody
Section titled “Invite somebody”Open Team in the dashboard and choose Invite. Type their email address, pick what they will be able to do, and send it.
They get an email with a link. The link works for fourteen days. They do not need an account here first. Accepting the invitation makes one, and signing in is the whole of it.
Until they accept, they are on the same table as everybody else, after the people already here. Under their address it says Invited and how many days their link has left. As soon as they accept, their row shows the day they joined instead.
The table is a list to read, and you are marked you on it. Everything you can do about one person — what they may do here, the invitation they are holding, and taking them out — is on their own page. Click their row to open it.
What they do with the link
Section titled “What they do with the link”The link opens a page here, and opening it is accepting: there is no separate button to press.
They sign in first, with GitHub or Google. They do not need an account before that — signing in makes one. Then they are in your workspace, and the page takes them to it.
They have to be signed in as the address you invited. Somebody signed in as another address is told which one the invitation was sent to, and can sign in as that one from the page.
Opening the link a second time is safe. It takes them to the workspace rather than letting them join twice.
When a link runs out
Section titled “When a link runs out”Fourteen days after you send it, the link stops working. Somebody who clicks it then is told the invitation expired and who sent it, so they know who to ask for another one. It is not a way into the workspace any more.
The invitation drops off the table soon after, because it is no longer an offer anybody can take up.
Send it again
Section titled “Send it again”Somebody who lost the email gets another. Open their row in the table and choose Send a new invitation.
It is a new link, not the one they lost. They get a fresh fourteen days, counted from the day you sent it, and the link already in their inbox stops working. There is one invitation for that person throughout rather than two, which is why the wording says new: somebody told it was “resent” will go looking for the first email.
There is nothing to copy. The link lives in the email we send and nowhere else, which is what keeps reading a list of invitations from being a way into your workspace.
An invitation has to stand for ten minutes before you can replace it. Sending a second one while the first is still arriving leaves the person holding two links, one of which is already dead.
What each role can do
Section titled “What each role can do”An invitation offers two roles.
- Admin
Reads the workspace, Apps, Functions, environment variables, domains, invocations, runs, schedules, previews and the egress allowlist, and can create Apps, deploy Functions, set environment variables, attach domains, detach domains, run Functions, pause and resume schedules, create previews, widen the egress allowlist, manage credentials and manage members. It does not rename the workspace, change billing or export the workspace.
- Developer
Reads the workspace, Apps, Functions, environment variables, domains, invocations, runs, schedules, previews and the egress allowlist, and can create Apps, deploy Functions, set environment variables, attach domains, run Functions, pause and resume schedules and create previews. It does not rename the workspace, detach domains, widen the egress allowlist, change billing, manage credentials, manage members or export the workspace.
Both read everything in the workspace: the Apps, the Functions, the runs, the schedules, the plan and what has been spent against it. A secret environment variable is masked for both of them, as it is for everybody, including you.
What separates them is what they may change. An Admin governs the workspace: they invite people, create deploy credentials, detach domains, and widen the outbound allowlist. A Developer builds in it: they deploy, set environment variables, attach the domain a site answers at, run a Function, pause a schedule and create a preview, and none of the governing acts are theirs.
Attaching a domain is build work, so a Developer does it. Detaching one is not. It takes a live site dark, so it stays with an Admin, and it is typed with the hostname wherever it happens.
Neither of them can change billing or rename the workspace address. Those two are the Owner’s alone, and there is one Owner.
Change what somebody can do
Section titled “Change what somebody can do”Open Team, open the person, and pick the other role. An Admin becomes a Developer, a Developer becomes an Admin, and nothing else about their account changes. Owners and Admins can both do this.
The change lands on their next request. They stay signed in and they accept nothing again. What somebody may do here is read fresh every time they ask for something. Widen what a contractor holds and they can do the new work at once; narrow it and they are held to the narrower role from their next click.
Narrowing someone’s role also narrows what they handed out. Every deploy credential they created and every connector they approved loses the words the new role does not carry, at the same moment. It keeps the rest and goes on working. One left with nothing is revoked.
Nobody can be made the Owner, and the Owner cannot be moved off it. A workspace with no Owner is one where nobody can change what it pays or the address its customers reach.
The three roles nobody is put at
Section titled “The three roles nobody is put at”The workspace has one Owner, so nobody is invited as one or moved to one. Handing a whole workspace over is not something you can do today.
There is no invitation for a pipeline. Something automated gets a deploy credential of its own, which carries only the words that job needs and can be revoked without anybody losing their account.
There is no read-only person. Somebody who can read everything can read the plan, what the workspace has spent, every App in it and every environment variable that is not a secret, and we would rather you decided about that deliberately than found it on a menu.
Somebody who is already here
Section titled “Somebody who is already here”Inviting an address that already belongs to somebody in the workspace is refused, and the refusal says what they hold. An invitation is an offer to join, so it has nothing to say to somebody who has already joined.
Two spellings of one address are one person. Somebody invited as Ana@example.com who signs in as
ana@example.com is the person you invited.
Being in more than one workspace
Section titled “Being in more than one workspace”You can be in several workspaces at once. Accepting an invitation adds one. It never takes you out of the one you are already in.
The workspace you are working in is named at the top of the sidebar. Click that name and you get every workspace you are in, with a tick beside the one you are in now. Pick another and the dashboard moves to it. The Apps, the Functions, the people, the domains and the plan are that workspace’s from then on.
Picking one takes you back to the overview, because the page you were on named an App or a person of the workspace you just left.
What you last picked is where you come back to. Signing out and in again, or opening the dashboard tomorrow, lands you in that workspace until you pick another one.
Each workspace decides on its own what you can do in it. You can be the Owner of one and a Developer in the next.
If somebody took you out of a workspace while the menu was open, picking it tells you so, drops it off the list, and leaves you working where you were. The same goes for a switch that fails for any other reason: you stay where you are and the menu says so.
Remove somebody
Section titled “Remove somebody”Open Team, open the person, and choose Remove under Danger zone. It is done when the page says so, not scheduled for later. Their very next request here is refused. They stay signed in and nothing has to reach their browser, because their role is read fresh on every request.
They keep their account, and they keep everything they hold in another workspace. Getting back into this one takes a new invitation.
Removing yourself is leaving. Your own page has no Remove. It points you to Account, where leaving is, and the next section says how.
Leave a workspace
Section titled “Leave a workspace”Anybody can leave, whatever their role. Open the menu under your name, choose Account, and choose Leave workspace under Danger zone. Nobody has to do it for you.
What happens is what a removal does. Your very next request here is refused. You keep your account and everything you hold in another workspace, and getting back in takes a new invitation. Every deploy credential you created and every connector you approved is revoked at the same moment, and the Owner is told what stopped, so a pipeline that was running on one is something they already know about.
Sign somebody out
Section titled “Sign somebody out”A laptop goes missing, or a token leaks, and the person should stay in the workspace. Open Team, open the person, and choose Sign out under Danger zone. Owners and Admins can do this.
Their next request here is refused, in every browser and every terminal they are signed in on. The
dashboard in their browser signs itself out within ten minutes, and the terminal is told to run
login again. They keep their role, and signing in again lets them back in at once.
It only touches this workspace. Their other workspaces, and their account, are left alone.
Deploy credentials and connectors are not sessions, so they keep working. If one of them leaked too, revoke it as well.
To do this for yourself, open Account and choose Sign out everywhere under Danger zone. Anybody can, whatever their role. The browser you did it from signs out too.
What they granted goes with them
Section titled “What they granted goes with them”A deploy credential stops working when the person who created it is removed. So does every connector they authorized. Both are revoked in the same moment the membership ends, and nothing un-revokes one.
The reason is what a removal is for. The person walking out is holding the secret. Their session here dies on their very next request, and a token in a config file on their laptop would not, which is the wrong way round.
The removal shows you what it revoked, in two lists: the credentials they created, and the connectors they approved. The Owner is also emailed the list, with the day each credential was last used, so a pipeline that has stopped is one somebody already knows about by name.
If a pipeline needed one of them, create a replacement and set it wherever the old one lived. Nothing is waiting on you while you do it: the person is already out.
Their open drafts are discarded too, and their preview links stop working. Drafts other people opened on the same Functions are left alone. The Remove dialog lists their drafts before you confirm, so you can ask them to finish one first.
The Owner stays
Section titled “The Owner stays”There is one Owner, and while they are the only one they cannot be removed and cannot leave. There is no way to hand a workspace to somebody else today, so an Owner who walked out would leave nobody able to change what the workspace pays or the address its customers reach.
The page tells you this when you try. Nothing half-happens.
Take an invitation back
Section titled “Take an invitation back”Somebody who has not accepted yet is not in your workspace, so there is nothing to remove them from. Open them from the table and choose Revoke invite under Danger zone. The link in their email stops working at once. Invite them again whenever you want to.