Keeping Thousands of CRM Configuration Items Consistent With Automated Pre-Commit Checks

Large CRM implementations drift. Every new field, picklist value and automation is added by someone solving today's problem, and over time the configuration stops agreeing with itself. On a large production Salesforce implementation for a professional-services delivery organisation, we worked on ongoing configuration and business-logic development where thousands of configuration items had to stay consistent. Automated pre-commit checks were how we kept them that way.

The implementation

The organisation uses Salesforce as its system of record for delivery, expense and revenue tracking. The work included:

• Batch jobs for recurring usage and revenue calculations.
• Automated integrations syncing expense approvers and professional services automation (PSA) data.
• A custom business-capability taxonomy that encodes the organisation's internal service offerings, spanning hundreds of fields and objects.

The technology includes Apex, Lightning Web Components, Salesforce DX and Jest for testing.

Configuration is code

With Salesforce DX, configuration lives as metadata files in source control, alongside Apex and components. That changes how configuration can be managed: it can be reviewed, versioned and checked automatically, like any other code.

At the size of this implementation, it has to be. Thousands of configuration items cannot be kept consistent by people remembering the rules. A taxonomy that spans hundreds of fields only stays coherent if something checks every change against it.

Automated pre-commit checks

Pre-commit checks run before a change is committed to the repository. Git supports this through hooks, which can run scripts at points in the commit process and reject a commit that fails them.

For this implementation, automated pre-commit checks keep the configuration items consistent. The value of checking at commit time rather than later is timing: an inconsistency is caught on the developer's machine, in seconds, before it reaches review, deployment or the production org.

Typical examples of what checks like these can enforce include:

• Naming conventions across fields and objects.
• Values that must match an agreed taxonomy.
• Required metadata that must accompany a new item.
• Formatting that keeps diffs readable for reviewers.

Test the parts users never see

Batch jobs and integrations run in the background, which makes their failures easy to miss until the numbers are wrong. Revenue calculations and expense-approver syncs affect money and approvals, so they are exactly the parts that need tests. Jest is part of the toolchain on this implementation, used for testing Lightning Web Components.

The outcome

The organisation has a single, well-tested system of record for delivery, expense and revenue tracking. The checks do not make the configuration smaller. They make its growth safe, so new work does not quietly break the consistency the business relies on.

A checklist for large CRM configurations

• Keep configuration in source control as metadata.
• Write down the rules your configuration must follow.
• Enforce those rules automatically at commit time.
• Test background jobs and integrations, not only screens.
• Treat the business taxonomy as a controlled vocabulary.

The anonymised write-up is in our work library. For understanding what depends on what before making changes, see mapping Salesforce dependencies in a graph. Keeping large systems healthy as they grow is part of our product improvement service.