All posts · VBCS Applications

VBCS Action Chains: Building UI Logic

Action chains are VBCS's visual programming model for UI events — here's how to structure them for common patterns like form submission, navigation, and API calls.

Anurag Jangra · December 20, 2025 · 6 min read · ... views

What action chains are

Action chains are sequences of actions that execute in response to UI events (button clicks, page loads, data changes). They are VBCS’s alternative to writing JavaScript event handlers.

flowchart TD
    EVT[User clicks Submit button] --> AC[Action Chain: submitForm]
    AC --> A1[1. Validate Form]
    A1 --> CHK{Valid?}
    CHK -->|No| A2[Show validation errors]
    CHK -->|Yes| A3[2. Set loading = true]
    A3 --> A4[3. Call REST Action
POST /orders]
    A4 --> RES{Response?}
    RES -->|Success 201| A5[4. Set loading = false]
    A5 --> A6[5. Show success toast]
    A6 --> A7[6. Navigate to Order Detail page]
    RES -->|Error 4xx/5xx| A8[4. Set loading = false]
    A8 --> A9[5. Show error message]

    style EVT fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style A7 fill:#0f2d1f,stroke:#22C55E,color:#e2e8f0
    style A9 fill:#2d0f0f,stroke:#EF4444,color:#e2e8f0

Common action chain patterns

Pattern 1: Page load data fetch

// vbEnter lifecycle action chain — runs when page opens
// Action: Call REST → GET /employees/{id}
// Map: 
//   Input:  page variable employeeId → path param {id}
//   Output: response.body → page variable employeeRecord

// Then: assign variable
$page.variables.pageTitle = 
  $page.variables.employeeRecord.firstName + 
  ' ' + 
  $page.variables.employeeRecord.lastName;

Pattern 2: Conditional navigation with parameters

// Navigate action configuration:
{
  "page": "employee-detail",
  "params": {
    "employeeId": "{{ $page.variables.selectedRow.employeeId }}",
    "mode": "{{ $page.variables.isManager ? 'edit' : 'view' }}"
  }
}

Pattern 3: Loop with REST call

For processing a list of records via multiple API calls:

flowchart TD
    A1[Get list of employee IDs] --> A2[For Each: employeeIds]
    A2 --> A3[Call REST: GET /timesheets/{id}/pending]
    A3 --> A4{Has pending
timesheets?}
    A4 -->|Yes| A5[Add to pendingList array]
    A4 -->|No| A6[Skip]
    A5 --> A7{More items?}
    A6 --> A7
    A7 -->|Yes| A2
    A7 -->|No| A8[Show pendingList in table]

    style A8 fill:#0f2d1f,stroke:#22C55E,color:#e2e8f0

Action types reference

ActionWhen to use
Call REST ActionInvoke a service connection endpoint
Assign VariablesSet page/app variable values
NavigateGo to another page or flow
Fire NotificationShow toast message
IfBranch based on condition
For EachLoop over an array
Call FunctionExecute a page function (JavaScript)
Reset VariablesClear form fields
Fire Custom EventCommunicate between components

Debugging action chains

Add $application.variables.debug = true and use the Audit panel in the VBCS designer to see each action’s input/output at design time. At runtime, use the browser DevTools Network tab — every REST call appears as an XHR request with the exact payload sent and response received.

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