Rule Versioning

Rule Versioning allows multiple numbered iterations of the same rule to exist side by side. All versions share the same Rule ID and Rule alias, while each version keeps its own structure, content, version number, and status.

Open the Rule Actions menu, the three-dot button in the rule editor, and select New Version. The same action is available by right-clicking a rule or opening its three-dot context menu in the folder or Business Rules view. DecisionRules copies the selected rule structure and assigns a version number one higher than the latest existing version.

Creating versions requires the corresponding Fork permission. The action can also be unavailable when the rule is locked, another version is currently being created, or versioning is not included in the current plan or configuration.

Every newly created version starts in Pending status. It cannot be executed through the Solver API, but it can be evaluated in Test Bench when Debug mode is enabled.

No. DecisionRules does not impose a limit on the number of versions that can be created for a rule.

A Published version is production-ready and can be executed through the Solver API. A Pending version is isolated from the Solver API, but it can still be evaluated directly inside DecisionRules using Test Bench.

Yes. Status is configured independently for each rule version. This allows one version to remain available in production while another is developed and tested in Pending status.

When a Solver API request does not include a version, DecisionRules automatically uses the latest Published version, the Published version with the highest version number. Specify a version explicitly when an integration must remain pinned to known behavior.

The remaining versions keep their original numbers. New numbering always continues from the highest existing version. For example, if v23 was deleted but v24 exists, the next new version will be v25.

Yes, supported rule types can be compared side by side. The comparison helps identify changed conditions, values, rows, branches, or script lines depending on the rule type. Only rules of the same type can be compared, and Rule Comparison is available for selected subscriptions.

An earlier version can be used as a clean rollback point. Select the known-good version and create a new version from it. DecisionRules copies its structure into the next sequential version, which can then be tested and published through the normal release process. This preserves the version trail instead of rewriting it.

Pending versions of Decision Tables, Scripting Rules, Decision Trees, and Rule Flows can be evaluated in Test Bench with Debug enabled. Lookup Tables must be Published before they can be evaluated. Integration Flows are executed through the Jobs API rather than the Solver API.

Yes. A selected rule version can be exported like any other rule. Rules use the DecisionRules JSON format, while Decision Tables also support spreadsheet-based export and import workflows.

Import behavior depends on the import method and source format. Always review the imported rule's status after import before connecting it to a production integration.

Yes. The Management API can be used to work with rule resources and their versions, making versioned rules suitable for automated backup, migration, and deployment workflows. The complete environment promotion process will be covered on the dedicated CI/CD Pipelines page.

Rule Versioning creates explicit numbered checkpoints for significant changes and releases. Rule History records saved states inside the current rule version each time the rule is saved. Use versions for controlled releases; use History to inspect or restore smaller editing changes within a version.

No. Saving creates a new entry in Rule History, not a new numbered Rule Version. A numbered version is created only when the user explicitly chooses New Version.

Yes. A historical save can be restored as the current state of that rule version, or cloned into a separate rule. Historical entries are read-only until one of those actions is selected. Rule History is not currently available for Rule Flow.

Create a new version for changes that deserve their own testing and release checkpoint, for example a new pricing strategy, a compliance update, a major restructuring, or any change that should be promoted independently.

For production rules, create a new version and make the change there. Keeping development in a Pending version protects the currently published behavior and gives the team a clear review and testing step.

Use explicit versions when an integration must remain pinned to known behavior. Test the Pending version, compare it with the currently used version, publish it after approval, and promote it between environments through the Management API or a CI/CD pipeline.

Keep versions that represent meaningful releases, audit points, or rollback candidates. Remove only versions that are no longer useful. Deleting a version does not renumber the remaining versions.