A service agent selects the right customer Account but attaches a Contact from another company. Reports and follow-up messages now point to an inconsistent relationship. A lookup filter can narrow the Contact choices and reject a selection that does not meet the chosen business rule.
This tutorial implements one specific rule: a Case’s Contact must have the same primary Account as the Account selected on that Case. It is appropriate only when that is how your service process defines a valid contact. Test the configuration in a sandbox before changing production.
Start with a small, explicit example
Create two fictional business Accounts: Harbor Lab and Canyon Lab. Create a Contact named Alex Harbor under Harbor Lab and a Contact named Bailey Canyon under Canyon Lab. Use non-sensitive test data and give your test agent the normal access required to work with these records.
For a Case whose Account is Harbor Lab, Alex should be selectable and Bailey should not. Write that expected result down before configuring anything. Also decide whether a Case may have no Contact or no Account. A lookup filter and a required-field setting answer different questions; do not assume that configuring the filter makes either field mandatory.
Configure the field-to-field comparison
- In Setup → Object Manager → Case → Fields & Relationships, open Contact Name and select Edit.
- In the Lookup Filter section, select Show Filter Settings.
- For the first field, choose Contact Name: Account ID. Set the operator to equals.
- Choose Field, rather than a fixed Value, for the comparison type. Select Case: Account ID as the comparison field.
- Keep the filter active and select Required. If you provide a custom error, explain the correction: “Choose a contact whose primary account matches this case’s account.” Save.
- Confirm that both Account Name and Contact Name are available on the intended Case page, with Account before Contact. Test the actual layout and Lightning page used by agents.
The comparison uses the relationship IDs, so it is not a text comparison between company names. Two Accounts with identical names remain separate records. Avoid replacing this rule with a comparison of display labels.
Run a test that can fail
- Valid selection: create a Case for Harbor Lab and search for Alex. Select the Contact and save. Reopen the Case and verify both relationships.
- Wrong Account: search for Bailey on that Case. Confirm the lookup excludes the invalid choice. Test an attempted invalid selection through the relevant entry path, and record the observed error.
- Account changed: start with the valid Harbor Case, then change its Account to Canyon Lab. Verify the saved result and the correction the agent must make. Do not assume the old Contact is silently replaced.
- Blank values: test a blank Account, a blank Contact, and a Contact with no primary Account. Compare the behavior with the requirement written earlier.
- Normal user: repeat as a representative service user. A test performed only with administrator access does not establish that agents can find and correct the records.
Keep the expected result, observed result, and test user with the change ticket. If a lookup appears empty, check the filter, the selected Account, Contact access, and page configuration before broadening access or removing the filter.
Plan for existing data and integrations
Activating a filter does not rewrite existing relationships. Salesforce documents that an existing value that becomes invalid can remain stored, but editing the record can then require correction before saving. Review existing Cases and agree on remediation before rollout, especially if agents cannot edit one of the affected fields.
Lookup filters are enforced for data loaded through supported Salesforce APIs. In the sandbox, submit one valid pairing and one deliberately mismatched pairing through your real integration or import process. Verify its failure handling and retry behavior. Do not repeatedly replay an entire successful load because one row failed.
For an integration that creates Accounts, Contacts, and Cases separately, document when the correct relationship IDs become available. The filter does not infer which company a person belongs to or repair an upstream mapping. The sending system still needs to supply the intended IDs.
Know when this rule is too narrow
This comparison uses the Contact’s primary Account field. It does not implement “any account associated with this person” through an Account Contact Relationship junction record. If your process relies on indirect relationships, document that requirement and design a different selection and validation approach rather than pretending this simple comparison covers it.
In Lightning Experience, Salesforce treats lookup filters as required even if Setup marks one optional. Classic’s optional-filter behavior is different. Test the interface your users actually use; optional is not a reliable Lightning escape hatch.
A lookup filter restricts valid relationships and search choices. It does not grant object permissions, field access, or record sharing. For complex formula-based business conditions, Salesforce’s guidance also points to validation rules as an alternative. Keep the selection experience and the enforcement requirement clear when choosing the mechanism.
Release and support handoff
Publish the rule in field help and agent training, identify the owner for correcting old mismatches, and monitor integration errors after release. Keep the tested criteria and previous configuration with your deployment record. A useful error message should tell the agent what to change without exposing unrelated customer information.
Official Salesforce references
- Trailhead: Create a Lookup Filter — Case Contact and Account setup.
- Lookup Filter Examples — dependent lookup comparison using Account IDs.
- Considerations for Lookup Filters — existing values, API enforcement, and page configuration.
- Lookup Filters — required and optional behavior in Lightning and Classic.
- Lookup Filters Best Practices — help text, error messages, and user testing.
Published November 5, 2026. Official references checked on this date. Organizations and people in the example are fictional; verify behavior in your org before release.