Business Rules & Governance
A validation rule is a public contract—not a form message
The rule runs wherever the record is saved
A validation rule is often designed while looking at a Lightning record page: a user enters a value, clicks Save and sees a message beside a field. That view is dangerously narrow. The same rule can reject a change made through an API, data load, Flow, Apex service, integration or background process. It is part of the transaction boundary, not decoration on one form.
Salesforce documents validation rules as formulas that evaluate data before a record can be saved; a true result means the data is invalid. The platform behaviour is simple. The operating consequences are not. One new condition can stop salespeople, fail an integration batch and break an automation path on the day it is activated. Treat that reach as a design property from the start.
Express an invariant, not a screen instruction
A strong validation rule protects a business invariant: an approved discount must have an approver, an end date cannot precede a start date, or a closed case must contain a resolution. These statements remain meaningful regardless of who or what performs the update. ‘User must complete this field on the opportunity page’ is usually a presentation requirement disguised as a data rule.
Use page configuration, guided Flow or component behaviour to help people complete a task. Use a validation rule when every relevant writer must preserve the condition. Sometimes both are appropriate: the interface prevents an avoidable mistake early, while the server-side rule protects the record against every write path. Write the invariant in business language before writing the formula; if stakeholders cannot agree on the sentence, the syntax will not resolve the ambiguity.
Design for the transaction state Salesforce actually evaluates
Order of execution matters. Salesforce runs system validation, before-save record-triggered flows, before triggers, custom validation rules and later automation in a defined sequence. A rule may therefore see values changed earlier in the transaction, while a later process cannot repair a record the rule has already rejected. Architecture diagrams that say only ‘on save’ hide this critical timing.
Map every field used by the rule to the process that supplies it. If a before-save Flow normalises a code, test the normalised state. If Apex expects a later workflow update to populate a dependent field, the design is inconsistent. Prefer one clear owner for deriving prerequisite values, and make the validation rule independent of execution-order accidents.
Scope the transition deliberately
Rules intended for a particular change often become accidental tests of the entire historical record. A stricter address standard, for example, can prevent a service agent from updating an unrelated phone number on an old account. The rule may improve new data while freezing legitimate work on legacy data.
Decide explicitly whether the invariant applies on creation, every edit, or only when relevant fields or lifecycle states change. Functions such as ISNEW, ISCHANGED and PRIORVALUE can express that transition. They are not automatic exemptions: a badly scoped condition can also let invalid data persist forever. Document the remediation plan for existing records and the event that brings them under the new standard.
Error messages are operational output
The message is not only microcopy for an employee. It can appear in import results, API errors, Flow fault paths, Apex exceptions and support logs. Make it specific about the failed condition and the action that can resolve it. ‘Validation exception’ creates a ticket; ‘Set an approval owner before moving the discount above 20%’ helps a person or operator recover.
Do not make integrations parse English text as a machine contract. Wording can change and may be translated. Integration owners should classify Salesforce error structures, retain record-level results and reconcile failed rows using stable business context. The human-readable message remains valuable, but it is an explanation—not an error code scheme.
A bypass is a privileged capability
Some migrations, repair jobs and tightly controlled service processes need to write data that ordinary operations cannot. Hard-coding a username, profile name or integration user into the formula turns an exception into hidden identity debt. It is difficult to audit, survives role changes badly and encourages teams to grant a broad exemption permanently.
Where a bypass is justified, model it as a custom permission checked by the rule and grant that permission through a narrowly scoped permission set. Define who can assign it, for which procedure, for how long and how use will be reviewed. The existence of a bypass should never mean ‘trusted users do not need data integrity’; it means a named operational process owns the risk and the subsequent reconciliation.
Bulk changes reveal the real contract
A rule that looks harmless during a single-record test can make a 50,000-row load operationally expensive. Some rows may be valid, others may fail, and the caller's all-or-none choice determines whether successful work is committed. Salesforce's Database methods can return per-record SaveResult details when partial processing is allowed; DML statements instead raise exceptions for failed operations.
Design the surrounding process accordingly. Keep a correlation key for each input, retain row-level errors, separate retryable technical failures from rejected business data and provide a route for correction. Test representative batches, not just one record. A validation rule is safe at scale only when the writer can explain exactly what happened to every row.
Roll out the rule as a behavioural release
Activating a rule changes the write contract immediately. Sequence the release: profile existing data, identify every producer, repair or quarantine non-compliant records, update automation and integration tests, deploy supporting permissions, then activate the rule. For a material change, rehearse the activation and recovery path in an environment with representative data and identities.
Do not use deactivation as the only rollback plan. Records written while the rule is off may need reconciliation when it returns. Define whether failure calls for a configuration rollback, a forward formula fix, a temporary governed bypass or an upstream correction. Monitor import failures, Flow faults, API error rates and support cases after activation so that an apparently clean deployment does not conceal blocked business work.
Test the contract from every important writer
A formula syntax check proves almost nothing about operational correctness. Test valid and invalid boundaries, create and update transitions, nulls, historical records and combinations of related fields. Exercise the rule as real personas, the least-privilege integration identity and the automation that owns prerequisite values. Include bulk requests with mixed outcomes.
Tests should assert the business result, not merely that some exception occurred. Apex tests can inspect DML errors; Flow tests and integration suites should verify their fault handling and reconciliation. Keep a positive test for each authorised exception as well as a negative test proving that ordinary users cannot bypass the rule. That evidence should travel with the metadata change.
Give every rule an owner and a lifecycle
Record the business invariant, owner, affected fields, known writers, transition scope, exception mechanism and implementation date in the rule description or an adjacent register. Review rules when processes, products or integrations change. Duplicate and contradictory rules are usually evidence that ownership has fragmented across projects.
The JSBC Labs view is that validation rules deserve the same discipline as public service contracts. They define what the platform will accept, expose errors to multiple consumers and can stop critical operations without changing a line of application code. Design the invariant, transaction timing, error semantics, bypass, rollout and evidence together. The formula is the smallest part of the decision.