Dynamic Visualforce Binding
Dynamic Visualforce Binding is a Visualforce expression syntax that references fields by name at runtime, rather than hardcoded at compile time.
Definition
Dynamic Visualforce Binding is a Visualforce expression syntax that references fields by name at runtime, rather than hardcoded at compile time. Standard Visualforce bindings look like {!Account.Name}; dynamic bindings look like {!Account['Name']} or {!Account[fieldNameVariable]}, where fieldNameVariable is an Apex string. This lets Visualforce pages handle different fields based on user input, custom configuration, or runtime decisions, without needing a separate page per field combination.
Dynamic bindings are useful for building flexible UIs: a page that displays whichever Account fields a user has configured in their preferences, a generic record viewer that shows fields appropriate for any object, or a list table that lets users pick which columns to display. The trade-off is type safety: the compiler cannot verify field names that come from runtime variables, so typos or missing fields produce runtime errors instead of compile errors.
How Dynamic Visualforce Binding works
The bracket syntax for field references
Dynamic Visualforce binding uses bracket notation around the field name: {!Account[Industry]} returns the Industry field''s value, the same as {!Account.Industry}. The bracket form accepts a string literal or a string-typed expression: {!Account[myFieldNameVariable]} where myFieldNameVariable is an Apex variable holding a field name. The runtime resolves the field by name and returns the value if accessible, throws if not.
Common use cases
Three common patterns. First, configuration-driven UIs: an admin picks fields to display in a Custom Setting; the page reads those fields and renders each one through dynamic binding. Second, generic record viewers: a page that takes an object name and an Id as URL parameters and renders all editable fields. Third, list views with user-selected columns: the page loops over a user''s column choices and renders the matching field per row.
The describeSObjects integration
Dynamic binding pairs naturally with Schema.describeSObjects(). The describe returns metadata about an object''s fields (name, type, label, accessibility), which the page uses to drive both what fields to show and how to format them. A generic record viewer reads describe, lists the editable fields, and uses dynamic binding to render each one. This is how show-me-everything-on-this-record pages are built without hard-coding field names.
Type safety and runtime errors
Standard Visualforce bindings catch typos at compile time: a misspelled field name shows in the Salesforce IDE as an error. Dynamic bindings catch them at runtime: the page fails with FIELD_NOT_FOUND when the user opens it. Test dynamic bindings thoroughly, especially for edge cases (fields removed in newer releases, fields restricted by FLS for certain users). Catching the error and rendering a fallback is the production pattern.
Field-level security and accessibility
Visualforce respects field-level security, even with dynamic bindings. If the running user lacks Read access to a field, the binding returns blank (or, depending on configuration, an error). This is by design: dynamic bindings cannot be used to bypass FLS. For pages that must show a field regardless of FLS, use the WITHOUT_SECURITY_ENFORCED flag on the underlying SOQL query and document the security trade-off.
Performance considerations
Each dynamic binding requires the runtime to look up the field by name and check accessibility. For a single-record view, the cost is negligible. For a list view with 50 rows and 20 dynamic fields per row, the lookups add measurable rendering time. Cache the field metadata in the Apex controller and bind to a typed wrapper class for high-row-count scenarios.
When to use dynamic binding versus Lightning Web Components
Visualforce is legacy for new development. Lightning Web Components (LWC) handle the same flexible-field rendering patterns more cleanly through declarative data binding and @api decorated properties. For new projects, prefer LWC even when the dynamic-field-rendering use case fits. Dynamic Visualforce Binding remains relevant for maintaining existing Visualforce pages and for the few cases where Visualforce''s print-friendly rendering is still required.
How to build a Visualforce page with dynamic field bindings
Building a page with dynamic bindings combines Visualforce expression syntax with an Apex controller that resolves field names at runtime. The pattern fits any case where the fields to display are not known at compile time.
- Identify the runtime variable
Decide what determines which field is rendered: a URL parameter, a Custom Setting value, a list of fields configured per user. The variable is an Apex string at runtime.
- Build the Apex controller
In an Apex controller class, expose a method that returns the field name (or list of field names) to the page. Use Schema.describeSObjects() for object metadata if you also need labels, types, or accessibility checks.
- Reference the field with bracket syntax
In the Visualforce page, use {!Account[dynamicFieldName]} where dynamicFieldName is the controller property. The runtime resolves the field on every render.
- Handle missing or inaccessible fields
Wrap the dynamic binding in a conditional render that checks accessibility before binding. Usually you do the check in Apex and gate the binding through a Boolean returned to the page.
- Test thoroughly
Hit the page with the runtime values you expect, then with edge cases: a deleted field, a field the user lacks Read access to, a field with an unexpected type. Dynamic bindings fail at runtime; test paths the user might actually hit.
- Consider LWC for new pages
If this is a new page, build it as an LWC component instead. The dynamic-field-rendering pattern in LWC is cleaner: a wired Apex method returns the metadata and values, an iterated template renders each field, and the compiler does not need to know field names ahead of time.
String-literal dynamic binding. Use for compile-time known fields where you still want bracket syntax.
True runtime binding. The Apex variable resolves to the field name at render time.
Apex method to get object metadata at runtime. Pairs with dynamic bindings for full-introspection UIs.
FLS check before rendering. Avoid surprising users with empty fields they cannot see.
- Dynamic bindings fail at runtime for typos. Use Schema.describeSObjects() to validate field names before binding.
- FLS still applies. A field the user cannot read renders blank or throws, depending on configuration. Document the behavior for your page''s audience.
- Visualforce is legacy. New work should use Lightning Web Components; Visualforce dynamic bindings are for maintaining existing pages.
- Performance degrades with many dynamic bindings per page. Cache field metadata in the controller and minimize per-render lookups.
Trust & references
Straight from the source - Salesforce's reference material on Dynamic Visualforce Binding.
- Dynamic Visualforce BindingsSalesforce Developers
- Schema Namespace ReferenceSalesforce Developers
Hands-on resources to go deeper on Dynamic Visualforce Binding.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Dynamic Visualforce Binding enable?
Q2. What's the modern alternative for reusable UI work?
Q3. What's a downside of dynamic binding?
Discussion
Loading discussion…