Page Branching, Releases and Approvals

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 the team-scale safety features of Webflow as they were on 2026-10-28, the date on which their facts were checked against the official documentation. Webflow is a software-as-a-service product with no version numbers, so everything below is dated rather than versioned. Plans are named by tier only. Page branching, branch staging, design approvals and the publishing workflow are, according to Webflow’s documentation, Enterprise features: they are offered to Enterprise customers and Enterprise Partners, and other customers contact Webflow’s Enterprise team to use them. The Plans, Workspaces, Seats and Roles page explains the tiers, and Publishing and Scheduling explains what every plan can do without these features.

The running example is Fernbrook Gardens, a fictitious botanical garden. Its team wants to redesign the Plants collection template page for the spring season while editors keep publishing Garden Journal posts. The redesign must not leak onto the live site until a reviewer has approved it, and the whole site is promoted from staging to production only after someone has read what is about to change.

Why a visual builder needs branches

In a code repository, a branch lets several people change the same project without stepping on each other, and a pull request lets a reviewer approve the change before it is merged. A visual builder has the same problem with fewer tools: two designers who edit the same page at the same time change the same classes, and a half-finished redesign is, from that moment, the design of the site. Without isolation, teams fall back on duplicating pages by hand, naming them Plants (new) and hoping that nobody publishes them by accident.

Webflow’s answer has four parts, and each solves a different problem.

Feature Problem it solves Scope

Page branching

Work on a page without touching the live copy

One page, or a few pages, each in its own branch

Branch staging

Look at the branch rendered on a real URL before merging

One branch, published to its own staging address

Design approvals

Require a named person to approve before a branch is merged

One review per branch

Publishing workflow

See and control what moves from the staging site to production

The whole site

Releases

Branch and stage a whole site, with CMS content and assets, as one launch

The whole site (announced at Webflow Conf 2026)

Page branching

Page branching creates an isolated copy of a page, called a branch, that you can change freely. The page on the main site is untouched until the branch is merged. Webflow documents the following behaviour.

  • One active branch per page. A page cannot have two branches at once. A second attempt is refused, and the Branches API reports it as the error page_cannot_branch.

  • Isolation. Edits in the branch are not visible on the main site, on its staging address or in production.

  • Merge overwrites the original. Merging a branch replaces the original page on the main site with the branch. Content edits that were made to the original page while it was branched are lost after the merge. This is the most important consequence to teach a team: the branch is a snapshot of the page, not a three-way merge of text.

  • Conflicts are resolved before merging. If classes, states or main components were changed both on the main site and in the branch, those conflicts must be resolved before the merge can complete. The Designer asks which version to keep.

  • Pulling from the main site. A branch can be updated with the latest changes from the main site so that it does not drift, which is why a branch can report that it needs an update.

The CMS is shared

A branch isolates the design of a page, not the content of the site. CMS items belong to the site, so a branch of the Plants template page shows the site’s items, and an item that an editor publishes while the branch exists appears in the branch preview as well. The consequence is useful: a designer can check a new template against real, current plants instead of copies. The corresponding limit is that a branch cannot be used to try out a content-model change such as a new field; structural changes to collections belong to the site, and the CMS Concepts and Content Modeling page covers how to roll them out safely. Whole-site isolation, including CMS content, is what Releases is designed for; see Releases.

Branch staging

Branch staging publishes a single branch to its own staging environment. Webflow announced it for Enterprise customers and Enterprise Partners as a way to test designs faster, review custom code fully rendered and catch problems earlier. The documented properties are:

  • the branch is published to a staging subdomain that is separate from the site’s main staging subdomain and from any custom staging domain;

  • the staged address shows a snapshot of the full site, so a reviewer can see how the branch affects the rest of the site, such as a navigation bar that links to the redesigned page;

  • each branch has its own address, so three branches can be staged at the same time and each URL can be shared with the stakeholders who need to review it;

  • stakeholders can leave feedback by commenting directly on the build in Webflow, and the free commenter role exists so that reviewers do not need a paid seat (see Collaboration, Comments and the Activity Log).

Custom code matters here. Interactions and scripts are not run on the canvas the way they run in a browser, so a branch that adds a script to the Plants page can only be judged on the staged URL. Fernbrook uses this to check that the Plant Finder filter script still works after the redesign, using the technique from Custom Code in the Head, Footer and Embeds.

Real-time collaboration on a branch

On 2026-07-17 Webflow launched real-time collaboration for page branching for all Enterprise customers. Multiple people can view and edit the same branch at the same time, presence indicators show who is working on what, and a review can be approved live before the merge. The safeguards that existed before stay in place: one branch per page, protected edits during merge and publish, and a single active review at a time. A team that previously serialized branch work (one designer at a time per branch) can now work in parallel inside a branch, which matters for a launch with a deadline.

