Dynamic Forms in VBCS: Beyond Simple Show/Hide

Most VBCS tutorials cover basic show/hide on a field. Real enterprise forms are more complex: sections that appear based on a combination of field values, validation rules that depend on business context, and layouts that change based on the user’s role. Here’s how to handle them.

The building blocks

VBCS gives you three primary tools for dynamic forms:

1. Component visibility expressions — show/hide using [[ condition ]] syntax
2. Required/disabled expressions — make fields mandatory or read-only conditionally
3. Action chains triggered on field change — run logic when a field value changes

Used together, these cover most dynamic form requirements.

Cascading field dependencies

The most common pattern: selecting a value in Field A changes the options available in Field B.

Example: Selecting a Business Unit populates the available Cost Centers for that BU.

Implementation:

1. Bind Field A (Business Unit) to a variable
2. Add an ojValueAction event listener on Field A
3. In the action chain: call a REST service filtered by the selected BU value
4. Map the response to the items list bound to Field B’s options

The key detail: reset Field B’s value when Field A changes, or you risk stale values persisting from a previous selection.

Context-sensitive validation

VBCS’s built-in validators (required, min/max, regex) are static. For dynamic validation — where the rule depends on other field values — use a custom JavaScript validator function:

validatePOAmount(amount, formContext) {
  const poType = formContext.variables.poType;
  if (poType === 'BLANKET' && amount > 100000) {
    return { valid: false, messageSummary: 'Blanket POs cannot exceed 100,000' };
  }
  return { valid: true };
}

Assign this to the field’s validator property using the expression editor.

Role-based layout adaptation

Use OIC user roles (from VBCS’s authentication context) to conditionally render entire form sections:

[[ $application.user.roles.contains('FINANCE_APPROVER') ]]

Important: client-side role checks are for UX only — they don’t enforce security. Always validate role-based actions server-side in your REST API or OIC integration layer.

Performance tip for complex forms

Avoid binding large REST-backed business object lists to dropdown options directly in forms. Fetch on demand (on field focus or section open) rather than loading all reference data when the form first renders. For forms with 5+ dropdown fields each backed by a REST call, eager loading creates a noticeable delay.