Oracle Cloud Visual Builder Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application Development

1. Introduction

What this service is

Visual Builder is Oracle Cloud’s low-code service for building and delivering web and mobile applications with a visual, declarative development experience—while still allowing you to extend behavior with JavaScript and integrate with REST APIs.

One-paragraph simple explanation

If you can describe your app as pages, forms, lists, and actions—and your data comes from REST services or simple data objects—Visual Builder helps you assemble the UI quickly, connect it to data, add basic logic, and publish the result without standing up your own app servers.

One-paragraph technical explanation

Technically, Visual Builder provides a browser-based IDE for designing UIs (typically using Oracle’s component model) and binding those UIs to data sources via “service connections” (often REST). It also provides an application runtime and lifecycle features (environments, publishing, and access control). For certain scenarios, it includes “business objects” to model and persist application data without requiring you to build your own database schema and API layer (verify the exact capabilities for your tenancy in the official docs).

What problem it solves

Many teams spend weeks building “standard” enterprise app plumbing—UI scaffolding, CRUD screens, API wiring, authentication, environments, and deployment. Visual Builder reduces that effort by providing a managed, integrated, low-code platform so you can focus on the app’s workflow and data rather than app infrastructure.

Naming note (important): Oracle has multiple products with similar names, including Visual Builder and Visual Builder Studio. This tutorial is specifically about Visual Builder on Oracle Cloud in the Application Development category. If you are looking for source control/CI features, you may be thinking of Visual Builder Studio instead—verify in official docs for the product you are using.

2. What is Visual Builder?

Official purpose

Visual Builder is designed to help developers and teams build and extend applications faster using a low-code approach, with strong support for integrating enterprise APIs and Oracle SaaS/Oracle Cloud services.

Core capabilities (what you can do)

Common Visual Builder capabilities include:

Visual UI design for web applications (and in some cases mobile-oriented UIs), including responsive layouts.
Data binding between UI components and data sources.
Service connections to REST endpoints (and commonly Oracle SaaS REST APIs).
Business objects for modeling data and supporting CRUD-style applications (availability and details can vary—verify in official docs for your environment).
Application lifecycle features such as environments (for example, development/stage/production patterns), publishing, and access control.

Major components (conceptual model)

While exact terminology may vary slightly by release, Visual Builder implementations generally include:

Visual applications: The top-level app artifact that contains pages, flows, resources, and configuration.
Pages and flows: UI pages and navigation/flow logic.
Components: Prebuilt UI components used to assemble screens.
Service connections: Definitions for calling REST services, including authentication configuration.
Business objects (optional/when enabled): Data models managed within Visual Builder for quick CRUD apps.
Environments: Deployment targets and runtime contexts for testing and production publishing.

Service type

Type: Managed low-code PaaS (Platform-as-a-Service) for application development and hosting.
Management: Oracle manages the platform runtime; you manage the apps, access policies, integrations, and release process.

Scope: regional vs global and tenancy alignment

Visual Builder is typically provisioned as an instance in an Oracle Cloud region and associated with your tenancy and compartment. In practice:

You create/manage Visual Builder instances in OCI.
Apps live inside an instance and are accessed via instance-specific endpoints.
Identity and access integrate with Oracle Cloud identity services (often via IAM/identity domains).

Because service behavior can vary by region and tenancy configuration, confirm region support and identity integration details in the official documentation for your cloud account.

How it fits into the Oracle Cloud ecosystem

Visual Builder commonly sits in the Application Development layer of an OCI solution:

Front end: Visual Builder (UI, client logic)
Back end: REST APIs hosted on OCI (Functions, Container Instances, OKE, Compute), Oracle SaaS APIs, or custom services
Data: Autonomous Database, Oracle Database, or Visual Builder business objects (where suitable)
Identity: OCI IAM / identity domains (and potentially federation)
Ops: OCI Logging, Monitoring, Audit (integration details depend on service features—verify in official docs)

3. Why use Visual Builder?

Business reasons

Faster time-to-market for internal apps and departmental solutions.
Reduced development cost for UI-heavy business apps (forms, lists, dashboards).
More predictable delivery through standardized patterns and managed runtime.

Technical reasons

Low-code UI assembly reduces boilerplate front-end work.
Standard integration approach through REST service connections.
Rapid CRUD app creation when business objects meet requirements (verify availability and constraints).
Extensibility with JavaScript for client-side logic beyond declarative actions.

Operational reasons

Managed runtime reduces the operational burden of running custom web app stacks.
Environment/publishing workflow simplifies releasing versions to test and production.
Centralized governance (who can build, publish, access apps) through OCI identity controls.

Security/compliance reasons

Enterprise identity integration (OCI IAM/identity domains, federation options depending on tenancy configuration).
Controlled access via roles/groups and app-level authorization models.
Auditability for instance-level operations via OCI Audit (and additional app/runtime logs depending on configuration—verify).

Scalability/performance reasons

Managed scaling characteristics for the service runtime (within limits and quotas).
Efficient client-side rendering using Oracle’s UI component model (performance still depends heavily on API design and payload sizes).

When teams should choose it

Choose Visual Builder when: – You need to build business applications quickly (data-centric UIs). – Your back end is available through REST APIs (Oracle SaaS, custom services, or OCI-hosted APIs). – You want a managed front-end platform with clear publishing workflows. – You have a small-to-medium team that benefits from a standardized low-code approach.

When teams should not choose it

Avoid or reconsider Visual Builder when: – You need deep control over front-end architecture (custom frameworks, SSR, highly specialized UI). – Your solution requires heavy offline-first mobile features (confirm current mobile capabilities in official docs). – You need extremely high throughput, ultra-low latency, or specialized performance tuning that requires owning the full stack. – You have strict requirements to run entirely outside managed PaaS (for example, self-hosted-only constraints).

4. Where is Visual Builder used?

Industries

Visual Builder is commonly used in industries that build many internal business apps: – Finance and insurance (operations, onboarding workflows) – Manufacturing (shop-floor dashboards, quality tracking) – Retail (inventory tools, store operations) – Healthcare (non-clinical admin tools—ensure compliance review) – Public sector (case management front ends, internal portals)

