How Pimcore Studio UI Changes Daily Work for Data Teams

Pimcore has always been a powerful platform for managing product information, digital assets, and content across multiple channels. Its flexibility allows organizations to model complex data structures and adapt the system to their specific needs.

As these environments grow, daily work becomes more demanding. More data, more users, and more processes increase the need for a clear and efficient way to interact with the system.

Studio UI introduces a more structured and adaptable interface that builds on Pimcore’s existing capabilities. The goal is not to replace core functionality, but to improve how users navigate, organize, and manage their work.

This article takes a user-focused perspective. It does not cover features in detail or explain migration steps. Instead, it focuses on how Studio UI changes daily work for teams managing product data.

If you want to explore Studio UI from other perspectives, you can continue with:

• General overview of Pimcore Studio UI 
• Full breakdown of Pimcore Studio features
• Transition from Classic UI to Studio UI

Reducing Repetitive Actions with Custom Shortcuts

Daily work in Pimcore often involves repeating the same actions. Opening objects, publishing updates, or navigating between sections becomes routine, especially for users who spend several hours in the system.

StudioUI builds on existing keyboard shortcut functionality within the My Profile section, making it more accessible and easier to customize. Users can adjust shortcuts based on their own habits and frequently used actions, instead of relying solely on the default keyboard shortcut setup.

While this capability was already present in earlier Pimcore versions, it was often underutilized. In StudioUI, it becomes more visible and practical in everyday work.

This does not change what users can do in Pimcore, but it changes how quickly they can do it:

• frequent actions can be triggered without navigating through menus
• repetitive clicking is reduced
• common operations become faster to execute

For users who rely on Pimcore throughout the day, this leads to a more consistent and efficient way of working, without changing the underlying processes.

Making Data Changes More Transparent and Easier to Manage

As more users interact with product data, tracking changes and maintaining consistency becomes increasingly important. This is especially relevant in environments where multiple roles are involved in preparing, reviewing, and publishing data.

Existing capabilities such as Notes & Events are now easier to access and interpret in daily work. While the functionality itself is not new, the updated interface improves visibility by structuring changes more clearly within the object view.

Users can now more easily:

• review what was changed and when
• see who performed the update
• understand workflow-related actions directly on the object

This becomes particularly useful in collaborative environments, where multiple users contribute to the same dataset and need a clear overview without additional coordination.

Managing Bulk Updates with Search & Replace Assignments

StudioUI introduces Search & Replace assignments, a new functionality designed to simplify how relationships between objects and assets are managed.

In practice, the same asset or reference is often used across multiple objects. Updating these relationships manually can be repetitive and difficult to control at scale.

The process follows a structured set of steps:

1. Select the element to search for

The user defines the asset or object that should be replaced. This can be done through search or drag-and-drop selection.

2. Review affected objects

The system returns all objects where the selected element is currently used. This allows users to understand the scope of the change before proceeding.

3. Define the replacement

A new asset or object is assigned as a replacement for the selected element.

4. Select the scope of the update

Users can choose whether to apply the update to all results or only a selected subset of objects. Once confirmed, the update is executed as a background process.

This introduces a more controlled and scalable approach to bulk updates, especially in environments with large product catalogs and shared assets.

Managing Access Through Users and Roles

In environments where multiple users work on the same product data, defining who can access and modify specific information becomes essential. This is particularly important when different roles are responsible for different stages of data preparation.

In Pimcore, permissions can be defined both on the User level and the Role level. StudioUI builds on this foundation by making these structures easier to navigate and understand from a user perspective.

Roles are typically used to group permissions and assign them to multiple users, while user-level permissions can be used for more specific adjustments.

Permissions control what users can do across the system, including:

• viewing data
• editing content
• publishing changes
• deleting elements
• accessing system features

These permissions apply across different areas such as Data Objects, Assets, Documents, and other system functionalities, including custom extensions.

Permissions are configured on the administrative level and directly affect what users can see and do within the interface. From a user perspective, this is reflected directly in StudioUI. Depending on assigned permissions, users may see different options, actions, or even entire sections of the interface, even when working on the same data.

Refining Permissions with “Allowed Types to Create”

Once a permission is granted, it can be further refined using the “Allowed types to create” configuration.

By default, when create permission is enabled for a specific functionality (for example, Data Objects), users are allowed to create all available types within that category. The “Allowed types to create” section allows this behavior to be restricted.

In practice, this means:

• permissions can be limited to specific object classes
• or specific document types
• instead of allowing access to all available types

For example:

• a system may contain multiple object classes
• create permission is enabled for Data Objects
• without restrictions, users can create all available classes

