Fusion HCM BI Access Control

Fusion HCM BI Report Access Control: A Practical Consultant Guide

When working on Fusion HCM BI Report Access Control, one of the most common challenges consultants face is ensuring the right users see the right data—no more, no less. In real-world implementations, this is not just a technical requirement but a compliance necessity, especially in HR systems where sensitive employee data is involved.

This guide is written from a hands-on consultant perspective, aligned with Oracle Fusion Cloud 26A practices, and will walk you through how to design, configure, and test BI report security effectively.

What is BI Report Access Control in Fusion HCM?

BI Report Access Control refers to the mechanism used to restrict or grant access to reports and data within Oracle Transactional Business Intelligence (OTBI) and BI Publisher (BIP).

In Fusion HCM, access control works at multiple layers:

A key understanding:
Even if a user can open a report, data security roles determine what data they see.

Key Features of BI Report Access Control

1. Role-Based Security Model

Access is controlled through:

• Job Roles
• Abstract Roles
• Data Roles

2. BI Catalog Permissions

Reports and folders are secured via:

• Read
• Write
• Execute

3. Data Security Policies

Defines:

• Business Unit access
• Legal Entity access
• Department restrictions

4. Integration with HCM Security Profiles

Security profiles (Person, Department, BU) directly influence report output.

5. OTBI + BIP Unified Security Approach

Though technically different:

• OTBI → real-time analytics
• BI Publisher → formatted reports
  Both rely on role-based security.

Real-World Business Use Cases

Use Case 1: HR Manager Access Restriction

An HR Manager should:

• View employee reports only for their department
• Not access salary data of other departments

Use Case 2: Payroll Confidential Reports

Payroll reports must be restricted to:

• Payroll Admin role only
• No access to HR generalists

Use Case 3: Global vs Local HR Access

• Global HR → full access
• Country HR → restricted by Legal Employer

Architecture / Technical Flow

In real projects, BI report access works like this:

1. User logs into Fusion
2. System identifies assigned roles
3. BI Catalog checks:
   • Does user have access to report?
4. Data Security kicks in:
   • Filters data based on security profiles
5. Report output generated

Prerequisites

Before configuring BI access control, ensure:

• Required Job Roles are defined
• Data Roles are created with:
  • Business Unit
  • Legal Employer
• Security Profiles configured:
  • Person Security
  • Department Security
• BI duty roles available:
  • BI Consumer Role
  • BI Author Role (if needed)

Step-by-Step Configuration in Oracle Fusion

Step 1 – Identify the Report

Navigation:
Navigator → Tools → Reports and Analytics

• Locate report under:

   

  Shared Folders → Custom → HCM Reports

   

Step 2 – Set BI Catalog Permissions

1. Click More → Permissions
2. Add Role:
   • Example: HR_MANAGER_JOB_ROLE
3. Assign:
   • Read
   • Execute

Important Tip:
Never give “Write” access in production unless required.

Step 3 – Verify Role Mapping

Navigation:
Navigator → Tools → Security Console

• Search for role
• Confirm:
  • Role hierarchy
  • Assigned duty roles

Step 4 – Configure Data Role

Navigation:
Navigator → Setup and Maintenance
Search Task: Manage Data Roles and Security Profiles

• Create Data Role:
  • Job Role: HR Manager
  • Business Unit: India BU
  • Security Profile: Department-based

Step 5 – Assign Role to User

Navigation:
Navigator → My Client Groups → Person Management

• Open user record
• Add Role:
  • HR Manager Data Role

Step 6 – Validate BI Duty Roles

Ensure role includes:

• BI Consumer Role
• Required HCM reporting duties

Testing the Setup

Test Scenario

User: HR Manager (India)

Steps

1. Login as HR Manager
2. Navigate:
   Tools → Reports and Analytics
3. Run report:
   • Employee Details Report

Expected Results

Common Implementation Challenges

1. Report Visible but No Data

Cause: Missing data security
Fix: Check security profiles

2. User Cannot See Report

Cause: Missing catalog permission
Fix: Assign role at folder level

3. Excessive Data Access

Cause: Broad data role
Fix: Restrict BU/Department

4. OTBI vs BIP Confusion

• OTBI → uses subject area security
• BIP → uses SQL/data model

Best Practices from Real Projects

1. Always Use Folder-Level Security

Instead of securing individual reports:

• Secure parent folder

2. Avoid Giving BI Administrator Role

This exposes:

• All reports
• All data

3. Design Data Roles Carefully

Separate:

• Global roles
• Local roles

4. Test with Real User Accounts

Never rely only on admin testing.

5. Document Security Design

Include:

• Role mapping
• Data restrictions
• Report access matrix

Expert Consultant Tips

• Combine data roles + catalog security for full control
• Use naming conventions:
  • HR_INDIA_MANAGER_ROLE
• Always validate:
  • Legal Employer access
  • Department hierarchy

Summary

Fusion HCM BI Report Access Control is not just about giving access—it’s about controlling visibility with precision.

A successful implementation requires:

• Proper role design
• Strong data security configuration
• Thorough testing

When done correctly, it ensures:

• Compliance
• Data confidentiality
• Better user experience

For deeper understanding, refer to Oracle official documentation:
https://docs.oracle.com/en/cloud/saas/index.html

FAQs

1. Why can a user see a report but no data?

Because data security roles are missing or restricted, even though catalog access is granted.

2. What is the difference between OTBI and BI Publisher security?

• OTBI → Subject area + role-based filtering
• BIP → Data model + SQL-level filtering

3. Can we restrict reports by department?

Yes, using Department Security Profiles in data roles.