Team types

Application development teams building line-of-business apps
Fusion/Oracle SaaS extension teams
Platform teams providing low-code capabilities
DevOps teams standardizing app delivery for internal tools

Workloads

CRUD applications (requests, approvals, inventory, task tracking)
Data entry and validation front ends
Dashboards that aggregate data from multiple APIs
Rapid prototypes that mature into production apps

Architectures

Front end in Visual Builder + REST APIs in OCI
Visual Builder + Oracle SaaS REST integration
Visual Builder + API gateway pattern (Oracle API Gateway or other gateway layer, depending on org standards)

Real-world deployment contexts

Internal applications behind corporate identity, accessed by employees/contractors
Partner portals with federated identity
Department apps that integrate with central enterprise services

Production vs dev/test usage

Dev/test: Rapid prototyping, validating UX with stakeholders, early integration tests.
Production: Stable, governed apps with controlled publishing, least-privilege IAM, tested integrations, and defined monitoring/incident processes.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Visual Builder is frequently a strong fit.

1) Internal Request & Approval App

Problem: Teams track requests (IT access, procurement, HR) in email/spreadsheets.
Why Visual Builder fits: Fast UI creation for forms, lists, and role-based pages; integrates with approval APIs/workflows.
Example: Build an “Access Request” app that calls a backend REST API to submit requests and shows status per user.

2) Oracle SaaS Extension UI (ERP/HCM/SCM integrations)

Problem: Users need a custom UI for processes not covered by standard SaaS screens.
Why Visual Builder fits: Designed for enterprise integrations and REST service connections commonly used with Oracle SaaS.
Example: A supplier onboarding front end that calls Oracle SaaS REST endpoints and a custom validation service.

3) CRUD App with Lightweight Data Storage

Problem: You need a small app with its own data model but don’t want to build a full backend.
Why Visual Builder fits: Business objects can provide quick data modeling and CRUD (verify feature availability and limits).
Example: A “Facilities Issue Tracker” app where users log issues and technicians update status.

4) Operations Dashboard for On-Call and SRE Teams

Problem: Operations teams need a unified view across multiple monitoring sources.
Why Visual Builder fits: Build pages that call REST endpoints from monitoring/incident tools and display aggregated views.
Example: A “Service Health” dashboard that reads from an internal status API and an OCI Monitoring exporter API.

5) Partner Portal (Controlled External Access)

Problem: Partners need access to specific resources without giving them broad enterprise access.
Why Visual Builder fits: Supports identity integration and app-level authorization patterns.
Example: A logistics partner portal showing shipments and allowing updates via REST APIs.

6) Field Service Web App (Responsive UI)

Problem: Field teams need a mobile-friendly web app for job assignments and updates.
Why Visual Builder fits: Responsive UI patterns, fast form and list creation.
Example: A technician web app for viewing assigned jobs and submitting completion notes to a REST service.

7) Data Capture & Validation Front End

Problem: A backend system requires clean, validated data but current capture methods are error-prone.
Why Visual Builder fits: Declarative validation and standardized forms reduce errors.
Example: A product data entry app with validation rules calling an internal “catalog validation” API.

8) Migration Bridge UI for Legacy Systems

Problem: Legacy apps need a modern UI while the backend stays unchanged.
Why Visual Builder fits: Wrap legacy backends exposed as REST (or via an integration layer).
Example: A new UI for a legacy order system whose data is exposed through an API gateway.

9) Departmental App with Centralized Identity and Governance

Problem: Departments create shadow IT apps without governance.
Why Visual Builder fits: Central platform with controlled access, shared patterns, and managed runtime.
Example: A finance reconciliation app governed by OCI policies and published through controlled environments.

10) Event Registration and Capacity Tracking (Internal)

Problem: Teams need lightweight registration and attendee management without buying a separate tool.
Why Visual Builder fits: Quick UI + data model + publishing for internal audiences.
Example: An internal training signup app with capacity tracking and email integration via a backend API.

11) Self-Service Knowledge/Request Portal

Problem: Users want a single portal for FAQs and service requests.
Why Visual Builder fits: Build a portal UI that integrates with knowledge and ticketing APIs.
Example: A portal that searches a knowledge base API and submits tickets to a service desk API.

12) Proof-of-Concept UI for New APIs

Problem: API teams need a realistic UI to validate endpoints and workflows.
Why Visual Builder fits: Rapid UI plus easy REST wiring enables fast feedback cycles.
Example: A POC UI for a new pricing API to validate data shape, latency, and error handling.

6. Core Features

Note: Exact feature availability can vary by region, service edition, and tenancy configuration. Where details are uncertain, confirm in official docs.

Visual application development (low-code UI designer)

What it does: Provides a visual designer to create pages, add components, and set up navigation.
Why it matters: Reduces time spent writing boilerplate front-end code.
Practical benefit: Teams can deliver usable UIs quickly and iterate with stakeholders.
Limitations/caveats: Extremely custom UI/UX may require deeper JavaScript work or a different framework.

Component-based UI (Oracle UI components)

What it does: Uses a structured component model for building enterprise UIs (often aligned with Oracle’s web component ecosystem).
Why it matters: Consistency, accessibility patterns, and predictable behavior.
Practical benefit: Faster assembly of forms, tables, and layouts.
Limitations/caveats: You are generally aligned to the provided component ecosystem; custom components may have constraints.

Data binding and declarative actions

What it does: Binds UI components to data variables and configures actions (fetch, create, update, navigation) without writing code for every operation.
Why it matters: Reduces integration boilerplate and makes UIs easier to maintain.
Practical benefit: Build CRUD screens quickly.
Limitations/caveats: Complex orchestration may still require custom code or a backend workflow engine.

REST service connections

What it does: Defines reusable connections to REST APIs, including endpoints, authentication, and headers.
Why it matters: Enterprise apps typically depend on many APIs.
Practical benefit: Central place to manage API definitions and reuse them across pages.
Limitations/caveats: If APIs lack CORS support or have complex auth flows, integration may require additional gateway/proxy design.

Business objects (rapid data modeling) — where supported

