Over the years, many of us working in the Oracle analytics space have helped customers implement Oracle Business Intelligence Applications (OBIA) - a powerful solution in its time, offering prebuilt analytics across ERP, HCM and more. If you ever spent hours managing DAC, tweaking ETL mappings, or retrofitting OBIA customisations after a patch - you’ll understand why Fusion Data Intelligence feels like Oracle finally got analytics right.But let’s be honest: it had its fair share of complexity, rigidity, and technical debt.
​
Fast-forward to today and we’ve entered a new era with Oracle Fusion Data Intelligence (FDI) - a reimagined, cloud-native analytics platform designed from the ground up for the Fusion SaaS landscape. And if you’ve ever battled with OBIA’s extensibility, upgrade cycles or data latency, FDI is likely to feel like a breath of fresh air.

This post is the first in a short series unpacking what FDI actually is, how it compares with its predecessors, and what it means for Fusion customers today.

Oracle's recent growth

Over the past 2–3 years, Oracle has consistently grown its cloud business, with total revenue rising from $40.5 billion in FY2022 to $57.4 billion in FY2025, driven largely by strong momentum in Fusion Cloud Applications, NetSuite, and OCI (Oracle Cloud Infrastructure).

While Oracle doesn’t match the scale of hyperscalers like AWS or Microsoft Azure in infrastructure alone, its distinct advantage lies in its full-stack strategy - uniquely offering enterprise SaaS, infrastructure, and the database layer under one roof. This vertically integrated model means Oracle can optimise performance, security, and cost across its stack, especially for Fusion workloads. Competitors like SAP and Workday lead in applications but lack native cloud infrastructure; AWS and Azure dominate infrastructure but rely on third-party SaaS partners.

​Oracle, by contrast, continues to blur the lines between application and platform, using technologies like Autonomous Database, OCI Gen2, and now Fusion Data Intelligence to deliver insights that are deeply embedded, secure, and performant - all within its own ecosystem.

These figures aren’t just impressive - they’re a strong signal that Oracle’s SaaS portfolio is achieving scale and maturity, particularly in core enterprise functions like Finance, HR, and Operations. Fusion ERP alone has grown from $0.9B to $1.0B in quarterly revenue, underscoring widespread enterprise adoption.

From Adoption to Insight: The Next Frontier

​As organisations continue investing in Oracle Fusion Cloud applications, the expectation isn’t just automation - it’s intelligence. Businesses aren’t content with simply moving transactional processes to the cloud; they want to understand the return on those investments, monitor performance in real time, and use their data to make faster, smarter decisions.
This is where Fusion Data Intelligence (FDI) steps in.
Just as Oracle’s adoption of Fusion SaaS pillars is accelerating, so too is the demand for embedded, governed, cross-functional insights that empower users in the flow of work. With SaaS platforms becoming the new systems of record, the analytics layer must evolve in lockstep - and be natively integrated, secure, and scalable.
FDI is that evolution.

Why FDI Matters Now More Than Ever

• Data gravity has shifted - core operational data now lives in Fusion Cloud ERP, HCM, SCM, and CX.
• Decision-makers want answers in context - not in a separate BI tool, but embedded inside the applications they use every day.
• Cloud-native analytics isn’t a nice-to-have; it’s a business requirement for agility, accountability, and optimisation.

​FDI bridges this critical gap by turning raw operational data into actionable intelligence - all while aligning with the Fusion application security model, lifecycle, and extensibility standards.

But OBIA came with constraints that, over time, became significant limitations:

• Customisations were fragile: Even minor changes to the ETL or data model could break during upgrades, making custom development expensive and hard to maintain.
• Siloed architectures: Each functional pillar (e.g. Oracle EBS, PeopleSoft, Siebel, JDE) had its own data model and ETL codebase, with no unified customer or product view.
• Upgrade pain: OBIA upgrades were major projects in themselves - often requiring reimplementation or heavy retrofitting for customised solutions.
• Customer-managed infrastructure: Customers had to provision, maintain, and tune on-premises environments — including DAC, Informatica, BI Server, and database platforms - with all the associated complexity and cost.
• Slow to evolve: The on-prem model struggled to keep up with rapidly changing business requirements and the rise of cloud-based enterprise applications.

The Modern Alternative: Fusion Data Intelligence

With Fusion Data Intelligence (FDI), Oracle has reimagined what enterprise application analytics should look like in the cloud era.

