Webflow Roles & Team Workflow

How the CAS web team is organized in Webflow, what each role can and cannot do, and the standard workflows for publishing content, building pages, and managing translations.

Last Updated: April 7, 2026 | Audience: Everyone

Team Roles in Webflow

Every person who touches CAS.org in Webflow has a specific role that determines what they can access and what actions they can take. These roles are set at the workspace and site level by the web team lead (Jimmy). If you are unsure of your role or need your permissions adjusted, contact Jimmy.

Web Developers

Webflow role: Site Admin (Can Design & Publish) on a full seat.

Web Developers have unrestricted access to the Webflow Designer and all site settings. They are responsible for the site's architecture, design system, components, CMS collection schemas, custom code, interactions, redirects, integrations, and full site publishing. Web Developers are the only team members who should make structural changes to the site.

Day-to-day work includes: building and modifying page layouts, creating and updating reusable components, managing CMS collection fields and schemas, writing custom code and embeds, configuring HubSpot form integrations, managing 301 redirects, branching pages for staged changes, and publishing the full site to cas.org.

Solution Marketers

Webflow role: Can Edit & Publish (Content Editor) on a limited seat.

Solution Marketers have the same Webflow permissions as Content Editors. The difference is organizational, not technical: Solution Marketers own the content strategy for their solution areas, while Content Editors handle the execution of routine publishing tasks. In Webflow, both roles can edit text, images, and links on existing pages, and both can create, edit, and publish individual CMS items.

Day-to-day work includes: writing and updating solution page copy and CTAs, managing CMS items related to their solution area (relevant CAS Insights articles, webinars, gated content), updating SEO title tags and meta descriptions on their pages, coordinating with Content Editors on publishing schedules, and submitting requests to Web Developers for any page structural changes, new components, or custom code needs.

What Solution Marketers cannot do: build new pages, modify page layout or structure, edit the design system, create new styles or classes, change CMS collection schemas, or edit custom code. If a solution area needs a new landing page, page redesign, or component that doesn't exist yet, submit a request to a Web Developer through ClickUp.

Content Editors

Webflow role: Can Edit & Publish (Content Editor) on a limited seat.

Content Editors work within the established page layouts and CMS structure to create and manage content. They are the primary publishers of routine content: CAS Insights articles, webinars, events, speakers, and gated content. They can edit text, images, and links on existing pages, and they can create, edit, and publish individual CMS items.

Day-to-day work includes: creating and publishing CMS items following the relevant SOPs (CAS Insights, Webinars, Events, Gated Content), editing text and swapping images on static pages, managing image optimization and alt text per the Image & Media Guidelines, and responding to review comments.

What Content Editors cannot do: add or rearrange page elements, create new pages, modify styles or layout, edit custom code or embed elements, change site settings, or publish the full site. Content Editors can publish individual CMS items, which is the right way to push content live without affecting other in-progress work.

Linguists

Webflow role: Can Edit (Content Editor, publishing restricted) on a limited seat.

Linguists work in secondary locales to review and refine translations that have been pushed from Smartling. They use the locale switcher in Webflow to view content in each language, verify translation quality, and make minor corrections to translated text.

Day-to-day work includes: reviewing translated content in secondary locales (pt-br, ko, es-es, zh-hans, ja), making minor text corrections in the locale switcher, flagging translation issues for the Smartling workflow, and verifying that translated CMS items display correctly.

What Linguists cannot do: publish the full site (a Web Developer handles this after translations are verified), edit the English locale (English is managed by Content Editors, Solution Marketers, and Web Developers), modify layout or design, or create new pages or CMS items. Linguists work exclusively in secondary locales.

Role Summary

Here is a quick comparison of what each role can do:

Edit text, images, and links on existing pages: Web Developers, Solution Marketers, Content Editors, Linguists (secondary locales only).

Create and publish CMS items: Web Developers, Solution Marketers, Content Editors.