What it does: Lets you model entities (tables/objects), relationships, and basic CRUD operations within the Visual Builder environment.
Why it matters: Eliminates the need for a separate backend for small apps.
Practical benefit: Build “data + UI” apps quickly.
Limitations/caveats:
Not intended to replace full enterprise databases for complex workloads.
Review data residency, backup/restore, and lifecycle constraints in official docs.
Confirm limits (row counts, storage, API limits) before production use.

Environments and publishing lifecycle

What it does: Supports publishing applications to controlled environments, often following dev → test/stage → production patterns.
Why it matters: Enterprises need controlled releases.
Practical benefit: Reduces “works on my machine” drift and supports repeatable promotion.
Limitations/caveats: Advanced CI/CD integration may require external tooling (verify supported integrations).

Role-based access control (app and instance level)

What it does: Controls who can access the service, who can build, and who can run specific apps.
Why it matters: Low-code platforms can become shadow IT without governance.
Practical benefit: Enforce least privilege and separation of duties (builders vs publishers vs users).
Limitations/caveats: Identity integration details vary (OCI IAM/identity domains vs legacy IDCS patterns)—verify your tenancy setup.

Extensibility with JavaScript (custom logic)

What it does: Allows client-side scripting for validation, custom actions, and integration logic.
Why it matters: Real apps need “escape hatches” beyond declarative configuration.
Practical benefit: You can implement non-trivial UX behaviors without abandoning the platform.
Limitations/caveats: Be careful not to put sensitive logic in client-side code; enforce authorization on the server.

Import/export and packaging (lifecycle portability)

What it does: Supports moving application artifacts between instances/environments using supported packaging mechanisms.
Why it matters: Needed for promotion, backup, and collaboration.
Practical benefit: Enables controlled rollout patterns.
Limitations/caveats: Large apps and external dependencies (APIs, secrets) need environment-specific configuration management.

7. Architecture and How It Works

High-level service architecture

At a high level, Visual Builder consists of: – A design-time experience (browser IDE) where developers build apps. – A runtime that serves the published application to end users. – Integration endpoints (service connections) to backend APIs. – Optional data persistence (business objects) managed by the service (where enabled).

Request/data/control flow (typical)

A user accesses the published app URL.
The app authenticates the user via configured identity integration.
The UI loads and triggers actions (for example: fetch list, submit form).
Visual Builder calls configured REST endpoints (or business object APIs).
The backend returns data; the UI renders it.
Logs/metrics are generated (service-level observability varies—verify exact capabilities).

Integrations with related services

Common integrations around Visual Builder on Oracle Cloud include:

Oracle Cloud Infrastructure IAM / identity domains for authentication and group-based access.
Oracle SaaS REST APIs (ERP/HCM/SCM/CX) for extension apps.
OCI API Gateway (optional) to standardize authentication, throttling, and routing to backend services.
OCI Functions / OKE / Compute as backend API hosts.
Autonomous Database / Oracle Database for enterprise data backends (commonly via custom APIs).
OCI Vault for secrets used by your backend services (Visual Builder itself typically should not hardcode secrets).

Dependency services (typical)

Identity service (OCI IAM)
Networking (public endpoints and/or controlled access patterns)
Backend hosting for APIs (if not using business objects)
Optional logging/monitoring services

Security/authentication model (practical view)

User authentication: Typically via OCI identity integration configured for the instance/application.
API authentication:
For user-context calls to APIs: often OAuth2/OIDC patterns (through identity provider).
For service-to-service calls: use an API gateway or backend service account patterns.
Authorization: Enforce authorization in backend APIs; don’t rely solely on client logic.

Networking model

Visual Builder is generally accessed over HTTPS via service URLs.
Backend APIs should be reachable from the client:
If APIs are public: protect them with strong auth and gateway controls.
If APIs are private: you may need a pattern like a gateway/proxy accessible to the client, or a dedicated architecture that avoids direct browser-to-private-network calls. The correct pattern depends on your security requirements—verify with OCI networking guidance.

Monitoring/logging/governance considerations

Use OCI Audit for tracking instance-level administrative operations.
Use OCI Logging/Monitoring for backend services and gateways.
For app errors, implement:
client-side error handling
backend structured logs with correlation IDs
API dashboards for latency/error rate
Tag Visual Builder instances using OCI tagging for cost allocation and governance.

Simple architecture diagram (conceptual)

flowchart LR
  U[End User Browser] -->|HTTPS| VB[Visual Builder Runtime]
  VB -->|REST calls| API[Backend REST API]
  API --> DB[(Database)]
  VB -->|Auth| IAM[OCI IAM / Identity Domain]

Production-style architecture diagram (recommended pattern)

flowchart TB
  subgraph Users
    B[Browsers / Mobile Browsers]
  end

  subgraph OCI["Oracle Cloud (OCI)"]
    VBRT[Visual Builder Runtime (Published App)]
    IAM[OCI IAM / Identity Domains]
    APIGW[API Gateway (Optional but common)]
    FN[Backend Service: Functions / OKE / Compute]
    DB[(Autonomous DB / Oracle DB)]
    LOG[Logging/Monitoring]
    VAULT[OCI Vault]
    AUDIT[OCI Audit]
  end

  B -->|HTTPS| VBRT
  VBRT -->|OIDC/OAuth| IAM

  %% Browser-origin API calls often go through gateway
  VBRT -->|HTTPS REST| APIGW
  APIGW -->|mTLS/OAuth/JWT validation| FN
  FN --> DB
  FN -->|Secrets| VAULT

  APIGW --> LOG
  FN --> LOG
  VBRT -.instance events.-> AUDIT

8. Prerequisites

Account/tenancy requirements

An Oracle Cloud tenancy with access to Visual Builder.
Ability to create resources in a target compartment.

Permissions / IAM roles

You typically need permissions to: – Create and manage Visual Builder instances – Manage policies, groups, and users (or work with an admin who can) – Manage networking resources if your architecture requires gateways/backends

Because OCI policies are tenancy-specific, follow Oracle’s official Visual Builder IAM documentation for the exact policy statements (verify in official docs).