• Extensibility is core, not an afterthought: FDI is metadata-driven and designed to be extended - securely, scalable, and without breaking with every update.
• Unified cross-pillar model: Instead of siloed data marts, FDI provides a 360-degree customer, employee, and transaction view across Fusion ERP, HCM, SCM, and CX — built on a shared semantic model.
• Evergreen analytics: As Fusion Apps evolve, so too does FDI — delivered as a SaaS analytics layer that evolves in sync with Oracle’s application roadmap.
• Oracle-managed infrastructure: FDI is provisioned, patched, secured, and optimised by Oracle - no DAC, no Informatica, no infrastructure headaches.
• AI and machine learning embedded: Insights aren’t just historical - FDI includes predictive models, anomaly detection, and natural language queries right out of the box

From OBIA to OAX to FAW to FDI: An Analytics Evolution

FDI didn’t appear out of nowhere - it’s the result of five years of iterative development across multiple product identities. It began as Oracle Analytics for Applications (OAX), introduced around 2019 as a cloud-based successor to OBIA. OAX was designed to deliver prebuilt analytics for Oracle Fusion Cloud Applications, leveraging Oracle Autonomous Data Warehouse and Oracle Analytics Cloud. In 2020, OAX was rebranded as Fusion Analytics Warehouse (FAW), marking a shift toward a more unified, extensible platform. FAW introduced modular “pillars” aligned with business domains--ERP, HCM, SCM, and CX—each offering curated data models, semantic layers, and prebuilt KPIs. Over the next few years, Oracle expanded these pillars with hundreds of subject areas and embedded machine learning for predictive insights.

In 2024, FAW was renamed Fusion Data Intelligence (FDI). This rebranding emphasized its broader mission: not just warehousing analytics, but enabling intelligent decision-making across the enterprise. FDI retained the core architecture—Autonomous Data Warehouse, Oracle Analytics Cloud, and managed pipelines—but added enhanced extensibility, data sharing capabilities, and a more intuitive console for governance and customisation.

Looking Ahead

​This post was just the beginning. Over the next few instalments, we’ll dive deeper into the nuts and bolts of Fusion Data Intelligence - from how it handles extensibility and embedded insights, to what it means for Fusion customers trying to move beyond dashboards and into decision intelligence.

FDI represents more than just a new analytics tool - it’s a shift in how Oracle customers can extract value from their SaaS investments. If you’ve ever found yourself battling data silos, struggling with upgrades, or explaining to stakeholders why reporting still takes days, this series is for you. Stay tuned.

When we think about business data, we usually picture tidy tables and dashboards neatly populated with structured relational data. But in reality, much of an organisation’s most valuable information lives in unstructured formats—scanned invoices, PDFs, handwritten notes, and contracts. This data is often locked away in silos, disconnected from the wider analytical ecosystem.

Oracle Analytics’ AI Document Understanding feature changes that. It enables organisations to automatically extract structured data from documents stored in OCI Object Storage using pretrained AI models—all without needing a data science team. With this capability, you can enrich dashboards with data that would previously be too costly or complex to access.

In this post, we’ll walk through:

• What the AI Document Understanding feature is
• Practical business scenarios where it is applicable
• Step-by-step setup and configuration, including OCI policy management and model registration
• Tips and tricks for working with unstructured data in Oracle Analytics

What Is Oracle Analytics AI Document Understanding?

At its core, the AI Document Understanding capability in Oracle Analytics leverages AI models (deployed within Oracle Cloud Infrastructure) to parse and extract fields of interest from documents stored in OCI Object Storage. This is particularly powerful for automating workflows that currently depend on manual data entry or semi-structured file formats.

It supports a range of document types and layouts, including:

• PDF invoices from suppliers
• Utility bills or receipts
• Financial statements
• Handwritten or printed forms (subject to OCR accuracy)

The output is a structured dataset—columnar data ready for blending, analysis, and visualisation in Oracle Analytics.

IAM Policies
​To enable Oracle Analytics to securely access documents stored in OCI Object Storage and to invoke AI services like Document Understanding, specific IAM policies must be in place. Without these policies, your OAC instance won’t have the necessary permissions to read documents or trigger AI model processing. In this section, we’ll walk through the exact tenancy- and compartment-level policies required, ensuring your setup is both functional and secure. You can find more information here.

The following IAM policies grant Oracle Analytics the necessary permissions to read from your Object Storage bucket and to invoke the AI Document Understanding service.

Notes

