Standalone module

Studio updates

Discover the latest features and enhancements in Frontend Studio to boost efficiency and collaboration.

Ask about this Page
Copy for LLM
View as Markdown

After completing this page, you should be able to:

  • Manage builds efficiently using deletion, bulk operations, and search capabilities in the Continuous Integration area.

  • Configure market-based permissions to control team access across different geographic regions and locales.

  • Implement Identity authentication and OAuth 2.0 tokens for secure Studio access and API deployments.

  • Utilize Studio tools like Trace view for debugging, visual schema editors for configuration, and version history for tracking project changes.

Frontend Studio received substantial improvements in 2025, focusing on developer workflows, build management, debugging capabilities, and user permissions.

Build management and deletion

Managing builds became significantly more flexible with the introduction of build deletion capabilities. You can now delete individual builds directly from the Continuous Integration (CI) area of the Studio, helping you maintain a cleaner build history and free up resources. Keep in mind that when you delete a build, both the backend build and the frontend build from Netlify are deleted, and you cannot restore a build after you have deleted it.
Later in the year, this capability was expanded with bulk deletion functionality. Studio users with Admin or Developer roles can now select multiple builds at once and delete them in a single operation, significantly speeding up build management for teams that generate numerous builds during development cycles.
To complement bulk operations, a build search feature was introduced, allowing you to quickly locate specific builds by filtering on criteria such as branch name, or short commit hash.
Build search interface in the Continuous Integration area showing filters for branch name and short commit hash.
These features are accessible from the Continuous Integration area in the Studio. To delete builds, navigate to the Developer ➜ Continuous Integration area, select one or more builds you want to delete, and click the delete button. For bulk deletion, use the checkbox selection to choose multiple builds before initiating the delete action. Note that you cannot delete a build that is currently deployed and is listed in the Deployment area.

Deployment notifications and monitoring

You can now stay informed about your deployment status without constantly checking the dashboard! Deployment notifications were introduced to alert you when deployments complete, fail, or encounter issues. These notifications appear directly in the Studio interface, eliminating the need to constantly monitor the deployment page or switch to external tools.

Notifications provide immediate feedback on successful deployments to staging or production, failed deployments with error indicators, and build queue status updates.

Deployment notifications bell icon in the Studio interface navigation. Deployment notifications panel listing recent staging and production deployments with success and error indicators.

Developer area reorganization

The Developer area was reorganized to improve usability and create a more intuitive workflow. The order of tiles was rearranged to better reflect common development tasks, and the Schemas tile was renamed to Other schemas to better reflect its purpose. From Other schemas, you can add and edit JSON schemas that define your project and page folder configuration.
Developer area tiles reordered so Data sources, Components, Page templates, and Other schemas are grouped to streamline navigation.

Trace view for advanced debugging

The Trace view area was introduced as a powerful debugging tool, providing deep visibility into how your Frontend application processes requests and interacts with backend services. This feature is particularly valuable when troubleshooting complex issues that span multiple system components.

The Trace view area allows you to:

  • Visualize the complete request lifecycle: follow a request's journey from browser to backend and back.
  • Identify performance bottlenecks: pinpoint slow data fetching operations and component rendering delays.
  • Debug integration issues: troubleshoot problems between Frontend components and data sources.
  • Track API calls: see exactly which API calls are made during page rendering.
  • Analyze timing information: review detailed timing data for each stage of request processing.
Trace view area
To analyze a specific request using Trace view, you first need to obtain the request ID. You can find this in two ways: from your browser or from Humio.

Obtain the request ID from your browser

Navigate to your staging or production site, open your browser's developer console, go to the Network tab, and locate the Frontastic-Request-Id header in the request headers.
Browser developer tools Network tab showing the Frontastic-Request-Id header value.

Alternatively, you can find the request ID logged directly in the browser console.

Browser console displaying the Frontastic-Request-Id value to copy into the Studio Trace view search field.

Obtain the request ID from Humio

If you're using Humio for log management, copy the request ID from your API call logs.

Once you have the request ID, navigate to the Developer area in the Studio and select Trace view. Make sure you're viewing the same environment where you captured the request ID—if you copied it from your production site, you need to be in the production environment in the Studio. Paste the request ID into the search box and click Show results to see the detailed trace information.

This workflow makes it straightforward to investigate specific requests and understand exactly what's happening under the hood of your Frontend application.

Visual schema editor

Schema creation became more user-friendly with the introduction of a visual editor for all schema builders in the Studio. Previously, creating and editing schemas required working directly with JSON code.

The visual editor provides a graphical interface for defining schema fields and properties, dropdown menus for selecting field types and validation rules, visual feedback for required fields and validation constraints, automatic JSON generation based on your visual configurations, and the ability to toggle between visual and code views.

The visual schema editor interface in the Studio

The visual editor is available in the editing pane when working with component schemas, data source schemas, and other schema types throughout the Studio.

Market permissions

For organizations operating across multiple geographic regions or business segments, the Studio introduced the market permissions functionality. This feature lets you control which team members can view and edit content for specific markets, providing granular access control based on locale groupings. Market permissions is currently an opt-in feature—contact the Frontend support team to enable it for your Studio.

Prerequisites