Billing requirements

Visual Builder is generally a paid OCI service under Universal Credits or contract terms.
You must have a billing method or credits available.
If you use additional services (API Gateway, Functions, DB), those are billed separately.

CLI/SDK/tools needed

For the core lab in this tutorial: – A modern browser – No OCI CLI is strictly required

Optional but useful: – OCI CLI (for managing related services) – A REST client (curl/Postman) for testing APIs – Git (if your team uses external source control; verify Visual Builder’s supported integration options)

Region availability

Visual Builder availability is region-dependent.
Confirm the regions where Visual Builder is available in your tenancy via the OCI Console service list and official docs.

Quotas/limits

Instance quotas (how many instances per region/tenancy)
Storage limits, user limits, and request limits (service-specific)

Always check Service Limits in OCI and the Visual Builder documentation for current quotas and constraints.

Prerequisite services (for typical production)

OCI IAM / identity domain configured (users, groups, federation if needed)
Backend API hosting (Functions/OKE/Compute) if you are not using business objects
API Gateway (optional but recommended for external-facing APIs)

9. Pricing / Cost

Current pricing model (how costs are typically measured)

Visual Builder pricing is published by Oracle and may vary by: – Region – Edition/SKU – Contract type (Pay-as-you-go vs Universal Credits vs negotiated enterprise agreement)

In general, low-code PaaS services are priced using one or more of these dimensions (confirm exact Visual Builder dimensions on the official pricing page): – Instance-based pricing (a running instance billed per hour/month) – Compute capacity (for example, OCPU-based capacity) – User-based metrics (named users or monthly active users) in some licensing models – Storage and data transfer charges

Because the exact SKU details can change, rely on: – Official pricing: https://www.oracle.com/cloud/pricing/ – OCI cost estimator: https://www.oracle.com/cloud/costestimator.html – Oracle price list / rate card references (often linked from pricing pages)

Free tier

Oracle Cloud has an Always Free/Free Tier program, but Visual Builder’s inclusion can change. Do not assume Visual Builder is Always Free. Verify in official Oracle Cloud Free Tier details: – https://www.oracle.com/cloud/free/

Cost drivers (what usually increases spend)

Direct drivers: – Number of Visual Builder instances – Instance sizing/capacity and how long instances run – Environment count and runtime usage patterns – Storage used by apps and (if applicable) business objects

Indirect drivers (often overlooked): – Backend services (API Gateway, Functions/OKE/Compute) – Database (Autonomous Database / Oracle Database) – Logging/monitoring retention – Outbound data transfer (egress) to the internet – Support plans and enterprise identity/federation overhead

Network/data transfer implications

User traffic to the Visual Builder runtime is inbound to OCI (typically not billed), but outbound responses and any cross-region traffic may have costs depending on OCI rules and architecture.
Calls from the browser to your backend APIs can increase:
API Gateway request charges
Backend compute usage
Data egress if endpoints cross regions or leave OCI

Validate egress assumptions with OCI Networking pricing documentation.

How to optimize cost (practical)

Use the minimum number of instances needed (avoid idle duplicates).
Turn off or decommission non-production instances when not needed (if the service supports stopping; otherwise delete and recreate when appropriate—verify).
Keep payload sizes small and paginate lists to reduce API and data transfer.
Put an API gateway in front of backends to enforce throttling and caching where applicable.
Set logging retention intentionally (avoid indefinite retention of verbose logs).

Example low-cost starter estimate (no fabricated numbers)

A low-cost starter typically includes: – 1 Visual Builder instance (dev/test) – A very small backend (or business objects if suitable) – Minimal logging retention – Limited users

Because the price depends on region and SKU, build the estimate using: – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html – Visual Builder pricing SKU on the official pricing page: https://www.oracle.com/cloud/pricing/

Example production cost considerations

A production setup often includes: – Separate dev/test/prod environments (or separate instances depending on governance) – API Gateway + backend compute + database – High availability requirements for backends – Observability (logs/metrics/traces) with retention and alerting

In many enterprises, backend and database costs exceed the Visual Builder line item. Plan a total cost view across the entire application stack.

10. Step-by-Step Hands-On Tutorial

This lab builds a small, real application using Visual Builder: a “Team Tasks” web app that lets authenticated users create, view, and update tasks. The goal is to demonstrate the core workflow: provision → build UI → bind to data → publish → validate → clean up.

Important verification note: Visual Builder UI labels and navigation can change between releases. Use the steps below as a practical guide, but follow your tenancy’s Visual Builder documentation if labels differ.

Objective

Provision a Visual Builder instance in Oracle Cloud.
Create a Visual Builder application.
Model a simple dataset (using business objects if available) or connect to a REST service.
Build a UI with list + create/edit form.
Publish the app and validate behavior.
Clean up resources to avoid ongoing charges.

Lab Overview

You will complete these stages:

Provision: Create a Visual Builder instance in OCI.
Build: Create a visual application and a “Task” data model.
Design UI: Add a page to list tasks and a page/dialog to create/update tasks.
Publish: Deploy to a test/stage environment.
Validate: Confirm CRUD works and access control is correct.
Cleanup: Delete the app/instance to stop billing.

Step 1: Create a Visual Builder instance in OCI

Sign in to the OCI Console.
Select the correct region (top-right region selector).
Select a compartment where you are allowed to create resources.
Use the console search bar and search for Visual Builder.
Open the Visual Builder service page (often shown as Visual Builder instances).
Click Create instance (or equivalent).

Fill in instance details: – Name: vb-lab-instance – Compartment: your lab compartment – Access/Network: keep default unless your org requires restricted access – Identity configuration: use your tenancy’s default identity integration

Click Create and wait until the instance is Active.

Expected outcome – A Visual Builder instance is created and in an Active/Ready state. – You can open the Visual Builder instance URL (design-time link).

Verification – Instance lifecycle state shows Active (or equivalent). – You can open the Visual Builder UI without authorization errors (you may be prompted to log in).

Common errors – Not authorized / insufficient permissions: ask an OCI admin to grant the required policies for Visual Builder instance creation. – Service not available in region: switch to a supported region (verify region availability).

