Sales Cloud · a field nobody can see
The new field is in Salesforce.
Five places decide whether anyone sees it.
A new Salesforce field stays invisible when one of five places was never told about it: field level security, the page layout, the record type, the Lightning record page or the mobile app. Field level security is the one every forum answer names, and the other four are why the field is still missing after it is fixed. Below is the order to check them in, a minute each, and what each one looked like in the orgs of a coworking and real estate group.
Salesforce Help and the Salesforce developer guides read on 1 November 2026. Reviewed 3 November 2026.
The cause
Why can the admin see a new field when the team cannot?
Because each of the five places is set per profile, per record type or per device, and the admin and the team rarely share any of them. A field that passes all five for the admin can fail one for a sales rep, and that one is enough to hide it.
Salesforce’s own answer, in the support article Salesforce Fields are not visible to users on record page, published on 29 May 2026, is to review the field access on the affected user’s profile. That is right, and it is one place of five. When Setup creates a field through the wizard in Create a Custom Field, it asks three questions in a row: which profiles or permission sets get access, which Dynamic Forms record pages include the field, and which page layouts include it. Each question is one of the places below.
| Where it hides | What the team sees | The one minute check |
|---|---|---|
| Field level security | No field anywhere: not on the record, not in a report, not in a list view filter | Compare who holds access to the new field with who holds it on a field the team already uses |
| Page layout | The field shows in a report but not on the record | Open the layout assigned to that user’s profile and record type, then the Setup Audit Trail for it |
| Record type | The field is there; the new value is missing from the dropdown | Read the values for that record type through the UI API, not the field definition |
| Lightning record page | The field shows on one page and not another, or vanishes on edit | Open the page in Lightning App Builder and read the visibility rule on the section |
| The mobile app | On the desktop, never on the phone | Look on the phone itself; no API answer settles it |
Deployed is not visible
Why does a deployed field not show on the page layout?
Because a deployment creates the field and stops there. The Setup wizard asks which profiles see it and which Dynamic Forms pages and page layouts include it. A deployment through the Metadata API asks nothing, so unless the same release carries the layouts and the access, the field exists in the org and in front of nobody.
The access half is the easiest to get wrong without noticing. Field permissions and layout assignments travel inside profile files, as the Profile type in the Metadata API Developer Guide lists them, and a file under the wrong name goes somewhere else without an error. The check is a comparison rather than a look. Run it in the Developer Console query editor with your own object, a field the team already sees and the new one:
The two counts should be equal. If the new field has far fewer holders, its access went to the wrong place, and copying the holders of the working field is safer than granting it again by hand.
The value, not the field
Why is a new picklist value missing from the dropdown?
Because a picklist value belongs to the field and to each record type allowed to use it. Add it to the field alone and the deployment succeeds, the field definition lists the value, and nobody can pick it. Field dependencies are a third place, and Salesforce documents that a new value is not added to them automatically.
The dependency rule is in the support article New Picklist Field Value Not Visible on Record Due to Field Dependency, published on 30 June 2026. The reliable check per record type is the User Interface API resource Get Values for a Picklist Field, which takes the record type Id in its path. The field definition returns every value at once and cannot say who may pick which.
One org, from the inside
Five places, each one met in a live org.
A coworking, office rental and residential real estate group runs every business in one Sales Cloud org, so the same object carries many record types, profiles and pages. Each of the five below was a real fault there. Four reached production and were closed the same way on the development, staging and production orgs; the profile mix-up was caught in the sandboxes and cleaned up there.
The fourth and fifth share a rule Salesforce documents in Dynamic Forms Tips and Considerations: visibility rules on Dynamic Forms fields and sections are respected only on the desktop unless Dynamic Forms on Mobile is turned on. The support article Fields are not visible while creating or editing records, published on 18 August 2026, adds the other surprise. With Field Sections on the page, the create and edit screens take their fields from the sections, not from the layout.
- 01
Field level security, and a profile with two names
In the group’s org the System Administrator profile is called Admin in the metadata; System Administrator is only its label. A deployment that carried field access in a file named after the label did not update the real profile. It created a second, empty profile with the same label, put the access there, and two new fields behaved as if they did not exist. A count found it: the new field had a fraction of the permission holders of a working field on the same object. The fix copied the holders of the working field instead of deploying profile files.
- 02
Page layout: deployed is not placed
A reference object for flow screen options went to production with twelve fields. Three landed on the layout, exactly the three required at field level, and nine stayed off the record. Nothing had removed them; nobody had ever added them, and the Setup Audit Trail is what tells those two apart. The same complaint has a second form: the field is on the layout, but in the first section among more than a hundred others, not in the section where people look for it.
- 03
Record type: the value exists and nobody can pick it
A new loss reason for deals was meant for commercial rent only. The whole change was the value on the field plus one record type, and a slice taken before and after across all 13 record types of the object showed a difference in exactly one. The same mechanism once broke lead conversion for one team: the value existed on the field but not on the record type of the deal the lead converted into, so conversion failed on a restricted picklist while ordinary saves went through.
- 04
The Lightning record page: a section with a rule
The property card on the desktop is drawn by a Dynamic Forms page, and on the phone by the classic layout, so a change in one does nothing in the other. A sales rep had access to the price field and still could not see it, because the field sat only in two sections whose visibility rules admitted leadership, administrators, marketing and holders of one custom permission. The fix put the field in the section everyone sees, with a rule on the field itself tied to that permission.
- 05
The phone: what the API says and what the phone shows
An administrator needed to change a contract’s owner from the phone. Asked for the phone’s actions, the UI API listed the layout’s actions, Change Owner among them. The phone showed the list from the Lightning record page, without it. The screenshot from the phone outranked the API answer, and the action went onto the record page with a condition for administrators. Files had the same shape: the standard single related list showed nothing in the mobile app, and a small component placed on the mobile pages only fixed it.
Hidden or unused
Two problems that look the same from the owner’s chair.
A hidden field and an ignored field both end in the same report: the data is not there. They are opposite problems. When the team will not use it is about layouts that ask for more than they give back, and the cure there is fewer fields. This page is about a field the team needs and cannot reach. If all five checks pass and the field is visible but empty, that page is the next place to look.
The quick fix people reach for, opening the field to every profile, trades this problem for risk 04 in the permissions audit: field level security left open by default, and never revisited.
Asked often enough to answer here
Questions
- Q
Should new fields be given to profiles or to permission sets?
To permission sets, wherever the org allows it. A grant on a profile cannot be taken from one person without taking it from everyone on that profile. Salesforce Help names the switch: enable Field-Level Security for Permission Sets during Field Creation in User Management Settings, and the create field wizard offers permission sets instead of profiles.
- Q
Why does a field show on the desktop but not on the phone?
Because the phone may be drawing a different page. Salesforce documents that visibility rules on Dynamic Forms fields and sections are respected only on the desktop unless Dynamic Forms on Mobile is turned on in Salesforce Mobile App Setup. In the group’s org the phone used the classic layout, so every change had to be made twice.
- Q
Will clearing the browser cache make the field appear?
Sometimes, right after a layout change, because Lightning keeps the old layout for a while and a hard refresh loads the new one. If the admin sees the field after a refresh and the user still does not after logging in again, the cause is one of the five places, not the cache.
- Q
Is it safe to give every profile access so the field shows up?
No. It fixes one field and leaves an access decision nobody made. If the field holds prices, pay or anything another business in the same org should not read, being hidden was the protection. Give access to the people who need it, then check the other four places.
One fixed working day, read only, against your own exports, delivered within three working days, with the query behind every figure. Worth it when a hidden field is one symptom among several. If the five checks above found the cause, you have already saved the fee.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 3 November 2026.
Read next
The question that usually comes after this one.
- 01
People avoid the system
A page layout that asks for more than it gives back. Read the cause, the check you can run yourself, and what it costs to put right.
- 02
Salesforce Permissions Audit: Fixed €650
Nine access risks a Salesforce permissions audit finds and why agents inherit them all. Check them yourself, or one fixed day at €650 against your exports.
- 03
Sales Cloud Audit: Eight Checks, €650 Day
A Sales Cloud audit in eight checks your admin can run, or done for you: €650 for one day against your exports, €4,875 to fix all eight.