Enhancement: Workflow Versioning — History tab

Announcements Product News
, ,
1

:sparkles: Description

NERM Classic workflow configuration now includes a History tab so IAM admins can review version lineage and step/configuration changes for the workflow they have open, without reconstructing that story from Admin Activity or the audit API.

History is a UI over the audit events and query-by-version work that already shipped. It does not introduce a second source of truth.

:light_bulb: Solution

Admins open an existing workflow, select History, and scan a paginated table (newest-first) of version-lifecycle and step/configuration-change events: when, who, event type, step (when applicable), and version identifier. Search covers step labels, step IDs, and version IDs; quick filters narrow the list.

Selecting a row opens event details (Workflow Update, Version Created, Version Forked). From a version-oriented event, the admin can follow the change(s) that spawned that version and open a comparison between versions, especially after a fork.

Access matches existing workflow-config and audit/admin rules. History is scoped to the workflow being viewed.

:busts_in_silhouette: Who is affected?

IAM admins and auditors who configure or review NERM Classic workflows and already have access to workflow configuration and audit data.

:date: Important dates

Sandbox: September 23, 2026
Production: September 30, 2026

1 Like
2

This is great news and sorely needed!

If we look at our own sandbox tenant, we see a lot of ‘empty’ values with ‘Workflow Updated’, but also some useful values like ‘step updated’. Example:

image
image1178×465 34 KB

Is there (going to be) documentation available that describes what and when something is recorded?

3 Likes
3

Thanks for checking this in your sandbox and for sharing the screenshot!

The dashes on Workflow Updated are expected. That event is recorded whenever the workflow changes: a step is added, a step is updated, steps are reordered, or the workflow name is changed. The row itself stores very little, so Step Label and Version ID stay blank. The step name and version are on the Step Created or Step Updated row with the same timestamp.

  • Step Created and Step Updated record a step being added or saved. Those rows include the step label and the associated version.
  • Version Created records a new workflow version. It includes the Version ID and no Step Label.
  • Workflow Updated records that the workflow changed. Open the row for its event details. The step and version are on the step event next to it.

History begins when the applicable audit functionality is enabled. Earlier workflow changes are not backfilled.

The production rollout is currently planned for September 30th. Documentation will be published shortly after. It will be under Activity and Reporting > Tracking Workflow Updates.

4

So the question is then on the timing of when the ‘Workflow Updated’ entry is recorded?

  • When someone hits save, or;
  • When someone opens that workflow to start editing

I’m asking this, because we also have an example with only ‘Workflow Updated’ entries, example:

image
image1467×606 62.6 KB

5

Thanks for the detail and the example. Workflow Updated entries are recorded when changes to the workflow are saved, not when the workflow is opened for editing.

Entries with Performer “Automatic” come from background system processes that update internal fields used by the platform (for example, a check for whether a workflow is recursive). These never change customer configuration. Workflow Updated events also don’t include a Step Label or Version ID because they apply to the workflow as a whole rather than a specific step or version.