Chapter 10: Stakeholder Collaboration (4.A)
Exam topic 4.A: Manage stakeholder access, permissions, and publishing workflows.
Exam topic 4.A: Manage stakeholder access, permissions, and publishing workflows.
Key terms: Workspace roles, site roles, content editor role, Designer role, Reviewer role, branching, approvals.
Weight: 8% of the exam (about 4 questions)
A Visual Developer builds the site, and also builds the workflow around it. Who can change styles? Who can publish? How do marketing edits get approved? How do two designers avoid overwriting each other? This topic is about matching people to the right permissions and designing safe paths to production.
Webflow’s role names and plan availability change over time, so focus on the concepts: workspace vs. site permissions, least privilege, separation of design and content, review before publish, and isolated work (branching).
10.1 Two layers of access: Workspace and site
| Layer | Controls | Typical decisions |
|---|---|---|
| Workspace roles | Membership of the workspace (team/agency/company), billing, creating sites, managing members, workspace-wide settings | Who administers the account? Who can create or delete sites? |
| Site roles | What a person can do on a specific site: design, edit content, comment/review, publish, manage settings | Who can change this client’s styles? Who can only edit blog posts? |
A person can have different site roles on different sites, so a freelancer can be a Designer on one site and have no access to others.
The principle: least privilege
Give each person the minimum access needed for their job. This:
- prevents accidental changes (a marketer breaking a global class),
- limits damage from compromised accounts,
- makes audits and offboarding straightforward.
10.2 The core roles and what they’re for
| Role (concept) | Can typically… | Can’t typically… | Who |
|---|---|---|---|
| Owner / Admin (workspace) | Manage billing, members, sites, permissions | — | Agency lead, client’s web owner |
| Designer (site) | Build structure, styles, components, interactions; manage settings depending on permissions | Workspace billing | Visual Developers, designers |
| Content editor (site) | Edit text, images and CMS items in Edit mode; publish content if permitted | Change structure, classes, components’ design | Marketing, copywriters, clients |
| Reviewer / Commenter | View the site in the Designer, leave comments, take part in reviews/approvals | Edit design or content | Stakeholders, legal, executives |
Design mode vs. Edit mode
Webflow separates Design mode (structure and styles) from Edit mode (content). Content editors work in Edit mode: they change text, swap images, manage CMS items and edit component properties you exposed (Chapter 3), but can’t alter the system. This is why good component properties and CMS architecture matter: they define what editors are allowed to change.
Matching roles to stakeholders (exam pattern)
- “A marketing team member needs to update blog posts weekly but must not alter the design” → Content editor.
- “A legal reviewer needs to comment on page copy before launch” → Reviewer/Commenter.
- “A freelance developer will build new landing page sections” → Designer on that site only.
- “The client’s CTO needs to manage billing and add team members” → Workspace Admin/Owner.
10.3 Comments and review
- Comments can be pinned to elements on the canvas, threaded, @mention collaborators, and be resolved when done.
- Use comments for feedback instead of screenshots in email, so the context stays with the element.
- Run reviews on the staging site as well (Chapter 11), because stakeholders should experience the real published behaviour (interactions, forms, custom code), which the canvas doesn’t fully show.
10.4 Branching
Page branching lets a designer create a branch of a page, work on it in isolation while the main version stays untouched and publishable, then request review and merge the approved changes back.
Why it matters:
- A redesign of the homepage can be built over two weeks while urgent copy fixes continue to be published on the main version.
- Changes are reviewed before they reach the main version.
- It reduces conflicts when multiple designers work on the same site.
This is the same idea as Git feature branches: isolate work, review it, then merge.
Branching and some approval features are available on specific plans (typically Enterprise). The exam tests the concept.
10.5 Approvals and publishing permissions
Approvals add a gate: changes (e.g. a branch, or content) must be approved by an authorised reviewer before they can be merged or published.
Publishing permissions control who can publish, e.g. designers can publish to staging, but only admins can publish to the production domain.
A mature workflow:
Designer builds on a branch
→ requests review
→ Reviewer comments; Designer revises
→ Approver approves and merges
→ Publish to staging → stakeholder QA
→ Authorised person publishes to production
For smaller teams without branching, a lighter version works: build → publish to staging → review with stakeholders → fix → publish to production, with production publishing limited to specific people.
10.6 Content workflows
- Drafts and scheduled publishing for CMS items let editors prepare content without it going live (Chapter 5).
- Publishing individual CMS items lets editors ship a blog post without publishing pending design changes. That’s important when a designer has unfinished work in progress.
- Separate design and content responsibilities: designers own the system; editors own the content within it.
- Handoff documentation: a short guide or Loom-style walkthrough for editors, plus a style guide page (Chapter 4), cuts support requests.
10.7 Offboarding and security
- Remove access when contracts end. Agencies often transfer the site to the client’s workspace at the end of a project.
- Prefer individual accounts over shared logins. Shared credentials remove accountability and make offboarding impossible.
- Review roles periodically.
- Keep API tokens and app authorisations tied to accounts the organisation controls (Chapter 8).
Practice questions: Stakeholder Collaboration
Q1 A marketing coordinator needs to publish blog posts and update homepage copy but must not change layouts or styles. Which access is most appropriate?
Show answer
Answer: b. Content editors edit content (including CMS and exposed properties) without changing the design. (a) and (c) far exceed the need. (d) shared logins break accountability.
Q2 A legal stakeholder must review and comment on landing page copy before launch without being able to edit anything. Which role fits?
Show answer
Answer: b. Reviewers/commenters can view and comment without editing. (a), (c) and (d) grant edit or admin abilities.
Q3 (Multi-select) Which principles should guide permission assignment? (Choose two.)
Show answer
Answer: a and b. Least privilege and individual accounts are security and accountability fundamentals. (c) and (d) are the opposite.
Q4 A homepage redesign will take two weeks, but the current homepage needs urgent copy fixes published during that time. Which feature best supports this?
Show answer
Answer: b. Branching isolates the redesign while the main page stays live and editable. (a) duplicates sites, which is messy. (c) blocks business needs. (d) exposes unfinished work.
Q5 What’s the role of approvals in a publishing workflow?
Show answer
Answer: b. Approvals are a quality and governance gate. (a), (c) and (d) false.
Q6 A stakeholder needs to see updates before they go live on the production domain. Which workflow is most effective?
Show answer
Answer: b. This mirrors the official sample answer: staging review before production. (a) risks errors going live. (c) screenshots miss interactions and responsiveness. (d) duplication drifts.
Q7 A designer has unfinished style changes in progress, but an editor needs to publish a new blog post today. What’s the best option?
Show answer
Answer: b. Publishing individual CMS items ships content without publishing pending design changes. (a) pushes unfinished work. (c) and (d) block or disrupt work unnecessarily.
Q8 (Multi-select) An agency is ending a project. Which steps are good practice? (Choose two.)
Show answer
Answer: a and b. Ownership transfer and removing unneeded access are clean offboarding. (c) shared passwords are a security risk. (d) tokens tied to a departing person will break or remain a risk.
Q9 Why should content editors work in Edit mode rather than having Designer access?
Show answer
Answer: b. Edit mode restricts editors to content and exposed properties, protecting structure and styles. (a) not the purpose. (c) false; designers can edit CMS. (d) false.
Q10 Where should feedback on a specific element be captured to keep context for the designer?
Show answer
Answer: b. Pinned comments keep feedback attached to its context and trackable to resolution. (a) loses context. (c) and (d) are misuse.
Q11 What’s the difference between Workspace roles and site roles?
Show answer
Answer: b. Workspace = organisation-level; site = per-site capabilities.
Q12 A company requires that only the web lead can push changes to the production domain, while designers can publish to staging. What should you configure?
Show answer
Answer: a. Publishing permissions restrict who can publish where. (b) violates least privilege. (c) removes a safe review step. (d) shared login.