Lookup Relationships and Lookup Filters

Why This Topic Matters

Relationships are the backbone of the Salesforce data model. Every time you connect a Contact to an Account, a Case to a Contact, or a custom Project record to its Owner, you are using a relationship field. On the Advanced Administrator exam, the Advanced Objects and Applications section tests your ability to choose the correct relationship type, understand the behavioral consequences of that choice, and enforce data quality through configuration rather than code. Lookup filters in particular are a favorite exam subject because they sit at the intersection of data integrity, user experience, and declarative design, and because candidates frequently confuse them with validation rules, record types, and sharing.

In real-world administration, misconfigured relationships cause orphaned records, reporting gaps, and user frustration. Understanding lookup relationships and lookup filters deeply allows you to design clean, scalable data models that enforce business rules at the point of data entry.

What Is a Lookup Relationship?

A lookup relationship is a loosely coupled link between two objects. It creates a relationship field on the child (or related) object that references a record on the parent object. Key characteristics include:

• Optional by default: The lookup field can be left blank unless you mark it as required on the field definition or page layout.
• Independent security and sharing: The child record does not inherit the parent's sharing settings. Each object maintains its own Organization-Wide Defaults, sharing rules, and ownership.
• Independent ownership: The child record has its own Owner field, which is not controlled by the parent.
• No roll-up summary fields: You cannot create roll-up summary fields across a lookup relationship. If you need aggregation, you must use a master-detail relationship, Flow, Apex, or a third-party tool.
• Flexible deletion behavior: When the parent record is deleted, you choose what happens to the child.
• Multiple lookups allowed: An object can have many lookup fields pointing to the same or different objects, including itself (a self-relationship, such as a Parent Account lookup on Account).
• Limit: By default, an object can have up to 40 lookup relationships (combined with master-detail, the total relationship limit is also 40 on most objects, with master-detail capped at two).

Lookup vs. Master-Detail: The Critical Comparison

The exam loves to present a scenario and ask which relationship type to use. Memorize these contrasts:

• Required field: Lookup is optional; master-detail is always required.
• Deletion: Lookup gives you a choice; master-detail always cascade-deletes the children.
• Sharing and security: Lookup is independent; master-detail child inherits the parent's sharing and the child has no Owner field.
• Roll-up summaries: Lookup does not support them; master-detail does.
• Reparenting: Lookup records can always be reparented; master-detail children can only be reparented if the "Allow reparenting" option is enabled.
• Standard objects as children: You cannot make a standard object the detail side of a master-detail; you can add a lookup to a standard object freely.
• Conversion: You can convert a lookup to master-detail only if every child record has a value in the lookup field. You can convert a master-detail to a lookup as long as no roll-up summary fields exist on the master object.

Deletion Options on a Lookup Relationship

When creating a lookup field, Salesforce offers three options for what happens when the parent (looked-up) record is deleted:

1. Clear the value of this field (default): The lookup field on the child becomes blank, and the child record remains. This is the only option available if the field is not required.
2. Don't allow deletion of the lookup record that's part of a lookup relationship: Users receive an error and cannot delete the parent while any child references it. This prevents orphaned data.
3. Delete this record also: A cascade delete across a lookup. This option is not visible in the standard UI by default; you must contact Salesforce Support to enable it. It is available only for lookups on custom objects pointing to custom objects, and it deletes children regardless of the current user's sharing access, so it must be used with caution.

If you mark the lookup field as required, option 1 is unavailable; you must choose either to block deletion or (if enabled) cascade delete.

What Is a Lookup Filter?

A lookup filter restricts the set of records a user can select in a lookup, master-detail, or hierarchical relationship field. Instead of showing every record of the related object in the lookup dialog, the filter narrows the valid options based on criteria you define. This improves data quality and usability at the same time.

Lookup filters are configured on the relationship field itself (Setup, Object Manager, select the object, Fields & Relationships, edit the relationship field, Lookup Filter section). Each filter can have up to 10 criteria, joined by AND, OR, or custom filter logic.

How Lookup Filters Work

A lookup filter compares values on the record being looked up against one of the following:

• A static value (for example, Account Type equals "Customer").
• A field on the current (source) record (for example, the Contact's Account must equal the Case's Account).
• A field on the current user's record (for example, the related record's Region must equal the User's Region).
• A field on the user's profile or role.
• A field on the related record's owner.

Key behaviors to understand:

• Required vs. Optional filters: A required filter blocks the save if the selected record does not meet the criteria, and displays an error message you define. An optional filter suggests filtered results in the lookup dialog by default, but the user can click "Show all results" to remove the filter and select any record.
• Enforcement across channels: Required lookup filters are enforced on record creation and edit through the user interface, the API, Data Loader, and Apex. However, they are not retroactively enforced on existing records that already violate the criteria until those records are edited.
• Dependent lookups: When a lookup filter references another field on the same record, it becomes a dependent lookup. If the controlling field is not on the page layout, the filter cannot evaluate properly, so Salesforce warns you to include it. Fields used as controlling fields in dependent lookups cannot be deleted while the filter exists.
• Record type behavior: Lookup filters apply the same criteria regardless of record type unless you build the record type into the filter criteria.
• Activation: Filters can be deactivated without deletion, which is useful during data migrations.
• Referencing other objects: You can reference fields on the source object, the current user, and the related record, but you cannot traverse arbitrary cross-object relationships beyond what the filter editor exposes. Formula fields on the related object are not available as filter criteria if they reference other objects.