Using “Allowed types to create”, this can be narrowed down so that users can only create selected object classes. This provides more control over how data is created and helps maintain structure and consistency within the system.

Workspace: Defining Where Users Can Work

In Pimcore, the Workspace section within Users and Roles is used to define tree-level access control for:

• Data Objects
• Assets
• Documents

This configuration determines:

• where a user is allowed to work
• what actions they can perform within that area

In practice, StudioUI reflects this by showing users only the parts of the structure they are allowed to access, rather than exposing the full system.

How Workspace Permissions Work

A workspace is defined as a path-based permission rule. When configuring a workspace, you select a specific location in the data structure, such as:

• a root path (for example: /Products)
• or a more specific sub-level (for example: /Products/Active)

Permissions are then granted only for the selected path and its child elements.

This means:

• access is limited to the defined part of the structure
• actions are only available within that scope
• everything outside that path remains inaccessible

Important: No Upward Permission Inheritance

Workspace permissions in Pimcore do not inherit upwards. This is an important distinction when defining access.

For example: If access is granted to /Products/Active, but not to /Products, the user will not have access to /Products

Even if /Products contains /Active, permissions must be explicitly defined for each required level.

This behavior ensures precise control but requires careful configuration when structuring roles. From the user perspective, this explains why certain folders or levels in the structure may not be visible, even if related data exists deeper in the hierarchy.

Allowed Actions Within a Workspace

Within the selected path, permissions also define what actions users are allowed to perform.

This can include:

• viewing content
• creating new items
• editing existing data
• deleting elements
• publishing changes

These permissions apply to the selected folder and all of its child elements, ensuring consistent behavior across that part of the structure.

Using Workspaces to Structure Responsibilities

Workspace configuration is particularly useful when defining roles for teams working on different stages of product data. For example:

• some users may be responsible for preparing and editing product data
• others may only need access to finalized data
• some users may not need visibility into certain areas at all

By assigning different workspace paths and permissions:

• users can be limited to specific stages of the data lifecycle
• sensitive or irrelevant areas can be hidden
• access can be aligned with actual responsibilities

This helps prevent errors and reduces unnecessary exposure to data that is not relevant to a specific role. In StudioUI, this results in a more focused interface where users work only within their assigned scope, without needing to navigate unrelated parts of the system.

Keeping the Working Environment Clean

By restricting access to only the necessary parts of the system, workspaces help create a more focused working environment.

Users:

• see only the data relevant to their tasks
• avoid navigating through unrelated structures
• work within a clearly defined scope

This is especially important in large systems, where data structures can become complex and difficult to navigate without proper access control. As a result, users experience a cleaner and more structured workspace, where available actions and visible data align with their responsibilities.

Understanding Permission Hierarchy in Practice

In Pimcore, permissions can be defined both on the User level and the Role level. This means that a single user can have:

• permissions assigned directly on their user account
• additional permissions inherited from one or more assigned roles

As a result, permissions are not defined in a single place, but can come from multiple sources.

User vs Role Permissions

When both user-level and role-level permissions are present, they need to be evaluated together. In practice:

• roles define a base set of permissions
• user-level permissions can be used to extend or adjust those rights

However, when there is overlap between the two: role-level permissions take precedence.

This means that the final set of permissions a user has is determined primarily by their assigned roles, with user-level settings acting as a secondary layer. For users, this can explain why certain actions are available or restricted, even if their individual user settings suggest otherwise.

Permission Model in Practice

Pimcore follows a role-first, additive permission model, rather than a strict override hierarchy.

This means:

• roles act as permission templates
• users inherit permissions from roles
• additional permissions can be assigned on the user level
• permissions are combined rather than fully overridden

In other words, permissions are built up through a combination of role and user configurations, rather than replaced by one or the other.

Summary

• permissions can be defined on both user and role level
• roles define the primary permission structure
• users inherit and can extend these permissions
• role-level permissions take precedence in overlapping cases

This model provides flexibility while maintaining consistency across users who share the same roles. Overall, StudioUI does not change how permissions are defined, but makes their effects easier to understand through the interface, helping users work more confidently within their assigned roles.

Customizing the Interface with Widgets and Perspectives

Widgets and Perspectives are new capabilities in Pimcore StudioUI that focus on how users interact with the interface. They do not change data structure or permissions. Instead, they define:

• how information is displayed
• how users navigate the system
• which elements are prioritized in daily work

Widgets are small, configurable UI panels that display specific information or shortcuts.

Perspectives are saved UI configurations that allow users to switch between different interface setups depending on their workflow.

From a user perspective, this means the interface can be adapted to match specific tasks, instead of requiring all users to work within the same default layout.