The branching workflow end to end

The Fernbrook spring redesign follows this sequence.

gitGraph commit id: "Live site" commit id: "Journal post published" branch plants-redesign checkout plants-redesign commit id: "New template layout" commit id: "Seasonal hero" checkout main commit id: "Journal post edited" checkout plants-redesign commit id: "Pull from main site" commit id: "Branch staged for review" checkout main merge plants-redesign id: "Approved and merged" commit id: "Published to production"

Read the diagram from the top. The main line is the site as it stands. The designer branches the Plants template page. While the branch exists, the main site keeps changing (an editor edits a Journal post), so the designer pulls the latest main-site changes into the branch before staging it. After review and approval the branch is merged, and only then does the next publish carry the new template to visitors. The names are those of a git history because the model is the same; Webflow does not expose commits, and a branch is not a git branch.

Branching through the Branches API

Enterprise workspaces with the page-branching entitlement can automate the same lifecycle through the Branches API. The API is documented as a beta of Data API v2: its endpoints live under https://api.webflow.com/beta, require branches: OAuth scopes, and answer every request with a 403 and the code not_enterprise_plan_site if the workspace lacks the entitlement. Creating, deleting, updating and merging are asynchronous; they return 202 with a task ID that you poll until it is finished or failed. A branch reports a status of ready, needs_update, has_conflicts, updating or merging and suggests the next actions. If it has conflicts, you list them and send a resolution for every one in the update or merge request; a merge without resolutions fails with 409 branch_merge_conflict, and an incomplete set fails with 400 invalid_resolution. Webhooks exist for branch_created, branch_merged and branch_deleted; a merge deletes the branch automatically and does not fire branch_deleted. If recent edits are still syncing, an endpoint can return 503 branch_sync_pending, and the client should retry with exponential backoff.

The example below polls a task until it finishes. It uses a placeholder token read from the environment and a placeholder task identifier, and the exact path of the task endpoint must be taken from the reference because the API is in beta.

const token = process.env.WEBFLOW_API_TOKEN!;

async function waitForTask(url: string): Promise<unknown> {
  for (let attempt = 0; attempt < 10; attempt++) {
    const res = await fetch(url, { headers: { Authorization: `Bearer ${token}` } });
    if (res.status === 503) {
      // branch_sync_pending: back off and retry
      await new Promise((r) => setTimeout(r, 500 * 2 ** attempt));
      continue;
    }
    const task = await res.json();
    if (task.status === "finished" || task.status === "failed") return task;
    await new Promise((r) => setTimeout(r, 1000));
  }
  throw new Error("Task did not finish in time");
}

Source: Webflow developer documentation: Branches API overview

Because the API is a beta, treat the paths and error codes above as a snapshot of 2026-10-28 and read the reference before building on them. See Data API: Sites, Pages and Components for the stable page endpoints and Enterprise APIs and Governance for the rest of the enterprise surface.

Design approvals

Design approvals make a review a condition of merging. They are an Enterprise feature that gates when a page branch can be merged into the live site. The documented rules are:

  • Designers and custom roles that do not have the "Make changes without approval" permission need an approved review before they can merge. Roles that have it can merge without one.

  • The requester opens the Branch tab and chooses Request review, then picks reviewers. Some reviewers can be marked required and others optional; the branch can be merged once all required reviewers have approved.

  • Reviewers compare the branch against the live site, leave comments or request revisions. Site managers, designers and reviewers can approve a review.

  • Reviewers cannot be added after the request is sent: the requester cancels the request and sends a new one.

  • Reviewers, content editors and marketers cannot merge branches. Approving and merging are separate powers.

  • There is a single active review at a time per branch, and a branch must have no unresolved conflicts to merge.

The Reviewer role, which Webflow describes in its University material, exists for people such as a legal officer or a marketing director who must look at work but should not change it; its permissions are explained in Plans, Workspaces, Seats and Roles.

A review for Fernbrook

Step Who What happens

1

Designer

Branches the Plants template page, edits it, stages the branch and posts the staging address in the team channel

2

Designer

Opens the Branch tab and requests a review from the Design lead (required) and the Education manager (optional)

3

Reviewers

Compare the branch with the live page, comment on the canvas and either approve or request revisions

4

Designer

Fixes the comments; if revisions were requested, a new request is made

5

Design lead

Merges the approved branch into the main site

6

Site manager

Publishes, using the publishing workflow described next

The publishing workflow

