Real-Time Notifications and Collaboration in Oracle APEX
Building Live Dashboards and Instant Updates

Search for a command to run...
Building Live Dashboards and Instant Updates

No comments yet. Be the first to comment.
El patrón para producción que ahora despliego en menos de 30 minutos — y por qué finalmente lo empaqueté.

A production pattern I now deploy in under 30 minutes — and why I finally packaged it.
Cómo resolvimos el caos de WhatsApp en las inmobiliarias mexicanas con componentes nativos de APEX y diseño intencional.

How we transformed a complex real estate workflow into a sleek, high-density productivity tool using native APEX components and intentional design.

Por qué el 'los empleados no tienen opción' es la mayor falacia del software empresarial, y cómo construir herramientas que los usuarios realmente amen.

In today’s systems, data that refreshes every few minutes is no longer enough. Business teams expect dashboards that react instantly—whether they’re monitoring sales performance, supervising logistics operations, or coordinating service teams in real time.
Oracle APEX provides a strong foundation for secure, scalable applications, but when combined with real-time capabilities, it becomes a powerful platform for live dashboards, collaborative interfaces, and event-driven user experiences.
This article focuses on how to build these experiences using:
These techniques will help you transform static charts into intelligent, reactive components that support real decision-making.
Imagine a regional sales manager reviewing the performance of their team. With a static dashboard, they see only what happened earlier. With a real-time dashboard:
This shift—from static reporting to continuous insight—is exactly what we'll build throughout this guide.
By the end of the article, you’ll have a full blueprint for a production-ready, real-time data flow in Oracle APEX.
Before building a real-time dashboard, it’s essential to understand the different interaction models available in Oracle APEX. Each approach has strengths and trade-offs, and choosing the right one depends on user expectations, system load, and the nature of the data.
Below is a clear overview of the three primary mechanisms: Declarative Refresh, AJAX Callbacks, and WebSocket-style architectures.
Oracle APEX allows regions—such as charts, reports, and cards—to refresh automatically at defined intervals. This is the fastest way to add “near-real-time” behavior without writing code.
Ideal for:
Configuration example:
Region → Attributes → Advanced → Refresh Every: 10 seconds
Limitations:
apex.server.process) for Dynamic UpdatesFor more control, AJAX callbacks provide a flexible way to fetch updated data from the server without reloading the page.
How it works:
Strengths:
Limitations:
For true real-time interaction, Oracle APEX apps can integrate event-driven flows where the server pushes updates instantly to all connected clients.
Conceptual model:
This enables:
Although APEX does not provide built-in WebSocket channels on pages, it integrates well with:
Charts are updated via:
chartRegion.setData(newData)This article uses a WebSocket-ready model with fallback to AJAX for universal compatibility.
| Feature / Model | Declarative | AJAX | WebSocket |
| Frequency | Interval-based | On-demand | Instant push |
| Complexity | Very low | Medium | High |
| Data Payload | Full region | Custom JSON | Custom JSON |
| Multi-user Sync | ❌ No | ⚠ Partial | ✅ Yes |
| Best For | Simple dashboards | Interactive UIs | Live systems |
| Server Load | Higher on intervals | Controlled | Minimal (push) |
This diagram helps visualize how each layer participates in the real-time workflow.
Real-time features have a direct impact on database workload, network traffic, and user session behavior. Here are key guidelines to ensure scalability and performance:
Avoid large aggregations on every refresh. Pre-aggregate if necessary.
Ensures shared cursors and reduces parsing overhead.
A region refreshing every 2 seconds is often worse than a WebSocket solution.
Smaller payloads = less bandwidth + faster rendering.
Dashboard queries typically filter by:
Ensure these columns are indexed.
LOVs, product lists, or category mappings shouldn’t hit the DB repeatedly.
Combine related data into a single JSON response when possible.
You now have a high-level understanding of the three interaction models available in Oracle APEX, along with the architectural and performance considerations that guide their usage:
With this foundation, you're ready to build a fully declarative interactive dashboard with filters, AJAX updates, and drilldown behavior.
Not all real-time scenarios rely solely on WebSockets. Many enterprise architectures use REST APIs, microservices, or external data sources to supply fresh information. Oracle APEX provides native tools to integrate REST endpoints seamlessly and refresh regions dynamically, resulting in real-time–like behavior without needing a persistent WebSocket connection.
This section explores how to consume REST APIs, transform responses, validate data, and update UI components in Oracle APEX.
REST integration is ideal when:
You can define REST endpoints declaratively via Shared Components → REST Data Sources.
Steps:
Create REST Data Source
Choose Authentication
Test and Inspect the Response
If the API returns something like:
{
"period": "2025-01",
"total_sales": 198400,
"region": "North"
}
APEX automatically generates metadata mappings.
Once defined, you can query the REST endpoint as if it were a table:
SELECT period,
total_sales,
region
FROM sales_api_latest;
This allows:
REST data sources behave like tables but are fetched on demand.
To simulate real-time updates, you can refresh regions on a timed interval.
Example configuration:
This gives you a pseudo–real-time feed without sockets.
Before binding REST data directly to UI components, apply validation and transformation in PL/SQL.
Example:
DECLARE
l_sales NUMBER := :TOTAL_SALES;
BEGIN
IF l_sales < 0 THEN
l_sales := 0; -- sanitize invalid API data
END IF;
RETURN l_sales;
END;
This prevents corrupted or inconsistent external data from breaking dashboards.
A powerful hybrid pattern:
Flow:
APEX WebSocket receives:
{"event": "sales_update"}
JavaScript refreshes the REST-based chart region:
apex.region("SALES_CHART").refresh();
This approach avoids pushing large datasets through WebSockets while still achieving real-time responsiveness.
✔ Always use HTTPS ✔ Never store API keys in JavaScript ✔ Use Named Credentials in APEX ✔ Validate and sanitize all external data ✔ Add logging and exception handling for timeouts
REST Data Sources in Oracle APEX enable:
Next, we’ll explore how to build collaborative interfaces using these technologies—task boards, messaging modules, and multi-user experiences.
Building real-time experiences in Oracle APEX requires more than adding automatic refreshes or AJAX callbacks. To ensure that dashboards, notifications, and multi-user interactions scale effectively, you must follow architectural, performance, and security best practices.
Below is an enhanced, production-ready set of guidelines covering SQL optimization, session management, UI responsiveness, and security controls.
Oracle APEX dashboards often query large datasets. These recommendations ensure high performance even under real-time workloads:
Don’t push thousands of rows to the browser if you only need daily totals.
Bad:
SELECT * FROM orders;
Good:
SELECT order_date, SUM(order_total)
FROM orders
GROUP BY order_date;
For dashboards that filter by:
ensure these columns are indexed to avoid full table scans.
For real-time dashboards with logic-heavy rules, calculations should live inside PL/SQL packages, not embedded inside region queries.
Real-time applications generate more requests per user, so state-handling must be efficient.
Each AJAX call should send the minimal number of items to avoid overhead.
Avoid polluting the session state with unnecessary values, especially when events occur frequently.
Do not attach heavy computations to events that fire often, like item changes or timer-based refreshes.
When charts refresh frequently, avoid sudden shifts:
For AJAX-based refreshes, add a loading indicator:
apex.util.showSpinner();
And hide it in the callback’s success function.
To target specific charts or regions via JavaScript:
Region Static ID: SALES_CHART
Then update:
apex.region("SALES_CHART").setData(newData);
This avoids brittle DOM queries.
If you are using notifications:
Real-time should be useful, not overwhelming.
SQL injection can happen even in dashboards. Never concatenate parameters manually.
A malicious user can trigger AJAX callbacks directly from the browser console.
Always assert permissions:
IF NOT user_can_view_region(:APP_USER, :P10_REGION) THEN
raise_application_error(-20001, 'Unauthorized');
END IF;
Real-time apps often include drilldowns, which must have:
Never rely solely on client-side logic.
A full chart refresh can weigh 30–80 KB or more.
A JSON response with metrics might weigh under 3 KB.
Polling every 1–2 seconds is rarely necessary unless you're building a trading dashboard.
Recommended:
Avoid sending 3–5 separate AJAX calls when one PL/SQL process could return a structured JSON payload.
This enhanced set of best practices ensures that your real-time Oracle APEX applications remain secure, scalable, and user-friendly:
Together, these principles allow your dashboard to support real-world business scenarios with speed, clarity, and professional-grade reliability.
These patterns bring enterprise-grade interactivity to APEX without compromising security or maintainability.
Real-time collaboration in Oracle APEX goes beyond chat modules and dashboards. Modern enterprise applications require indicators, alerts, and feedback mechanisms that react instantly to system events. These “micro-interactions” enhance usability and keep users informed without manual refresh.
This section covers three high-impact real-time patterns you can easily integrate into an Oracle APEX application:
Each pattern improves the user experience and promotes application adoption—especially in systems where timing and awareness are critical.
Real-time alerts notify users immediately when something important happens—such as approval requests, ticket escalations, SLA warnings, or new customer messages.
💡 Implementation Note: The code examples below use
apex_websocketandapex.webSocketas conceptual wrappers. In a real-world APEX implementation, this would likely wrapAPEX_WEB_SERVICEcalls to ORDS or a custom JavaScript library handling the WebSocket connection.
CREATE TABLE user_alerts (
id NUMBER GENERATED ALWAYS AS IDENTITY,
user_id VARCHAR2(100),
alert_type VARCHAR2(50),
alert_message VARCHAR2(4000),
created_at TIMESTAMP DEFAULT SYSTIMESTAMP,
is_read VARCHAR2(1) DEFAULT 'N'
);
-- Context: PL/SQL Process (e.g., "After Submit" or AJAX Callback)
INSERT INTO user_alerts (user_id, alert_type, alert_message)
VALUES (:P_TARGET_USER, 'WARNING', 'New ticket assigned to you.');
COMMIT;
apex_websocket.notify(
p_channel => 'user_alerts_channel',
p_message => '{"event":"new_alert"}'
);
Inside a Dynamic Action listening to WebSocket messages:
const ws = apex.webSocket.init("user_alerts_channel");
ws.onMessage = function() {
apex.region("ALERT_REGION").refresh();
apex.message.showPageSuccess("You have a new alert!");
};
Use case examples:
Toasts are small, dismissible UI messages that confirm actions or highlight events.
Oracle APEX provides two primary client-side APIs:
apex.message.showPageSuccess: Standard success banner (usually
top-right). Best for confirming user actions.apex.message.showToast: Passive notification (often bottom-center) that
doesn't interrupt flow.For background real-time events (e.g., "Import finished"), showToast is often superior as it doesn't demand immediate dismissal.
const toastWS = apex.webSocket.init("toast_notifications");
toastWS.onMessage = function(payload) {
const data = JSON.parse(payload.data);
apex.message.showToast({
message: data.message,
type: "info",
duration: 4000
});
};
apex_websocket.notify(
p_channel => 'toast_notifications',
p_message => '{"message":"Inventory updated successfully!"}'
);
Best used for:
This eliminates polling and keeps users informed without interrupting their work.
Presence indicators enhance collaboration by showing which users are currently active in the application or viewing the same page.
CREATE TABLE apex_user_presence (
session_id VARCHAR2(200),
user_name VARCHAR2(100),
last_seen TIMESTAMP
);
-- Context: Application Process (Fire on "On Load: Before Header")
MERGE INTO apex_user_presence p
USING (SELECT :APP_SESSION AS session_id, :APP_USER AS user_name FROM dual) d
ON (p.session_id = d.session_id)
WHEN MATCHED THEN
UPDATE SET last_seen = SYSTIMESTAMP
WHEN NOT MATCHED THEN
INSERT (session_id, user_name, last_seen)
VALUES (d.session_id, d.user_name, SYSTIMESTAMP);
And notify others:
apex_websocket.notify(
p_channel => 'presence_updates',
p_message => '{"event":"presence_changed"}'
);
const presenceWS = apex.webSocket.init("presence_updates");
presenceWS.onMessage = function() {
apex.region("PRESENCE_LIST").refresh();
};
Presence use cases:
Throttle refresh frequency for high-traffic dashboards.
Always set Static IDs for regions refreshed via WebSocket.
Send event flags, not full JSON data.
Never allow anonymous access.
Tables grow quickly in real-time collaboration apps.
Real-time UX patterns bring modern, intuitive interactions to Oracle APEX applications. With a combination of WebSockets, Dynamic Actions, and minimal JavaScript, you can create:
These enhancements transform APEX into a dynamic, multi-user application platform—ideal for operational systems, enterprise dashboards, and team-centered workflows.
Real-time collaboration features amplify usability, but they also introduce architectural considerations that must be handled with care. Oracle APEX provides built-in protections, but your implementation determines the final level of security, performance, and scalability.
This section highlights key principles and best practices to ensure your real-time system remains stable, secure, and production-ready.
WebSockets in Oracle APEX must always be protected by Access Control Lists (ACLs) to ensure that only authenticated and authorized users can subscribe to real-time channels.
BEGIN
APEX_ACL.ADD_USER_ROLE(
p_application_id => :APP_ID,
p_user_name => :APP_USER,
p_role_static_id => 'REALTIME_ACCESS'
);
END;
Then restrict the WebSocket channel to this role:
apex_websocket.subscribe(
p_channel => 'sales_realtime',
p_roles => APEX_STRING.T_VARCHAR2('REALTIME_ACCESS')
);
Never expose WebSocket channels to unauthenticated users.
Sending too many notifications—especially in dashboards updated frequently—may create:
✔ Group updates: Instead of sending 10 notifications, send 1 summary event. ✔ Throttle messages: Notify at a fixed interval (e.g., every 3 seconds). ✔ Debounce user actions: Prevent sending multiple events during rapid UI interactions.
Example throttled refresh in JavaScript:
let refreshTimer;
ws.onMessage = function() {
clearTimeout(refreshTimer);
refreshTimer = setTimeout(() => {
apex.region("SALES_CHART").refresh();
}, 1000);
};
Even in real-time scenarios, NEVER trust client-provided data.
In every PL/SQL process, validate inputs before executing SQL:
IF NOT apex_util.is_session_valid THEN
raise_application_error(-20000, 'Invalid session');
END IF;
IF :P10_ANIO NOT BETWEEN 2000 AND EXTRACT(YEAR FROM SYSDATE) THEN
raise_application_error(-20001, 'Invalid year parameter');
END IF;
This prevents tampered AJAX calls from injecting malicious filters.
Even with WebSockets or AJAX, the protection rules stay the same:
✔ Always use bind variables
✔ Never concatenate values directly into SQL
✔ Prefer APEX_EXEC over EXECUTE IMMEDIATE
Example (safe):
l_ctx := APEX_EXEC.OPEN_QUERY_CONTEXT(
p_sql_query => 'SELECT ... WHERE region_id = :REGION',
p_bind_values => APEX_EXEC.T_BIND_VALUES(
APEX_EXEC.T_BIND_VALUE('REGION', :P10_REGION)
)
);
Real-time features should be lightweight. Apply these practices:
Every query used for real-time updates should:
If the dashboard aggregates complex data:
Only return what the front-end actually needs:
❌ Bad
[
{ "order_id": 193, "customer": "John", ... more fields ... }
]
✔ Good
[
{ "period": "2025-04", "total_sales": 39429 }
]
Real-time systems behave differently under multiple users. Perform testing with at least:
APEX’s session-based architecture handles this well, but your queries and WebSocket broadcasts determine final scalability.
Even experienced developers can run into issues when building real-time dashboards. Avoiding these pitfalls will help you maintain secure, scalable, and predictable behavior:
Constructing SQL strings with concatenated user input exposes your application
to SQL injection.
Always rely on bind variables or APEX_EXEC with structured bind arrays.
Without Static IDs, JavaScript cannot reliably reference charts or regions after
a partial refresh.
This often leads to intermittent bugs in dashboards that depend on setData().
Large or deeply nested JSON dramatically slows down real-time refreshes.
Send only the essential fields (period, value, label, status).
setData()Full region refreshes cause unnecessary server load and can produce visible
flicker.
Whenever possible, update only the chart’s dataset via:
apex.region("SALES_CHART").setData(newData);
Missing error-handling blocks result in silent failures and dashboards that
“stop updating.”
Use standardized error handlers:
error: function(jqXHR, textStatus, errorThrown) {
apex.message.showErrors([{
type: "error",
message: "Dashboard error: " + errorThrown,
location: "page"
}]);
}
Avoiding these pitfalls ensures that your real-time dashboards remain fast, stable, and secure as they scale.
Secure and efficient real-time features follow these principles:
Applied correctly, these practices ensure your application remains fast, scalable, and secure—even as you add real-time collaboration features.
Real-time collaboration unlocks a new level of interactivity in Oracle APEX applications. Whether you're building dashboards that react instantly to new data, shared workspaces synchronized across users, or notification systems that keep teams aligned, APEX provides the tools to do it securely, efficiently, and with professional-grade architecture.
This article introduced two complementary approaches:
Perfect when you need responsiveness without increasing complexity.
Ideal for: dashboards, filters, UI refresh, and simple notifications.
The full-power solution for enterprise-grade real-time systems.
Ideal for: collaborative apps, instant dashboards, shared operational views, chat-style interactions, operations monitoring.
Here are the core principles that will keep your APEX real-time architecture robust:
With these practices, your real-time features will not only work, but scale and survive future growth.
In the next article of the series, we’ll shift our focus from backend events to User Experience (UX) in Oracle APEX.
You’ll learn:
This will help you transform your application from “functional” to “delightful”.
Real-time collaboration is fast becoming a requirement in modern applications. With Oracle APEX, you don’t need external libraries or complex infrastructure — the platform gives you all the tools to build instant, reactive, secure interfaces.
If you want to explore a specific real-time scenario for a future APEX Insights edition, share your idea — it may be the next article in the series!
Below is a curated list of official documentation, expert resources, and community tools that support real-time development in Oracle APEX:
Oracle APEX Official Documentation
https://docs.oracle.com/en/database/oracle/application-express
The foundation for understanding APEX architecture, security, and component behavior.
Oracle APEX JavaScript API (apex.server.process & more)
https://docs.oracle.com/en/database/oracle/application-express/latest/aexjs/api-reference.html
Essential reference for AJAX interactions, dynamic UI updates, and secure
client-server communication.
APEX_EXEC PL/SQL API
https://docs.oracle.com/en/database/oracle/application-express/latest/aeapi/APEX_EXEC.html
The recommended interface for executing SQL securely inside PL/SQL processes.
OWASP Top 10 Security Guidelines
https://owasp.org/www-project-top-ten/
Critical reading for preventing injection, XSS, and event-driven attack vectors.
Oracle REST Data Services (ORDS) Documentation
https://docs.oracle.com/en/database/oracle/rest-data-services
Helpful when your real-time features interact with REST endpoints or push events.
Oracle JET Cookbook
https://www.oracle.com/webfolder/technetwork/jet/index.html
Deep dive into chart customization, events, theming, and advanced visualization
patterns that APEX builds on.
APEX Community Blogs & Tutorials
https://blogs.oracle.com/apex
Articles from Oracle APEX product managers and leading experts — excellent for
staying current with new techniques.
I help companies facilitate professional Oracle APEX development and DevOps. If you want to build better applications or automate your pipeline, let's talk.
☕ Schedule a Call|💼 Connect on LinkedIn
If you found this article helpful, consider supporting me!
GitHub Sponsors | Buy Me a Coffee
Your support helps me keep creating open-source demos and content for the Oracle APEX community. 🚀