Your OTBI report is not returning data. You open the analysis in Oracle Fusion, run it, and get a blank screen or a “No Results” message. The report worked last week, or it works for one user but not another, or it returns data in one business unit but not the rest. This is one of the most common Oracle Fusion reporting problems I encounter, and it almost always traces back to one of four root causes: a subject area mismatch, a data security restriction, a flexfield mapping issue, or a date filter problem.

The frustrating part is that OTBI does not give you a helpful error message. It simply returns nothing. Here is how to systematically diagnose and fix the issue, based on patterns I have seen across dozens of Oracle Fusion implementations.

Cause 1: Subject Area Mismatch or Missing Columns

OTBI subject areas in Oracle Fusion are pre-built data models that expose specific sets of related data. Each subject area is designed for a particular reporting purpose, and they do not all contain the same columns or the same level of detail. If your analysis references columns from a subject area that does not contain the data you expect, OTBI will return no rows.

How this happens

The most common scenario: someone builds a report using columns from one subject area, then later adds a filter or column from a different (incompatible) subject area through a cross-subject-area join. Oracle Fusion supports cross-subject-area analysis in some cases, but the joins are implicit and can silently produce empty result sets when the underlying data does not match across subject areas.

Another common scenario: the report uses a subject area that only contains data for a specific module or transaction type. For example, using “Financials – AP Invoices” when the data you need is in “Financials – AP Invoices Real Time.” The non-real-time subject area only includes data that has been fully processed through the BI extract, which may not include recently created transactions.

How to fix it

  1. Open the analysis in BI Answers and check the Subject Area panel on the left side of the Criteria tab.
  2. Verify that every column in the Selected Columns panel belongs to the same subject area, or that cross-subject-area joins are supported for the combination you are using. Oracle documents supported cross-subject-area joins in the OTBI reference guides.
  3. If you need real-time data, switch to the “Real Time” variant of the subject area. If you need historical or batch-processed data, use the standard (non-real-time) variant and confirm that the BI extract has been run recently.
  4. Test with a simple analysis: one or two columns from the subject area, no filters. If that returns data, add columns and filters back one at a time to identify which one eliminates the results.

Cause 2: Data Security Restrictions

This is the root cause when the report returns data for some users but not others. Oracle Fusion enforces data security at the OTBI layer, meaning the same analysis will return different result sets depending on who runs it. If a user’s security profile does not grant access to the data the report is querying, OTBI returns no rows—without any indication that security is the reason.

How data security affects OTBI

Oracle Fusion uses a layered security model for reporting:

  • Role-based access — The user must have a role that includes the BI duty role for the relevant subject area. Without it, they cannot even open the subject area, let alone see data.
  • Data security policies — Even with the correct role, data security policies restrict which records the user can see. For example, an AP manager might only see invoices for their assigned business unit. If the report filters on a business unit the user does not have access to, the result is zero rows.
  • HCM security profiles — For HR and payroll subject areas, HCM security profiles control which person records are visible. A manager may only see their direct reports. An HR analyst may only see employees in their legal entity. If the security profile is too restrictive, the report returns nothing.

How to fix it

  1. Run the same analysis as an administrator (a user with broad data access). If it returns data, the issue is data security on the affected user’s profile.
  2. Check the user’s assigned roles in Security Console. Verify they have the appropriate BI duty role (e.g., “Financial Analyst” includes BI duties for Financials subject areas).
  3. Review data security policies assigned to the user’s roles. Navigate to Setup and Maintenance > Manage Data Access for Users to see which business units, ledgers, or legal entities the user can access.
  4. For HCM reports, check the user’s HCM security profile assignment under Manage Data Role and Security Profiles.

Cause 3: Flexfield Mapping Issues

Oracle Fusion uses flexfields extensively—descriptive flexfields (DFFs) for custom attributes and key flexfields (KFFs) for chart of accounts segments. OTBI exposes flexfield data through mapped columns, but these mappings must be configured correctly. If the flexfield is not mapped to BI, or if the mapping was changed after the report was built, OTBI will return blanks or no data for those columns.

Common flexfield problems

  • DFF not BI-enabled. Descriptive flexfields must be explicitly enabled for BI in the flexfield configuration. If someone added a DFF to capture custom data but did not check the “BI Enabled” flag, the column will not appear in OTBI subject areas or will appear but return nulls.
  • Flexfield deployment not run. After enabling or modifying a flexfield for BI, you must deploy the flexfield and then run the “Import Oracle Fusion Data Extensions for Transactional Business Intelligence” ESS job. If this job has not been run since the flexfield was modified, OTBI will not reflect the changes.
  • Segment mapping mismatch. For key flexfields like the GL account combination, each segment must be mapped to the correct BI dimension. If segment labels are incorrect or were reassigned, OTBI will join data incorrectly and produce empty results or wrong aggregations.

How to fix it

  1. Navigate to Setup and Maintenance > Manage Descriptive Flexfields (or Manage Key Flexfields). Find the relevant flexfield and verify the BI Enabled flag is set.
  2. Deploy the flexfield if any changes were made.
  3. Run the ESS job “Import Oracle Fusion Data Extensions for Transactional Business Intelligence” from the Scheduled Processes work area.
  4. After the job completes, test the OTBI analysis again. If the column now appears but shows nulls, verify that the underlying data actually has values populated for that flexfield attribute.

Cause 4: Date Filters Excluding All Data

This sounds obvious, but it accounts for a surprising number of “OTBI not returning data” support requests. Oracle Fusion date columns behave differently across subject areas, and a filter that looks correct can silently exclude all records.

Common date filter mistakes

  • Using Creation Date when you mean Accounting Date. A filter on “Invoice Creation Date > January 1” will miss invoices created before that date even if they were accounted in the current period. For financial reporting, filter on the accounting date or GL date, not the transaction creation date.
  • Time zone misalignment. Oracle Fusion stores some dates in UTC. If your filter specifies a date without considering the time zone offset, you may exclude transactions that occurred on the boundary dates. This is especially common for organizations spanning multiple time zones.
  • Period name vs. date range. Some subject areas use period names (e.g., “Mar-26”) while others use date ranges. If you filter on a period name in a subject area that expects a date range, or vice versa, you get no results.

How to fix it

Remove all date filters and run the analysis. If data appears, add date filters back one at a time. Use the date column that is appropriate for your subject area—check Oracle’s subject area documentation for the recommended filter columns. For period-based reporting, use the Period Name filter rather than a date range wherever the subject area supports it.

When to Get Expert Help

If you have worked through all four causes and the report still returns no data, the problem likely involves a combination of factors or a deeper configuration issue—a misconfigured BI extract schedule, a corrupted analysis definition, or a subject area bug that requires an Oracle SR. A Reporting Sprint puts a senior OTBI specialist on the problem. Typical resolution time for blank-report issues is 2–4 business days, including root cause diagnosis, fix implementation, and validation across user roles.