Step 2: Open the Visual Builder designer and create an application

From the instance details page, click Open Visual Builder (or the instance URL).
In the Visual Builder landing page, choose Create → Application (wording may be “Visual Application”).
Select a template: – Choose a Basic or Empty template if available.
Set: – Application Name: TeamTasks – Application ID: accept default or use teamtasks (must be unique within the instance)

Create the app.

Expected outcome – You are inside the Visual Builder designer with an empty/basic app. – You can see navigation for pages, components, and data/services.

Verification – The app appears in your applications list. – Opening the app shows the visual designer canvas.

Common errors – Cannot create app: confirm your user has the correct Visual Builder role (builder/developer role) within the instance.

Step 3: Create a data model (Business Object) OR connect a REST API

You have two valid paths. Use Option A if business objects are enabled in your Visual Builder environment. Use Option B if your organization prefers a separate backend API (recommended for production-grade authorization and data control).

Option A (simplest): Create a Business Object named `Task`

In the app designer, locate the section for Business Objects (sometimes under a “Data” area).
Create a new Business Object: – Name: Task
Add fields like: – id (often auto-generated primary key) – title (Text, required) – description (Text) – status (Text or Enum-like text) – dueDate (Date) (optional)

Save the object.

Expected outcome – Visual Builder generates a managed REST interface (or equivalent access layer) for CRUD operations for the Task object.

Verification – You can see the object and fields listed. – There is a way to preview/test the generated endpoints (if your edition supports it—verify in your UI).

Caveats – Business objects are excellent for labs and small apps, but for sensitive enterprise data, confirm compliance, backup, and lifecycle requirements before using in production.

Option B (recommended architecture): Connect to a REST API

If you already have a REST API (for example, GET /tasks, POST /tasks, PUT /tasks/{id}): 1. Go to Service Connections (or “Services”). 2. Add a REST Service Connection. 3. Provide: – Base URL of your API – Authentication method (OAuth2/OIDC, API key, etc.)

Expected outcome – Visual Builder can call your API operations and bind responses to UI variables.

Verification – Use the “Test” feature (if available) to call an endpoint and confirm you get data.

Common errors – CORS errors in browser: place the API behind a gateway configured for browser access or configure CORS on the API. – 401/403 responses: fix OAuth scopes/tokens and confirm backend authorization.

For the rest of this lab, assume Option A (business objects) to keep it low-cost and self-contained.

Step 4: Build the UI (Tasks list + Create/Edit form)

4.1 Create a page to list tasks

Create a new Page called Tasks.
Add a Table (or List component).
Bind the table’s data source to the Task business object collection.
Add columns: – Title – Status – Due Date

Add a Create Task button above the table.

Expected outcome – The page shows an empty table initially, ready to display tasks.

Verification – Use the designer’s preview/run feature to open the page. You should see the table UI load without errors.

4.2 Create a form for creating tasks

Create a Dialog (modal) or a new page called TaskCreate.
Add input fields bound to a new Task record: – Title (required) – Description – Status (default to Open) – Due Date
Add a Save button: – Configure the action to create a new Task record.
On success: – Close dialog (or navigate back) – Refresh the Tasks list

Expected outcome – Clicking Create opens a form; saving inserts a new Task and returns to the list.

Verification – Create a sample task: – Title: Write runbook – Status: Open – Confirm it appears in the list after saving.

4.3 Add edit support (optional but recommended)

Add an “Edit” action per row in the table.
Open the same dialog/page with the selected record.
Save changes using an update action.

Expected outcome – You can update a task status from Open to Done.

Step 5: Configure access (basic)

Visual Builder apps should not be published publicly unless required and reviewed.

In app settings, find Security or Access settings.
Ensure the app requires authenticated access.
Map app roles to identity groups if your environment supports it.

Expected outcome – Only authenticated users (and optionally only approved groups) can access the app.

Verification – Open the app in an incognito/private browser window. – Confirm you are prompted to authenticate and cannot access anonymously (depending on configuration).

Caveat – The exact role/group mapping steps depend on whether your tenancy uses OCI identity domains and how Visual Builder is integrated. Follow your tenancy’s official guide.

Step 6: Publish the application

Find the Publish action in the Visual Builder designer.
Choose the target environment (for example: Stage or Test).
Publish and wait for the process to complete.
Copy the published application URL.

Expected outcome – The app is accessible via a stable published URL.

Verification – Open the published URL in a browser. – Confirm: – Tasks page loads – You can create a task – You can edit a task (if implemented)

Validation

Use this checklist:

UI loads without console errors.
Create inserts a new task and appears in the list.
Edit updates status and persists after refresh.
Access control prompts for authentication (or blocks unauthorized users).
Data integrity: required fields enforced, basic validation works.

Optional deeper validation: – Confirm the app handles API errors gracefully (simulate by disabling network or forcing invalid input). – Confirm pagination/filtering for large lists (if needed).

Troubleshooting

Symptom	Likely Cause	Fix
“Not authorized” in OCI Console	Missing IAM policy	Ask admin to grant Visual Builder instance management permissions (verify official policy examples).
App preview works but published URL fails	Environment/publish configuration issue	Re-publish, confirm environment status, confirm identity settings for published runtime.
CORS error when calling REST API	API not configured for browser calls	Add CORS headers on API or use API Gateway configured for CORS and auth.
401/403 calling API	OAuth/token misconfiguration or missing scopes	Verify identity app registration, scopes, and backend validation rules.
Data not refreshing after create/update	Missing refresh action	Add a “refresh data provider” action after save.

Cleanup

To avoid ongoing charges:

Delete the published app artifact if your org requires it (optional).
In the OCI Console, navigate to your Visual Builder instance.
Delete the Visual Builder instance vb-lab-instance.

Expected outcome – The instance is terminated/deleted and no longer billed.

Verification – Instance lifecycle state shows Deleted/Terminated (or it disappears after deletion completes).

11. Best Practices

Architecture best practices

Treat Visual Builder as the front-end layer; keep core authorization and sensitive logic in backend services.
Prefer an API gateway for production APIs to standardize authentication, throttling, and routing.
Use a separate backend for complex workflows and sensitive data; use business objects for simpler departmental apps after governance review.

