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), andGeolocationare parent fields holding sub-fields. QueryBillingStreet,BillingCity,BillingStateindividually —BillingAddressonly works in the SELECT clause and only on certain APIs. - External IDs on a polymorphic relationship.
Owner.Nameworks because Owner can be User or Group; butOwner.User.Emaildoes not — you have to useTYPEOF 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.
