APIsChangelog
Log In

App Modes

Modes in the Webflow Designer

📘

App Modes Implementation

App Modes is being rolled out in phases. For more guidance, see the timeline below.

The Webflow Designer is a powerful collaborative tool for teams to design and build websites quickly and at scale. It offers various modes to support different aspects of the design process:

  • Designing and Editing: Designers can create and refine the website’s layout and appearance in the Webflow Designer, while marketers and content writers manage and update content in the Editor.
  • Page Branching: Multiple designers can work on different pages of the same site at the same time, allowing for parallel development and reducing bottlenecks.
  • Localization: Global teams can create customized experiences for different languages or regions, enabling global reach and tailored content for diverse audiences.

Through these features and modes, the Webflow Designer determines the specific actions a user can take to ensure teams make the right updates at the right time.

Modes in Webflow Apps

Apps in the Designer extend the user’s capabilities, respecting the same modes as the Designer. Each method in the Designer API offers distinct functionality, aligning with the actions feasible in each mode. By understanding the various modes in the Designer, and how Designer APIs interact with them, you can ensure your App functions correctly across different contexts within the Webflow Designer, thus providing a seamless user experience.

Understanding Modes and API Methods

Each API method’s documentation includes an “App Modes” section that outlines where and how the API can be used, as well as any limitations.

Here’s an example from the “Remove Element” method:

AbilityLocaleBranchWorkflowSitemode
Name of the current abilitySite uses Localization, and the user is working in a primary or secondary localeSite uses Page Branching, and the users working in a primary or branched pagedDetermines whether the user is actively working on the canvas, or viewing the site in preview mode.Determines whether the user is in design mode, or edit mode.
canDesignprimarymaincanvasdesign

In this example, the “Remove Element” method can only be successfully called if the user is in design sitemode, working on the canvas in a primary locale on the main branch. If the user is in any other mode, the API will throw a “Forbidden” error.

See below for a complete table of abilities, which defines where and how an API method can be used.

NameLocaleBranchWorkflowSitemode
canManageAssetsAnyAnyAnyAny
canAccessAssetsAnyAnyAnyAny
canAccessCanvasAnyAnyAnyAny
canDesignprimarymaincanvasdesign
canEditAnyAnycanvasAny
canCreateComponentsprimaryAnycanvasAny
canModifyComponentsAnyAnycanvasAny
canCreateStyleBlocksprimaryAnycanvasdesign
canModifyStyleBlocksAnyAnycanvasdesign
canCreatePageAnyAnyAnydesign
canReadPageSettingsAnyAnyAnyAny
canManagePageSettingsAnyAnyAnyAny
canReadVariablesAnyAnyAnyAny
canModifyVariablesAnymaincanvasdesign

Error handling for App modes

When an API call is made in an incorrect mode, a “Forbidden” error will be thrown. To manage this, implement error handling to guide users back to the appropriate mode. For more guidance on errors, see our guide on understanding and handling API errors.

To help you implement robust error handling for App Modes, we have included a list of API abilities along with the accepted modes for each ability and example error messages to direct users back to the correct mode:


NameExample Error Message
canManageAssetsThis action cannot be performed right now. Please ensure you have the correct permissions to manage assets.
canAccessAssetsThis action cannot be performed right now. Please ensure you have the correct permissions to view assets.
canAccessCanvasThis action cannot be performed right now. Please ensure you are working in the correct mode to access the canvas.
canDesignThis action cannot be performed right now. Ensure you are working in the Primary Locale and the Main Branch, and in design mode.
canCreateComponentsThis action cannot be performed right now. Ensure you have the correct permissions to create components, and are working in the Primary Locale.
canModifyComponentsThis action cannot be performed right now. Ensure you have the correct permissions to modify components.
canCreateStyleBlocksThis action cannot be performed right now. To create Styles, ensure you are working in the Primary Locale and in design mode.
canModifyStyleBlocksThis action cannot be performed right now. Make sure you are in design mode to modify Styles.
canCreatePageThis action cannot be performed right now. Ensure you have the correct plan and/or permissions to create additional pages. Additionally, ensure you are in design mode.
canReadPageSettingsThis action cannot be performed right now. Please ensure you have the correct permissions to view Page Settings.
canManagePageSettingsThis action cannot be performed right now. Please ensure you have the correct permissions to manage Page Settings.
canReadVariablesThis action cannot be performed right now. Please ensure you have the correct permissions to view Variables.
canModifyVariablesThis action cannot be performed right now. Please ensure you have the correct permissions to manage Variables.

