The most likely missing step is that the Record Page was never Activated and Assigned — building a Lightning Page in App Builder and saving it does not automatically make it the page users actually see; it must be explicitly activated and then assigned to a specific scope, such as Org Default, a specific App, a specific Record Type, or a specific Profile, before any real user's experience changes at all. Until this activation and assignment step is completed, the page exists purely as a saved, inactive definition in Setup, and every user continues seeing whatever standard default Lightning Record Page (or a previously-assigned custom page) was already in place, regardless of how much work went into building the new one. The fix is straightforward: return to the Record Page in App Builder, click Activate, and choose the appropriate assignment scope for who should actually see this new page.

Before Dynamic Forms, an entire Page Layout was placed onto a Record Page as one single, monolithic block with no internal per-field conditional logic — if different user groups, perhaps distinguished by Profile or Record Type, needed to see genuinely different sets of fields, the only mechanism available was building entirely SEPARATE Page Layouts, each with its own fixed field arrangement, and then assigning each one to the appropriate Profile-and-Record-Type combination via the Page Layout Assignment matrix from Module 8. With 8 meaningfully different field-visibility requirements across various Profile and Record Type combinations, this could genuinely require 8 separate, independently-maintained Page Layouts. Dynamic Forms fundamentally changes this by allowing individual FIELDS to be placed directly onto the Lightning Page with their OWN independent Visibility Rules, meaning a single Lightning Page can conditionally show or hide individual fields based on the viewing user's Profile or other context, often collapsing what previously required many separate Page Layouts down into one unified page with per-field conditional logic instead.

Org Default assignment makes a specific Lightning Page the default for EVERY user viewing that object, regardless of which Lightning App they happen to be using at the time, applying the broadest possible scope of assignment. App Default assignment instead scopes the page specifically to ONE Lightning App, meaning the same underlying object can display genuinely DIFFERENT Record Pages depending on which App the user is currently working within — for example, an Opportunity viewed inside a "Sales" App might show a full sales-focused page with pipeline details and Flow-based actions, while the same Opportunity viewed inside a "Finance" App might show a different, more finance-focused page emphasizing billing and revenue recognition fields instead. An Admin would specifically choose App Default over Org Default precisely when different user groups working in genuinely different Apps need meaningfully different views of the SAME underlying object, which Org Default's one-size-fits-all approach cannot express, since it applies identically everywhere regardless of App context.

This is implemented using Dynamic Forms combined with a Component Visibility Rule. First, the Discount field (and any related fields) would be organized into their own Field Section on the Lightning Record Page, placed directly using Dynamic Forms rather than being embedded inside one monolithic full Page Layout block, since Dynamic Forms is specifically what enables per-field or per-section conditional visibility in the first place. Then, a Visibility Rule would be added directly to that specific Field Section, with a filter condition checking the current record's StageName field, such as showing the section only when StageName is one of "Negotiation" or later stages. With this configuration, the Lightning Page dynamically evaluates the condition against each specific Opportunity record being viewed — the Discount Details section remains completely hidden for any Opportunity still at an earlier stage, and automatically appears the moment that same Opportunity's Stage genuinely progresses to Negotiation or beyond, all without requiring any Apex or Flow automation, purely through declarative page configuration.

A dedicated Lightning App lets an Admin curate a genuinely focused navigation experience specifically for users whose primary work centers on Vendor-related objects, exposing only the Tabs, Objects, and Home Page content actually relevant to that work — such as Vendor, Vendor Product, and relevant Reports — while deliberately excluding unrelated Tabs like Opportunity, Lead, or Campaign that would otherwise clutter the navigation with objects irrelevant to this specific job function. Relying on the default Sales App instead would expose these Vendor-focused users to the FULL, broader Sales-oriented navigation structure regardless of relevance, creating unnecessary cognitive overhead every time they need to find something, since they would need to navigate past or ignore many Tabs that have nothing to do with their actual daily work. A dedicated App also allows for a genuinely tailored Home Page experience specific to Vendor Management, such as a Dashboard of vendor performance metrics, which the general Sales App's Home Page would have no reason to prioritize or even include.

Standard Components provide the core building blocks placed onto the page's canvas — for example, an embedded Report Chart showing sales rep performance, an embedded Screen Flow letting a user create a related Case without navigating away, and a Related List showing existing Cases, all assembled visually without any code. Dynamic Forms then allows individual fields, rather than one entire fixed Page Layout block, to be placed directly onto this same page, organized into logical Field Sections the Admin controls precisely. Visibility Rules layer conditional logic on top of both the Standard Components and the Dynamic Forms field Sections, meaning specific pieces of the page — such as a Discount Details section relevant only once a deal reaches Negotiation stage — can automatically appear or disappear based on each specific record's actual current data, making the page genuinely adapt to context rather than showing identical content regardless of relevance. Finally, none of this reaches any real user until the page is explicitly Activated and Assigned at the appropriate scope, whether Org Default for universal application or a narrower App/Profile/Record-Type-specific assignment for more targeted rollout — this activation step is what transforms a well-designed page definition sitting in Setup into something users actually experience when they open a record.