Skip to main content

Business Rule Evolution

Business Rule Evolution is the change-tracking layer of aprity. Once your tenant has at least two successful scans of the same org, every new scan compares the business rules it extracts against the previous scan and surfaces the diff : rules that were added, modified, or removed.

This is how you spot what your team (or someone else's team) actually changed in the org since the last documentation snapshot -- without having to read both versions side-by-side.

What you'll see​

Each rule documented in your scan output now carries a small change badge :

  • New -- the rule did not exist in the previous scan.
  • Modified -- the rule existed but its definition (conditions, error message, target object, etc.) has changed.
  • Unchanged -- no change since the previous scan (default state, usually rendered without a badge).
  • Removed -- the rule existed in the previous scan but is no longer present. These appear in a dedicated Removed since last scan section so you can audit deletions without losing the trail.

Each change entry includes :

  • The rule's identity (validation rule name, trigger handler, Flow element, …).
  • The previous and current versions of the changed fields, side by side.
  • The source metadata type that drives the change detection (e.g. "Validation rule definition changed", "Apex trigger body changed", "Flow XML changed").
  • A pointer back to the scan that introduced or removed the rule, so you can navigate to a specific past scan and see the context.

The same change information also feeds the Customer Portal (where it appears as a coloured badge on each rule page), and is exported in the StorySite backlog (as a tag on each USER STORY).

How the diff is computed​

The change detection is deterministic. aprity computes a content hash of each rule's underlying metadata (Apex source, Flow XML, validation rule formula, …) on each scan, and compares it against the hash from the previous successful scan of the same org. A change in the hash means a change in the rule.

There is no LLM involvement in the diff -- the same input produces the same diff every time. The narrative around the diff (the human-readable description of what changed) is paraphrased from the metadata, not invented.

Plan availability​

Business Rule Evolution is included on every plan:

  • Trial -- included.
  • Documentation -- included.
  • Intelligence -- included.

See Plan Comparison for the full feature matrix.

Business Rule Evolution requires at least two successful scans of the same org for change badges to be visible. The first scan establishes the baseline -- change badges appear from the second scan onwards, comparing each rule against the previous scan.

Where to find it​

  • Customer Portal : a Changes tab and badges on each rule page.
  • StorySite export : each USER STORY carries a change tag (new, modified, removed).
  • Help Agent : ask "What changed since the last scan ?" or "Were there any new validation rules on Opportunity since last month ?" and the agent will cite the diff.

How to use it​

Business Rule Evolution is the right starting point when you need to :

  • Run a release retrospective -- list every business-rule change in the org over the past sprint or release.
  • Audit a deployment -- "After we deployed the package on Friday, did any unintended rules change in production ?" -- run a scan before and after, compare.
  • Track ownership-related changes -- "Which queues were added or removed since the last assignment-rule review ?"
  • Reduce review noise -- when a stakeholder asks "what's new in our doc since the last sync ?", share the Changes since last scan section instead of the whole document.
  • Trigger downstream work -- a Modified rule on a critical object is a candidate for re-testing in your UAT suite ; a Removed rule is a candidate for cleanup in dependent code.

Limitations​

  • A rule is considered changed when its source metadata changes. If a rule's behaviour changed because of a different metadata file (e.g. a renamed field in another object), the diff might not flag it -- the rule's own definition is the same.
  • Renames are detected only when the underlying metadata id is preserved by Salesforce. Renaming a Flow that becomes a brand-new Flow with a different id appears as one Removed + one New entry.
  • Diff scope is "since the previous scan of the same org", not "across multiple orgs". To compare two orgs, run scans on both and inspect the documentation side by side.
  • Documentation narratives change between scans even when the underlying rule did not (because the LLM paraphrases independently). The change detection looks at the metadata, not at the narrative, so narrative-only differences do not surface as rule changes.

For anything else, contact support@aprity.ai.