Release notes: October 22nd 2026 grade

Inriver is moving towards more incremental, smaller releases to better and faster accommodate our customers. With smaller, more frequent releases, Inriver will be able to increase the quality and transparency of the releases and identify and mitigate any erroneous behavior that may be caused by the release much faster.

To receive notifications when new release notes are published, please ensure you follow this page by clicking the “follow” button above.

Content Onboarding

Features

Improved result handling

You can now decide where the entities and linked entities from an import run are saved. Previously every run placed its result in a shared work area. Now you can choose between three different options: None, Shared work area and User work area.

• None, which is the default, keeps the result private and unlimited in size, but for a limited time only.
• Shared work area is the previous behavior and remains the default for existing mappings.
• User work area saves the result to your own personal work area.

Note: Existing mappings keep saving to the shared work area until you change the setting.

User can set the preferred option under settings, but it could also be changed under each mapping configuration.

The user preferred destination setting for imported entities

In addition, now only entities that are changed get stored in the result. If data in the import is not different to the data inside the PIM, no actual change to the entity has been done, and hence it will not be stored in the result. If you import 100 rows and 10 of them change something, the work area holds those 10. Relation imports are unchanged.

For the technical user: The setting is available per import configuration as ImportedEntitiesDestination (None, SharedWorkArea, UserWorkArea). When the destination is None, the hash code used to read the result from the portal’s compressed entities feature is returned on the new WorkAreaHashCode property of the run.

Who benefits: Data managers who want more control of what is actually being imported.

Improvements

Functions on all data fields

Previously, a source field always had to be mapped before a transformation function could be applied, even if the transformation function did not involve the source field, this was perceived as confusing and has now been addressed.

Since the function did not use the source field, this is now stricter and does not actually allow a function to be added when a source field is mapped. We’ve kept the button though for clarity even though now it is disabled whenever there is a source field.

Mapping view for a row mapped to a data field

Mapping view for a row where a function has been applied

Who benefits: Integration specialists who are managing more complicated mapping transformations

Auto match named mapping to file reintroduced

When we introduced the feature to upload a file without the need to use a named mapping covered in previous release notes, the default behavior to identify the best matching existing named mapping on the entry to the map was removed.

We now bring this functionality back on request.

This can be turned on inside settings.

Turn on the possibility to identify the right named mapping for the uploaded file

Who benefits: Users who are uploading the same file format multiple times and want to use a saved name mapping.

More information on the mapping top panel

The panel at the top of the mapping view with the key mapping configurations now also shows the import mode and the unique field type, to keep the user informed without opening the mapping configurations panel.

Who benefits: Anyone who reopens a saved mapping and wants to check at a glance how it will behave.

Fixes

General

• Previously, the entity name and field type names were displayed using the first language configured in the model and not the master language. This could result in an unexpected language being presented and make it difficult for users to correctly identify entities during field mapping. This has now been fixed to first look at the user's preferred model language from the portal, with a fallback to the model's configured master language.

Validate data

• Values in hierarchical CVL fields were not properly reset when changing the parent value.
• Fixing child values in hierarchical CVL value validation errors when the parent field is not mapped has also been resolved.
• Unique fieldtype recognition issue when working with larger data models in the validation addressed and resolved.