Creating a Custom Widget

To create a custom widget, navigate to: System → Widget Editor

Select the option to create a new widget by clicking “+ New”.

In the creation dialog:

• enter a name for the widget
• select the available option “Element tree”
• confirm the creation

Once created, the widget will appear in the widget listing.

Defining Widget Content

After creating the widget, the next step is to define what data it will display. In this example, the widget is configured to show Product data only.

This is done in two parts:

1. Specific Section

• set Element type to Data object
• drag and drop the folder where Product objects are stored (typically the root folder)
• enable visibility of the root folder

This ensures that only the relevant data structure is displayed within the widget.

2. Allowed Objects and Context Menu

• under Allowed objects, select only the relevant object class (e.g. Products)
• under Allowed context menu, define which actions are available

This step controls both:

• what users can interact with inside the widget
• which actions are available directly from that view

After saving, the widget is ready to be used in a perspective.

Creating a Custom Perspective

Once a widget is prepared, it can be used to build a custom perspective. Navigate to: System → Perspective Editor

Create a new perspective and define its name.

After creation, the layout editor is displayed. The interface is divided into three main areas:

• left
• bottom
• right

These define where widgets will be positioned in the UI.

Adding Widgets to a Perspective

To add a widget:

• select the desired area (e.g. left panel)
• click Add
• choose the widget

The same widget can be placed in multiple areas if needed, meaning the same data can be visible in different parts of the interface. After configuration, save the perspective.

Assigning Perspectives to Users

To make the perspective available:

• open the User or Role configuration
• assign the created perspective

Once assigned, users can switch between available perspectives from the main menu.

Additional Perspective Configuration

Perspectives can be further customized through additional options in the Perspective Editor. These include:

• defining quick access areas
• controlling which data management actions are available

For example, actions such as Notes & Events or Search & Replace Assignments, can be enabled or removed depending on the use case.

What This Means for Users

Widgets and Perspectives allow users to work within an interface that is tailored to their role and daily tasks. In practice, this means:

• frequently used data can be brought into focus
• unnecessary elements can be removed
• different workflows can have dedicated interface setups

Instead of adapting to a fixed interface, users can switch between perspectives that reflect different responsibilities, such as data entry, validation, or review.

Working with Multiple Elements Using Split-Screen

StudioUI introduces a split-screen feature that allows users to divide the workspace into multiple panels. This makes it possible to work with different objects, assets, or documents at the same time, without switching between tabs. From a user perspective, this improves efficiency when working on related data or configurations in parallel.

How Split-Screen Works

The feature is designed to be intuitive and requires no additional configuration. To activate split-screen:

• drag and drop an object, asset, or tab into the main working area
• the system will display highlighted zones indicating where the item can be placed

As the item is moved across the screen, the highlighted areas adjust dynamically, showing possible layout options. This allows users to quickly define how the workspace should be divided.

Working with Multiple Views in Parallel

Once placed, the interface is split into separate panels.

This allows users to:

• view and edit multiple elements at the same time
• compare data across objects
• work on related configurations without switching context

For example:

• widgets can be displayed on one side
• while a perspective configuration is edited on the other

This is particularly useful when configuring UI elements and immediately verifying how they behave.

Reorganizing the Workspace

The split-screen functionality can also be used to rearrange existing interface elements.

For example:

• data pools (such as product structures) can be moved from one side of the interface to another
• panels can be repositioned depending on user preference

In the example shown, the product section is moved from one side of the interface to the other, allowing for a different layout of the working area.

What This Means for Users

Split-screen reduces the need to constantly switch between tabs or views. In practice, this means:

• faster access to related information
• easier comparison between elements
• more flexible workspace organization

Users can adjust their layout depending on the task, whether they are editing data, configuring perspectives, or reviewing related content.

Working with Draft and Published Versions

StudioUI introduces the ability to work with draft versions of objects alongside published data, and schedule when those changes should go live.

In practice, there are situations where:

• product changes are known in advance
• updates are prepared ahead of time
• but should not be visible immediately

To handle this, users can create a draft version of an object.

This means:

• the currently published version remains active
• a new, edited version is saved separately as a draft
• changes can be prepared without affecting live data

Creating a Draft Version

The first step is to prepare a draft version of the object (for example, a product). This is done by:

• making changes to the object
• selecting “Save draft” instead of publishing

This creates a separate version that can later be published.

Scheduling the Update

To define when the draft should become active, navigate to the Scheduling tab within the object.

To create a new scheduled action:

• click “+ New”
• a new row will be added to the table

Note: Each field in the row can be edited by double-clicking the cell.

