Building a Visualforce Page is mechanically simple but produces output that increasingly feels dated next to Lightning UI. Use Visualforce for the specific use cases where it still shines (email templates, PDF rendering, certain Sites pages). For everything else, build LWC components instead. The instructions below cover the realistic activities for any team that still maintains or extends Visualforce.
- Confirm Visualforce is the right tool for the use case
PDF rendering, email templates, and certain Sites pages still warrant Visualforce. Everything else should be Lightning Web Components. If the page is a new record-detail experience, build LWC instead and skip Visualforce.
- Create the page via Setup or VS Code
Setup > Visualforce Pages > New. Or in VS Code with the Salesforce Extensions Pack, create a .page file under force-app/main/default/pages/. The file extension and metadata file (.page-meta.xml) make it deployable.
- Set the page attributes on apex:page
Specify standardController or controller, renderAs for PDF output, showHeader, sidebar, and tabStyle for visual integration. Lightning Experience compatibility requires checking the Available for Lightning Experience checkbox in the page metadata.
- Add Visualforce tags and HTML markup
Use apex:form to wrap input controls. apex:pageBlock for visual grouping. apex:inputField and apex:outputField for sObject-bound fields. apex:commandButton to trigger controller actions. Standard HTML tags work alongside Visualforce tags.
- Build the Apex controller
Custom controller for fully custom logic. Controller extension for adding methods to a standard controller. Each controller method returns a PageReference (for navigation) or void (for stay-on-page action). Mark methods @AuraEnabled if also calling from LWC.
- Test in sandbox with realistic data
Verify the page renders, postbacks work, view state stays small, and the rendered output matches design. Test on different profiles to catch FLS issues. Test in both Lightning Experience (iframe-wrapped) and any Sites context.
- Assign profile access
Setup > Visualforce Pages > the page > Security. Add profiles that should have access. Without access, users see a permission error when they navigate to the page.
- Deploy via change set, metadata API, or SFDX
Bundle the page, metadata file, and controller together. Run a test deployment in sandbox before promoting to production. Verify performance against production data volumes because Visualforce view state can balloon on large record sets.
Standard for one-sObject CRUD with auto-generated methods. Extension to add custom methods on top of standard. Custom for entirely custom logic.
Default is HTML. renderAs=pdf produces a server-rendered PDF, useful for invoices, contracts, and printable reports. No LWC equivalent for PDF rendering.
Available for Lightning Experience checkbox. Required for the page to appear in Lightning context (where it renders inside an iframe wrapper).
- Visualforce is supported but no longer the strategic direction. New custom UI should be Lightning Web Components. Every new Visualforce page becomes a future migration target.
- Lightning Experience wraps Visualforce in an iframe. Visual styling differs from the surrounding Lightning UI, and inter-frame navigation requires sforce.one.navigate instead of standard window.location.
- View state grows with the data the controller holds across postbacks. Large view states (over 170 KB) trigger warnings and degrade performance. Keep controllers lean by reloading data per postback when possible.
- PDF rendering via renderAs=pdf has its own gotchas: limited CSS support, no JavaScript execution, fixed page sizes. Build PDF pages with simple markup and test the rendered output carefully.
- Profile assignment is required even if the user has Apex class access. Visualforce Pages need explicit profile-level access; without it, users see a permission error.