Update page SEO settings: Web Developers, Solution Marketers, Content Editors.

Build new pages: Web Developers only.

Modify layout, styles, and components: Web Developers only.

Edit custom code and embeds: Web Developers only.

Manage CMS collection schemas: Web Developers only.

Publish the full site: Web Developers only.

Set up redirects: Web Developers only.

The Three Rules

Regardless of your role, these three rules apply to everyone working in Webflow on CAS.org:

1. English First

All content is created and finalized in the English locale before it goes to translation. English is the source of truth. Changes to secondary locales should only happen through the Smartling translation workflow or by Linguists making approved corrections. Never create original content directly in a secondary locale.

2. Publish Items, Not the Site

Solution Marketers and Content Editors should publish individual CMS items, not the entire site. Publishing the full site pushes all pending changes across every page, including other people's work in progress. Only Web Developers publish the full site, and they coordinate timing to ensure nothing unfinished goes live.

3. Escalate, Don't Workaround

If your role doesn't let you do something you think needs doing — a layout change, a new component, a custom code addition, a CMS schema modification — that's by design. Submit a request to a Web Developer through ClickUp. Don't try to hack around role limitations with embed code, inline styles, or creative workarounds. Those shortcuts create technical debt that compounds over time.

Standard Workflows

Publishing a CMS Article or Resource

This is the most common workflow on the site. Used for CAS Insights articles, webinars, events, speakers, and gated content.

1. Content Editor (or Solution Marketer for their solution area) creates the CMS item in the English locale following the relevant SOP.
2. Fills all required fields: title, slug, body content, images (AVIF, optimized), alt text, SEO fields, taxonomy references, and toggle settings.
3. Previews the item on the staging URL to verify it displays correctly.
4. Publishes the individual CMS item. The content goes live on cas.org within minutes.
5. If translation is needed: submits a localization request to the coordinator. The Smartling workflow handles translation (5–10 business days). Linguists review in Webflow. A Web Developer publishes the site to push translations live.

Requesting a New Page or Page Change

Since Solution Marketers and Content Editors cannot build or restructure pages, all new page requests and structural changes go through Web Developers.

1. Solution Marketer or Content Editor creates a ClickUp task in the CAS.org Redesign project describing what is needed: a new landing page, a page redesign, a new section on an existing page, or a new component.
2. Include as much context as possible: the page URL (if modifying an existing page), a rough outline or wireframe, the copy and images, and the target launch date.
3. Web Developer reviews the request, creates a page branch if modifying an existing page, and builds or modifies the page.
4. Web Developer shares the staging URL for review. Stakeholders add comments directly on the page.
5. After approval, Web Developer merges the branch (if applicable) and publishes the site.
6. Solution Marketer or Content Editor can then manage the content on the page going forward.

Making Structural or Design Changes

Used for page redesigns, new component creation, CMS schema changes, and design system updates. This workflow is exclusively handled by Web Developers.

1. Web Developer creates a page branch of the page being modified (see Navigation & URL Conventions for branching details).
2. Web Developer makes all layout, component, and styling changes on the branch. The live page is unaffected.
3. Web Developer shares the staging URL with stakeholders for review. Reviewers add comments directly on the branch.
4. After approval, Web Developer merges the branch back to the main page.
5. Web Developer deletes the branch and publishes the site.

Updating Translations

Used when English content changes or new content needs to be available in secondary locales.

1. Content Editor or Solution Marketer finalizes and publishes the English content. The English version must be complete and approved before translation begins.
2. Submits a localization request specifying the page URL, the content that changed, and the target locales.
3. The localization coordinator triggers the Smartling workflow. Smartling ingests the English content, routes it to professional translators, and leverages translation memory for consistency.
4. Translations are pushed back to Webflow via the Smartling API into the appropriate secondary locales.
5. Linguists review the translated content in Webflow using the locale switcher. They check for text overflow, translation accuracy, and proper rendering of CJK characters.
6. Web Developer publishes the full site to push translations live on cas.org.

