- Webflow & CMS
How to Set Up CMS Editor Access in Webflow for Your Nonprofit Team
Key takeaways
- The legacy Webflow Editor was retired on 4 August 2026. Access is now a seat plus a role, and very few people should hold Site manager or Designer.
- The Content editor role is the right level for communications and content staff: they can edit text and publish CMS items but cannot alter layouts, page slugs, or custom code.
- Apply the principle of least privilege and keep a documented record of who holds which access, so permissions match roles and can be traced.
- A common security failure is former staff or contractors retaining active access, so build access revocation into a formal offboarding step on someone's last day.
- Content editors can publish CMS items even when site publishing is switched off for them, so decide a publishing policy: trust-and-process, draft-first, or restricted publishing for high-stakes content.
- When working with an external agency, agree access levels upfront and ensure the nonprofit always owns its own Webflow workspace and site, with collaborator access revoked at project end.
Summary
How to configure Webflow content access for a nonprofit team: the seats and roles that replaced the legacy Editor, what a Content editor can and cannot do, and how to set up access correctly at handover.
The Problem This Post Solves
A nonprofit website is only as useful as the people who can update it. Most organisations have at least one person who can technically log into Webflow. Far fewer have established who is allowed to change what, how content gets reviewed before it goes live, and what happens when the person who built the site leaves.
One thing has changed since this guide was written: the legacy Webflow Editor, the separate ?edit interface, was retired on 4 August 2026 and replaced by seats and roles. Handover notes that say "ask for Editor access" now describe a screen that does not exist.
This guide covers how to set up Webflow's roles and permissions for a nonprofit context and, more importantly, how to establish the governance structure that makes those permissions meaningful.
Webflow's Permission Tiers: What They Are
Access works in two layers: a seat lets someone into your Workspace or a site, and a role decides what they can do once inside. Webflow publishes its site roles and what each can do. Three matter for a nonprofit running one site.
Site Manager and Designer
Full access to the Webflow Designer, where the site is built. Between them these two roles can:
- Change layouts, styles, and structural elements
- Create, edit, and delete CMS Collections and fields
- Access and modify custom code
- Publish the whole site
Site settings, billing, backups and transferring the site out of the Workspace are reserved to Site manager. This is full administrative control, and very few people at a nonprofit should hold either role: typically whoever is responsible for the technical build, and at most one trained senior internal stakeholder.
Content Editor
The content-focused role, and the one Webflow assigned to legacy Editor users at migration. There is no separate interface any more: a Content editor works inside Webflow, clicking editable text and images on the page. Webflow documents the boundary:
- Edit text, links, and images on static pages, in context on the canvas
- Create, edit, delete, and publish CMS Collection items (blog posts, team profiles)
- Upload and organise assets, and manage alt text on images
- Change page settings: password protection, SEO title and description, Open Graph
- Cannot make design changes, structural, style, or element settings
- Cannot rename a page, edit page folders or slugs, or set a homepage
- Cannot touch custom code, CMS settings, or create new Collections
This is the appropriate access level for communications staff, content managers, and anyone who updates website content as part of their role.
Reviewer
View and comment, nothing more: for a trustee who needs to see work before it goes out. Reviewer seats are free. There is no longer a billing-only access level; Workspace billing sits with the Owner and Admin roles, and a site's plan and billing with Site manager.
Webflow Workspaces and Team Seats
Full and limited seats cost money, so they cap how many people can hold the paid roles. Webflow sells full seats for the design roles and limited seats for Marketer and Content editor, and an unlimited number of both may be purchased. Client seats are the exception. They exist only in the workspace plans sold to service providers, they come with the plan, and additional ones cannot be purchased at this time: Starter includes one per paid site, Freelancer one per site, and Agency three per site.
If you're working with an external agency or consultant (like me through the Monthly Partnership), they'll typically hold the design roles in their own workspace and give your staff the Content editor role on a client seat. The specifics should be established clearly at project outset.
Count your editors before you agree that arrangement, because the client-seat allowance is small and cannot currently be topped up. A comms team of four cannot all sit on client seats under one supplier's workspace. Beyond the allowance, the extra people need paid limited seats, which means either your supplier buys them and bills them on, or your organisation holds its own workspace and seats directly. That is a purchasing decision with a recurring cost, and it is better settled at project outset than discovered the first time a fourth person needs to publish.
What Webflow Permissions Don't Cover
Webflow's permissions handle the technical question of who can do what. They don't handle the governance questions: who should make which decisions, what review content goes through before publication, or how to handle urgent updates when key people are unavailable.
Those questions require a governance policy: a document that lives outside Webflow and governs how the platform is used. See my guide on website governance policies for nonprofits for how to structure this.
Setting Up Roles in Practice
Identify Your Content Management Needs First
Before assigning roles, map out what content needs to change, how often, and who on your team can realistically maintain it. Common needs:
- News and blog posts (ongoing)
- Events and programme information (seasonal)
- Team profiles (occasional, triggered by staff changes)
- Homepage and key landing pages (infrequent, high-stakes)
- Funder and partner acknowledgements (occasional)
This tells you how many content accounts you need, where the boundaries sit, and how much the CMS structure itself is carrying.
Apply the Principle of Least Privilege
Give people access to what they need to do their job, nothing more. This isn't about distrust. It's about reducing the risk of accidental changes by people who didn't intend to make them. Someone who holds only the Content editor role cannot delete a page layout or break a navigation structure, regardless of what they click.
Document Who Has What Access
Maintain a simple record of who holds which role and when it was granted. This is basic governance hygiene: when someone leaves, you need to know what to revoke. In Webflow, a Workspace member is removed from Workspace settings, under Team; a client seat is emptied from Site settings, under Site access and then Clients.
Establish an Offboarding Process
A common access security failure I see is former staff or contractors still holding active Webflow access months or years after they've left. Build a formal step into offboarding: when someone leaves, their access is revoked on their last day.
The Publishing Decision: Who Can Publish What?
Publishing the whole site is a per-member toggle on Growth and Agency plans, but it does not close the door: members restricted from publishing can still publish individual CMS items that don't affect in-progress designs. So a team member with the Content editor role can write a blog post and make it live without any review. Depending on your communications policy and risk tolerance, that may or may not be appropriate.
Options for managing publishing governance:
- Trust and process: Content editors can publish, but are expected to follow internal review procedures. This requires strong internal culture and suits experienced, communications-trained staff.
- Draft-first policy: Editors always save as draft and notify the Communications Director for review and publishing. This adds friction but ensures a review stage.
- Restricted publishing for key content: High-stakes content (homepage updates, major programme announcements) needs review by a Site manager or Designer, while routine CMS content (blog posts, event listings) goes out directly.
Document your publishing policy as part of your website governance framework: my website governance policies guide carries a template structure, and content governance covers what it looks like in practice.
Agency and Consultant Access
If you work with an external agency or Webflow consultant, establish clearly:
- What role they hold (Site manager, Designer, Marketer, or Content editor)
- Whether they access via your Webflow account or their own
- What happens to that access when the project ends
- Who retains the site if the relationship ends (you should always retain ownership)
The standard arrangement: the nonprofit owns the workspace and site, and agencies join it as guests (free for up to two guest teams) holding a design role for the project's duration, with that access revoked or transitioned at the end.
Two-Factor Authentication
Webflow supports two-factor authentication (2FA), set up from Account settings under the Security tab. Any account with a design role on your site should have 2FA enabled. This is non-negotiable: a compromised Site manager account can take your site offline, change domain settings, or delete content.
For content accounts it is strongly recommended, and especially important for anyone with authority to publish public-facing content.
Connecting Access Governance to Your Broader Website Governance
Role and permission management is one part of a framework that also covers content review, update procedures, performance monitoring, and emergency protocols. For the complete picture, see my guides on website governance policies and the content audit framework. If you're planning a new site or a major update, the Blueprint Audit reviews your current governance arrangements and recommends the structure you'll need.
Two clicks. Three things.
Send the address of your website. Within two working days you get a short email naming the three things a funder would hold against it, including what AI assistants like ChatGPT and Google’s AI Overviews currently say about you. No report, no call, no follow-up unless you ask.
Received. Your three things arrive within two working days.
That did not send. Email hello@socialectric.com with your website address and I will reply from there.
Frequently asked questions
- What is the difference between Designer and Editor access in Webflow?
The legacy Editor, the separate content interface reached by adding
?editto a page URL, stopped being available on 4 August 2026. Its nearest replacement is the Content editor role, and Webflow assigned exactly that role to legacy Editor users at migration. The design roles, Site manager and Designer, are the equivalent of full administrative control: changing layouts, styles and structural elements, creating and deleting CMS Collections and fields, and reaching custom code, with site settings, billing, backups and site transfer reserved to Site manager. A Content editor works inside Webflow on the page itself, editing text, links and images, creating and publishing CMS items, and managing assets, without design access. Content editors cannot change layouts or styles, cannot reach custom code, and cannot rename a page, edit a page slug or set a homepage.- Who on our team should have Designer access?
Very few people. Typically the person or agency responsible for the technical build, and possibly one senior internal stakeholder who has been trained and understands the consequences of structural changes. Everyone else who updates content as part of their role, communications staff and content managers, should hold the Content editor role. The principle is least privilege: it is not about distrust, it is that someone with only content access cannot accidentally delete a page layout or break the navigation, whatever they click. The prior question is whether your team can maintain the site at all.
- Can someone with Editor access publish straight to the live site?
Largely yes. Publishing the whole site is governed by a Can publish toggle that Growth and Agency Workspace plans can switch on or off per member, but Webflow notes that members restricted from publishing can still publish individual CMS items that do not affect in-progress designs. So a team member with the Content editor role can write a blog post and make it live with no review at all. Whether that is appropriate depends on your communications policy and risk tolerance. There are three workable approaches: trust and process, where trained staff publish but follow an internal review procedure; a draft-first policy, where editors save as draft and notify the Communications Director; or restricting publishing for high-stakes content such as homepage updates while routine posts and event listings go straight out. Whichever you pick, document it.
- What should happen to Webflow access when someone leaves?
It should be revoked on their last day, as a formal step in your offboarding process. A common access security failure is former staff and contractors still holding active Webflow access months or years after they have gone. Keep a simple record of who holds which role and when each was granted, so you know what to remove. A Workspace member is removed from Workspace settings, under Team; someone on a client seat is removed from Site settings, under Site access and then Clients.
- If an agency builds our site, who should own the Webflow account?
You should. The standard recommended arrangement is that the nonprofit owns the Webflow workspace and the site, and agencies or consultants join it as guests, which Webflow supports at no cost for up to two guest teams. Agree at the outset what role they hold, whether they work through your account or their own, what happens to that access when the project ends, and who retains the site if the relationship ends.
- Do we need two-factor authentication on Webflow accounts?
Any account with design access should have it enabled, and that is non-negotiable: a compromised Site manager account can take your site offline, change domain settings or delete content. For content accounts it is strongly recommended, and especially important for anyone with the authority to publish public-facing content.