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.