Skip to main content

"No such column" After Deploying a Field — What It Means and How to Fix It

Short answer: you deployed a field with a change set, it's right there in Object Manager with the correct __c API name — yet a query fails:

No such column 'New_Field__c' on entity 'Custom_Object__c'.

The field is real. It's invisible because its field-level security (FLS) isn't granted to your profile. A change set — and any Metadata API deploy — carries the field but not its FLS, and SOQL, describe, and the REST API hide any field the running user can't read. Even a System Administrator hits this. The fix is to grant the field at least Read FLS on the querying user's profile or permission set.

Why the field is invisible​

Field-level security isn't a property of the field itself — it lives separately, in Profile and PermissionSet metadata as <fieldPermissions> entries. When you create a field through the point-and-click New Field wizard, Salesforce quietly grants Read/Edit to your admin profile as part of that flow. Every programmatic path — a change set, an Ant/SFDX deploy, the Metadata API — does not. It deploys the field with whatever FLS the package carries, and a change set that includes only the CustomField carries none.

So the field lands with no FLS for anyone, and SOQL treats a field the running user can't read as if it doesn't exist — hence "No such column," not "insufficient access." This is a stable Salesforce platform behavior, not a change-set bug, and it's a query-time error: the deployment itself already succeeded.

How to fix it​

  • Grant the field Read FLS on the querying user's profile or permission set (Setup → the field → Set Field-Level Security, or the profile/permission set's Field Permissions). That's the whole fix for the immediate error.
  • Deploy FLS with the field next time. Include the profile or permission set that grants the field in the same deployment, so the <fieldPermissions> travels with the CustomField and the field is visible the moment it lands.

How mtdt.io surfaces the FLS a change set drops​

A change set silently leaves FLS on the floor. When you add a field to a deployment in mtdt.io, the Deploy modal's Profiles & Permissions check queries the source org for every profile and permission set that grants that field's Read/Edit, and lists them as one-click toggle-in rows. Include one and mtdt attaches just that field's <fieldPermissions> entry to the profile — so the field lands already visible, without deploying the entire profile.

That's the honest hook: mtdt.io catches the FLS grant a bare change set omits and lets you ship it alongside the field. Two things to be clear about — it's a suggestion you accept, not an automatic action (deploy the bare field past the suggestion and the FLS still won't travel), and setting FLS is standard Salesforce, not an mtdt-only capability. What mtdt.io adds is surfacing which profiles grant the field so you don't discover the gap only when a query fails.

FAQ​

Why does "No such column" appear when the field exists in Object Manager? Because SOQL and the API hide any field the running user's profile can't read. The field deployed fine, but a change set doesn't carry field-level security, so no profile grants it Read — and an unreadable field looks like a missing column to a query, even for an admin.

Why did the field have FLS when I created it by hand but not after a change set? The point-and-click New Field wizard auto-grants Read/Edit to your admin profile as part of creating the field. Change sets, the Metadata API, and the CLI don't — they deploy only what's in the package, and FLS lives in a separate profile/permission-set component you have to include.

How do I make the field queryable? Grant it at least Read field-level security on the querying user's profile or permission set. Going forward, include that profile or permission set in the same deployment as the field so the FLS travels with it.

Is this the same as the deploy error "no CustomField named X.Y found"? No. That one is a deploy-time failure — a component you're deploying references a field that isn't in the package or on the target. "No such column" is a query-time error that happens after a successful deploy, when FLS is missing. Different stage, different fix.

Does deploying the whole profile fix it? Yes, but you rarely need to. Including the profile carries its <fieldPermissions>, which grants the field — but deploying an entire profile drags along everything else it controls. Deploying just the field's FLS entry (which mtdt.io's Profiles & Permissions check does per field) is the scoped version.