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's editor. 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.

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

Webflow has three primary access levels for site collaborators. Understanding what each can and can't do is the starting point for setting up appropriate governance.

Designer Access

Full access to the Webflow Designer — the visual editor where the site is built. People with Designer access can:

• Change layouts, styles, and structural elements
• Create, edit, and delete CMS collections and fields
• Modify site settings including publishing
• Access and modify custom code
• Change domain settings

This is the equivalent of full administrative control. Very few people at a nonprofit should have this level of access. Typically: the person or agency responsible for the technical build, and potentially one senior internal stakeholder who has been trained and understands the consequences of structural changes.

Editor Access

Access to the Webflow Editor — the content-focused interface that allows text, image, and CMS item editing without exposing structural or design controls. People with Editor access can:

• Edit text content on static pages
• Create, edit, and publish CMS items (blog posts, team profiles, etc.)
• Upload images to existing image fields
• Cannot change page layouts, styles, or structural elements
• Cannot access site settings or custom code

This is the appropriate access level for communications staff, content managers, and other team members who need to update website content as part of their role.

Billing Only

Limited access for managing subscription and billing information. Not typically relevant to day-to-day governance.

Webflow Workspaces and Team Seats

At the workspace level (above individual sites), Webflow has additional permission tiers that control who can access and manage multiple sites within an agency or team account. For nonprofits managing a single site, the site-level permissions above are the primary consideration.

If you're working with an external agency or consultant (like me through a retainer arrangement), they'll typically maintain Designer access in their own workspace and add you to your site as an Editor. The specifics of how access is structured vary by working arrangement and should be established clearly at project outset.

What Webflow Permissions Don't Cover

Webflow's built-in permissions handle the technical question of who can do what in the platform. They don't handle the governance questions of who should make which decisions, what review process 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 any roles, map out what content on your site needs to change, how often, and who currently has that knowledge. Common content management needs for nonprofits:

• 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 mapping exercise tells you how many Editor accounts you actually need and where the boundaries should sit.

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 has only Editor access cannot accidentally 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 has Designer access, who has Editor access, and when each person was granted those permissions. This is basic governance hygiene — when someone leaves the organisation, you need to know to revoke their access. In Webflow, you can revoke access from Site Settings → Editors.

Establish an Offboarding Process

The most common access security failure I see is organisations where former staff or contractors still have active Webflow access months or years after they've left. Build a formal step into your offboarding process: when someone leaves, their Webflow access is revoked on their last day.

The Publishing Decision: Who Can Publish What?

In Webflow, Editor-level users can publish CMS items directly. This means a team member with Editor access can write a blog post and make it live on your website without any review. Depending on your organisation's communications policies and risk tolerance, that may or may not be appropriate.

Options for managing publishing governance:

• Trust and process: Editor-level staff can publish, but are expected to follow internal review procedures before doing so. This requires strong internal culture and is only appropriate for 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) requires Designer-level review before publishing, while routine CMS content (blog posts, event listings) can be published by Editors directly.

Document your publishing policy as part of your website governance framework. See the content governance section of my website governance policies guide for a template structure.

Agency and Consultant Access

If you work with an external agency or Webflow consultant, establish clearly:

• What level of access they have (Designer or 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 of your own Webflow site)

The standard recommended arrangement: the nonprofit owns the Webflow workspace and site. Agencies and consultants are invited as collaborators with Designer access for the duration of the project, and that access is revoked or transitioned at project end.

Two-Factor Authentication

Webflow supports two-factor authentication (2FA) for user accounts. Any account with Designer access to your site should have 2FA enabled. This is non-negotiable — a compromised Designer account can take your site offline, change DNS settings, or delete content.

For Editor accounts, 2FA is strongly recommended but especially important for accounts used by people with authority to publish public-facing content.

Connecting Access Governance to Your Broader Website Governance

Role and permission management is one component of a broader website governance framework. The others include content review processes, update procedures, performance monitoring, and emergency protocols.

For the complete governance picture, see my guides on website governance policies and the content audit framework. If you're in the process of planning a new site or major update, the Blueprint Audit includes a review of your current governance arrangements and recommendations for the structure you'll need.