Blank lookup
A blank lookup in Salesforce is a lookup relationship field that holds no value.
Definition
A blank lookup in Salesforce is a lookup relationship field that holds no value. The record points at no parent, so the field reads as null in SOQL, shows as empty in the user interface, and returns true for ISBLANK in formulas. Because a lookup relationship can be defined as optional, an empty lookup is a fully valid state rather than an error. The official platform docs note that a lookup links two objects much like a master-detail relationship, except it does not require a parent and does not support sharing or roll-up summaries.
A blank lookup can happen by design or by accident. The relationship may be genuinely optional, in which case the empty value is expected. Or a field that should always be set was left empty by an import, an API call, or a user who skipped it. The two cases look identical in the data but mean very different things. Deciding which one you have, and enforcing it, is a core part of Salesforce data hygiene. Quietly tolerating empty lookups in fields that the business treats as required is one of the most common sources of long-term data quality problems.
Working with empty lookup values across SOQL, formulas, and automation
Why a lookup can legitimately be blank
Salesforce supports two relationship types between objects. A master-detail relationship is required: the child cannot be saved without a parent, and deleting the parent deletes the child. A lookup relationship is looser. The platform documentation describes a lookup as a link between two objects that, unlike master-detail, does not support sharing or roll-up summary fields and does not force a parent value. That single design choice is why blank lookups exist at all. When you create or edit a lookup field, you mark it Required or leave it optional on the field definition. An optional lookup is blank-tolerant by design. A Contact with no Account, a Case with no parent Case, or a custom record with no category lookup are all valid records. The relationship is simply unset. This is different from a missing required value, which the platform actively blocks. Understanding that the empty state is intentional for optional lookups stops you from treating every null as a defect. The real work is separating the nulls you meant to allow from the ones that slipped through.
How a blank lookup appears on each surface
The empty value is consistent under the hood, but the syntax you use to detect it changes with the surface. In SOQL, a blank lookup is null, so you filter with WHERE AccountId = null or WHERE AccountId != null. The SOQL reference documents using the null keyword in a WHERE clause for exactly this purpose. In the record UI, the field shows as empty with no linked record name. In formula fields, the idiomatic test is ISBLANK(LookupField__c). Salesforce recommends ISBLANK over the older ISNULL for general use, and the distinction matters: text fields are never truly null, so ISNULL on a text value always returns false, while ISBLANK handles both empty text and null relationship values. In Flow, you compare the field to null or use the Is Blank operator, which checks for null on non-text values. In Apex, you test the field reference against null before walking it. Same empty state, four different idioms, and mixing them up is a frequent source of conditions that never fire.
The deletion behavior that creates blanks automatically
Optional lookups can become blank without anyone touching the child record. When you define an optional lookup field, the platform asks what should happen if the looked-up parent record is deleted. The documented default is Clear the value of this field, which sets the child lookup to null. So deleting a parent silently empties the lookup on every child that referenced it. That is often correct, but it means blank lookups appear in your data as a side effect of normal deletes. The other documented options are Do not allow deletion of the lookup record that is part of a lookup relationship, which protects the parent when dependencies exist, and Delete this record also, which cascades the delete and is available only when a custom object holds the lookup, not when a standard object does. Choosing Clear without thinking through the downstream impact is how teams end up with orphaned children. If a report or rollup depends on that parent link, the cleared field quietly breaks it. Pick the deletion behavior to match how tightly the two records are coupled.
Enforcing non-blank with validation rules
The field-level Required flag is all or nothing. It blocks every blank save through the standard UI, with no exceptions for context. Real requirements are often conditional: an Account is mandatory only when an Opportunity reaches a certain stage, or a parent lookup is needed only for a specific record type. Validation rules fill that gap. A rule such as AND(ISPICKVAL(StageName, 'Closed Won'), ISBLANK(AccountId)) fires only when the lookup is empty in the situation that actually requires it. The rule runs on save and surfaces an error message to the user, so the blank is caught before it lands. This keeps the field optional at the schema level while still guaranteeing it is populated where the business demands it. One caveat worth knowing: validation rules guard the save path, but data loaded with certain API options or created by code that bypasses the rule can still arrive blank. Validation is a strong gate, not an absolute guarantee, so pair it with a periodic audit of the field.
Why blank lookups slip past reports
Reports built on a parent-child relationship can hide records with empty lookups, and the behavior surprises people. A standard report type that joins Account with Opportunity shows only Opportunities that have an Account. Opportunities with a blank AccountId drop out of the result entirely, because the join is on the populated relationship. Sales operations can look at a clean report and never see the records that have no parent. SOQL behaves differently and it is worth contrasting. The SOQL reference explains that relationship queries return records even when the foreign key is null, behaving like an outer join. So a SOQL query traversing the relationship still returns the child rows with a null parent, while a relationship-based report type filters them out. To find empty lookups in reporting, build a separate report with a Custom Report Type set to include records with or without the related object, or filter directly on the lookup field equals empty. Treating that cleanup report as a routine check turns invisible data gaps into a visible, actionable list.
Null-guarding formulas, Flows, and Apex
Any logic that reads through a lookup has to handle the empty case, or it returns wrong answers and throws errors. In a formula, referencing LookupField__r.Name when the lookup is blank yields a blank result, which often shows up as a confusing gap in a report column. The fix is an explicit guard: IF(ISBLANK(AccountId), 'Unassigned', Account.Name) makes the empty case readable instead of mysterious. In Flow, a Get Records element that finds no related record returns a null record variable. A later element that references a field on that variable fails at run time. A 2021 release update specifically tightened how Flow formulas detect null record variables and null lookup values, so testing for null before you use the variable is the safe pattern. In Apex, walking opp.Account.Name when Account is null raises a NullPointerException in production. The Apex guide also recommends avoiding null comparisons in SOQL filters where you can, since they can hurt query performance. The runtime cost of a null check is trivial. The cost of skipping it is silent wrong output or a hard failure.
Blank lookups, sharing, and orphan records
Because a lookup relationship does not drive record sharing the way master-detail does, an empty lookup has sharing consequences that are easy to miss. A Contact with no Account does not inherit any access path from a parent Account. It sits unattached. In many orgs these orphan records are exactly the rows that fall outside normal visibility and ownership processes, so they linger. The practical pattern is to treat blank values in business-critical lookups as orphans to be reassigned, not as a permanent state. Build a list view or report that filters the lookup field to empty, review it on a schedule, and route the records to an owner or a parent through a Flow or a manual cleanup. For genuinely optional lookups, a blank is fine and needs no action. The judgment call is knowing which lookups carry weight. A blank AccountId on a Contact usually signals a gap. A blank optional category lookup usually does not. Documenting that expectation per field, so the team knows which empties matter, is what keeps the data model trustworthy over time.
Set and enforce a blank-lookup policy on a field
There is nothing to create for a blank lookup itself, since it is just an empty field. What admins actually do is decide and enforce whether a given lookup is allowed to be blank. Here is how to set that policy on a single lookup field.
- Open the lookup field definition
In Setup, go to Object Manager, open the object, select Fields and Relationships, and click the lookup field you want to govern. Confirm it is a Lookup relationship and not a Master-Detail, since master-detail can never be blank.
- Set the field-level requirement
Edit the field and decide whether it is Required. Required blocks every blank save through the standard UI. Leave it optional only when an empty value is genuinely acceptable for some records.
- Choose the parent-delete behavior
On the field, set what happens when the looked-up record is deleted: Clear the value of this field (default, creates blanks), Do not allow deletion when dependencies exist, or Delete this record also for tightly coupled custom-object children.
- Add a conditional validation rule
For requirements that apply only in some cases, create a validation rule using ISBLANK on the lookup combined with the condition, for example AND(ISPICKVAL(StageName,'Closed Won'), ISBLANK(AccountId)). Write a clear error message.
- Build a blank-lookup audit report
Create a report or list view filtered to the lookup field equals empty. If a standard report type hides them, use a Custom Report Type that includes records without the related object. Review it on a schedule.
Field-level setting that forces a value on every standard UI save. All-or-nothing, with no per-context exceptions.
Default parent-delete behavior. Sets the child lookup to null when the parent is deleted, which is a common source of automatic blanks.
Parent-delete option that protects a looked-up record when other records or automation depend on the relationship.
Uses ISBLANK on the lookup to require a value only when business logic demands it, while keeping the field optional at the schema level.
- Validation rules guard the save path but data loaded through some API options or created by code that bypasses the rule can still arrive blank.
- The default Clear the value of this field deletion behavior creates blank lookups silently whenever a parent record is deleted.
- Relationship-based report types hide records with blank parent lookups, so a clean report can mask real data gaps.
- Use ISBLANK rather than ISNULL on lookups and text, since ISNULL always returns false for text fields and can mislead your logic.
Prefer this walkthrough as its own page? How to Blank lookup in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Blank lookup.
- ISBLANK Formula FunctionSalesforce
- Use null in WHERE (SOQL and SOSL Reference)Salesforce
Hands-on resources to go deeper on Blank lookup.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does a Blank Lookup mean on a record?
Q2. How is a Blank Lookup expressed in a SOQL WHERE clause?
Q3. Why is finding Blank Lookups valuable for data hygiene?
Discussion
Loading discussion…