Strategic Validation Rule Carve-Outs for Integration Field Updates

Records in Salesforce often reach a "locked" state where general edits should be blocked -- an activated Order, an approved Quote, a closed Case. But integration processes frequently need to update specific fields on these locked records: writing back PO numbers, updating shipment tracking, or recording invoice references. Validation rule carve-outs solve this tension.

The Pattern

A carve-out uses NOT(ISCHANGED()) to exclude specific fields from triggering a validation rule. If the only fields being modified are the carved-out fields, the rule does not fire.

Basic Example: Locked Order with Integration Updates

Suppose an Order is locked after activation, but the integration needs to write a Coupa PO number:

Without carve-out (blocks everything):

AND(
    ISPICKVAL(Status, "Activated"),
    ISCHANGED(Status) = FALSE
)

With carve-out for PO number:

AND(
    ISPICKVAL(Status, "Activated"),
    NOT(ISCHANGED(Status)),
    NOT(ISCHANGED(Coupa_PO_ID__c))
)

The rule now fires only when a field other than Coupa_PO_ID__c or Status is changed on an activated Order. If the integration updates only Coupa_PO_ID__c, the NOT(ISCHANGED(Coupa_PO_ID__c)) clause evaluates to FALSE, making the entire AND expression FALSE -- the rule does not trigger.

Combining Multiple Carve-Outs

When multiple integration fields need exceptions, chain them with AND:

AND(
    ISPICKVAL(Status, "Activated"),
    NOT(ISCHANGED(Status)),
    NOT(ISCHANGED(Coupa_PO_ID__c)),
    NOT(ISCHANGED(Coupa_PO_Line_ID__c)),
    NOT(ISCHANGED(Supplier_Invoice_Number__c)),
    NOT(ISCHANGED(Shipment_Tracking__c))
)

Each NOT(ISCHANGED()) clause creates an independent carve-out. The rule only fires when a field that is not in the carve-out list is modified.

How It Works Logically

Consider the AND expression with three conditions:

AND(
    Record_Is_Locked,            -- TRUE (record is in locked state)
    NOT(ISCHANGED(Field_A__c)),  -- FALSE if Field_A changed
    NOT(ISCHANGED(Field_B__c))   -- FALSE if Field_B changed
)

• If only Field_A__c changes: second condition is FALSE, rule does not fire.
• If only Field_B__c changes: third condition is FALSE, rule does not fire.
• If both Field_A__c and Field_B__c change: two conditions are FALSE, rule does not fire.
• If Field_C__c changes (not carved out): all three conditions are TRUE, rule fires and blocks the edit.
• If Field_A__c AND Field_C__c both change: second condition is FALSE, but this means the rule does not fire -- which may or may not be desired.

Important nuance: If a carved-out field changes alongside a non-carved-out field, the carve-out still prevents the rule from firing. This means a user could theoretically modify a locked field by including a carved-out field in the same transaction. Assess whether this is an acceptable risk for your use case.

Carve-Outs vs. Bypass Mechanisms

Approach	Pros	Cons
NOT(ISCHANGED()) carve-out	Field-level precision; no profile/permission dependency	Complex formulas for many fields; the nuance above
Profile-based bypass	Simple; covers all fields for the integration user	Overly broad -- integration user can modify anything
Custom Permission bypass	Flexible; assignable via Permission Set	Requires managing Permission Set assignments
Custom setting/metadata bypass	Configurable without deployment	Additional maintenance; easy to forget to re-enable

Carve-outs are best when you need surgical precision -- only specific fields should be updatable, and the rule should still protect everything else. Profile or Permission-based bypasses are better when the integration user needs broad update access.

Documentation Is Essential

Carve-outs make validation rules harder to read and maintain. Document them clearly:

1. In the rule description: List every carved-out field and the reason for the exception.

   Locks activated Orders from editing.
   Carve-outs: Coupa_PO_ID__c (INT12), Coupa_PO_Line_ID__c (INT12),
   Supplier_Invoice_Number__c (INT16), Shipment_Tracking__c (INT15)

2. In a central reference: Maintain a table of all carve-outs across the org, mapping each carved-out field to the integration point that requires it.

3. In code reviews: When adding new integration fields, check whether existing validation rules need new carve-outs.

Testing Carve-Outs

Test each combination to verify the carve-out works correctly:

1. Update only a carved-out field -- should succeed.
2. Update only a non-carved-out field -- should be blocked.
3. Update a carved-out field and a non-carved-out field simultaneously -- should succeed (the carve-out overrides). Verify this behavior is acceptable.
4. Update no fields (trigger a save without changes) -- should not fire (no ISCHANGED returns true).

Use anonymous Apex to simulate integration updates, since the integration user context may differ from manual UI testing.