IAM/security best practices

Use least privilege:
Separate roles for instance admins, app developers, and publishers.
Use groups to assign access, not individual users.
Require authentication for published apps unless explicitly intended for public access and reviewed.

Cost best practices

Limit the number of instances and environments.
Decommission dev/test instances when no longer needed.
Control logs/retention for backend services and gateways.
Optimize API payload sizes and implement pagination.

Performance best practices

Paginate tables and avoid loading large datasets into the browser.
Cache reference data where appropriate (in backend or gateway).
Minimize chattiness: combine API calls when possible.
Use efficient filters and server-side search.

Reliability best practices

Design backend APIs for retries and idempotency.
Implement proper error states in the UI (user-friendly messages, safe retries).
Use health checks and SLOs for backend services; the UI is only as reliable as its dependencies.

Operations best practices

Define ownership:
Who publishes?
Who responds to incidents?
Who rotates secrets (backend)?
Implement monitoring for API latency, error rate, and saturation.
Use correlation IDs in API calls to trace user actions end-to-end.

Governance/tagging/naming best practices

Use OCI tags (cost center, environment, owner, data classification).
Standardize naming:
vb-<team>-<env> for instances
<app>-<env> for app identifiers
Document:
API dependencies
identity groups/roles
publish process and rollback steps

12. Security Considerations

Identity and access model

Visual Builder typically integrates with OCI identity (identity domains) for authentication and group-based access.
Ensure builders/publishers are restricted; low-code platforms can become “deployment tools” if over-permissioned.

Encryption

Data in transit uses HTTPS.
For data at rest:
Service-managed storage is typically encrypted by default in OCI services, but confirm the specific encryption posture for Visual Builder and business objects in official docs.

Network exposure

Published app endpoints are reachable via HTTPS.
Treat any public endpoint as internet-exposed:
Require authentication
Limit access by group/role
Consider additional protections (WAF in front of backends; gateway throttling)

Secrets handling

Do not store secrets (API keys, client secrets) in client-side code.
For backend services, store secrets in OCI Vault and inject them at runtime.
Prefer OAuth flows that do not expose long-lived secrets to the browser.

Audit/logging

Use OCI Audit for instance-level administrative actions.
Ensure backend API logs capture:
authentication subject
authorization decisions
request IDs/correlation IDs
sensitive data redaction

Compliance considerations

Confirm data residency and retention requirements:
Where is data stored?
How are backups handled?
What is the deletion lifecycle?
For regulated industries, validate:
access control
audit trail requirements
encryption requirements
vendor attestations available from Oracle (through official channels)

Common security mistakes

Assuming UI controls enforce authorization (they do not—backend must enforce).
Publishing apps without authentication.
Calling internal/private APIs directly from browser without proper gateway patterns.
Over-permissioning builders with instance admin rights.
Logging sensitive data (tokens, PII) in client logs or backend logs.

Secure deployment recommendations

Put critical data and authorization behind backend APIs.
Use API Gateway policies for JWT validation and rate limiting.
Limit app access by group and environment.
Perform security testing:
OWASP checks for web apps
authorization tests (horizontal/vertical privilege escalation)
dependency review for custom JavaScript libraries

13. Limitations and Gotchas

Treat this section as a “watch list.” Always validate against your exact Visual Builder edition and OCI region.

Service availability varies by region: You may not find Visual Builder in every OCI region.
Business objects are not a universal replacement for enterprise databases: Validate limits and operational controls before production use.
Browser-to-API networking constraints: Private APIs are not directly reachable from the public internet without an appropriate pattern; CORS can block requests.
Client-side logic visibility: Any JavaScript logic in the client is inspectable; don’t embed sensitive rules or secrets.
Identity integration differences: OCI IAM/identity domains vs legacy identity setups can change configuration steps—follow official docs.
Promotion between environments: Environment-specific configuration (API endpoints, auth) requires careful management to avoid “works in test, fails in prod.”
Cost surprises:
Multiple always-on instances
Excessive logging retention
Backend egress to the internet
Operational ownership: Teams sometimes treat low-code apps as “no ops,” but production still needs monitoring, incident response, and change control.
Vendor-specific UI component model: Deep customization may be harder than in a fully custom framework.

14. Comparison with Alternatives

Visual Builder sits in the low-code application development space. Here’s how it commonly compares.

Alternatives in Oracle Cloud

Oracle APEX: Strong for database-centric apps, especially Oracle Database workloads.
Custom web apps on OCI (React/Angular/Vue + backend): Maximum flexibility, more engineering/ops effort.
Oracle Integration / Process Automation (where applicable): Better for orchestration and integration flows; not primarily a UI builder (confirm current product boundaries in official docs).

Alternatives in other clouds

Microsoft Power Apps: Deep M365/Dynamics integration, broad low-code adoption.
Google AppSheet: Spreadsheet/database-driven low-code apps.
AWS Amplify: Developer-centric full-stack tooling; not low-code in the same way.

Open-source / self-managed alternatives

Budibase, Appsmith, ToolJet: Self-hosted internal tools platforms; requires operating the platform.
Retool (commercial): Internal tools with fast UI + integrations; not Oracle-managed in OCI.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Visual Builder	Low-code enterprise UIs integrated with REST/Oracle ecosystems	Fast UI development, managed runtime, Oracle ecosystem alignment	Less control than fully custom stacks; must follow service patterns/limits	You need rapid delivery with governance on Oracle Cloud
Oracle APEX	Database-centric apps on Oracle DB	Extremely productive for CRUD/reporting; tight DB integration	Different development model; best when Oracle DB is central	Your data is primarily in Oracle DB and you want rapid DB apps
Custom React/Angular + OCI backend	Highly customized apps and UX	Maximum flexibility, full control	Higher engineering and ops effort	You need custom UX/performance and can operate the stack
Microsoft Power Apps	M365/Dynamics organizations	Huge connector ecosystem, citizen dev adoption	Licensing complexity; may not align with Oracle stack	Your org is standardized on Microsoft low-code
Google AppSheet	Simple apps from sheets/tables	Very fast for lightweight apps	Limited for complex enterprise patterns	You need quick departmental apps with minimal engineering
Open-source (Appsmith/ToolJet/Budibase)	Self-hosted internal tools	Full control, extensibility	You operate security, upgrades, HA	You need self-managed and accept operational burden

