11.3 Visualforce in Lightning Experience

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

11.3 Visualforce in Lightning Experience

Key Takeaways Explain This Topic AI

Visualforce can run inside Lightning Experience via Lightning pages, tabs, actions, and app navigation—not only in Salesforce Classic

Set lightningStylesheets="true" on apex:page (where supported) so VF markup picks up Lightning-like styling in LEX

Navigation differs: prefer Lightning-friendly navigation APIs and avoid Classic-only assumptions about window.location and sidebar chrome

Hybrid solutions embed VF in Lightning while new work moves to LWC; plan migration when interactivity, performance, or App Builder composition demands it

Choose migration to LWC for new reusable UI, mobile-first Lightning, and component ecosystem fit; keep VF when PDF, cost of rewrite, or specialized embeds dominate

Last updated: August 2026

11.3 Visualforce in Lightning Experience

Quick Answer: Visualforce still runs in Lightning Experience (LEX) . You embed pages on Lightning record/app/home pages , tabs , and actions , improve look-and-feel with lightningStylesheets , and watch navigation/chrome differences versus Classic. Treat hybrid VF+Lightning as a bridge; migrate to LWC when you need modern composition, performance, and long-term maintainability—while remembering PDI still tests VF fundamentals.

Sections 11.1–11.2 covered markup and controllers. This section is about where VF lives in modern orgs and how exam scenarios frame Classic vs LEX vs LWC choices.

Visualforce Did Not Disappear When Lightning Arrived

Many production orgs still depend on VF for:

Overrides of standard buttons/links not yet rebuilt in LWC
PDF generation ( renderAs="pdf" )
Dense admin tools and wizards written years ago
Managed package UIs
Embedded tools that already work

Salesforce’s strategic UI for new development is the Lightning Component Framework , especially LWC . Your job as a Platform Developer is dual literacy: maintain and correctly host VF , and know when not to start new work in VF .

Embedding Visualforce in Lightning Experience

Common hosting surfaces:

Surface How VF shows up Exam angle

Lightning record page VF component / page embedded via App Builder (Visualforce page component) Pass recordId / use standard controller id context carefully

Lightning app page / home page Same embedding model for utilities No record id unless you supply context
Lightning tab Tab points at a VF page Full-page VF inside LEX shell

Quick action / override Action or button opens VF Classic overrides may behave differently in LEX—verify action type

App Manager navigation Items launch VF pages Navigation and header/sidebar options matter
Record context tips
Pages with standardController still expect an id parameter when acting on a record

Embedded components may receive the record id through the Lightning host—design the page to read parameters or use extensions that accept standard controllers when opened from overrides

Do not assume Classic URL shapes always match LEX hosts; test the actual entry points

Chrome attributes on apex:page often change when embedding:

showHeader="false" , sidebar="false" — reduce double headers inside LEX
applyHtmlTag / applyBodyTag — control outer HTML when the page is framed
Standard LEX header still wraps many tabs; avoid building a second full Classic header
lightningStylesheets

Visualforce pages historically rendered with Classic look (blue-gray pageBlocks, older fonts). In Lightning Experience, that mismatch is jarring.

lightningStylesheets="true" on <apex:page> instructs the platform to apply Lightning-styled CSS to many standard VF components so pageBlocks, tabs, and buttons better match LEX. <apex:page standardController="Account" lightningStylesheets="true">

</apex:page>
What it does and does not do

Does Does not
Improve visual alignment of many standard VF components in LEX Convert the page into LWC architecture
Reduce “Classic island” appearance Automatically fix all custom CSS conflicts
Help hybrid UX acceptance Remove view state or change controller semantics

If you ship heavy custom CSS built for Classic, audit it after enabling lightningStylesheets . Specificity wars are common.

Navigation Considerations

Classic VF often used:

Full page redirects via PageReference
window.top.location hacks for console/iframes
Assumptions about sidebar, header, and URL patterns ( /apex/PageName )

In Lightning Experience:

Iframes / containers — Embedded VF may run in a container; aggressive window.top navigation can break the Lightning shell or be blocked.

PageReference still works for many server-side redirects, but UX may feel like a full reload inside the LEX frame.

Lightning Navigation — For modern client-side patterns you would use Lightning navigation service in LWC/Aura , not classic JS hacks. Hybrid pages should minimize cross-frame gymnastics.

RetURL / saveURL / cancelURL parameters from Classic button overrides may not map 1:1—prefer explicit PageReference returns you control.

Console vs standard nav — Service Console workspace tabs add another navigation model; VF that assumes a single browser tab can misbehave.

