Removing Old Business Rules

Business rules were meant to be the easy way: logic on the form without code, assembled with a few clicks. Suddenly you could build logic that previously required JavaScript. This easy way gets used a lot, and that is why grown environments almost always contain a stock of rules that nobody fully keeps track of anymore. When cleaning up, there are a few peculiarities worth knowing.

Where business rules live in the export

In the solution export, business rules do not show up as a block of their own but in the "Workflows" section of the customizations.xml, as processes of category 2. That is surprising the first time you look for them, but it is practical: you get them in one list together with classic workflows and flows and can read name, target table, scope and activation status directly.

The scope is the most important piece of information. A rule can apply to one specific form, to all forms, or to the entire table including server-side evaluation. Rules with table scope also take effect during imports and integrations, and when removing them that makes the difference between a cosmetic change and a functional one.

The three typical legacy cases

Rules for requirements that no longer exist. A field is hidden because a process demanded it years ago. The process is history, the rule keeps running. From the outside it cannot be told apart from an intended rule, so only asking the business helps.

Duplicate logic in rule and script. The same visibility or the same required level is also set by a JavaScript, usually because two generations of developers solved the same need differently. These duplicates are the first candidates, because removing one side changes nothing except that the behavior once again has a single cause.

Deactivated rules. They do nothing, but they appear in every list and every export and get dragged along. In the worst case they also carry dependencies that would otherwise not be needed and inflate the solution artificially. If nobody has reactivated them in a year, chances are high that they were an abandoned attempt or unused logic. The same pattern applies to other ballast in a solution, as described in finding dead components.

A special case deserves its own attention: several active rules that affect the same field. The platform does not guarantee an evaluation order. The result can therefore depend on which rule happens to fire last. Strictly speaking, such overlaps are not a cleanup problem but a correctness problem, and they should be consolidated regardless of any cleanup effort.

The safe approach

Compared with scripts, business rules have one advantage when cleaning up: the deactivate switch. A rule does not have to be deleted to get rid of it. Deactivate it, wait for an observation period, then delete it. If someone speaks up in the meantime, the rule is back with one click.

What matters is the order in your head: first understand what the rule does (the conditions and actions are readable in the definition). Then check whether the same effect is produced somewhere else, and only then deactivate it. Whoever does it the other way round and deletes first ends up negotiating with the business about a behavior that nobody can reconstruct anymore.

Removing rules is maintenance. Ten fewer rules sounds like little, and yet it is ten things that no longer have to be considered during the next form redesign. Rules in large numbers also add to form load times, one of the quieter causes covered in why forms load slowly. And why this kind of routine care pays off at all is the topic of why solution hygiene saves time and money.