15. Real-World Example

Enterprise example: Oracle SaaS extension for procurement intake

Problem
A global enterprise uses Oracle SaaS for procurement but needs a custom intake portal for multiple business units with additional validation, attachments, and status tracking.
Proposed architecture
Visual Builder app provides the portal UI.
API Gateway fronts backend services.
Backend microservice (OKE/Functions/Compute) performs validation, integrates with Oracle SaaS REST APIs, and writes audit logs.
Database stores portal-specific metadata and status history (Autonomous Database).
OCI IAM groups control access by business unit and role.
Why Visual Builder was chosen
Fast UI iteration with stakeholders.
Strong fit for REST-based integration with Oracle SaaS.
Managed runtime reduces front-end operational load.
Expected outcomes
Reduced intake time and fewer errors due to validation.
Centralized governance for who can submit/approve/view.
Faster delivery compared to building a custom portal from scratch.

Startup/small-team example: Internal operations tracker

Problem
A 20-person startup needs an internal tool to track onboarding tasks, equipment assignments, and IT requests.
Proposed architecture
Visual Builder app using business objects for tasks and requests (after confirming suitability).
Authentication through OCI identity domain users/groups.
Minimal backend; optional webhook service for notifications later.
Why Visual Builder was chosen
Small team can deliver quickly without building/operating a full stack.
Fits CRUD workflow with minimal integration complexity.
Expected outcomes
Replace spreadsheets with an auditable tool.
Quick updates as processes change.
Low operational overhead for the team.

16. FAQ

1) Is Visual Builder the same as Visual Builder Studio?
No. Visual Builder focuses on building low-code applications and publishing them to a managed runtime. Visual Builder Studio is a separate product often focused on source control and DevOps-style workflows. Verify the product pages for your subscription.

2) Do I need to know JavaScript to use Visual Builder?
Not for basic CRUD and standard UI flows. For custom behaviors, validation logic, or advanced UI patterns, JavaScript is often helpful.

3) Can Visual Builder connect to my existing REST APIs?
Yes—service connections are a core concept. You must handle authentication and CORS/networking constraints appropriately.

4) Can I build mobile apps with Visual Builder?
Visual Builder commonly supports building responsive web UIs and may support mobile-oriented patterns. Confirm current mobile capabilities in official docs for your version.

5) Is Visual Builder suitable for public internet-facing apps?
It can be used, but you must design security carefully (authentication, authorization, rate limiting, WAF/gateway patterns). Many teams use it primarily for internal/partner apps.

6) Where should authorization be enforced—UI or backend?
Backend. Always enforce authorization in backend services. The UI can hide controls, but it cannot be trusted to protect data.

7) What are business objects and when should I use them?
Business objects provide quick data modeling and CRUD without building a separate backend. Use them for smaller, governed apps after validating limits, data policies, and lifecycle requirements.

8) How do environments work (dev/test/prod)?
Visual Builder typically supports publishing to separate environments or stages. The exact model varies. Establish a promotion process and manage environment-specific settings carefully.

9) Can I integrate Visual Builder with OCI API Gateway?
Commonly yes, especially for browser-facing APIs. Use the gateway for JWT validation, throttling, and routing. Confirm exact integration steps in OCI docs.

10) How do I manage secrets for API calls?
Avoid secrets in client-side code. Use OAuth flows or gateway mediation. For backend services, store secrets in OCI Vault.

11) Does Visual Builder support CI/CD?
There are usually mechanisms for packaging, exporting/importing, and publishing. Full CI/CD may involve external tooling and/or other Oracle services. Verify current supported workflows in official docs.

12) What’s the best database for Visual Builder apps?
For enterprise data: use a proper database (Autonomous Database/Oracle Database) behind APIs. For small apps: business objects may suffice if approved.

13) How do I troubleshoot failed REST calls from the UI?
Check browser developer tools (network tab), confirm CORS, verify auth tokens, and inspect backend logs with correlation IDs.

14) How do I control who can create or publish apps?
Use OCI IAM groups and Visual Builder roles. Separate duties: builders vs publishers vs admins.

15) What are common production pitfalls?
Relying on client-side authorization, ignoring CORS/networking, underestimating backend costs, and lacking monitoring/incident ownership.

16) Can I migrate away from Visual Builder later?
You can usually export app artifacts, but UI frameworks and low-code abstractions create platform coupling. Plan migrations by separating business logic into backends and keeping APIs portable.

17. Top Online Resources to Learn Visual Builder

Use these as your primary references (prefer official sources for correctness).

Resource Type	Name	Why It Is Useful
Official Documentation	Oracle Visual Builder Documentation: https://docs.oracle.com/en/cloud/paas/visual-builder/	Authoritative, updated product docs, concepts, tutorials, administration guidance.
Official Pricing	Oracle Cloud Pricing: https://www.oracle.com/cloud/pricing/	Entry point to official pricing; search for Visual Builder SKUs and terms.
Pricing Calculator	OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html	Build region-specific estimates without guessing.
Free Tier Info	Oracle Cloud Free Tier: https://www.oracle.com/cloud/free/	Confirms what is included in free tier and current terms.
Architecture Center	Oracle Architecture Center: https://www.oracle.com/cloud/architecture-center/	Reference architectures and best practices (useful for API gateway, IAM, networking patterns).
Solutions Docs	Oracle Cloud Solutions: https://docs.oracle.com/solutions/	Practical architecture patterns and implementation guidance across OCI services.
Hands-on Labs	Oracle LiveLabs: https://apexapps.oracle.com/pls/apex/r/dbpm/livelabs/home	Official hands-on labs; search within LiveLabs for “Visual Builder”.
OCI IAM Docs	OCI Identity documentation: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm	Essential for authentication, groups, policies, and least privilege.
OCI API Gateway Docs	API Gateway documentation: https://docs.oracle.com/en-us/iaas/Content/APIGateway/home.htm	Commonly used with Visual Builder apps for secure API access.
Official Videos	Oracle YouTube Channel: https://www.youtube.com/@Oracle	Find Visual Builder sessions, demos, and webinars (verify recency).

