INVALID_FIELD: NULL_FOR_NON_REFERENCE_FIELD: <field> can not be null
You assigned `null` to a field type that doesn't accept null — usually a Boolean (which expects `true` or `false`, not null) or a primitive Number on certain field configurations. The fix is supplying an explicit value instead of null.
Also seen asNULL_FOR_NON_REFERENCE_FIELD·field can not be null·NULL value for non-reference
Some Salesforce field types are conceptually nullable in the API but reject null on write because of how the platform stores them.
The usual culprits
| Field type | Behaviour with null |
|---|---|
| Checkbox | Rejects null on insert; defaults to false |
| Number / Currency / Percent (with default) | Rejects null if there's a default value |
| Date / DateTime | Accepts null only if Required is unchecked |
| Picklist (with default value) | Defaults to the configured default; null is sometimes rejected |
The error message names the field. The fix is providing a real value.
What triggers it in code
Account a = new Account(Name = 'Test', Active__c = null); // Active__c is a Checkbox
insert a; // NULL_FOR_NON_REFERENCE_FIELD: Active__c can not be null
Or in JSON for REST:
{ "Name": "Test", "Active__c": null }
The fix:
Account a = new Account(Name = 'Test', Active__c = false);
insert a;
A common confusion: nullable vs required
Salesforce has two field-level concepts:
- Required at the API level: the field has the platform-internal "always required" flag. You'll get
REQUIRED_FIELD_MISSINGif you don't supply it. - Required in UI: a page-layout setting only.
For Boolean / Number with default, the API level says "if you provide a value, don't make it null." Without an explicit value, the platform fills in the default. Sending null says "I want this to be null" — which is the rejection.
Handling null gracefully
For incoming integrations where the upstream system might send null, transform null to the appropriate default before insert:
public static Account fromExternal(ExternalSchema input) {
Account a = new Account();
a.Name = input.name == null ? '' : input.name;
a.Active__c = input.active == null ? false : input.active; // default to false
a.Annual_Revenue__c = input.revenue == null ? 0 : input.revenue;
return a;
}
This is verbose but explicit. Better than silently propagating nulls and letting the API reject them.
When the field IS allowed to be null
Most Text, Long Text, and Date fields do accept null on update. So if you're seeing this error on what you think should be a nullable field, two suspects:
- The field has a default value configured. Setup → Object → Field → defaults to a non-null value. Remove the default or supply the value explicitly.
- A validation rule is rejecting the null indirectly. Check Object → Validation Rules for any rule referencing the field with
ISBLANK().
A subtle case: aggregate query results
SELECT AVG(Amount), Stage FROM Opportunity GROUP BY Stage
If a Stage has zero opportunities, AVG(Amount) is null in the result. Apex code reading this needs to guard:
for (AggregateResult r : ...) {
Decimal avg = (Decimal) r.get('expr0');
if (avg == null) avg = 0; // handle empty groups
}
This isn't strictly the same error code, but is the same family of nullability mistake.
