All posts · VBCS Applications

Custom Validation Strategies in VBCS Forms

VBCS's built-in validators cover the basics, but enterprise forms require context-aware, cross-field, and server-side validation. Here's how to implement all three.

Anurag Jangra · April 10, 2026 · 6 min read · ... views

The validation layers available in VBCS

VBCS validation works at three levels:

  1. Component-level: validators on individual input components (required, min/max, regex)
  2. Cross-field: logic that compares multiple field values
  3. Server-side: validation against live business data

All three are needed in enterprise forms.

Component-level validators

Built-in validators are set on the component’s validators property:

<oj-input-text
  value="{{ $page.variables.amount }}"
  validators="[[ [
    { type: 'numberRange', options: { min: 0, max: 999999 } },
    { type: 'required' }
  ] ]]">
</oj-input-text>

For pattern matching (e.g. account number format), use the regexp validator type.

Custom component validator functions

When built-in validators aren’t sufficient, write a custom validator function:

function validatePOAmount(value) {
  var type = $page.variables.poType;
  if (type === 'STANDARD' && value > 50000) {
    return {
      valid: false,
      messageSummary: 'Standard POs cannot exceed 50,000',
      messageDetail: 'Use a Blanket PO for amounts above this threshold.'
    };
  }
  return { valid: true };
}

Assign to the field’s validators property as a JavaScript expression referencing this function.

Cross-field validation

Cross-field validation belongs in the form’s submit action chain, not on individual components:

// In submit action chain — before calling any REST service
var startDate = new Date($page.variables.startDate);
var endDate = new Date($page.variables.endDate);

if (endDate <= startDate) {
  $page.variables.formError = 'End date must be after start date';
  return; // stop the chain
}

Show $page.variables.formError in an inline error message component above the submit button.

Server-side validation via OIC

For validations that require a database lookup (e.g. “does this supplier code exist?”, “is this project still open?”):

  1. Call an OIC integration that performs the check
  2. Use the failure path if validation fails
  3. Display the server error in the form using an error variable

Don’t call server-side validation on every keystroke — trigger it on field blur or on form submit.

Validation before navigation

For multi-step forms, validate the current step before allowing navigation to the next:

// In "Next" button action chain
if ($page.functions.validateStep1()) {
  $page.variables.currentStep = 2;
} else {
  // Show validation errors — don't navigate
}

This prevents users from reaching step 3 with invalid step 1 data, which leads to confusing error handling on submit.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp