Upgrade notes (3.0 to 3.1)

Heads Up!

To upgrade Optimize to version 3.1.0 please perform the following steps: Migration & Upgrade Instructions.

Here you will find information about:

  • limitations,
  • known issues,
  • changes in the supported environments,
  • any unexpected behavior of Optimize (e.g due to a new feature)

Changes in the supported environments

With this Optimize version there are also changes in the supported versions of Camunda BPM platform.

Camunda BPM platform

Optimize now requires at least Camunda BPM 7.11.13. See the Supported Environments sections for the full range of supported versions.

Breaking Changes

With Optimize 3.1.0 the History Cleanup configuration got restructured and needs to get adjusted accordingly. Major changes are the removal of the global feature flag historyCleanup.enabled in favor of entity type specific feature flags as well as a relocation of process and decision specific configuration keys. Best refer to the configuration reference.

Known Issues

Event Based Processes - Event counts/suggestions

As part of the upgrade from Optimize 3.0 to 3.1, the event counts and the next suggested events used as part of the event based process feature are recalculated. Until the recalculation is complete, the event counts might be incorrect and the suggestions inaccurate. Once the recalculation is complete, the event counts will return to being correct and you will see more accurate suggested next events.

Limitations

User Permissions

With Optimize 3.1, user and group related permissions are checked by Optimize to determine whether the current user is authorized to access other users/groups within Optimize, for example when adding new roles to a collection. Due to this it is now required to explicitly grant users the relevant authorizations, otherwise they will not be able to see other users and groups in Optimize. More information on authorizations can be found here.

User Operations Log Import

With Optimize 3.1, the user operations log is imported to detect changes to running instances’ suspension status. The user operations log informs Optimize when instance suspension requests have been received by the engine, and Optimize then reimports the relevant instances to ensure their suspension state is set correctly in Optimize. However, if instances are suspended using the engine API’s executionDate parameter, with which suspension operations can be triggered with a delay, Optimize currently is not able to detect this delay, and will re-import the running process instances at the time the suspension operation is read from the user operations log, not at the time the suspension takes place. This can lead to inaccuracies in the suspension state of process instances in Optimize.