Merging a branch changes the design of the main site; it does not change what visitors see. The publishing workflow is the Enterprise feature that controls the next step. Instead of publishing from the Designer straight to every domain, the team publishes first to the staging subdomain or a custom staging domain, looks at the result, and then publishes the staged site to production.

The prepublish summary

Before publishing, the workflow shows a prepublish summary. According to the help article, it presents:

  • the differences between the Designer and the staging site, and between staging and production;

  • the changes that are tracked in the Site Activity log, and which teammates made them.

Changes to site settings are not included, with the exception of custom code changes. Webflow’s guidance for Enterprise teams is to review this summary and the detailed changes in the activity log before publishing. The summary is the visual-builder equivalent of reading a diff before releasing, and it is the reason to prefer the workflow over ad hoc publishing on a site with many editors.

Staging to production

With the workflow turned on, the team publishes from the Designer to staging, checks it on the staging address, and then publishes from staging to production. A change that fails review on staging never reaches visitors. The documented limitation is that the publishing workflow cannot be used on a site that has Logic flows set up. The staging site is a real, public address, so a team that stages sensitive content should combine it with the controls in Password Protection and Site Search.

How the pieces compose

Stage Where the change lives Who can see it

Branch

An isolated copy of one page

The people working in or reviewing the branch

Staged branch

A branch-specific staging address with a snapshot of the whole site

Anyone who holds the URL, such as stakeholders and testers

Main site (merged)

The design of the site, not yet published

The team in the Designer

Staging site

The main staging address or a custom staging domain

Anyone who holds the URL

Production

The custom domains

Visitors

Content publishing is a separate channel. CMS items are published individually, on a schedule or with a site publish, as described in Publishing and Scheduling; a team that uses the publishing workflow should agree whether urgent content fixes are allowed to bypass it. Single-page publishing, which Webflow offers to Team and Enterprise plans, is the other way to ship one page quickly, and Webflow documents that page-specific access controls determine who may use it.

Releases

At Webflow Conf 2026 (1 to 3 September), Webflow announced Releases as "a new way to ship your biggest projects". According to the official announcement, teams can branch an entire site, including pages, CMS content, components, assets and locales, so that big launches are staged together before they ship. Webflow’s conference coverage adds that:

  • a Release Manager tracks work across the site, showing what has changed, who is working on it and where it stands;

  • once individual releases ship, updates can be pulled into open branches to keep them in sync with the site;

  • agents can contribute inside a release and are subject to the same roles and permissions as teammates when it is time to merge and publish.

Availability as of 2026-10-28

The conference announcement states that Releases will be available in beta later in 2026. As of 2026-10-28 the pages that Webflow has published about it are the announcement and the Builder keynote material; this page therefore describes its announced behaviour and does not give click-by-click steps. Check Webflow updates for the date on which the beta opens and for the eligible plans, and read the Product Changes and Deprecations page for how this sub-section tracks such changes.

Releases compared with page branching

Aspect Page branching Releases

Scope

A page

A whole site: pages, CMS content, components, assets and locales

CMS content

Shared with the main site

Included in the branch, per the announcement

Coordination

Branch tab and review request

Release Manager across the site

Agents

Not a documented concept of the feature

Agents work in a release under the same roles and permissions as people

Status on 2026-10-28

Available to Enterprise customers

Announced, beta later in 2026

The practical guidance for Fernbrook is to adopt page branching and the publishing workflow now, because they are available, and to design the team’s habits (one owner per branch, a named required reviewer, a staging check before every production publish) so that they carry over to Releases when it opens.

Pitfalls

  • Losing edits on merge. An editor who fixes a typo on a page while a designer holds a branch of it loses the fix at merge. Freeze editing of a branched page, or copy the edits into the branch before merging.

  • Staged URLs are not private. A branch staging address is a normal URL. Do not stage embargoed content on it unless the site is protected.

  • Assuming a branch tests content-model changes. The CMS is shared; test a new field in a Developer workspace copy of the site instead.

  • Confusing merging with publishing. A merged branch is still unpublished. Visitors see it only after the next publish.

  • Approvers who can also merge. Give the Make changes without approval permission sparingly, or the approval is advisory.

  • Using the workflow with Logic. The publishing workflow cannot be used on a site that has Logic flows.

  • Treating beta endpoints as stable. The Branches API is in beta; pin your integration to what the reference says on the day you build it.

Where the older book is out of date

The book Webflow by Example (Packt, 2021) describes collaboration through duplicated pages and shared project access, because page branching, approvals, the publishing workflow and Releases did not exist in the product it covers. Its advice to duplicate a page and rename it is still possible, but on an Enterprise site a branch is the safer equivalent, because it carries conflict detection and a review gate. The list of outdated claims is on Where Older Books and Tutorials Are Outdated.

Where to go next

References