Configuring Scheduled Actions

For each scheduled task, the following fields must be defined:

• Date & Time: defines when the change will be executed
• Action: determines what the system should do. Options include:
  • Publish (make a draft version active)
  • Delete (remove the object at a specific time)
• Version: defines which version will be applied

This allows flexibility in version management.

Users can:

• create multiple draft versions
• choose which version should become active
• schedule changes independently of when they were created

Saving and Managing Scheduled Tasks

After defining the required fields: save the scheduled task. The system will then display the schedule as active.

Users can:

• edit scheduled actions at any time by double-clicking fields
• delete a schedule using the delete (trash) option

This allows full control over future updates.

What This Means for Users

Scheduled publishing allows users to prepare and control changes without manual intervention at the time of release. In practice, this means:

• product updates can go live automatically at a defined time
• draft changes can be reviewed before publishing
• multiple versions can be prepared in advance

This is especially useful for:

• timed product launches
• price or content updates
• coordinating changes across teams and markets

Using Custom Grid Views for Data Management

Custom grid view is an existing Pimcore capability, but in StudioUI it becomes a more flexible and practical working layer for users who need to review, filter, and update structured data more efficiently.

To set up a custom grid, we must first select a folder within which the data we want to view resides. In this example, we want to view Manufacturer data, which is located within the Product Data folder. Once the Product Data folder is expanded, the Manufacturer folder appears.

We can select the Manufacturer folder directly, which will instantly open the manufacturer grid view, or we can select the Product Data folder and then choose the Manufacturer class, which will take us to the same grid. Both options lead to the same result.

When opened, the grid displays a default view. This default grid does not show a lot of information, because only a limited number of attributes are included out of the box. To get more relevant data into the view, we need to create a custom grid configuration that matches the task we are working on.

Each grid can be customized through the grid configuration options on the right-hand side. Once we expand the grid config option, a new view is displayed. In this view, we can see that several elements are already added. These are the fields currently visible in the default grid view. Each listed item represents one attribute that exists on the Manufacturer object class. This means that if we want the grid to display a field such as manufacturer logo, we must add that field manually.

To add new columns to the grid, we select the option “Add a column.” The system gives us three options:

System: This grouping contains system-related information such as date of creation, system ID, path, or modification date.

Manufacturer: This grouping contains all available attributes defined on the Manufacturer object class.

Advanced: This option allows us to combine multiple fields under the System and Manufacturer groupings into a single custom column.

In this example, we want to create a custom grid that shows Manufacturer ID, Manufacturer Name, and Manufacturer Logo. We also want a custom advanced field that merges manufacturer name and manufacturer logo into one field.

Our first step is to expand grid config and remove the currently defined fields. Next, we select Add a column and add the following fields:

• Manufacturer ID
• Manufacturer Name
• Manufacturer Logo

Now that we have our base, we add another column and select Advanced. We name the column “Name&Logo.” Then we add a source field of type simple field and select Name. After that, we add another source field of type simple field and select Logo. Then we select Apply.

This gives us a more useful working view, especially in cases where users want to combine identifying information and visual reference in one place, instead of spreading it across separate columns.

Additionally, we can add transformers to adjust how values are displayed, such as date and time formatting or boolean values. Once the grid is configured, we can save this setup as a template so it does not need to be recreated later.

To do this, we select “Save as template.” We then define the template name and, if needed, add a description. If multiple templates are available, one of them can be defined as the default template by selecting “Set as default template.” Each template can also be shared globally, meaning all users will see it on this grid, or it can be shared only with a particular role or user. Once saved, the template appears in the template listing.

This is particularly useful in StudioUI because it allows different users or teams to return to the same structured view without rebuilding it each time.

Grid Filters, Batch and Inline Editing

When working with a large amount of data, filtering becomes important. To search or filter by specific information, we navigate to the Search & Filter section of the grid.

The first option is a global search function, where the system looks for any value in any column that is currently present in the grid view. The second option is to filter by actual attributes or columns. To do this, we again select “Add a column,” and the system presents the same three options as before:

• System
• Manufacturer
• Advanced

In this example, we want to filter by manufacturer name, so we select Manufacturer and then choose the Name attribute. Once the element is added to the filter section, we enter the manufacturer name we want to filter by and select apply. Multiple filters can be added and combined.

Once we have found the manufacturer we want, we can edit the manufacturer name directly through inline editing. To enter inline edit mode, we double-click the manufacturer name. Once the field is highlighted, we adjust the value. To save the input, we simply click anywhere outside the highlighted area. The updated value is then saved automatically.

