How to set up a shared website workspace for a team
A shared login works until someone leaves, a password ends up in a group chat, or nobody can tell who changed the prices. A workspace fixes that: each person signs in as themselves, with a role that fits their job. Here's how to set one up on Anticode's Team plan, and the decisions about publishing and enquiries that the roles alone won't make for you.
How a Team workspace works
The Team plan gives the subscriber a shared workspace with a number of seats, ten by default including the owner. Everything in it (projects, published sites, domains, form data) belongs to the subscriber's account, and other people work inside it. That keeps ownership simple: when someone is removed, their access ends at once and there's nothing to hand back. If the subscription lapses, the workspace stops being shared.
| Role | Can | Can't |
|---|---|---|
| Owner | Everything, including changing others' roles and the subscription | Be removed by anyone else |
| Admin | Invite and remove people, delete projects, take sites down, plus everything a member does | Change anyone's role or the subscription |
| Member | Build, edit and publish | Delete projects or take sites down, invite people |
Setting it up
- Choose the owner carefully. The subscriber should be the business, through an account that won't disappear when one person leaves, such as a founder or a director with a work email.
- Subscribe to Team on the pricing page, and give the workspace a recognisable name.
- Turn on two-factor sign-in for the owner first. A site that collects data can't be published until the account owner and the person publishing have two-factor sign-in, so do it before inviting anyone.
- Invite people by email with the right role. Most people should be members. Make one or two admins, so someone can remove a leaver when the owner is away.
- Ask everyone to turn on two-factor sign-in with an authenticator app, and to store their recovery codes somewhere other than their phone.
- Create the team's projects inside the workspace, so they belong to it from the start.
Decide who publishes
Members can publish, so the roles don't stop a junior colleague putting a draft live. Decide the rule as a team and write it down. Three patterns work for most teams: everyone publishes their own small edits; one or two named people publish anything that touches prices, legal pages or the homepage; or nothing goes live without a second person looking at the preview first. Whatever you choose, version history keeps recent saves (up to the plan's number), so a mistake can be previewed and restored, then published again.
For a second look before publishing, a client review link works internally too: it opens the current preview with no account, and comments attach to specific sections.
Send form submissions to the right channel
Connectors are set for the whole workspace, not per site. Each enabled connector receives submissions from every site in it, labelled with the site's name. For a team running one site, a single Slack, Discord or Telegram channel is usually right. For a team running several sites (a marketing team with campaign pages, say), send submissions to a webhook in an automation tool and route them by site name, so sales enquiries don't land in the events channel. Every submission is also kept in the dashboard, and an access log records the last 200 reads, exports and deletes of form data. There's more in routing contact form enquiries.
When people join and leave
- Joiners get an invitation to their work email, the member role, and a short note on the publishing rule.
- Role changes are the owner's job. Promote to admin only people who'll actually manage access.
- Leavers are removed on their last day by the owner or an admin. Their access ends straight away. Check any automation or channel that still sends enquiries to them personally, and see removing a leaver's website access.
How you know it's set up well
Nobody shares a password. Every person in the workspace still works for you. At least two people can remove a leaver. Everyone who can read form data has two-factor sign-in on. And when a change goes live, the team knows who was allowed to publish it.
Limits
- Three roles only. There's no publish-only, read-only or per-project permission.
- Connectors are workspace-wide. Route by site name if you run several sites.
- Seats are counted, pending invitations included. Check the number on your plan before inviting a large group.
Questions people ask
Can I stop members from publishing?
Not with a role setting: members can build, edit and publish. Agree a publishing rule as a team, and use version history to restore anything published by mistake.
What happens to projects when someone leaves?
Nothing moves. Projects and sites belong to the workspace owner's account, so removing a person only ends their access.
How many people can be in a workspace?
The Team plan includes ten seats by default, counting the owner. The Agency plan has its own seat count; see the pricing page.