Practical guidance for exam scenarios
Prefer server-side PageReference navigation you can reason about over brittle DOM navigation

When the requirement is “navigate to a record page in Lightning without full Classic chrome,” the better long-term answer is often LWC + NavigationMixin , not a new VF page with window.location

If maintaining VF, set header/sidebar flags appropriately and test in LEX, not only Classic
Lightning Experience vs Classic Differences Relevant to VF

Topic Classic Lightning Experience
Default shell Classic header/sidebar Lightning nav bar, App Launcher
Styling Classic styles by default Use lightningStylesheets for closer match
Primary new UI VF / early Aura LWC + Aura legacy + embedded VF
App Builder Limited compared to LEX Central place to embed VF among LWCs

Performance expectations Full postbacks more accepted Users expect snappier component UX—large VF postbacks feel dated

Mobile Often poor VF mobile story Lightning mobile favors LWC patterns
Feature investment Maintenance mode for many Classic-only features New UI capabilities land in Lightning first

Security and sessions are still Salesforce sessions in both UIs, but clickjack protections, CSP , and locker rules around embedded content matter more as you mix JS. Keep VF JavaScript conservative; prefer platform components and tested remoting patterns.

Hybrid Apps: Living with Both
A hybrid approach is normal during multi-year migrations: Lightning Record Page
├── LWC: highlight panel & related lists (modern)
├── LWC: custom path or KPI tiles
└── Visualforce embed: legacy pricing worksheet not yet rewritten
Hybrid best practices
Isolate legacy VF to the smallest surface that still needs it
Do not start parallel new features in VF on the same page if LWC can own them

Share Apex domain services between VF controllers and LWC Apex controllers—avoid duplicating business rules in two UI layers with divergent bugs

Align field-level security and sharing assumptions across both UIs

Document why the VF island remains (PDF, package vendor, rewrite cost) so future teams do not cargo-cult more VF

Data communication: Classic VF and LWC on the same record page do not automatically share a rich component event bus like two LWCs. They share the database and sometimes URL/record id. Design updates so each side refreshes appropriately (user refresh, platform events, or accept eventual consistency).

When to Migrate Visualforce to LWC

Migrate (or build new in LWC) when most of these are true:

Driver Why LWC wins
New product surface Aligns with Salesforce roadmap and hiring skills
App Builder composition Drop components on record pages without full-page takeovers
Performance / UX Client-side rendering, finer-grained refresh, less view state
Mobile / LEX-first users Better fit for Lightning runtime
Reusable UI Components reused across objects/apps
Testing & modularity Clearer component boundaries and Jest-level unit tests for UI logic
Keep VF longer when

Driver Why VF may stay
renderAs="pdf" Mature VF PDF path still widely used
Vendor managed package You do not own the source
Rewrite cost ≫ benefit Stable, rarely touched admin tool
Niche embed that already meets requirements Opportunity cost of migration
Exam / maintenance of existing overrides Short-term operational need
Migration pattern (conceptual)
Extract business logic from VF controllers into service classes used by both UIs
Rebuild UI as LWC with wire/imperative Apex
Replace button overrides and App Builder embeds
Retire the VF page after traffic dies
Keep PDF VF until you adopt an alternative document strategy
Exam Decision Mini-Scenarios

“New interactive component on Account record page, reusable, LEX only.” → LWC , not new VF.

“Existing VF page looks Classic inside LEX.” → Enable lightningStylesheets , fix chrome attributes, consider CSS cleanup—not necessarily an emergency rewrite.

“Need PDF of Quote.” → VF renderAs="pdf" remains a standard answer unless the scenario specifies another document product.

“Page hits view state limits and users live in LEX.” → Fix state/pagination and consider LWC migration for the interactive parts.

“Standard controller extension still required while page is VF.” → Extension patterns from 11.2 still apply inside LEX-hosted VF.

Study Checklist for UI Domain VF Topics
Read and write basic apex:page with form, inputField, commandButton
Choose standard vs extension vs custom controller for a scenario
Explain view state and one mitigation ( transient , pagination)
Place VF on a Lightning page/tab conceptually
State what lightningStylesheets does (styling, not architecture change)
Argue LWC for new LEX UI vs VF for PDF/legacy

Bottom line: In Lightning Experience, Visualforce is an embedded citizen , not the default capital. Style it with lightningStylesheets , host it on pages/tabs/actions , navigate carefully inside the LEX shell, run hybrid architectures when needed, and migrate to LWC when modern composition and longevity matter—while still mastering VF for the User Interface portion of Platform Developer I.