All posts · VBCS Applications

VBCS Variable Types: When to Use Each

Choosing the wrong variable scope in VBCS leads to subtle bugs and performance issues. Here's a clear guide to application, flow, page, and component-level variables.

Anurag Jangra · April 1, 2026 · 5 min read · ... views

The four variable scopes in VBCS

VBCS organises variables in a hierarchy: Application → Flow → Page → Component. Each scope has different lifetime, visibility, and appropriate use cases.

Application-level variables

Persistent for the entire session. Accessible from any page or flow. Use for:

  • Currently logged-in user details
  • Application-wide settings (locale, theme preference)
  • Reference data that doesn’t change during a session (currency codes, status maps)
  • Feature flags

Don’t overuse: every application variable consumes memory for the full session. Large arrays or objects at app scope can noticeably increase memory usage.

Flow-level variables

Shared across all pages within the same flow. Reset when the user leaves the flow. Use for:

  • Multi-step wizard state (data entered in step 1 needed in step 3)
  • Shared filter state for a group of related pages
  • Cross-page context (e.g. selected record that multiple pages act on)

Page-level variables

Available only on the current page. Destroyed when the user navigates away. Use for:

  • Form input bindings
  • Table data and pagination state
  • Loading and error flags
  • Computed display values

The majority of your variables should be page-level. If something is only needed on one page, it belongs here.

Component/event-level variables

Scoped to a single component instance or event handler. Use for:

  • Temporary values inside action chains (intermediate calculation results)
  • Event-specific context that doesn’t need to outlive the action

Common mistakes

Putting everything at app level: convenient but causes stale data bugs. Page A sets a variable; the user navigates to Page B, navigates back to Page A — the stale value is still there.

Flow variables for page-specific data: flow variables persist as users move between pages in the flow. If Page 2 modifies a flow variable expecting it to be reset when re-entering Page 2, it won’t be — flow variables reset only when leaving the flow entirely.

Large arrays as page variables bound to tables: page variables holding a 10,000-row array render slowly. Paginate and fetch incrementally instead.

Type discipline

Define variable types explicitly — don’t rely on Any. An untyped variable that receives unexpected structure causes hard-to-debug binding failures. Define object types with all expected fields, even if some are optional.

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