When a user sees the wrong page layout in Salesforce — or your freshly edited layout never appears — the cause is almost always assignment precedence, not the layout itself. In Lightning, a record page can be activated at three levels: org default, app default, and app + record type + profile. The most specific assignment wins, and a more specific assignment you forgot about silently overrides the one you just changed. Classic page layouts add a second layer: they are assigned per profile per record type from Object Manager. The fastest diagnosis is the View Page Assignments lookup on the object's Lightning Record Pages list, which shows exactly which page wins for a given app, record type, and profile. This is the same debugging path Vantage Point's Salesforce team follows when a UI change "doesn't take."
Every admin has lived some version of this: you edit a layout, save it, refresh the record — and nothing changes. Or one user reports the new layout while three others still see the old one. The layout editor feels like the whole story, but visibility is decided somewhere else entirely, by a layered assignment model that is mostly invisible until it bites.
There are actually two layout systems in play. Classic page layouts — the ones managed from Object Manager — control which fields, sections, buttons, and related lists appear, and they are assigned per profile per record type. Lightning record pages — the flexible pages built in Lightning App Builder — control the arrangement of components on the page and are assigned through activation. A record can be using a perfectly correct classic layout while displaying the wrong Lightning page around it, or vice versa. Knowing which layer is wrong is half the fix. If you are deciding whether record types and layouts have sprawled beyond usefulness, our guide to record types vs. page layouts and when to consolidate covers that design question; this article is about troubleshooting the assignment itself.
A Lightning record page is activated at one of three levels, and Salesforce resolves them from most specific to least:
| Assignment level | Applies to | Precedence |
|---|---|---|
| App + record type + profile | One combination of app, record type, and user profile | Highest — wins over everything |
| App default | All users of a specific Lightning app | Middle — beats the org default inside that app |
| Org default | Everyone, everywhere the page type is used | Lowest — applies only when nothing more specific exists |
The practical consequence: editing or activating a page as the org default does nothing for a user whose app, record type, and profile already match a more specific assignment made months ago by someone who has since left the company. The "wrong layout" ticket is usually an orphaned specific assignment, not a broken page.
Salesforce documents a console-specific gotcha: in the standard Lightning Sales Console and Lightning Service Console, some objects ship with a system app default record page. For those objects, assigning your custom page as the org default has no effect inside the console — the system app default takes precedence. The fix is to activate your custom page as the App Default specifically for that console application: open the page from the object's Lightning Record Pages list, use the Activation action, choose the App Default tab, and select the console app. If the app does not appear in the list, it is not a Lightning app — check its type in App Manager.
Do not debug by logging in as five different users. Salesforce provides the lookup directly:
Once you know the winner, the fix writes itself: either remove the unwanted specific assignment, reassign your intended page at that same level, or accept the design and fix the page that is actually winning.
If the fields or related lists are wrong while the page structure looks right, you are dealing with the classic layer. From Object Manager, open the object's Page Layouts list and click Page Layout Assignment. The grid shows which layout each profile sees for each record type. Two users with the same profile but different layouts — a common support question — are almost always looking at records with different record types. Changing a record's record type changes its layout, which is why "the layout changed when I edited the record" reports usually trace back to a record type change, not a layout change.
Keep in mind that profile-per-record-type layout assignment is exactly where org complexity multiplies: five profiles times six record types is thirty assignments to keep correct. Teams deep into that matrix should consider consolidating profiles and moving flexibility into permission sets — our profile consolidation playbook walks through doing that safely.
A page that works in a sandbox can arrive in production without its assignments. Lightning page activation assignments are stored separately from the page itself — app- and profile-level assignments live in the application's metadata, while the org default lives in the object metadata — so a deployment that carries only the page silently drops who it was assigned to. Admins discover this as a wave of "my layout reverted" tickets the morning after a release. The durable fix is process: include activation assignment verification in the deployment checklist, and re-check View Page Assignments for the affected objects immediately after every deployment that touches Lightning pages.
Layout chaos is usually a symptom of an org whose assignment model was never documented. We help teams audit record types, layouts, and Lightning page assignments, consolidate the matrix into something maintainable, and put sandbox-tested deployment checklists around it so changes stop reverting. If your admins spend more time hunting assignments than building, our managed services team can own org hygiene as an ongoing practice.
We will trace the winning assignment, fix the precedence, and document the model so the next change lands the first time.
Usually because a more specific Lightning page assignment is winning. Assignments resolve from most specific (app + record type + profile) to least (org default), so an older specific assignment silently overrides your new org-level activation. Use View Page Assignments on the object's Lightning Record Pages list to see which page actually displays.
Go to Setup → Object Manager, select the object, open Lightning Record Pages, and click View Page Assignments. Enter the user's app, record type, and profile in the Look Up an Assignment box and click Find Page. The Page Displayed result names the exact page that combination receives.
Some objects in the standard Salesforce console apps have a system app default record page that takes precedence over the org default — this is by design. To display your custom page inside the console, activate it as the App Default for that specific console application from the page's Activation action.
Yes. Classic page layouts are assigned per profile per record type, so users with the same profile see different layouts when they open records with different record types. In Lightning, app-level and app + record type + profile assignments can also make the same record render differently for users working in different apps.
Not reliably. Activation assignments are stored in different metadata than the page — app and profile assignments live with the application, the org default with the object — so deploying only the Lightning page can drop its assignments. Always verify assignments with View Page Assignments after deploying pages between environments.
A page layout (managed in Object Manager) controls which fields, sections, buttons, and related lists exist for a profile-and-record-type combination. A Lightning record page (built in Lightning App Builder) controls how components are arranged on the record's page and is assigned through activation levels. Both must be correct for the page to look right.
Vantage Point is a boutique CRM consulting firm helping businesses transform with Salesforce, HubSpot, and AI. Learn more at vantagepoint.io.