1. Replace <GROUP NAME> with your OCI IAM Group name
2. Replace <COMPARTMENT NAME> with your OCI Compartment name where you Object Storage bucket is located in your OCI tenancy
3. Replace <BUCKET NAME> with your Object Storage Bucket name where your files have been uploaded to. Note that the Bucket Name is in single quotes.​

​
​Next policy needs to be defined at the root compartment level 

These policies are necessary to enable Oracle Analytics to access the OCI AI Document Understanding model. Without these policies correctly setup, you will encounter errors when you attempt to run your data flow in Oracle Analytics. 

With the IAM policies configured, you can now proceed with setting up the connection and registering the model within Oracle Analytics.

You do this by creating an Oracle Analytics connection to your Oracle Cloud Infrastructure tenancy that will enable you to gain access to your OCI Object Storage Bucket.

Register a pre-trained Document Key Value Extraction model with your Oracle Analytics instance ensuring that the bucket created previously is  selected.

This completes all prerequisites and the next step is to run the newly registered pre-trained model in Oracle Analytics by creating a data flow.

The next step is to create a create a "dataset" which is used as an input to the data flow. This dataset is a CSV file that contains the OCI object storage bucket URL where the documents have been uploaded to. 

This CSV file can either contain a row for each document with a URL for each document that you intend to process or a single row with a URL for the bucket itself. This way every document within this bucket will be processed. Personally, it's a no brainer for me to use the second option.  As mentioned earlier in this article, you need to derive the bucket URL by logging on to the OCI console's bucket details page and copying the URL from your browser. You can see a sample below that has 2 tabs; the 1st tab is what you would use for option 1 where you list out your documents with their corresponding URLs. The 2nd tab has a single row and this is what you would use to instruct the data flow to process all documents within the specified bucket.

Follow the instructions here to create your data flow.

Using the Apply AI Model step, you make a call the the registered pretrained AI Document Understanding model. You then add a Save Data step in which you specify the output dataset. In my example below, I have a few Transform Column steps which are being used to execute some transformations to some columns.

Once the data flow has been saved, it can be run to generate the output dataset. You can see a sample data visualisation workbook below based on the output dataset with some insights of the information derived from the invoices.

Tips and tricks for working with unstructured data in Oracle Analytics

Working with unstructured documents—especially at scale—introduces its own set of quirks. Here are some practical insights to help you get the most out of the AI Document Understanding feature in Oracle Analytics:

Use Document Batching Strategically
Oracle Analytics currently imposes a 10,000-row processing limit per run. If you’re working with high volumes:

• Break documents into batches and use multiple data flows.
• Consider filtering by date or document type.​

 
​Reuse and Schedule Data FlowsOnce you’ve built a data flow that works, save it and schedule it to run regularly:

• Use the built-in scheduler in Oracle Analytics.

​Start Small, Then Scale
Try a proof-of-concept with 10–20 documents first:

• Test how accurate the model is.
• Check how the data appears in the dataset.
• Adjust your approach based on results—especially if OCR noise is high.

Resources

​Official Documentation
Some YouTube videos from the Oracle Analytics channel:

Gotchas, Limits and Tips

1. Bucket URL Must Be Copied from Browser
The most confusing part of this setup is finding the correct OCI Object Storage bucket URL. It’s not visible anywhere in the console UI—you must copy it from the bucket’s detail page URL in your browser.
2. 10,000 Document Row Limit
There’s a hard limit of 10,000 document rows per data flow run. If your use case involves large volumes of documents, you’ll need to split your data or automate batch runs accordingly. Note that this limit is even less when a custom model is used. The limit in this scenario is 2,000 documents. 
3. Document Layouts Matter
The AI model is pre-trained for certain layouts (e.g. invoices, forms). Custom layouts may yield mixed results, and you may need to experiment with field mappings to improve outcomes.
4. Use Tags for Traceability
Tag your buckets and policies in OCI with labels like oac-ai-docs so they’re easier to audit and maintain.

Conclusion

Oracle Analytics’ AI Document Understanding feature bridges a crucial gap between unstructured documents and visual analytics. With a few setup steps—bucket creation, IAM policy configuration, model registration, and a simple data flow—you can surface hidden insights from documents that would otherwise sit untouched.

It’s a powerful tool, but one with nuances—such as the hidden bucket URL and processing limits—that are worth planning for. Still, for anyone looking to extend their analytics to the edges of their data estate, this capability opens the door. Oracle Analytics now makes it possible to integrate scanned documents, invoices, and other unstructured data sources directly into your dashboards—unlocking insights that were previously out of reach.​