Collaboration, Comments and Activity Log

This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production.

This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages.

This page describes how teams collaborate inside a Webflow site as it was on 2026-10-28, the date on which its facts were checked against the official Webflow Help Center, the Webflow updates feed and the developer reference. Webflow is a software-as-a-service product with no version numbers, so everything below is dated rather than versioned, and the Product Changes and Deprecations page tracks what changes afterwards. Plans are named by tier only. Where a capability depends on the plan, the page says which tier, and the Plans, Workspaces, Seats and Roles page explains what each seat and role can do.

The running example is Fernbrook Gardens, a fictitious botanical garden. Its team is small and mixed: Marta designs pages, Idris writes the Garden Journal, a volunteer reviewer checks the Visit page copy before the spring opening, and a developer connects an AI agent to the site through the MCP server. All of them touch the same site on the same day, and the features below exist so that they do not overwrite one another, can leave feedback where the problem is, and can later reconstruct who changed what.

Four mechanisms, four questions

Collaboration in Webflow is not one feature. Four mechanisms answer four different questions.

Mechanism Question it answers When it applies

Real-time collaboration

Can two people edit the same page at the same moment?

While the Designer is open, as the changes happen

Comments

Where exactly is the problem, and has it been dealt with?

From the first draft to the review, on the canvas and on CMS content

Site Activity log

Who changed what, when, and through which route?

After the fact, as an audit trail

Agent presence

Which AI agent is working on which part of the site right now?

While an agent connected through the MCP server is editing

The first, second and fourth are live and visual; the third is a record. Using them together is what allows a human team and AI agents to share one site without a handover step.

Real-time collaboration

The Webflow Help Center describes real-time collaboration as the ability for several teammates to work in the Designer on the same site at the same time, editing elements, classes, styles and content without refreshing the page or taking turns. Each person’s canvas updates as the others make changes.

What you see while others work

When other teammates are working in the site, their avatars appear at the top of the canvas toolbar. A coloured outline appears around the element a teammate is working on, so everyone can see which part of the page is occupied and avoid working on the same element. For Fernbrook Gardens this means that while Marta restyles the hero section of the Visit page, Idris can open the same page and fix a heading in the intro section without waiting for her to finish.

When two edits collide

Real-time collaboration is not a locking system. The Help Center states that when edits overlap, the last change that reaches Webflow’s servers is the one that is saved. Two practical consequences follow.

  • Do not edit the same property of the same element together. If Marta and Idris both change the font size of one heading, the later change wins and the earlier one is lost without a conflict dialog. The coloured outline is the cue to pick another element or to agree out loud.

  • Text is synchronised on blur. Text changes are not synchronised keystroke by keystroke; they are synchronised after the person clicks out of the text block. A colleague therefore does not see a sentence grow as it is typed.

Availability and limits

The Help Center article on real-time collaboration, checked on 2026-10-28, says the feature is available on all sites and plans, including single-user sites, and that the opt-out setting in Site Settings was removed on 25 February 2026, so it can no longer be switched off per site. An earlier version of the same article stated a limit of 25 concurrent users per site; the current article does not repeat that figure, so a team that expects a large number of simultaneous editors should read the article again before depending on any number.

Real-time collaboration is about people in the same copy of a page. Enterprise sites that need each designer to work on an isolated copy, for example for a redesign that must not appear until it is approved, use page branching instead; it is described in Page Branching, Releases and Approvals.

Who can enter the Designer

Collaboration is bounded by seats and roles. Only people with a Designer-capable seat can edit styles and structure; content editors work through the on-canvas editing mode described in Content Editing on the Canvas, and reviewers can look and comment but not change the design. The roles are covered in Plans, Workspaces, Seats and Roles.

Comments

Comments let a person attach feedback to the exact place it concerns. They are the main channel through which people who do not build the site, such as the volunteer who checks the Visit page copy, take part in its production.

Who can comment

The Help Center on commenting states that all Workspace roles can use comments, including guests and Reviewers. A Reviewer is a restricted role intended for stakeholders: it gives access to view the site and to comment, without a full Designer seat. This is why a Reviewer can leave a comment on a heading and cannot restyle it. The distinction matters when a client or a volunteer should give feedback without being able to break the design, and it is the reason the Fernbrook volunteer is invited as a Reviewer rather than as a Designer.

Comment mode and shortcuts

Comments are created in Comment mode. According to the Help Center you enter it by clicking the comments icon in the top toolbar or by pressing C. The keyboard shortcuts are summarised below.

Key Effect

C

Enter Comment mode to create a comment, and open or close the comment side panel

Shift+C

Hide the comments on the canvas, or show them again

