Since Publications provides a final end point for users to review changes, it would benefit content editors tremendously if they could also review their workflow changes.

There is an unacceptable decrease in performance observed within large Publications. With publications housing a large number of individual changes, the current system struggles to maintain acceptable performance levels, especially during conflict checking and publishing publications. These two phases leverage handwritten SQL queries to perform those tasks that allow Publications a shortcut through our persistence layer to maximize performance in small publications. In large publications though, further considerations must be taken to ensure consistent performance.

Allow users to map Repeatable fields of a Web Content Structure already defined in Fragments and Collection Displays.

The /search and /suggestions APIs comes with the following enhancements:

• New, optional scope parameter supporting Site (Group) IDs and External Reference Codes (ERCs) in /search. The scope parameter of /suggestions has also been updated to have the same semantics.

• /search now is in RELEASE status.

• The APIs now are available under the /o/search/v1.0/ endpoint with backward compatibility for current /o/portal-search-rest/v1.0 calls through server-side forward.

Refer to the documentation for more details.

Clause Contributors configuration is now stored within the blueprint’s JSON with a smaller footprint, reducing the size of a blueprint by more than 90% when using the default setting (all contributors enabled → Enable All) or the new Disable All option.

The behavior of the different options is as follows:

• with Enable All, all current and future query clause contributors introduced to the platform will be enabled automatically. Disable All behaves the opposite way,

• with Customize, the configuration is locked to the specified contributor list.

The selection filters of the Data Set Manager has been revamped to allow chosing different type of sources. On top of the picklist, now the admin user may select an API Headless as filter values source, so the filter values might be populated with the values coming from the API response. This allow users to have a more automated process on the filter creation.

The CX Filter allows developers to build their own filters, with on demand bussiness logic and UI, to be added to a Data Set in the Data Set Manager and then be used for end-users in the Data Set. With this new value, the Client Extension can be generic, and the same Client Extension can be used to build filters that filter by different fields.

User session replication has been optimized for the Tomcat application server.