Skip to main content

Business Rule Evolution

Business Rule Evolution tells you what changed in your org's business rules between two scans: rules added, modified or removed. It is the quickest way to see what a release actually changed, without comparing two versions of the documentation side by side.

It is included on every plan.

Turning it on​

Change tracking is an option of each scan. On the New Analysis screen of the aprity app, keep Change Tracking enabled (see Analysis Configuration).

The first scan establishes the baseline. Changes appear from the second scan onwards.

Where to find it​

  • Coverage and fidelity → Versions in the portal: the Change history, most recent first, with filters Added, Modified and Removed. See Coverage and Fidelity.
  • Documentation home: a Changes since the previous version summary.

For each change you see the rule and, for a modification, the fields that changed: Title, Condition, Action, Business relevance, Error message.

When two scans cannot be compared​

A difference between two scans is not always a change in your org. aprity shows a notice instead of a misleading list when:

  • the two analyses did not cover the same perimeter (for example a different number of objects analysed),
  • the two analyses were written in different languages,
  • aprity upgraded its analysis engine between the two scans, so the rules were re-derived,
  • the comparison perimeter of some objects could not be certified (those objects are excluded and counted).

When no change can be established, the page says so rather than showing an empty list.

How to use it​

  • Release retrospective -- list every business-rule change since the last release.
  • Deployment check -- scan before and after a deployment, then check that only the expected rules changed.
  • Change review -- when a stakeholder asks "what is new since last time?", share the change history instead of the whole documentation.
  • Test planning -- a modified rule on a critical object is a candidate for retesting.

Limitations​

  • A rule is reported as changed when its own definition changes. A behaviour change caused by another component (for example a field used by the rule) may not appear as a change of that rule.
  • A component recreated under a new identity (for example a flow deleted and rebuilt) appears as one removal and one addition.
  • The comparison is between consecutive scans of the same org, not across orgs.
  • A change in wording alone is not a business change; the comparison is designed to report changes in the rules themselves.