18. Training and Certification Providers

The following training providers may offer courses related to Oracle Cloud, Application Development, and Visual Builder. Confirm current course availability and outlines on each website.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	Developers, DevOps engineers, platform teams	OCI fundamentals, app delivery practices, DevOps integration patterns	check website	https://www.devopsschool.com/
ScmGalaxy.com	Students, engineers	Software lifecycle, DevOps foundations that support application delivery	check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers, operations teams	Cloud operations practices, monitoring, reliability patterns	check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, operations, platform engineering	SRE practices, incident response, reliability engineering	check website	https://www.sreschool.com/
AiOpsSchool.com	Operations, SRE, IT ops	AIOps fundamentals, observability, automation concepts	check website	https://www.aiopsschool.com/

19. Top Trainers

These sites are presented as training resources/platforms. Verify the specific Visual Builder/OCI course offerings directly.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	Cloud/DevOps coaching and technical training (verify focus areas)	Engineers seeking guided training	https://rajeshkumar.xyz/
devopstrainer.in	DevOps and cloud training (verify OCI coverage)	DevOps engineers, developers	https://www.devopstrainer.in/
devopsfreelancer.com	Independent consulting/training style resources (verify offerings)	Teams needing short-term expertise	https://www.devopsfreelancer.com/
devopssupport.in	Support and training resources (verify OCI/Visual Builder availability)	Operations and DevOps teams	https://www.devopssupport.in/

20. Top Consulting Companies

These consulting providers may assist with Oracle Cloud implementations and application delivery. Validate service catalogs and case studies on their websites.

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify offerings)	Architecture, implementation support, operations setup	OCI landing zone + API gateway patterns + deployment practices	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training	Platform engineering, DevOps enablement, delivery pipelines	Build an app delivery workflow for Visual Builder + backend APIs	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify OCI scope)	CI/CD, infrastructure automation, operational readiness	Set up monitoring/logging and release governance for app platforms	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Visual Builder

To be effective with Visual Builder on Oracle Cloud, learn:

Web app fundamentals: HTTP, REST, cookies/tokens, browser security basics (CORS).
Identity basics: OAuth2/OIDC concepts, JWT, user vs service authentication.
OCI fundamentals: compartments, policies, regions, tagging, auditing.
API basics: design CRUD endpoints, pagination, filtering, error handling.

What to learn after Visual Builder

To deliver production solutions:

OCI API Gateway patterns (auth, throttling, routing).
Backend development on OCI:
OCI Functions, OKE, Compute
Autonomous Database
Observability: metrics, logs, tracing, alerting, SLOs.
Security engineering: threat modeling, OWASP, secrets management with OCI Vault.
Release engineering: environment promotion, rollback strategies, configuration management.

Job roles that use it

Application Developer (enterprise apps)
Solutions Engineer / Solutions Architect
Platform Engineer (low-code governance)
DevOps Engineer (release and environment patterns)
Integration Engineer (REST and SaaS integrations)

Certification path (if available)

Oracle certification offerings change over time. Use Oracle University to confirm current certifications relevant to: – OCI Foundations – OCI Developer tracks – Application development/low-code tracks (if offered)

Start here and search for current tracks: – https://education.oracle.com/

Project ideas for practice

A “Team Tasks” app (this lab) connected to a custom REST API with JWT auth.
An “Asset Tracker” app with barcode input and a backend validation service.
A “Partner Portal” prototype with role-based views and API gateway throttling.
A “SaaS extension UI” that reads/writes to Oracle SaaS REST endpoints (in a sandbox).

22. Glossary

Business Objects: A Visual Builder feature for defining data entities and performing CRUD without building a separate backend (verify scope/limits in official docs).
Compartment (OCI): A logical container in Oracle Cloud used to organize and isolate resources with IAM policies.
CORS (Cross-Origin Resource Sharing): Browser security mechanism that can block API calls unless the server allows the requesting origin.
CRUD: Create, Read, Update, Delete—common operations for data-centric apps.
Environment: A deployment target (dev/test/stage/prod) used to separate development and production runtimes.
IAM (Identity and Access Management): OCI service that manages users, groups, policies, and authentication.
Identity Domain: OCI’s identity management boundary (terminology and configuration depend on tenancy; verify in official docs).
JWT (JSON Web Token): A signed token commonly used for stateless authentication/authorization.
Low-code: Development approach that uses visual tools and configuration to reduce hand-coded work.
PaaS: Platform-as-a-Service—managed platform where the provider operates underlying infrastructure/runtime.
REST API: HTTP-based API style typically using JSON payloads and standard verbs (GET/POST/PUT/DELETE).
Service Connection: Visual Builder configuration representing an integration to an external service (commonly REST).
Tenancy (OCI): Your Oracle Cloud account boundary containing compartments, users, policies, and resources.

23. Summary

Visual Builder is Oracle Cloud’s low-code Application Development service for building and publishing web (and often mobile-friendly) applications quickly, especially when your data and processes are accessible through REST APIs or simple managed data objects. It matters because it reduces UI and deployment overhead while still fitting into enterprise identity and governance patterns on Oracle Cloud.

Cost-wise, the biggest drivers are typically the number of instances/environments and the downstream services your app depends on (API gateway, backend compute, databases, logging, and data egress). Security-wise, the key principle is to keep authorization and sensitive logic in backend services, use strong identity integration, and apply least-privilege IAM for builders and publishers.

Use Visual Builder when you need fast delivery of data-centric business apps with controlled publishing on Oracle Cloud. For highly customized applications or situations requiring full stack control, consider a custom front-end stack on OCI instead.

Next step: provision a non-production Visual Builder instance, complete the “Team Tasks” lab, and then evolve the architecture by adding an API Gateway + backend REST service to practice production-grade authentication, authorization, and observability.

rajeshkumar

Category