You give each person the narrowest role that lets them do their job. Webflow has roles at the workspace level and at the site level, plus a guest option for outside collaborators. Set them deliberately when you invite someone, and the accidental homepage edit stops being possible rather than just unlikely.
Almost every Webflow permissions problem we see started the same way. Somebody needed to update one blog post, an admin was in a hurry, and the fastest option was full access. Nobody meant to hand over the whole site. It just happened one invite at a time.
The fix is not complicated, but it does have to be done on purpose. Here is how the pieces fit together and how we set them up on client sites.
Webflow University states that "the main site roles in Webflow are Admin, Designer, and Content Editor". Admins get full access to site settings, publishing, and everything in the Designer. Designers can build and edit in the Designer with limited access to some admin settings. Content Editors only get the Webflow Editor.
That third role is the one most teams underuse. The Editor is the simplified interface for updating text, images, and CMS content, and it deliberately keeps people out of the design. A marketer who needs to publish blog posts does not need the Designer, and giving it to them creates a risk with no matching benefit.
Webflow separates these from workspace roles, which govern access to the workspace as a whole. As Webflow University puts it, "while workspace-level roles determine overall access to your Webflow workspace, site roles let you get more specific about permissions on a per-site basis." You assign site roles when you invite somebody to a site, through the site's share settings.
The mental model that helps is to think of the workspace as the building and each site as a room. Workspace roles decide who gets through the front door. Site roles decide which rooms they can enter once inside.
A member has standing access to the workspace. A guest only reaches the specific sites you name. Webflow University describes the guest role as letting you "invite collaborators to your Workspace who only need access to specific sites, not your entire Workspace", which is exactly the shape of most outside relationships.
There is a billing difference too, and it is significant. Webflow states that "workspace members require a paid seat, guests are free to add, though they'll need to be on a site plan that supports guest access." So the narrower option is also usually the cheaper one, which is a rare and welcome alignment.
You add guests the same way you add members. Go to Workspace settings, open Members, choose to invite a guest rather than a member, enter their email, and pick which sites they can reach. You then set their role for each site separately, so the same person can be an Editor on one site and an Admin on another.
Invite them as guests on the specific sites they are working on, and keep ownership of the workspace yourself. Webflow's guest flow is built for this, and it means an agency can work without you transferring the site or sharing a login. When the engagement ends, you remove the guest and the access disappears.
We work on the client side of this arrangement constantly, so we will say the quiet part out loud. A studio asking for the workspace owner account, or for your login, is asking for more than the job requires. Guest access to the relevant sites is enough for us to design, build, and publish.
The reason this matters is offboarding. If access was granted through a shared password, you can never be sure it is gone. If it was granted through a named guest invite, removing it takes one click and leaves a clear record. That difference shows up in every security questionnaire we have ever filled in.
It also makes handover much cleaner at the end of a project. We wrote about the rest of that process in our guide to handing off a Webflow site to a client, and permissions are the part people most often leave until it is too late.
Granular access control lets you restrict a person to specific pages, specific CMS collections, or a single locale within one site. Webflow University says it is "available on Enterprise plans" and describes it as letting you "decide exactly which part of the site each person can touch".
This is the level most large teams actually need. Standard site roles are all or nothing within their scope, so a Content Editor can edit any content. Granular controls turn that into a per-person map of what is editable and what is merely visible.
The examples Webflow walks through in its own lesson are the realistic ones. Limiting a marketer to a single CMS collection, locking a pricing specialist to just the pricing page, and stacking restrictions for a regional translator who works in one locale. If those situations sound like your team, this is the feature you are missing.
The plan requirement is real, and it is worth knowing before you design a workflow around it. Several of Webflow's governance features sit behind the same tier, including page branching and approvals. Our guide to Webflow plan limits covers what else changes as you move up.
Open your site settings and go to Site access, find the person, and click into their access settings. Under CMS, deselect every collection and then select only the one they need. Under Pages, leave nothing selected. Save, and their access is now scoped to that single collection.
What that person sees afterwards is the useful part. Webflow describes the result as the other collections being "visible, but they're view-only", while restricted pages can be clicked through but not changed. Nothing disappears from view, so the site still makes sense to them. They simply cannot alter anything outside their lane.
We like this behaviour because it avoids a common support problem. When you hide things entirely, people assume something is broken and message you about it. When things are visible but locked, the boundary explains itself and nobody files a ticket.
You can stack the three restriction types together for one person. A regional translator might be limited to one locale, a subset of pages, and one CMS collection at the same time, which is roughly the tightest scope Webflow offers without moving to custom roles.
Custom roles let you define your own permission sets instead of picking from Webflow's defaults. Webflow University explains that "instead of being limited to a fixed set of roles like Designer, Editor, or Admin, you can create custom roles with precise permission sets tailored to your organization's needs".
You build them in Workspace settings under Roles. You name the role, then configure what it can reach, including which sites, which publishing environments, which CMS collections, and which locales. Once the role exists you assign it to workspace members or to guests, and their access everywhere follows from that definition.
The publishing environment control is the one worth highlighting. Webflow's own example is a contractor who needs to publish to staging but not to production. That single distinction removes most of the risk of outside collaboration while leaving the contractor able to work independently.
Webflow describes custom roles as part of a broader governance toolkit "alongside features like page branching, approvals, and audit logs". Those pieces are designed to work together, and evaluating any one of them in isolation tends to undersell the set.
Fewer people than currently can. Publishing is the only action in Webflow that is instantly visible to the public, so it deserves a tighter list than editing does. Our default on client sites is that everyone can edit and a small named group can publish to production.
This is where we disagree with how most teams set things up. Publishing rights get handed out for convenience, because waiting for someone else is annoying. Then a half-finished section goes live on a Friday afternoon, and the convenience turns out to have been expensive.
The compromise that works is generous staging access and strict production access. Let people publish to staging freely so they can test their own work properly, and keep the production step with whoever owns the site. Nobody feels blocked, and nothing reaches customers unreviewed.
Every quarter, and always at the end of a project. Access lists only grow on their own. People join, contractors finish, agencies rotate staff, and none of those events removes anybody automatically unless somebody makes it their job. Put the review on a recurring calendar invite so it actually happens.
The review itself is quick. Open your workspace members list and your site access list, and for each name ask whether that person did anything on this site in the last three months and whether they still need the level they have. Anyone you hesitate over gets downgraded rather than removed, which is easy to reverse.
Tie it to offboarding as well. When a project ends or a person leaves, removing their Webflow access should sit in the same checklist as their email and their password manager. It is the item that gets forgotten most often, because Webflow is not usually the system anyone thinks about first.
Open your Webflow workspace right now and look at the members list. For every person with Admin or Designer access, ask whether they genuinely need to change the design. Most teams find at least one person who only ever edits content and could be a Content Editor instead.
Then fix the invites you send from here on. Decide the role before you send the invite rather than upgrading later, and use guests for anyone outside your organisation. Getting this right at the moment of invitation is much easier than auditing it back down afterwards.
If you are setting up a Webflow workspace for a bigger team and you want a second opinion on how to scope the roles, we are happy to talk it through. We set this up on every site we build and hand over. Let's talk, and you can find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.