This makes StudioUI more practical for day-to-day corrections, because users do not need to open each object individually for smaller updates.

If we need to update multiple values at the same time, we can use the batch edit option. First, we select all manufacturers we want to update. Next, we choose “Apply to selection” and select batch edit.

In the newly opened screen, we select “Add a column” and choose the attribute Name. Once that field is added, we enter the new value we want to apply to all selected rows. Once we are satisfied, we select apply changes.

The system then adds the task to the queue and executes it as soon as possible. A notification appears in the bottom right corner of the screen, and once the task has finished, the new values become visible after reloading the grid view.

This allows users to handle repetitive updates more efficiently, especially when working with larger datasets.

Setting Up Dashboards for Data Overview

Dashboards are a new capability in Pimcore Studio that allow users to group analytical data into a single, structured view. Instead of accessing reports individually, users can organize multiple data insights in one place, depending on their needs or role.

This does not replace reporting functionality, but builds on it by providing a way to present and combine results in a more accessible format.

Creating Custom Reports for Data Analysis

To create dashboards with analytical data, we first need to set up custom reports. Custom reports can also be created and used independently, without being part of a dashboard.

To create a new custom report, we navigate to the Reporting section in the main menu and select Custom Reports Configuration.

Simpler custom reports can be set up by non-technical users. However, for more complex reports, especially those involving advanced queries or multiple data sources, it is recommended to involve a Pimcore developer.

In this example, we will create a simple report that displays the number of cars per year.

Preparing Data for the Report

Before creating the report, we need to understand where the data is stored.

This can be checked in Data Model Definitions → Classes.

Here, we locate:

• the object class Car
• the attribute productionYear

These are the key elements required for building the report.

Creating a Custom Report

Once we have identified the required data, we return to Custom Reports Configuration and create a new report by selecting “+ New.”

After defining the report name, we configure the SQL query that will fetch the data.

The configuration includes:

• selecting the attribute (productionYear) and applying a count() function
• defining the object class (Car)
• specifying conditions, such as filtering data (e.g. years after 1920)

This defines what data will be displayed and how it will be aggregated.

After saving, the report becomes available in the All Reports section.

From here, the data can also be exported using the export function.

Custom reports can vary in complexity. In this example, we are using a simple aggregation, but more advanced reports can include multiple conditions, joins, or calculated values.

Building Custom Dashboards for Centralized Insights

Once reports are prepared, they can be combined into a dashboard.

We navigate to Dashboards → New Dashboard.

The first step is to define the layout.

Each dashboard is structured into rows, and each row can contain one or more elements. This allows flexible arrangement of different report components.

After selecting a layout, we can add content by selecting the “+” option and inserting the previously created custom reports.

Once configured, we finalize the setup by selecting “Create dashboard.”

Extending the Dashboard

If the dashboard contains empty areas, they can be filled with additional elements.

In addition to custom reports, dashboards can include:

• WYSIWYG content
• Notifications
• Recently modified items
• Last changes

This allows dashboards to combine analytical data with contextual information, depending on how users want to structure their workspace.

What This Means for Users

Dashboards in StudioUI provide a centralized way to access and organize analytical data.

In practice, this means:

• multiple reports can be viewed in one place
• users can structure data based on their responsibilities
• analytical insights become easier to access without navigating through separate sections

This is particularly useful for users who need a quick overview of key data points, without manually opening individual reports.

Conclusion

StudioUI does not introduce a completely new way of working in Pimcore, but it changes how users interact with the system in everyday tasks.

The core capabilities remain the same. What changes is how these capabilities are accessed, structured, and combined within the interface.

Across the examples in this article, this becomes visible in several areas:

• data can be reviewed and updated more directly through grid views
• interface layouts can be adjusted using widgets, perspectives, and dashboards
• repetitive actions can be reduced through shortcuts and bulk operations
• access and visibility are easier to understand through clearer permission structures

These changes reduce the need for constant navigation between different parts of the system and make it easier to focus on the task at hand.

At the same time, StudioUI introduces more flexibility into how users organize their working environment. Instead of relying on predefined layouts, users can adapt views and tools based on their role or workflow.

This becomes particularly relevant in larger environments, where multiple users work on the same data and require clear structure without unnecessary complexity.

Overall, StudioUI improves the usability of Pimcore by making existing functionality more accessible and easier to work with, rather than changing how the system fundamentally operates.

If you are exploring how these changes could fit into your current setup or planning a transition to StudioUI, it can be useful to review your existing workflows and identify where these improvements would have the most impact. In practice, this is often part of a structured Pimcore consulting service, where current processes are evaluated and aligned with how the platform is used in daily work.