Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
All errors
SOQL

INVALID_FIELD: No such column 'X' on entity 'Y'

Either the field truly doesn't exist on the object, or it exists but the running user / API session can't see it. The same error message is used for "field doesn't exist" and "you don't have FLS to read it" — and disambiguating those two is the whole job.

Also seen asINVALID_FIELD·No such column·No such column on entity·INVALID_FIELD: No such column

This message is misleadingly singular: it covers two completely different failures with the same words.

Failure 1: the field really doesn't exist

You typed Phon instead of Phone. Or you renamed Old_Notes__c to Notes__c and missed an Apex class. Or you're hitting a sandbox where the field was never deployed.

Diagnosis: open the object in Setup → Object Manager → Fields & Relationships and ctrl-F for the API name. If it's not there, you have a typo or a missing deployment. If it is there with __c and you're querying without it (or vice versa), that's your fix.

A custom field is Notes__c. A custom field on a custom object is on Project__c.Notes__c. A relationship to a custom parent uses __r: Project__r.Owner.Name. Standard fields drop these suffixes.

Failure 2: the field exists but the user can't read it

Salesforce treats no read access the same as field doesn't exist — it's a security choice (don't leak schema to unauthorised users). If your query works as you in the Developer Console but fails for a Community user, this is what's happening.

Diagnosis: as that user, do a Schema.describeFieldResult and check isAccessible(). Or, in Setup → Profiles / Permission Sets → Field-Level Security, confirm read on the field for the running profile.

SObjectField f = Account.Description;
if (f.getDescribe().isAccessible()) {
    // safe to query
} else {
    // fall back, or throw a meaningful error
}

For Apex running with sharing in a controller serving a Community user, you must also satisfy CRUD/FLS. The new way to enforce this is WITH USER_MODE:

List<Account> rows = [SELECT Id, Name, Description FROM Account WITH USER_MODE LIMIT 10];

If the user can't see Description, the query simply omits the field instead of throwing. That's a better failure mode than a flat error.

Failure 3: the field name looks valid but is wrong shape

Two specific cases bite:

  • Compound fields. Address, Name (on Person Account), and Geolocation are parent fields holding sub-fields. Query BillingStreet, BillingCity, BillingState individually — BillingAddress only works in the SELECT clause and only on certain APIs.
  • External IDs on a polymorphic relationship. Owner.Name works because Owner can be User or Group; but Owner.User.Email does not — you have to use TYPEOF Owner WHEN User THEN Email END.

Cross-org gotcha

If you maintain a managed package and your customer is on a different version, this error often means the field was added in a later version and isn't installed yet. Check IsAccessible() defensively before referencing fields that may or may not be there.

Related dictionary terms