Managing and synchronizing content across multiple environments just became easier and more reliable. With this release, Liferay expands the capabilities of the Batch Engine by introducing two powerful enhancements:

1. Batch Delete by External Reference Code – Users can now delete items using external reference codes instead of internal IDs, making batch deletions simpler and more consistent across environments.

2. Import Strategy Support for Deletion – When performing a batch delete, users can now define whether the operation should be partial (stop on error) or complete (continue even if some items fail), offering more control and fault tolerance during the process.

Together, these updates streamline how teams manage bulk deletions—especially in environments that rely on external identifiers or require consistent data maintenance across staging, production, and other instances.

Key Benefits:

• More reliable environment synchronization: External Reference Codes allow you to delete the same entities across different environments without depending on internal IDs, reducing risk of mismatches.

• Simplified bulk deletion workflows: Deleting large sets of data is now easier, with fewer manual steps and lower chance of errors.

• Greater control over delete operations: Choose whether the process should stop on errors or complete fully—helping teams tailor the behavior to fit their operational needs.

• Increased resilience and fault tolerance: Deletion jobs are less likely to fail entirely due to minor issues, ensuring smoother maintenance processes.

• Consistent support across entities: These enhancements are available for all entity types supported by the batch engine, making them broadly applicable across different use cases.

In order to add more flexibility to every execution in batch engine, we have added a new parameter ( batchExternalReferenceCode ) to be capable to send it to the backend without updating the ERC of the import task.

Key Benefits:

• Simplicity of execution with one parameter for each purpose.

• Add new capabilities for all entities that supports batch.

We made sure to be able to configure the most relevant SCIM providers by implementing their specifications(Microsoft Entra, Cyber Ark, etc.)

Key Benefits:

Implementing SCIM endpoints from top identity providers streamlines and secures user management by enabling automated provisioning, deprovisioning, and syncing of user data across platforms. This enhances security, ensures compliance, reduces manual work, and improves consistency and user experience. With standardized interoperability, it also future-proofs integrations and boosts operational efficiency while offering better visibility and control over identity lifecycle events

Captcha engine needs to be configurable on instance level to satisfy the multi-tenant environments' need. That has to be possible to configure them for one instance without interfering with the configuration for other instances.

Key Benefits:

Enabling CAPTCHA at the Instance level adds flexibility in configurations without affecting global settings. This supports tailored security and user experiences, and enables compliance per instance, all while retaining centralized control when needed

It’s going to be available without enabling the BETA flag, and from now it’s officially supported.

When issues happen during maintenance periods, end users saw an unbranded default maintenance page. This leaves part of the user flow unattended, with customers unable to forward users to the correct next steps. Setting up and managing maintenance pages that work when DXP is down requires technical skills that not all customers possess, making it impractical for many.

Now we allow customers to upload a maintenance page they designed, fitting their brand and instructing customers on what to do. The implementation functions indepedently from their DXP instance so, as soon as they detect a downtime, they can enable the maintenance page in their Cloud Console to be displayed for their users while they address the issue that caused the downtime.

Configuring the scaling behaviour of Liferay is not simple. Customers are required to have a deep understanding of how their application' metrics behave to set their thresholds. Since charges are also incurred depending on the hours and instances scaled, customers can feel confused on the value they are being invoiced. 

That’s why we allowed for customers to set the maximum and minimum number of scaled instances in their Cloud Console scaling page. This means non-technical customers now can control how little or how much they want to spend in scaling their application. Allowing them pinpoint precision when balancing between improved user experience with more instances, and the increase in costs associated with that.

The Liferay Developer Studio installer now includes JDK 21 as a selectable option if it’s available, simplifying the initial setup and providing a more convenient and user-friendly experience for developers wanting to use the latest Java version supported by Liferay.