How would you implement cross-object validation that depends on related records?

Validation Rules can reference parent records via a master-detail or lookup relationship using formula syntax: Account.Industry__c == 'Healthcare' works inside an Opportunity validation rule referencing its parent Account.

But validation gets harder when:

1. Validation depends on child records (parent referencing children). Validation Rules can't natively traverse parent-to-child collections.
2. Validation depends on a calculation across multiple children (e.g., "Opportunity can't close if any Quote Line Item has unapproved discount").
3. Validation depends on records on a different object entirely (no lookup relationship).

Strategies:

For parent -> child constraints:

• Roll-Up Summary (master-detail only) — sum/count/max/min of child records, then validate that summary on parent. E.g., a Roll-Up Summary Unapproved_Discount_Count__c on Opportunity counting Quote Line Items where Discount_Approved__c = false; then a validation rule blocks save if Unapproved_Discount_Count__c > 0.
• Trigger / Apex — the most flexible. Write a trigger on the parent (or child) that queries the related records and throws a validation error.
• Record-triggered Flow with Get Records to fetch children, then a Decision element to evaluate, then addError (Apex) — actually, Flow can't addError declaratively; you must call an Apex action that does it. Or use a before-save flow on the child that errors when invalid.
• Validation on the child object itself — instead of validating "Opportunity has at least one approved line item" on Opportunity save, validate on Quote Line Item save that the parent Opportunity stage allows the line item's state.

For unrelated cross-object constraints:

• Build a Formula Field that fetches data via a custom code/formula (limited).
• More commonly, an Apex Trigger that queries the unrelated object and validates.

Recommended pattern:

For most cross-object validation, the cleanest approach is to define the constraint on the child object's save (e.g., "child cannot be created with state X if parent's state is not Y"), enforced via a child-side validation rule referencing the parent through the lookup. This avoids the parent-needing-to-know-children problem.

When the constraint truly requires aggregation across multiple children before allowing a parent transition, fall back to Roll-Up Summary + parent validation, or to a record-triggered flow / trigger.

Avoid over-engineering — many "complex cross-object validations" can be reframed as simpler constraints on the right object.