As an example, see the below snippets on guidance for how to catch the new Forbidden error and surface appropriate user messaging.

Before App Modes

const el = await webflow.getSelectedElement();
// Assumes a user can create elements
await el.append(webflow.elementPresets.DOM);

After App Modes

try {
  // The element is able to be selected
  const el = await webflow.getSelectedElement();
  // However, appending an element is disallowed in a secondary locale
  await el.append(webflow.elementPresets.DOM);
} catch (error) {
  if (error.cause.tag === 'Forbidden') {
    // It is up to the developer to craft an error message to the user.
    // below is an example of what they could do:
    await webflow.notify({
      type: 'Error',
      message: 'This action cannot be performed right now. Ensure you are working in the Primary Locale and the Main Branch, and  in design mode.',
    })
  }
}

Implementation Timeline

🗓️ July 01

  • There is NO impact to your Apps, we are just notifying you that App Modes is coming
  • You have until August 01, 2024 to temporarily opt-out of App Modes by submitting an updated App bundle if you wish.
  • You can test any necessary code changes to your Apps in other Designer modes locally

🗓️ Aug 01

  • App Modes feature turned on for all users
  • End-users will be able to launch an App from the Apps panel in other Designer modes, unless the App has been updated to opt-out of the feature
  • Deadline for developers to temporarily opt-out their App from the App Modes feature
  • After this date, only Designer Extension / Hybrid Apps using Designer Extension v2 APIs that have not opted-out of App Modes will be available to launch from the Apps Panel by end-users in different modes

🗓️ Sept 26

  • All Apps using Designer v2 APIs may be launched in various modes (including ones that had temporarily-opted out)

Testing with App Modes

To test out how your Designer Extension will function with Expanded App Modes, you can opt-in to the feature with your webflow.json manifest file.

// webflow.json manifest file
{
  "name": "my app",
  "apiVersion": "2",
  "featureFlags": {
    "expandedAppModes": true
  }
}

Now, if you launch your Designer Extension from the Apps Panel as you normally would today, you can switch to Editing mode, as an example, and your App should remain open. If you take an action via your App that a user shouldn't be able to in that mode, you will see a Forbidden error thrown, and you can catch the error appropriately to surface relevant user messaging.

Temporary Opt Out

We recognize that for some Apps, it may take more time to incorporate code changes to add extra error handling, UI considerations, etc. with expanded App Modes. Thus, you’ll have until August 01, 2024 to opt-out of this feature. We give you until August 01 so you may have time to decide whether or not you’d like to opt-out temporarily after trying your App in other modes.

To opt-out, set the expandedAppModes feature flag to false in your webflow.json manifest files (see below). Then, simply create a new updated app bundle with this change and submit it for review.

// webflow.json manifest file
{
  "name": "my app",
  "apiVersion": "2",
  "featureFlags": {
    "expandedAppModes": false
  }
}

Deciding to Opt Out

Opting-out of this feature means your App will only be able to be launched under the existing conditions today; end-users who are Designing in the primary locale and main branch. Additionally, your App will not be launchable from the Apps panel of the Designer by users who don’t meet those conditions (i.e,. in Editing mode). If you decide to opt-out, you will have until September 26, 2024 to make any necessary changes to your application and prepare for the default switch to App Modes.

Deciding to not Opt Out

If you do not opt-out, after August 01, your App will respect App Modes by default, and may be accessible via the App panel in the Designer to users in other modes such as secondary locales and non-main branches.

❗️

Opt Out Deprecation

After September 26, 2024, Webflow will ignore the feature flag value and App Modes will be on by default for every application

Designer v1 APIs

If you have an App using Designer v1 APIs, your app will not be able to be launched in other modes around the Designer, and will continue to only be launched when Designing in the canvas in the primary locale and main branch.