The Webflow update of 13 November 2025, titled See comments on the canvas while you work, describes how this changed the workflow: comments are visible on the canvas without switching into Comment mode, and while you keep designing you can hover over, reply to, react to and resolve comments. Before this, resolving a comment required leaving the design mode. Shift+C exists for the opposite need, when a crowded canvas of open comments gets in the way of the layout work and you want them out of sight without resolving them.

A comment’s life

A typical comment follows a short cycle.

  1. A reviewer enters Comment mode and clicks the element, for example the opening-hours table on the Visit page.

  2. The reviewer writes the feedback. Teammates can be mentioned so that they are notified.

  3. The designer sees the pin on the canvas and in the comments panel, replies, and changes the page.

  4. When the change is done the comment is resolved, which removes it from the active view.

Because a comment is anchored to an element rather than to a screenshot, it stays attached to the right place while the page is rearranged, and the thread keeps the discussion together instead of scattering it over email and chat.

Comments on CMS content

Static elements are only half of a site. At Fernbrook Gardens most of the Garden Journal and the Plants pages come from the CMS: the page layout is a collection template page, and the words and pictures come from items. Feedback on such content used to be awkward, because a reviewer could not point at a dynamic element and say what was wrong with it.

The update titled On-canvas CMS commenting, announced in May 2025 as part of the overhaul of the commenting experience, closes that gap. It lets reviewers leave comments on CMS-bound elements of template pages, directly on the canvas. The update describes these points.

  • Dynamic elements are marked. Elements bound to CMS content have a purple border, so a reviewer can tell at a glance whether the heading belongs to the template or to the item.

  • Comments are labelled. A comment says whether it is attached to a dynamic or a static element, both on the canvas and in the comments panel.

  • The view can be narrowed. You can filter the comments so that only those tied to the CMS item you are currently editing or previewing are shown.

This matters for the reasoning about where a fix belongs. A comment on a static element is fixed in the Designer by changing the template. A comment on a dynamic element is usually fixed by editing the item in the CMS. The label and the purple border tell the person resolving the comment which of the two is needed. The template mechanism itself is explained in Collection Template Pages, and the editing route for the item in Content Editing on the Canvas.

A review round at Fernbrook Gardens

Before the spring opening the team runs a review round on the Garden Journal.

  1. Marta publishes the newest template changes to the staging address and invites the volunteer as a Reviewer.

  2. The volunteer opens a journal post, presses C, and comments on the dynamic title: "Use the common name of the plant first." The comment is labelled as attached to a dynamic element.

  3. Idris filters the comments to the item he is editing, sees only this post’s feedback, changes the title in the CMS item, and resolves the comment.

  4. The volunteer also comments on the static Subscribe box in the template. Marta fixes it in the Designer and resolves it.

  5. Idris publishes the item; the template change goes out with the next site publish. The publishing rules for items and sites are in Publishing and Scheduling.

No part of the round needed a separate tool, and every fix is traceable to a comment.

Comments and automation

The Webflow announcement of the new commenting experience of 2025 lists, next to the CMS commenting, further additions: custom code renders while in Comment mode, so reviewers can comment on pages that depend on embeds; comment notifications can be sent to other tools through Zapier, Make or APIs; and comments can receive emoji reactions. A team that follows its feedback in a ticket system can therefore forward comments there rather than asking reviewers to leave Webflow.

The Site Activity log

Comments describe what people want changed. The Site Activity log records what was actually changed. The Help Center describes it as a panel in the Designer that tracks important changes to the site: what was changed, when, and by whom.

What it records

The log covers the activity that affects the live product: design updates, changes to CMS collections and to collection items, page settings, and publishing events. It is a record of important events and not a version-control history. In particular, it does not necessarily show the exact before-and-after value of every change, so it answers "who published and when" better than "what was the previous colour code". For recovering earlier states, use the mechanisms in Backups and Recovery.

Who can see it and on which plan

Any team member with the Content editor site role or above can see the log and its details. As for the plan, the sources on Webflow’s own sites differ, and both are stated here so that a team can check its own workspace.

  • The Help Center article on the Site Activity log, checked on 2026-10-28, describes the feature as available for Enterprise customers and Enterprise partners.

  • The Webflow University lesson on the log describes it as available on Platform plans.

  • The developer reference for the Site Activity log API requires an Enterprise workspace.

The tier names change over time. Before planning an audit process around the log, open the panel in the site, and treat the Enterprise requirement as the safe assumption for the programmatic API.

Source attribution: human, Webflow AI and MCP

The Webflow update titled Track AI and MCP changes in your Site Activity Log adds an attribution label to every entry recorded after the feature was introduced. An entry is labelled as made by a human, by Webflow AI, or through MCP. The Source filter in the panel offers three choices: all sources, Webflow AI, and Webflow MCP. The MCP choice covers changes made by an MCP-connected tool such as an AI coding assistant.