Before you can use market permissions, your Project must meet these requirements:

  • Minimum locale count: your Project needs at least five locales configured.
  • Consistent component library: all markets must share the same component set to ensure a cohesive editing experience.
  • Admin role required: only users with Admin privileges can create and configure market permissions.

Understand markets and locales

Markets are built on locales. When you create a market permission, you're essentially grouping one or more locales together—for example, you might create a "DACH" market that includes German, Austrian, and Swiss German locales. The locale selection interface shows only those locales that haven't been assigned to another market yet, preventing overlap. Note that the default locale won't appear as an option when configuring the Global market.

The Create market permission dialog with a locale selection list for assigning non-overlapping locales to a market for access control.

This locale-based structure is what enables access control. When you assign a team member to a specific market, they can only modify page versions associated with that market's locales, ensuring that changes remain isolated and don't inadvertently affect other markets or the Global market.

Global market access vs. specific market access

Market permissions creates two distinct types of users in your Studio:

  • Global market users: can access all markets in your Studio and perform actions according to their assigned role. These users have the flexibility to view all markets at once or use the market selector to focus on a particular market when needed. Developer-related roles are exclusively available to Global market users, as these roles require system-wide access.

  • Specific market users: have restricted access limited to their assigned markets. A team member can be assigned to multiple specific markets, but they'll only see content and tools relevant to those markets. These users can access Site builder, Dynamic pages, Templates (with Component groups fully editable and Page templates available in view-only mode), Media, and Team sections of the Studio.

These two user types are mutually exclusive—a team member assigned to specific markets cannot also be a Global market user, and vice versa.

Work with page versions across markets

Specific market users can edit page versions only within their assigned markets. If they need to adapt content from the Global market for their region, they can duplicate the Global page version and then customize the duplicate. This workflow protects the Global market content while enabling localized customization, ensuring that changes in one market don't unintentionally impact others.

Manage market permissions

Keep in mind that once you create a market permission, it becomes a permanent part of your Studio configuration. If you need to remove a market permission, you'll need to contact the Frontend support team for assistance.

Project settings version history

We added version history tracking to the project settings area, giving you the ability to view and restore previous configurations from up to 90 days in the past. This feature provides valuable insights into how your project has been configured over time and who made specific changes.
The Version history pane listing past project settings changes with timestamps, authors, and options to inspect or restore configurations.

With version history, you can track the evolution of your project configuration, see exactly which team member modified settings and when they did so, review the specific values that were set in each historical version, and maintain a clear audit trail for compliance purposes.

To review version history, open the Project area in the Studio and access the Version history pane. When you're viewing historical versions, the project settings become read-only to prevent accidental modifications while you're reviewing past configurations.

Restore previous versions

While you can restore your project settings to any earlier version from the past 90 days, proceed with caution. Before rolling back to a previous configuration, verify that the earlier schema version is compatible with your current setup. Restoring an incompatible version could cause unexpected issues with your website, particularly if there have been significant changes to your data structures or component definitions in the interim.

Identity and authentication improvements

Frontend Studio now supports Identity, commercetools' new authentication service designed to streamline your access across all commercetools business tools and services with a single unified account.

URL structure update

As of 26 August 2025, Studio URLs transitioned to a new format. Instead of https://CUSTOMER_ID.frontastic.io, you'll now access your Studio at https://CUSTOMER_ID-PROJECT_ID.studio.frontend.commercetools.com. This new structure better reflects the integration with the broader commercetools ecosystem.

Access Studio with Identity

Logging in with Identity is straightforward. Navigate to your new Studio URL, and you'll be automatically redirected to the Identity authentication page. Sign in using your username and password or through Single Sign-On (SSO) if your organization has it configured. Once authenticated, you'll be returned directly to your Studio.

Your existing access levels and permissions remain unchanged during this transition, so you'll have the same capabilities you had before. If you don't yet have an Identity account, you can create one by following the setup instructions in the Identity documentation.

Token-based authentication for deployments

In parallel with the Identity integration, the Studio introduced a more secure authentication approach for API deployments. The deployment authentication system was updated to use OAuth 2.0 tokens instead of the previous cookie-based approach, providing enhanced security and better access control. This change is particularly valuable because OAuth client credentials allow you to immediately revoke access if credentials are compromised, giving you faster response capabilities in security incidents.

To request an OAuth 2.0 token, use the following command:

curl --request POST \
 --data "client_id={api_key}&client_secret={api_secret}&grant_type=client_credentials" \
     "https://{customer-name}.studio.frontend.commercetools.com/oauth2/token"

To deploy, use the following command and make sure to replace the value of the Authorization Bearer token with the one you received as an output from the previous command:

curl -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer {OAuth2-token}" \
-d '{"commitHash": "[full-commit-hash]", "environment": "[staging-or-production]", "branch": "[branch-name]"}' \
"https://{customer-name}.studio.frontend.commercetools.com/api/multitenantDeployment/deployExternal?project={project-name}"
You can consult the full list of steps here.

If your current deployment workflow relies on cookie-based authentication or uses automated pipeline deployments, you'll need to migrate to the OAuth 2.0 authentication method. Updating your authentication approach ensures your deployments continue to work without interruption.

Test your knowledge