4.4 Record Types, Business Processes, Page Layouts, and Lightning Pages

Separating Process, Layout, and Page Experience

Many admin requests sound like schema requests but are really experience or process requests. Sales wants enterprise opportunities to show a procurement section. Support wants warranty cases to use different status values. Marketing wants campaign records to emphasize budget and audience fields. These needs do not automatically require new objects. They often require record types, business processes, page layouts, and Lightning record pages.

A record type is a way to segment records within the same object. Record types can control available picklist values, support different page layout assignments, and participate in Lightning page activation. They are useful when records share the same core object but have different subtypes, processes, or user experiences. A record type is not a security boundary by itself, although access to record types is assigned through profiles and permission sets.

Business processes are connected to certain standard objects where a lifecycle picklist is central. Sales processes control Opportunity Stage values. Lead processes control Lead Status values. Support processes control Case Status values. Solution processes control Solution Status values where that feature is used. The point is to align the process values with the record type so users see the right lifecycle choices.

Page layouts are still important in Lightning Experience. They influence the Record Detail component, related lists, buttons, and field arrangement when Dynamic Forms are not fully replacing the detail layout. Layout assignment is commonly based on profile and record type. If a user sees the wrong fields in the record detail area, page layout assignment is one of the first places to check.

Lightning App Builder controls the component-based page. On a record page, an admin can place components such as Highlights Panel, Path, Record Detail, Related Lists, Report Chart, Rich Text, Flow, or custom Lightning components. Activation determines where the page applies. An org default page is broad. An app default page is narrower. An app, record type, and profile assignment is more specific.

The most specific activation that matches the user generally wins. This is a common source of confusion. An admin can build a beautiful Lightning record page and still have users see another page because activation was incomplete or because a more specific assignment already exists. Always test as a user with the target profile, app, and record type.

A practical setup workflow for an Opportunity variation looks like this:

1. Confirm the records are still Opportunities, not a new business object.
2. Create or review the Sales Process for the needed Stage values.
3. Create the Opportunity record type and assign the Sales Process.
4. Assign record type access and defaults to the right profiles or permission sets.
5. Create or clone the page layout and assign it by profile and record type.
6. Build the Lightning record page and activate it for the target app, record type, and profile.
7. Create sample records and test with users who have different assignments.

Record type design should be conservative. Too many record types create administrative overhead, duplicate layouts, picklist maintenance, report filters, automation branches, and user confusion. Before adding one, ask whether the business needs different picklist values, layouts, business processes, or Lightning pages. If the only need is one extra field, a record type may be unnecessary.

Page layouts and Lightning pages should not be mistaken for security. Hiding a field from a layout does not remove field-level access everywhere. A user may still see the field in reports, list views, API results, or other pages if field-level security allows it. To protect data, configure object permissions, field-level security, sharing, and permission sets. Then use layouts and Lightning pages to make the experience efficient.

Lightning pages can improve adoption when they match the job. A sales rep may need Path, key fields, activities, and opportunity products. A support agent may need case status, entitlement, knowledge, contact details, and related assets. A manager may need report charts and escalations. Good admins design pages around decisions users make repeatedly, not around every field the object contains.

Exam traps often combine these features. If the scenario says different Opportunity Stage values, choose Sales Process plus record type. If it says different Case Status values, choose Support Process plus record type. If it says different fields in the record detail area for two profiles, think page layout assignment and possibly record type. If it says different Lightning components for an app and profile, think Lightning page activation.