Details worth remembering:

  • Not retroactive. Attribution applies to activity recorded after the feature became available; older entries have no source label.

  • On by default. The update presents it as available on Enterprise, switched on by default, with no setup.

  • Credited to a person. The MCP server attributes each change to the user who authorized the connection, so an AI edit appears under the name of the person whose agent made it, with the source marking it as an MCP change. A service credential shared by several people would blur this, because every change would then appear under one identity.

  • Filtering narrows the work. The Filter dropdown in the Site activity panel narrows the list by activity type, for example CMS or publish events, as well as by source.

For Fernbrook Gardens the practical use is a morning check. Before the weekly publish, Marta opens the log, filters by Webflow MCP, and sees the edits that the developer’s agent made to the Plants collection overnight. She reviews them on the canvas before publishing instead of finding out afterwards. The agent side is described in MCP Server and AI Agents.

Reading the log from code

The log can also be read programmatically, for example to feed a security-information tool or a dashboard. The Data API exposes a list endpoint for site activity logs. According to the developer reference it requires an Enterprise workspace and the site_activity:read scope, and it paginates with a maximum of 100 records per request. The update on AI attribution mentions that the response carries an enriched generatedBy field exposing the same attribution, which tools can use for audit pipelines.

# List recent activity of the Fernbrook Gardens site. The token and the site id are placeholders.
curl --request GET \
  --url "https://api.webflow.com/v2/sites/<SITE_ID>/activity_logs?limit=100" \
  --header "Authorization: Bearer <YOUR_ACCESS_TOKEN>" \
  --header "accept: application/json"

Source: https://developers.webflow.com/data/reference/enterprise/site-activity-logs/list.mdx

The token must be created with the site_activity:read scope; scopes and the authentication models are covered in Data API Authentication and Scopes, and the Enterprise interfaces in Enterprise APIs and Governance.

Agent presence

The log shows completed changes. It does not show an agent that is working at this moment. Agent presence fills that gap. It was announced in the Webflow updates feed in October 2026 as a way to see AI agents on the Designer canvas the way you see teammates.

What it shows

When an agent connected through the Webflow MCP server is editing the site and the Designer is open, the Designer displays it.

  • An agent avatar, marked with a sparkle, appears in the top bar next to the human avatars.

  • The element the agent is editing is highlighted.

  • A border runs around the page or component the agent is working on.

  • Agent avatars appear next to pages and components in the Pages and Components panels, so you can see which pages are busy before opening them.

The indicators cover agents that you connected yourself and agents that teammates connected. They apply to agents using the MCP server, such as Claude, Codex, Cursor or ChatGPT; the Webflow AI Assistant is not covered yet. The Designer must stay open for the indicators to appear, and the Webflow community post announcing availability states that agent presence is available in all workspaces at no additional cost.

Why it is useful

Real-time collaboration prevents collisions between people by showing coloured outlines. Agent presence applies the same idea to agents, with one extra benefit: an agent can change many elements quickly, and a human who sees the border around the Plants template page knows to wait, or to ask the agent’s owner to stop it, before starting on that page.

Presence (live) Activity log (afterwards)

Shows

Who or what is editing now

What was changed and who or what changed it

Human edits

Avatar and coloured outline

Entry labelled as human

Agent edits

Sparkle avatar, highlight and border

Entry labelled Webflow MCP or Webflow AI

Purpose

Avoid collisions, wait for the result

Review, audit, troubleshooting

Putting it together

A workable routine for a team like Fernbrook Gardens follows from the mechanisms above.

  1. Invite by role. Designers get Designer seats, writers work through content editing, and outsiders such as the volunteer are invited as Reviewers who can only view and comment.

  2. Talk on the canvas. Use comments with mentions, on static elements in the template and on CMS-bound elements, and resolve them as the fixes land.

  3. Watch the outlines. Look at the avatars and coloured outlines, including the sparkle avatars of agents, before starting on a page; do not edit the same property in parallel, since the last write wins.

  4. Review the trail. Before each publish open the Site Activity log, filter by source and by publish or CMS activity, and confirm that every change is expected.

  5. Isolate big work. For a redesign that must not collide with daily edits, use page branching rather than relying on real-time collaboration; see Page Branching, Releases and Approvals.

Limits to keep in mind

  • Real-time collaboration is last-write-wins; it neither locks elements nor merges conflicting edits.

  • Text edits become visible to others only after the editor leaves the text block.

  • Comments and agent presence need the Designer or the on-canvas view to be open; neither replaces a ticket system or an approval step.

  • The Site Activity log is an event record. It is not a backup, and entries from before source attribution have no source label.

  • Plan availability of the log is stated differently by different Webflow pages; confirm it in the workspace.

References