Determine if next Process Action should be executed immediately

We are considering a solution where the runtime would automatically merge subsequent process actions into a single merged follow-up action.

Only actions on the same subject which may affect the current data set in the UI would be merged.
  - Open document (only as first-merged action)
  - Activate document (only as first-merged action)
  - Activate detail (only as first-merged action)
  - Zoom detail (only as first-merged action)
  - Change filters
  - Change prefilters
  - Clear filters/restore filters/default prefilters
  - Change sort order
  - Refresh
  - Go to row
  - Go to first/previous/next/last row

A process action with a process step towards an action type that is not in the list above will cause the process action to be the last merged process action.

The merged process actions must be a lineair chain. A process action with more than one subsequent step will be the last merged process action.

The steps between merged process actions may only be  ‘Always’ or ‘Success’. Since the merged actions is performed as a single action at the same time, the UI will not be able to distinguish between success or failure of individual aspects such as applying sorting, going to a specific page for a row or changing prefilters and will consider them successful for the merged steps. A process action with a subsequent step that is not ‘Always’ will be the last merged process action.

The merging of actions stops when a process action has an output variable mapping - this would be able to affect subsequent action input and as such cannot be merged. The process action with the output variable mapping will be the last merged process action.

The merging of actions stops when there is process logic - this may both affect action input and which steps are executed. The process action with process logic enabled will be the last merged process action.

The output variables are all based on the last merged process action and the success and status code is based on the action as a whole. This means you would not be able to distinguish between the ‘open document’ failing or the ‘go to row’ not being able to find the row.

This solution would automatically work for existing process flows and require no changes by developers as long as the flows follow the rules above.

We’d love to hear all of your input on this.

We have implemented custom flow monitoring for all of our process flows. To log actions and the current state of process variables we use dynamically assigned process logic. It seems we would have to rework this to make this merging of actions possible even though this monitoring process logic never changes which steps are taken.

Would this merging of process actions still work if we only assigned our monitoring to the last merged process action? If so, we can change our dynamic code to only assign the monitoring to these last merged actions. If not, we would require a substitute for our flow monitoring as described in this idea: 

This depends a bit on how intelligent the merging of the process actions will be. If the process actions do not use any input variables that may be modified by the process logic it may still allow merging.

Only applying the logging logic at the last process action is not trivial - you’d need to replicate the algorithm in your own dynamic assignment logic to determine what will and what won’t be merged. It may be easier to simply tag certain process actions to exclude them from receiving monitoring logic. If only the last process action in a merged chain has the monitoring logic it should work out.

First-class logging features of process flows as you pointed out would indeed be the easiest solution.

@Anne Buit @Jeroen van den Belt Since this was marked as Planned months ago, we kinda expected this to be part of the 2023.2 Release. It doesn't seem to be there (yet), but we're still eagerly awaiting this significant performance improvement! When can we expect this?

Hi Arie,

This change will not be bound to a specific Thinkwise Platform release version.

Work has been done, both for Indicium and Universal and significant progress has been made, but since the current focus is on porting existing platform features, we’ve not officially marked this idea as ‘Working on it’ because the horizon for release of this idea is still quite vague.

When we can commit to being able to actually finish up and release this idea, we’ll update the status.