ERP Data Access for Integration Users

Introduction

In any real Oracle Fusion ERP implementation, controlling who can access what data is one of the most critical aspects of security design. When we talk about Oracle ERP Cloud-specific data access to the integration user, we are addressing a very practical challenge faced in almost every integration project—how to restrict an integration account to only the required business data.

In Oracle Fusion Cloud (26A), integrations built using Oracle Integration Cloud (OIC Gen 3), REST APIs, or SOAP services typically use a generic integration user. However, without proper data access controls, this user may inadvertently gain access to sensitive data across Business Units, Ledgers, or Legal Entities.

This blog explains how to design and implement data-secure integration users in Oracle ERP Cloud with real-world examples, navigation paths, and consultant-level insights.

What is Oracle ERP Cloud Data Access for Integration Users?

Oracle ERP Cloud uses role-based access control (RBAC) combined with data security policies to govern access. When an integration user invokes APIs, the system evaluates:

• Assigned roles

• Associated data roles

• Defined data security policies

• Context like Business Unit, Ledger, or Reference Data Set

For integration users, this means:

Even if the API is accessible, data visibility depends on data roles and security context.

Key Concept

There are two levels of control:

Key Features of Data Access Control in ERP Cloud

1. Role-Based Access Control (RBAC)

• Users are assigned roles

• Roles define privileges and data access

2. Data Roles

• Combination of:

  • Job Role

  • Data Security Policies

  • Business Unit / Ledger context

3. Security Contexts

• Business Unit

• Ledger

• Legal Entity

• Reference Data Set

4. Integration User Behavior

• APIs respect the same security model as UI users

• No “special bypass” for integrations

Real-World Integration Use Cases

Use Case 1: AP Invoice Integration via OIC

A company integrates invoices from a third-party procurement system.

Requirement:

• Integration user should only create invoices for India Business Unit

Solution:

• Assign a custom data role restricted to India BU

Use Case 2: GL Journal Import

Finance team uploads journals from a legacy system.

Requirement:

• Integration user should only access Primary Ledger

Solution:

• Create data role scoped to specific Ledger

Use Case 3: Supplier Sync via REST API

Suppliers are synced from external vendor management system.

Requirement:

• Integration user should only access specific Procurement BU

Solution:

• Restrict via Procurement Business Unit data role

Architecture / Technical Flow

Here is how data access works during integration:

1. OIC calls ERP API using integration user credentials

2. ERP authenticates user

3. System checks assigned roles

4. Data role filters records based on:

   • BU / Ledger / Legal Entity

5. API returns only allowed data

Important Insight

Even if your payload is correct:

If data role is missing → API may return empty response or authorization error

Prerequisites

Before configuring data access:

• Integration user created in ERP

• Required job roles identified (e.g., Accounts Payable Manager)

• Business Units / Ledgers already configured

• Access to Security Console

• Access to Setup and Maintenance

Step-by-Step Configuration

Step 1 – Identify Required Job Role

Example:

• Accounts Payable Manager

• General Accountant

• Procurement Agent

Step 2 – Create Custom Role (Optional but Recommended)

Navigation:

Navigator → Tools → Security Console

Steps:

1. Click Roles

2. Search for base role (e.g., Accounts Payable Manager)

3. Click Copy Role

4. Rename:

   • Example: XX_AP_INTEGRATION_ROLE

Why?

• Avoid modifying seeded roles

• Maintain upgrade safety

Step 3 – Create Data Role

Navigation:

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

Steps:

1. Click Create Data Role

2. Select:

   • Base Role: XX_AP_INTEGRATION_ROLE

3. Assign Data Security Context:

4. Save

Step 4 – Assign Data Role to Integration User

Navigation:

Navigator → Tools → Security Console

Steps:

1. Search User → Integration User

2. Go to Roles

3. Add:

   • Newly created Data Role

4. Save

Step 5 – Verify Role Hierarchy

Ensure:

• Job Role → Privileges

• Data Role → Context applied

Step 6 – Assign Required Privileges (If Needed)

Sometimes APIs require additional privileges:

Example:

• Manage Payables Invoices

• Import Journals

Add via:

Security Console → Role → Add Privilege

Testing the Setup

Scenario: AP Invoice Integration

Test Payload (via OIC or Postman):

• Create invoice for India BU

Expected Result

• Invoice created successfully

Validation Checks

Negative Test

Try creating invoice for another BU:

Expected:

• Error or rejection

Common Implementation Challenges

1. API Works but Returns No Data

Cause:

• Missing data role

Fix:

• Assign correct BU / Ledger in data role

2. ORA-Authorization Errors

Cause:

• Missing privilege in job role

Fix:

• Add required functional privilege

3. Too Much Data Exposure

Cause:

• Using seeded roles without restriction

Fix:

• Always create custom roles with scoped data

4. Multiple BUs Not Working

Cause:

• Incorrect data role configuration

Fix:

• Add multiple BUs in security profile

Best Practices from Real Implementations

1. Always Use Dedicated Integration Users

Avoid using personal or admin accounts.

2. Create Separate Roles per Integration

Example:

3. Restrict to Minimum Required Data

Principle of least privilege:

• Only required BU / Ledger

• No global access unless needed

4. Avoid Seeded Roles in Production

Always:

• Copy

• Customize

• Assign

5. Document Security Design

Maintain:

• Role mapping

• Data role definitions

• API usage

6. Test with Real Business Data

Many issues appear only with:

• Multi-BU setups

• Multi-ledger configurations

7. Align with OIC Integration Design

Ensure:

• Integration payload uses correct BU

• Matches security context

Summary

Designing Oracle ERP Cloud-specific data access to the integration user is not just a security task—it is a critical integration design component. Without proper data scoping:

• APIs may fail silently

• Sensitive data may be exposed

• Compliance risks increase

By leveraging:

• Custom roles

• Data roles

• Security profiles

You can ensure that integration users behave exactly like controlled business users, accessing only the required data.

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

FAQs

1. Can an integration user access all data by default?

No. Access depends on assigned roles and data roles. Without proper configuration, access may be restricted or overly broad.

2. What is the difference between job role and data role?

• Job Role → Defines what actions can be performed

• Data Role → Defines on which data those actions apply

3. Can one integration user be used for multiple integrations?

Yes, but not recommended. It’s better to use separate users or roles per integration for better control and troubleshooting.