Subject areas in Oracle Analytics Cloud (OAC) — and in Oracle OBIEE — are the organised, business-facing presentation of the semantic model’s data, structured into domain-specific folders that report authors use to build analyses and dashboards without writing SQL. A subject area is a named set of dimension and metric folders presented to the user in the OAC Workbook’s data panel: “GL – Revenue Analysis” might contain folders for Time, Entity, Account, and a Metrics folder with Revenue, Budget Revenue, Variance, and YTD Revenue measures. The user selects columns from these folders, and OAC’s BI Server translates those column selections into the appropriate SQL query against the physical data source — the user never sees the SQL or the underlying table structure. Subject areas define the analytical vocabulary available to each user group, and the OAC security model restricts which subject areas are visible to each user role.
Oracle BI Applications Subject Areas for Oracle EBS
Oracle’s BI Applications — the pre-built analytical content for Oracle EBS and Oracle Fusion — provide a library of subject areas covering Oracle’s standard financial, supply chain, HR, and CRM modules. For Oracle EBS financial reporting, the key BI Applications subject areas include:
| BI Applications Subject Area | Oracle EBS Module | Key Metrics Available |
|---|---|---|
| GL – Profitability | Oracle General Ledger | Revenue, COGS, Gross Margin, Operating Expenses, EBITDA by entity/account/period |
| AP – Payments | Oracle Payables | Invoice amounts, payment terms, DPO, aging buckets, vendor spend |
| AR – Billing | Oracle Receivables | Invoice amounts, DSO, aging buckets, customer revenue, collection efficiency |
| FA – Assets | Oracle Fixed Assets | Asset NBV, depreciation, additions and disposals, asset category summary |
| Cash Management – Bank Reconciliation | Oracle Cash Management | Bank statement reconciliation status, outstanding items, cash position |
Custom Subject Area Development
For GCC enterprises with Oracle EBS or Fusion deployments where the standard BI Applications subject areas do not cover a specific reporting requirement — Zakat base calculation reporting, Nitaqat compliance metrics from HRMS, ZATCA invoice detail analysis — custom subject areas must be built by extending the OAC RPD. A custom subject area requires: a physical layer connection to the data source (Oracle EBS table, Oracle ADW mart, or custom view), a business model layer logical table definition with the appropriate joins and calculation logic, and a presentation layer folder organisation that presents the content in a domain-appropriate, user-friendly structure. Custom subject areas are built in Oracle Analytics Developer Client Tool (the desktop RPD editor, equivalent to OBIEE’s Administration Tool) and promoted through the OAC environment using Oracle’s Semantic Model Promotion tooling.
Subject Area Security
OAC subject area security is implemented at two levels. Subject area access — which subject areas each user role can see — is configured in OAC’s Application Role security, where specific subject areas are granted or denied to each role. Data-level security — which rows of data within a subject area a user can see — is implemented through OAC’s Row-Level Security capability, using session variables that are populated with the user’s identity and used in data filter rules on the physical layer tables. Both layers must be configured for a complete security implementation; subject area access controls which domains the user can query, and data-level security controls what they can see within those domains.
What Goes Wrong in Practice
The most common subject area design failure in OAC environments is a subject area that exposes too many columns — presenting every column from every table in the physical layer to the report author, organised only by table name rather than by business domain. A subject area with 200 columns organised into one folder called “GL_BALANCES_V” is not useful to a finance analyst who does not know the Oracle EBS internal column naming convention. Subject areas must be designed from the user’s analytical vocabulary — the terms and concepts the finance team uses in their reports — not from the database schema structure.
How Loop Wise Solutions Designs Subject Areas
We design OAC subject areas from a business requirements workshop — identifying the analytical domains, the dimensions, and the metrics that each finance user group needs — and building the subject area presentation layer to match that vocabulary. Every column in the presentation layer has a business-friendly name and description visible to report authors in the OAC data panel.