Common Real-World Scenarios

• Ensuring a Contact selected on a Case belongs to the same Account as the Case.
• Restricting the Account field on an Opportunity to only Accounts where Type equals "Customer" or "Prospect".
• Limiting a custom Approver lookup to active Users whose Profile is "Manager".
• Preventing users from selecting inactive Products on a line item.
• Allowing sales reps to associate only Accounts in their own Territory using a User field comparison.

Limits and Gotchas

• A maximum of five active required lookup filters per object (optional filters do not count toward this limit, but total filters per object are also limited; check current Salesforce documentation for the exact figure).
• Lookup filters on standard objects referencing certain fields may be restricted; for example, filtering a User lookup by Profile is supported, but some system fields are not.
• Lookup filters cannot reference fields on records that are not directly related, cannot use formula functions, and cannot be bypassed by profile (unlike validation rules, which can use $Profile logic to exempt users, lookup filters can only incorporate user, profile, or role criteria as part of the filter itself).
• When a lookup filter is required and a record already violates it, users editing that record will be blocked until they fix the lookup value.
• Lookup filters are supported in Lightning Experience, Salesforce Classic, and the mobile app, but behavior in some custom Lightning components may vary.

Lookup Filters vs. Validation Rules

Candidates often ask: why not use a validation rule? A validation rule evaluates after the user attempts to save and can only reference fields available in formula syntax. A lookup filter proactively narrows the choices displayed to the user, delivering a better experience and preventing invalid selections before they happen. Validation rules are better when the logic is complex, spans multiple fields in unusual combinations, or must be conditionally bypassed. Lookup filters are better when the goal is specifically to restrict which related records can be selected.

Exam Tips: Answering Questions on Lookup Relationships and Lookup Filters

Tip 1: Identify the relationship type from the requirements. If the scenario mentions roll-up summaries, inherited sharing, or automatic deletion of children, the answer is master-detail. If it mentions optional association, independent ownership, standard-object children, or more than two parents, the answer is lookup.

Tip 2: Watch for deletion behavior clues. "The parent should not be deletable if children exist" points to the lookup option "Don't allow deletion." "Children should remain but lose the reference" points to "Clear the value." "Children should be deleted with the parent across a lookup" requires Salesforce Support to enable cascade delete, and it only works for custom-to-custom lookups.

Tip 3: Distinguish required from optional lookup filters. If the question says users must be prevented from selecting a record, choose a required filter. If users should see a suggested subset but still be able to choose others, choose an optional filter.

Tip 4: Recognize dependent lookup scenarios. Any time the filter compares a field on the related object to a field on the current record (for example, Case Account equals Contact Account), it is a dependent lookup, and the controlling field must be on the page layout.

Tip 5: Remember the conversion rules. Lookup to master-detail requires all child records to have a parent value. Master-detail to lookup requires removing roll-up summary fields first.

Tip 6: Know what lookup filters cannot do. They cannot be bypassed via validation-rule style profile checks, cannot use formula functions, and do not retroactively clean existing data. If the question asks about fixing existing bad data, the answer involves a data update, not simply adding a filter.

Tip 7: Choose declarative over programmatic. The exam consistently rewards the simplest declarative solution. If a lookup filter solves the problem, it beats a validation rule, which beats a Flow, which beats Apex.

Tip 8: Eliminate distractors. Answer options mentioning "sharing rules" to restrict lookup choices are wrong, since sharing controls record visibility in general, not lookup selection specifically (though records a user cannot see will not appear in a lookup anyway). Options mentioning "record types" alone are wrong unless the requirement is about picklist values or page layouts.

Tip 9: Count the limits. If a scenario involves adding a sixth required lookup filter on one object, recognize the five-active-required-filter limit and look for a validation rule alternative.

Tip 10: Read for the word "standard." A standard object cannot be the child in a master-detail relationship, so any scenario requiring a standard object (like Contact or Case) to be a child of a custom object must use a lookup.

Summary

Lookup relationships offer flexible, loosely coupled connections between objects with independent security, optional values, and configurable deletion behavior, in contrast to the tightly coupled master-detail relationship. Lookup filters add a layer of data quality by restricting which related records can be selected, either as a hard requirement or a soft suggestion, using criteria based on the related record, the current record, or the running user. Mastering the differences between relationship types, the three deletion options, the required-versus-optional distinction, dependent lookup behavior, and the limits and conversion rules will prepare you to answer any lookup-related question on the Advanced Administrator exam with confidence.