Fixing a Bug or Urgent Issue

Used for broken pages, display issues, incorrect content, or dead links that need immediate attention.

1. Whoever discovers the issue reports it to the web team lead (Jimmy) with the URL, a screenshot, and a description of the problem.
2. If it's a content issue (wrong text, missing image, outdated information): the Content Editor or Solution Marketer fixes it directly and publishes the CMS item.
3. If it's a structural issue (broken layout, missing component, code error): a Web Developer fixes it in the Designer and publishes the site.
4. If it's a translation issue (incorrect translation, missing locale content): the Linguist corrects it in the locale switcher and a Web Developer publishes.

Comments & Review

Webflow's built-in commenting system is the primary tool for review and feedback on CAS.org. Comments are tied to specific elements on the page, keeping feedback contextual and actionable.

How to Use Comments

• Adding a comment: Click on any element on the page and use the comment icon (or keyboard shortcut) to add a comment. Tag specific team members using @mentions.
• Responding: Reply to comments in the thread. Keep responses concise and actionable.
• Resolving: Once the feedback has been addressed, resolve the comment to keep the thread clean. Only resolve comments you have actually addressed.

When to Use Comments vs. Other Channels

• Use Webflow comments for page-specific feedback: copy corrections, image swaps, layout questions, design feedback on a specific section.
• Use ClickUp for project-level tasks: new page requests, feature development, multi-step workflows, and anything that needs tracking across sprints.
• Use Slack or email for urgent issues, questions that need a quick answer, or coordination that doesn't relate to a specific page element.

Publishing Etiquette

Publishing on CAS.org requires care because multiple people may be working in the system simultaneously.

CMS Item Publishing (Solution Marketers & Content Editors)

Publishing an individual CMS item is safe and isolated. It only affects that specific item. You do not need to coordinate with others before publishing a CMS item. However, always preview before publishing to catch errors.

Full Site Publishing (Web Developers Only)

Publishing the full site pushes every pending change on every page and every CMS item. Before publishing the full site:

• Announce in the team Slack channel that a site publish is coming.
• Verify there are no in-progress page branches or unfinished design changes.
• Check that no one is actively editing content that isn't ready to go live.
• Publish and confirm the live site is functioning correctly.

Requesting Changes Outside Your Role

When you need something your role cannot do, follow this escalation path:

• Need a new page or landing page? Submit a ClickUp task under the CAS.org Redesign project. Include the page purpose, target audience, copy, images, and target launch date.
• Need a page restructured or redesigned? Submit a ClickUp task with the page URL, a description of what needs to change, and a wireframe or sketch if possible.
• Need a new component? Submit a ClickUp task describing the component's purpose, where it will be used, and any design references.
• Need a CMS schema change? (new field, new collection, field modification) Contact Jimmy directly. CMS schema changes affect all existing items and require careful planning.
• Need custom code or integration? Submit a ClickUp task with the requirements, the target page, and any third-party credentials or documentation needed.
• Need a redirect? Submit a ClickUp task with the old URL path, the new URL path, and the reason for the redirect.
• Need translation? Submit a localization request to Jimmy or the localization coordinator with the page URL and target locales.

Quick Reference

• Web Developers: Full Designer access. Build, design, code, publish everything.
• Solution Marketers: Content Editor role. Edit content, manage CMS items for their solution areas, update SEO. Cannot build pages or modify layout.
• Content Editors: Content Editor role. Edit content, create and publish CMS items. Cannot build pages or modify layout.
• Linguists: Content Editor role (no publish). Edit secondary locales only. Cannot publish the site.
• Always create content in English first.
• Publish CMS items individually (not the full site).
• Escalate to Web Developer for new pages, layout changes, code, schema, or structural changes.
• Use Webflow comments for page-specific feedback.
• Use ClickUp for project tasks and change requests.