How to review CRM workflow rules without breaking them

• Requests arrive individually. Each rule was a sensible answer to one problem, so nobody reviewed the set.
• Authors leave. The rule stays; the reason for it goes with the person who wrote it.
• Processes change underneath. A stage is renamed or a pipeline restructured, and a rule written against the old shape no longer does what it appears to do.
• Duplicate intent, different rules. Two rules reassign ownership for similar conditions, and the record ends up with whichever ran last.
• Nothing is ever removed. There is no habit of retiring automation, so the set only grows.

One row per rule, with six columns:

1. Rule name, as it appears in the account.
2. Trigger: the event that makes the rule evaluate.
3. Conditions: what has to be true, including the fields it depends on.
4. Actions: what changes, and whether the change can trigger another rule.
5. Owner: who asked for it, or who maintains it now.
6. Last changed, and whether that is known or inferred.

Building the inventory is most of the work. Once it exists, the duplicates and conflicts are usually visible from the rows rather than needing to be hunted.

Three patterns account for most of the trouble. First, two rules that set the same field on similar conditions: the outcome depends on evaluation order, which means the behaviour is stable only by accident. Second, an action that triggers another rule that changes the field back, producing a loop or a record that flips between owners. Third, rules whose conditions reference fields nobody maintains, so they evaluate against placeholder values.

Recording what each rule is for, not only what it does, is what makes consolidation possible. Two rules with the same intent become one; rules with different intents stay, and are documented as such.

1. Document the current state before touching it, including the rules you intend to keep.
2. Consolidate duplicates into a single rule with the combined conditions, and check the edge cases.
3. Disable anything whose purpose cannot be established, and watch the records it touched for a period.
4. Change one rule at a time, in a window when the team is not depending on its outcome.
5. Record each change with its date and reason, so a later side effect can be traced to a cause.

The documentation is the deliverable that outlasts the project. An account where each rule's purpose is written down can be administered by somebody who was not there when it was built.

The example below is hypothetical and describes a pattern rather than a client account.

Rule review and consolidation is the third of the CRM consulting scopes, inside the Operations & Systems capability. Where the rules that matter connect two systems rather than operate inside one, the integration work owns that boundary.