All posts · OIC Integrations

OIC Lookup Tables: Patterns and Best Practices

Lookup tables are one of OIC's most powerful and underused features. Here's how to use them for code translations, configuration management, and environment-specific settings.

Anurag Jangra · February 5, 2026 · 5 min read · ... views

OIC Lookup tables let you store key-value mappings that your integrations can reference at runtime — without hard-coding values in your mappings or storing them in a database. Used well, they make integrations significantly more maintainable.

What lookup tables are good for

  • Code translations — mapping source system status codes to target system equivalents (e.g. ACTIVE → A, CLOSED → C)
  • Environment configuration — storing environment-specific values (endpoint URLs, business unit IDs) that differ between dev, test, and production
  • Reference data — currency codes, country codes, business unit names
  • Feature flags — lightweight toggles for enabling/disabling integration behaviour without code changes

Creating and managing lookup tables

In OIC: Designer → Lookups → Create

Structure your lookup with meaningful domain names (the category) and columns (the lookup dimensions). A currency mapping lookup might have domains per source system and columns SourceCode and FusionCode.

Using lookups in mappings

Reference a lookup in the XSLT mapper using the lookupValue() function:

lookupValue("StatusMap", "SourceStatus", $sourceStatus, "FusionStatus", "UNKNOWN")

Parameters:

  1. Lookup table name
  2. Column to search in
  3. Value to search for
  4. Column to return
  5. Default value (critical — always provide one)

Environment-specific configuration pattern

Create a lookup called EnvConfig with a single domain. Store values like:

DomainKeyValue
EnvConfigNotificationEmailops-team@company.com
EnvConfigMaxBatchSize500
EnvConfigTargetBUNameVision Operations

Swap the values between environments without touching the integration. This is the cleanest way to manage environment-specific configuration in OIC without separate integration versions.

Limitations to know

  • Lookup values are strings only — no native support for numeric or boolean types (cast in your mapper)
  • Changes take effect immediately on save — no versioning or rollback
  • There’s no audit log of changes — for business-critical lookups, document changes externally
  • Large lookup tables (thousands of rows) may have performance implications when referenced in loops

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