---
# === IDENTITY ===
id: business/erp-integration/oracle-erp-cloud-data-security-api/2026
canonical_question: "How do Oracle ERP Cloud data security policies affect API responses for integration users?"
aliases:
  - "Why is my Oracle Fusion REST API returning incomplete data?"
  - "Oracle ERP Cloud data roles and API response filtering"
  - "Oracle Fusion Cloud data security policies for integration users"
  - "How to troubleshoot missing records in Oracle ERP Cloud API responses"
entity_type: erp_integration
domain: business > erp-integration > oracle-erp-cloud-data-security-api
region: global
jurisdiction: global
temporal_scope: 2025-2026

# === SYSTEM PROFILE ===
systems:
  - name: "Oracle Fusion Cloud ERP"
    vendor: "Oracle"
    version: "25A-25D (Release 25)"
    edition: "All editions"
    deployment: cloud
    api_surface: "REST (fscmRestApi)"

# === VERIFICATION ===
last_verified: 2026-03-09
confidence: 0.85
version: 1.0
first_published: 2026-03-09

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: volatile
  last_breaking_change: "25A — data security REST endpoints added for Financials"
  next_review: 2026-09-05
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "Integration users are denied all data by default — every data dimension must be explicitly granted"
  - "Data security policies use SQL WHERE-clause conditions that filter API responses at the database layer — no bypass via REST parameters"
  - "Data roles must combine a job role AND a security profile to grant data access — a job role alone provides zero data visibility"
  - "Business unit, ledger, and legal entity access are independent dimensions — granting one does not cascade to others"
  - "Data access sets for General Ledger must be assigned separately from business unit access for Payables/Receivables"
  - "Security context changes require user session refresh — cached tokens retain old security scope until re-authenticated"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs Oracle HCM Cloud data security (person/org security profiles)"
    use_instead: "Search knowledgelib.io for Oracle HCM Cloud security profiles — no dedicated unit yet"
  - condition: "User needs Oracle ERP Cloud REST API authentication setup"
    use_instead: "business/erp-integration/oracle-erp-cloud-rest-api-capabilities/2026"
  - condition: "User needs Oracle Integration Cloud (OIC) adapter configuration"
    use_instead: "business/erp-integration/oracle-oic-deep-dive/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: integration_pattern
    question: "What integration pattern do you need?"
    type: choice
    options:
      - "real-time sync (individual records, <1s latency)"
      - "batch/bulk (scheduled, high volume)"
      - "event-driven (webhook, CDC, platform events)"
      - "file-based (CSV/XML import/export)"
  - key: data_volume
    question: "What's your daily data volume?"
    type: choice
    options:
      - "< 1,000 records/day"
      - "1,000-100,000 records/day"
      - "> 100,000 records/day"
  - key: direction
    question: "What's the data flow direction?"
    type: choice
    options:
      - "inbound (writing to this ERP)"
      - "outbound (reading from this ERP)"
      - "bidirectional sync"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/erp-integration/oracle-erp-cloud-data-security-api/2026"
suggested_citation: "Source: knowledgelib.io -- AI Knowledge Library (verified 2026-03-09)"

# === RELATED UNITS ===
related_kos:
  depends_on:
    - id: "business/erp-integration/oracle-erp-cloud-rest-api-capabilities/2026"
      label: "Oracle ERP Cloud (Fusion) REST API capabilities — 499-record pagination, expand vs fields, CRUD"
  solves:
    - id: "business/erp-integration/invoice-to-pay-ap-automation/2026"
      label: "Multi-ERP invoice-to-pay AP automation playbook (OCR capture, 3-way match, ERP posting, payment gateways) with an Oracle ERP Cloud path, not an Oracle-only guide"
  alternative_to:
    - id: "business/erp-integration/oracle-erp-cloud-fbdi-import/2026"
      label: "Oracle ERP Cloud FBDI file-based import — 250MB/100K limits, UCM upload, two-phase ESS job scheduling"
  often_confused_with:
    - id: "business/erp-integration/oracle-erp-cloud-integration-security-roles/2026"
      label: "Oracle ERP Cloud security roles — function security privileges (what actions) vs data security policies (which data), minimum-privilege design"

# === SOURCES ===
sources:
  - id: src1
    title: "Data Security — Oracle Fusion Cloud Applications Common Features"
    author: Oracle
    url: https://docs.oracle.com/en/cloud/saas/applications-common/25d/faser/data-security.html
    type: official_docs
    published: 2025-10-01
    reliability: authoritative
  - id: src2
    title: "Fusion API Duty Roles, Privileges, and Data Security"
    author: Oracle
    url: https://docs.oracle.com/en/cloud/saas/field-service/famca/c-mca-fusion-api-duty-roles-privileges-data-security.html
    type: official_docs
    published: 2025-06-01
    reliability: authoritative
  - id: src3
    title: "REST API for Oracle Fusion Cloud Financials — Quick Start"
    author: Oracle
    url: https://docs.oracle.com/en/cloud/saas/financials/25a/farfa/Quick_Start.html
    type: official_docs
    published: 2025-02-01
    reliability: authoritative
  - id: src4
    title: "Enforcing Role-Based Data Security over HCM Cloud REST API"
    author: Oracle A-Team
    url: https://www.ateam-oracle.com/post/enforcing-role-based-data-security-over-hcm-cloud-rest-api-a-worked-example
    type: technical_blog
    published: 2024-08-15
    reliability: high
  - id: src5
    title: "Oracle Fusion Security: Roles, Privileges and Data Access"
    author: Hexstream
    url: https://www.hexstream.com/tech-corner/oracle-fusion-security-roles-privileges-and-data-access
    type: technical_blog
    published: 2025-01-10
    reliability: moderate_high
  - id: src6
    title: "Introduction to Fusion Applications Roles Concepts"
    author: Oracle A-Team
    url: https://www.ateam-oracle.com/post/introduction-to-fusion-applications-roles-concepts
    type: technical_blog
    published: 2024-05-20
    reliability: high
  - id: src7
    title: "GET Data Assignments by User and Role — Oracle Financials REST API"
    author: Oracle
    url: https://docs.oracle.com/en/cloud/saas/financials/25a/farfa/op-datasecurities-get.html
    type: official_docs
    published: 2025-02-01
    reliability: authoritative
---

# Oracle ERP Cloud Data Security Policies: API Impact for Integration Users

## TL;DR

- **Bottom line**: Oracle ERP Cloud data security policies silently filter REST API responses at the database layer -- an integration user missing a data role or security context assignment will receive empty result sets or partial data with no error, making this the #1 cause of "missing data" in Oracle ERP Cloud integrations.
- **Key limit**: Users are denied access to all data by default; every data dimension (business unit, ledger, legal entity, inventory org) must be explicitly granted through data roles combining job roles with security profiles.
- **Watch out for**: A job role alone grants functional access (menu/page visibility) but zero data visibility -- you must pair it with a data role or explicit data access set assignment to see any records via API.
- **Best for**: Diagnosing incomplete API responses, configuring integration users for cross-business-unit data access, and understanding why Financials REST API endpoints return fewer records than expected.
- **Authentication**: Multi Token Over SSL (Basic Auth, SAML 2.0 Bearer, or JWT over HTTPS); authentication succeeds even when data security blocks all records -- you get HTTP 200 with empty results, not a 401/403. [src3]

## System Profile

This card covers Oracle Fusion Cloud ERP (Releases 25A through 25D, covering 2025-2026) and how its data security framework affects REST API responses for integration users. The data security model applies uniformly across all Oracle Fusion Cloud ERP modules including Financials (GL, AP, AR, FA), Procurement, Project Portfolio Management, and Supply Chain Management. The REST API surface is the fscmRestApi, which is the primary programmatic interface for all ERP data operations.

This card does NOT cover Oracle HCM Cloud security profiles (which use a different person/organization security model), Oracle Integration Cloud (OIC) adapter-level security, or Oracle Cloud Infrastructure (OCI) IAM policies. On-premise E-Business Suite data security is architecturally different and not applicable here.

| Property | Value |
|---|---|
| **Vendor** | Oracle |
| **System** | Oracle Fusion Cloud ERP (Release 25A-25D) |
| **API Surface** | REST (fscmRestApi) |
| **Current API Version** | 11.13.18.05 (Release 25A) |
| **Editions Covered** | All editions (data security is consistent across editions) |
| **Deployment** | Cloud |
| **API Docs URL** | [Oracle Financials REST API](https://docs.oracle.com/en/cloud/saas/financials/25a/farfa/Quick_Start.html) |
| **Status** | GA |

## API Surfaces & Capabilities

Oracle ERP Cloud exposes multiple API surfaces. Data security policies apply to all of them -- REST, SOAP, FBDI file imports, and BIP report extracts all respect the same underlying data security grants. [src1]

| API Surface | Protocol | Best For | Data Security Enforced? | Security Mechanism | Notes |
|---|---|---|---|---|---|
| REST (fscmRestApi) | HTTPS/JSON | Individual CRUD, queries, real-time operations | Yes | Database-layer WHERE clauses via ADF security | Primary integration surface |
| SOAP (composite services) | HTTPS/XML | Legacy integrations, specific complex operations | Yes | Same OPSS/data security framework | Being phased out for most use cases |
| FBDI (File-Based Data Import) | CSV via UCM | Bulk imports, data migration | Partially | Validates on write; import user needs target BU access | Bypasses read-side filtering |
| BIP Reports | HTTPS/XML-CSV | Bulk data extracts, scheduled reporting | Yes | Report data security parameters filter output | Ledger/BU parameters required |
| Business Events | REST/webhook | Event-driven, outbound notifications | Yes | Events only fire for data the triggering user can access | Event payload scope matches user scope |

## Rate Limits & Quotas

### Per-Request Limits

| Limit Type | Value | Applies To | Notes |
|---|---|---|---|
| Default page size | 25 records | REST API collection responses | Configurable via `limit` parameter |
| Max page size | 500 records | REST API collection responses | Use `offset` for pagination beyond 500 |
| Max request body size | 50 MB | REST API POST/PATCH | Split larger payloads |
| Max concurrent REST sessions | No published hard limit | Per-tenant | Oracle throttles at infrastructure layer |
| FBDI file size | 250 MB | File-Based Data Import | Split across multiple files for larger loads |

[src3]

### Rolling / Daily Limits

| Limit Type | Value | Window | Notes |
|---|---|---|---|
| REST API calls | No published per-day cap | N/A | Oracle uses fair-use throttling rather than hard daily caps |
| FBDI import jobs | No published cap | N/A | Throttled by ESS (Enterprise Scheduler Service) queue depth |
| BIP report executions | Configurable by admin | Per-tenant | Default concurrent report limit is configurable |
| Concurrent long-running requests | Managed by ESS | Per-tenant | ESS work manager thread pool limits concurrency |

[src3]

### Data Security Processing Overhead

| Security Dimension | Performance Impact | Mitigation |
|---|---|---|
| Business unit grants (< 5 BUs) | Negligible | Standard configuration |
| Business unit grants (> 20 BUs) | Noticeable query slowdown | Use "All Values" grant where audit allows |
| Cross-module security joins | Moderate (ledger + BU + legal entity) | Pre-build data roles with combined grants |
| Custom data security policies with complex SQL | Significant | Avoid subqueries in instance set conditions; use indexed columns |

## Authentication

Data security is independent of authentication method. All three supported auth flows respect the same data security policies. [src3]

| Flow | Use When | Token Lifetime | Refresh? | Notes |
|---|---|---|---|---|
| Basic Auth over SSL | Testing, simple integrations | Session-based (default 8h) | No | Easiest to set up; credentials in every request |
| SAML 2.0 Bearer Token | Enterprise SSO, federated identity | Configurable (typically 1-2h) | Yes (via IdP) | Requires SAML IdP configuration |
| JWT Token | Server-to-server, modern integrations | Configurable (typically 1-2h) | New JWT per request | Recommended for production integrations |
| OAuth 2.0 (via OCI IAM) | Cloud-native integrations | Access: 1h, Refresh: configurable | Yes | Requires OCI IAM domain federation with Fusion |

[src3]

### Authentication Gotchas

- Authentication succeeds even when data security blocks ALL data -- you get HTTP 200 with an empty `items` array, not a 401 or 403. This is the most common misdiagnosis: teams assume an auth problem when the issue is missing data security grants. [src1]
- Basic Auth credentials are tied to a specific Fusion user -- the user's data roles determine what the API returns, NOT the authentication method. Switching from Basic to JWT does not change data visibility unless you also change the underlying user. [src3]
- Session timeout can be changed by the Fusion administrator -- do not hardcode session duration assumptions. Use the response header `Set-Cookie` to detect session validity. [src3]

## Constraints
<!-- Agents: read this section before recommending any integration approach from this unit.
     These are hard constraints that must not be violated. -->

- **Default-deny model**: Users are denied access to all data by default. Every business unit, ledger, legal entity, and inventory organization must be explicitly granted through data roles or data access set assignments. [src1]
- **Database-layer enforcement**: Data security policies generate SQL WHERE clauses that are injected at the ADF (Application Development Framework) database access layer. There is no REST API parameter, header, or flag to bypass or override data security filtering. [src1]
- **Job role != data access**: A job role (e.g., Accounts Payable Manager) grants functional privileges (which pages/actions the user can access). A data role inherits the job role and adds a security profile that restricts which DATA the user sees. Assigning only the job role gives the user access to the AP screens but zero AP data. [src5]
- **Independent security dimensions**: Business unit access, ledger access (via data access sets), legal entity access, and inventory organization access are separate security dimensions. Granting BU access does not automatically grant the corresponding ledger or legal entity. [src1]
- **No cascading grants**: Granting access to a parent organization does not cascade to child organizations. Each organizational unit in each security dimension must be individually granted or use an "All Values" grant. [src1]
- **Session-scoped security**: Data security grants are evaluated at session creation. Changes to data roles require the user to log out and back in (or for the API: obtain a new session/token) before the new grants take effect. [src4]

## Integration Pattern Decision Tree

```
START -- Integration user gets empty/incomplete data from Oracle ERP Cloud REST API
|
+-- Is authentication succeeding? (HTTP 200 returned?)
|   +-- NO (401/403) --> Fix authentication credentials; this is NOT a data security issue
|   +-- YES (200 with empty or partial results) --> Data security filtering is the cause
|       |
|       +-- Check 1: Does the integration user have a DATA ROLE (not just a job role)?
|       |   +-- NO --> Create a data role that inherits the job role + security profile
|       |   +-- YES --> Continue
|       |
|       +-- Check 2: Does the data role include the correct security context assignments?
|       |   +-- For Financials (AP/AR):
|       |   |   +-- Business Unit assigned? (Setup > Security > Data Access)
|       |   |   +-- Ledger assigned via Data Access Set?
|       |   |   +-- Legal Entity assigned?
|       |   +-- For Procurement:
|       |   |   +-- Procurement Business Unit assigned?
|       |   |   +-- Requisitioning Business Unit assigned?
|       |   +-- For Inventory/SCM:
|       |   |   +-- Inventory Organization assigned?
|       |   |   +-- Manufacturing Plant assigned?
|       |   +-- NO --> Add missing security context values
|       |   +-- YES --> Continue
|       |
|       +-- Check 3: Has the user session been refreshed after grant changes?
|       |   +-- NO --> Force new session (re-authenticate API user)
|       |   +-- YES --> Continue
|       |
|       +-- Check 4: Are there custom data security policies with restrictive conditions?
|       |   +-- YES --> Review instance set SQL WHERE clauses in Security Console
|       |   +-- NO --> Check for module-specific feature opt-in requirements
|       |
|       +-- Check 5: Is the data visible in the UI when logged in as the integration user?
|           +-- NO --> The data security configuration is the issue (fix in Security Console)
|           +-- YES --> There may be REST API-specific privilege requirements (check API duty roles)
```

## Quick Reference

### Data Security Components and Their Relationships

| Component | Definition | Scope | API Impact |
|---|---|---|---|
| **Privilege** | Single action on a business object (e.g., "View AP Invoice") | Per-object/action | Determines which CRUD operations succeed |
| **Duty Role** | Bundle of related privileges (e.g., "AP Invoice Inquiry") | Per-module | Must include REST API-specific duty roles for API access |
| **Job Role** | Business role with multiple duty roles (e.g., "Accounts Payable Manager") | Cross-module | Grants functional access but NOT data access alone |
| **Data Role** | Job role + security profile (e.g., "AP Manager - US BU") | Data-scoped | Controls which records API responses include |
| **Security Profile** | Defines which data a role can see (e.g., "US Business Unit Only") | Per-dimension | WHERE-clause generator for DB queries |
| **Data Access Set** | GL-specific: which ledgers a user can access | GL module | Required separately from BU access for GL API calls |
| **Security Context** | Category of securable values (e.g., "Business Unit", "Ledger") | Per-module | Each context is an independent filter dimension |
| **Instance Set** | SQL condition defining which records match (e.g., BU_ID IN (1001, 1002)) | Per-grant | Directly translates to API response filtering |
| **Grant** | Authorization linking role + privilege + instance set | Per-user/role | The actual enforcement mechanism |

### Security Context Dimensions by Module

| Module | Security Context | Typical Grant | API Resource Affected |
|---|---|---|---|
| General Ledger | Data Access Set (Ledger) | Specific ledgers or "All Ledgers" | /journals, /accountingPeriods, /generalLedger |
| Accounts Payable | Business Unit | Specific BUs or "All BUs" | /invoices, /payments, /suppliers |
| Accounts Receivable | Business Unit | Specific BUs or "All BUs" | /receivablesInvoices, /receipts |
| Fixed Assets | Asset Book | Specific books | /assets, /assetBooks |
| Procurement | Procurement BU + Requisitioning BU | Specific BUs | /purchaseOrders, /requisitions |
| Inventory | Inventory Organization | Specific orgs | /inventoryItems, /inventoryTransactions |
| Project | Project Organization | Specific orgs | /projects, /projectTasks |

[src1, src2, src5]

## Step-by-Step Integration Guide

### 1. Verify integration user's current security assignments

Query the data securities REST endpoint to see what access the integration user currently has. [src7]

```bash
# Input:  Integration user credentials, Fusion Cloud base URL
# Output: JSON listing all data security assignments for the user

curl -u "INTEGRATION_USER:password" \
  -X GET "https://your-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/dataSecurities?q=UserName=INTEGRATION_USER" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json"
```

**Verify**: Check that the response `items` array contains entries for each required security context (BusinessUnit, Ledger, LegalEntity). If `items` is empty, the user has no data access grants.

### 2. Assign the correct job role with API duty roles

Navigate to Security Console and assign the job role that includes the necessary REST API duty roles. For Financials, ensure the role includes API-specific duties. [src2]

```
Navigation: Setup and Maintenance > Security Console > Users
1. Search for integration user
2. Click "Edit" > "Roles" tab
3. Add required job role (e.g., "Accounts Payable Manager")
4. Verify the job role includes REST API duty roles:
   - "Financials REST Services" duty role
   - Module-specific duty roles (e.g., "AP Invoice REST Services")
```

**Verify**: In Security Console > Roles > search for the job role > "Privilege" tab, confirm REST-related privileges are present.

### 3. Create or assign a data role with security profile

The data role pairs the job role with a security profile to scope data visibility. [src1, src5]

```
Navigation: Setup and Maintenance > Manage Data Access for Users
1. Search for the integration user
2. Click "Add Data Access"
3. Select the role (e.g., "Accounts Payable Manager")
4. Select the security context (e.g., "Business Unit")
5. Select the value(s) (e.g., "US Operations BU", "EU Operations BU")
6. Save
```

**Verify**: `curl` the invoices endpoint and confirm records from the assigned BU now appear.

### 4. Assign Data Access Sets for General Ledger

GL access requires separate Data Access Set assignment -- BU grants do not cascade to ledger access. [src1]

```
Navigation: Setup and Maintenance > Manage Data Access Set Assignments
1. Search for integration user
2. Add data access set (e.g., "US Primary Ledger Access Set")
3. Set access privileges: Read-Only or Read/Write
4. Save
```

**Verify**: Query the journals endpoint -- records from the assigned ledger should now appear:

```bash
curl -u "INTEGRATION_USER:password" \
  -X GET "https://your-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/journals?limit=5" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json"
```

### 5. Force session refresh and validate

Data security changes require a fresh session. Re-authenticate after making grant changes. [src4]

```bash
# Force new session by making a fresh authenticated request
# Previous sessions may cache old security grants

curl -u "INTEGRATION_USER:password" \
  -X GET "https://your-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/invoices?limit=5&fields=InvoiceId,InvoiceNumber,BusinessUnit" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json" \
  -H "Cache-Control: no-cache"
```

**Verify**: Response `items` array contains records with `BusinessUnit` values matching your assigned BUs. If empty, recheck Steps 2-4.

## Code Examples

### Python: Diagnose data security grants for an integration user

```python
# Input:  Oracle Fusion Cloud base URL, integration user credentials
# Output: Dictionary of security context assignments per module

import requests
from requests.auth import HTTPBasicAuth

FUSION_BASE = "https://your-instance.fa.us2.oraclecloud.com"
API_PATH = "/fscmRestApi/resources/11.13.18.05"
USERNAME = "INTEGRATION_USER"
PASSWORD = "secure_password"

def get_data_security_assignments(username):
    """Retrieve all data security assignments for a user."""
    url = f"{FUSION_BASE}{API_PATH}/dataSecurities"
    params = {"q": f"UserName={username}", "limit": "500"}
    headers = {
        "Content-Type": "application/vnd.oracle.adf.resourcecollection+json"
    }
    resp = requests.get(
        url, params=params,
        auth=HTTPBasicAuth(USERNAME, PASSWORD),
        headers=headers, timeout=30
    )
    resp.raise_for_status()
    return resp.json().get("items", [])

def diagnose_missing_data(username):
    """Check which security contexts are assigned."""
    assignments = get_data_security_assignments(username)
    contexts = {}
    for a in assignments:
        ctx = a.get("SecurityContext", "Unknown")
        if ctx not in contexts:
            contexts[ctx] = []
        contexts[ctx].append(a.get("SecurityContextValue", "N/A"))
    # Report missing common contexts
    required = ["BusinessUnit", "Ledger", "LegalEntity"]
    for r in required:
        if r not in contexts:
            print(f"WARNING: No {r} assignment found for {username}")
        else:
            print(f"OK: {r} -> {contexts[r]}")
    return contexts

if __name__ == "__main__":
    diagnose_missing_data(USERNAME)
```

### cURL: Quick test for data visibility per module

```bash
# Input:  Valid credentials for the integration user
# Output: Record counts per module to verify data security grants

FUSION_BASE="https://your-instance.fa.us2.oraclecloud.com"
API="$FUSION_BASE/fscmRestApi/resources/11.13.18.05"
AUTH="INTEGRATION_USER:password"

echo "=== AP Invoices ==="
curl -s -u "$AUTH" "$API/invoices?limit=1&totalResults=true" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json" \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(f'Total: {d.get(\"totalResults\",\"N/A\")}')"

echo "=== GL Journals ==="
curl -s -u "$AUTH" "$API/journals?limit=1&totalResults=true" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json" \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(f'Total: {d.get(\"totalResults\",\"N/A\")}')"

echo "=== Purchase Orders ==="
curl -s -u "$AUTH" "$API/purchaseOrders?limit=1&totalResults=true" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json" \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(f'Total: {d.get(\"totalResults\",\"N/A\")}')"

# If any module returns Total: 0, the integration user
# is missing data security grants for that module's security context
```

## Data Mapping

### Security Context to API Resource Mapping

| Security Context | Grant Type | API Resources Filtered | How to Check Assignment |
|---|---|---|---|
| Business Unit (AP) | Manage Data Access for Users | /invoices, /payments, /suppliers | GET /dataSecurities?q=SecurityContext=BusinessUnit |
| Business Unit (AR) | Manage Data Access for Users | /receivablesInvoices, /receipts | GET /dataSecurities?q=SecurityContext=BusinessUnit |
| Data Access Set (GL) | Manage Data Access Set Assignments | /journals, /accountingPeriods, /balances | Separate admin page; not in /dataSecurities |
| Legal Entity | Manage Data Access for Users | /legalEntities, tax-related resources | GET /dataSecurities?q=SecurityContext=LegalEntity |
| Asset Book | Manage Data Access for Users | /assets, /assetBooks | GET /dataSecurities?q=SecurityContext=AssetBook |
| Inventory Organization | Manage Inventory Org Data Access | /inventoryItems, /inventoryTransactions | Separate admin page for SCM |
| Procurement BU | Manage Data Access for Users | /purchaseOrders, /purchaseRequisitions | GET /dataSecurities?q=SecurityContext=ProcurementBU |

[src1, src2, src7]

### Data Type Gotchas

- Business Unit IDs in data security assignments are internal numeric IDs (e.g., 300000001234567), not the human-readable BU name. When comparing assignments to API responses, use the `BusinessUnitId` field, not `BusinessUnit` (display name). [src1]
- Data Access Set assignments for GL are managed through a different admin page than BU assignments and do not appear in the standard /dataSecurities REST endpoint -- you must check them separately. [src1]
- Security context values are case-sensitive in some Oracle Fusion releases. Ensure grant values match exactly what the system stores (typically uppercase for codes, mixed case for names). [src5]

## Error Handling & Failure Points

### Common Error Codes

| Code | Meaning | Cause | Resolution |
|---|---|---|---|
| HTTP 200 + empty items | Data security filtering | User has no grants for the requested data dimension | Add data role / security context assignment |
| HTTP 200 + partial results | Partial data security grants | User has grants for some BUs/ledgers but not all | Add missing security context values |
| HTTP 403 | Functional privilege denied | User lacks the duty role / privilege for this REST resource | Add the required job role with API duty roles |
| HTTP 401 | Authentication failure | Invalid credentials or expired session | Re-authenticate; check password expiry |
| JBO-27122 | SQL data security error | Custom data security policy has invalid SQL in instance set | Fix the instance set WHERE clause in Security Console |
| APJ-1 | Application privilege error | User role missing specific object privilege | Add the missing privilege to the duty/job role |

[src1, src3]

### Failure Points in Production

- **Silent data loss in API responses**: The most dangerous failure mode. API returns HTTP 200 with fewer records than expected because the integration user lacks grants for certain business units. No error, no warning, no indication that records were filtered. Fix: `Compare API totalResults count against a known-good count from a super-user query; alert on discrepancy`. [src1]
- **Data access drift after org restructuring**: When business units are added, merged, or reorganized, integration user data roles are not automatically updated. The new BU data is invisible to existing integrations. Fix: `Create a checklist that includes updating integration user data access whenever organizational changes are made`. [src1]
- **GL journal extraction missing ledgers**: General Ledger data access uses Data Access Sets, which are configured on a separate admin page from the standard "Manage Data Access for Users" page. Integration teams configure BU access but forget the GL-specific Data Access Set. Fix: `Always configure Data Access Sets separately when the integration touches GL data`. [src1]
- **FBDI import succeeds but API read fails**: An integration user can import data via FBDI into a business unit they have write access to, but then cannot read it back via REST API because the read-side data security grant was not configured for that BU. Fix: `Ensure read and write grants match for all data dimensions`. [src2]
- **Security grants not effective after assignment**: Data security changes require session refresh. The integration keeps using a cached session with the old security scope. Fix: `After any security change, invalidate existing API sessions by re-authenticating; do not reuse session cookies`. [src4]
- **Custom data security policy performance degradation**: Custom instance set SQL conditions using non-indexed columns or subqueries cause severe query slowdown on large datasets. Every API call pays the cost. Fix: `Audit custom data security policies for query performance; use indexed columns in WHERE clauses and avoid correlated subqueries`. [src1]

## Anti-Patterns

### Wrong: Granting only a job role and expecting API data access

```
# WRONG -- job role alone gives functional access but zero data visibility
# The integration user can authenticate and call the API, but gets empty results

Setup steps (incorrect):
1. Create integration user
2. Assign job role: "Accounts Payable Manager"
3. Call /invoices API
4. Result: HTTP 200, items: [] (empty -- no error!)
```

### Correct: Grant a data role that combines job role with security profile

```
# CORRECT -- data role = job role + security profile (data dimension)
# The integration user gets data scoped to the assigned business units

Setup steps (correct):
1. Create integration user
2. Assign job role: "Accounts Payable Manager"
3. Navigate to: Manage Data Access for Users
4. Add data access: Role = AP Manager, Context = Business Unit, Value = "US Operations"
5. (This creates/assigns a data role behind the scenes)
6. Call /invoices API
7. Result: HTTP 200, items: [invoices from US Operations BU]
```

### Wrong: Assuming Business Unit access includes Ledger access

```
# WRONG -- BU and Ledger are independent security dimensions
# Granting BU access for AP does NOT grant the corresponding ledger for GL

Steps (incorrect):
1. Assign data access: BU = "US Operations" for AP Manager role
2. Call /journals API (General Ledger)
3. Result: HTTP 200, items: [] (empty -- ledger not granted!)
```

### Correct: Configure each security dimension independently

```
# CORRECT -- grant BU access AND Data Access Set for GL separately

Steps (correct):
1. Assign data access: BU = "US Operations" for AP Manager role
2. ALSO: Manage Data Access Set Assignments > add "US Primary Ledger" for GL role
3. Call /journals API
4. Result: HTTP 200, items: [journal entries from US Primary Ledger]
```

### Wrong: Using a super-user integration account with all-access grants

```
# WRONG -- violates least privilege, creates audit risk,
# and may hit performance issues with large cross-BU data sets

Steps (incorrect):
1. Create integration user "INT_SUPER_USER"
2. Grant "All Values" for every security context
3. Use for all integrations regardless of scope
```

### Correct: Create purpose-specific integration users with scoped access

```
# CORRECT -- each integration has its own user with minimum required access

Steps (correct):
1. Create "INT_AP_US" for US AP integration
   - AP Manager role + BU = "US Operations" only
2. Create "INT_GL_GLOBAL" for GL consolidation
   - GL Accountant role + Data Access Set = "All Ledgers" (justified for consolidation)
3. Create "INT_PO_EU" for EU procurement
   - Buyer role + Procurement BU = "EU Procurement" only
```

## Common Pitfalls

- **Confusing functional security with data security**: Functional security (job roles, duty roles, privileges) controls WHICH screens and actions a user can access. Data security (data roles, security profiles, instance sets) controls WHICH records they can see. Both must be configured correctly. The API equivalent: functional security determines whether a 200 or 403 is returned; data security determines whether the 200 has data in it. Fix: `Always configure both functional AND data security for integration users`. [src1, src5]
- **Not testing with the integration user account**: Developers test the API with their own admin account (which has broad access) and then deploy using the integration user (which has restricted access). The integration works in dev but fails in production. Fix: `Always test API calls using the actual integration user credentials, never with a personal admin account`. [src4]
- **Forgetting to refresh sessions after security changes**: Data security grants are evaluated at session creation time. Changing grants while a session is active has no effect until the session is refreshed. Fix: `After modifying data access, always re-authenticate (obtain new session cookie or token) before testing`. [src4]
- **Ignoring cross-module security dependencies**: Some operations span modules (e.g., creating an AP invoice with GL distribution). The integration user needs data access grants for BOTH the AP business unit AND the GL data access set. Missing either one causes partial failures. Fix: `Map all security dimensions touched by each integration flow and grant all of them`. [src1]
- **Using "All Values" grants without business justification**: Granting "All Values" for a security context bypasses data security for that dimension. While convenient, it creates audit findings and SOX compliance risks. Fix: `Document business justification for every "All Values" grant; use specific value grants where possible`. [src5]
- **Not monitoring for organizational changes**: When new business units, ledgers, or inventory orgs are created, existing integration users do not automatically receive access. This causes silent data gaps. Fix: `Integrate security access reviews into the organizational change management process`. [src1]

## Diagnostic Commands

```bash
# Check integration user's data security assignments
curl -s -u "INT_USER:password" \
  "https://your-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/dataSecurities" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json" \
  | python3 -m json.tool

# Test AP invoice visibility (should return records if BU access granted)
curl -s -u "INT_USER:password" \
  "https://your-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/invoices?limit=1&totalResults=true" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json"

# Test GL journal visibility (requires separate Data Access Set)
curl -s -u "INT_USER:password" \
  "https://your-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/journals?limit=1&totalResults=true" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json"

# Verify which business units the user can see via BU resource
curl -s -u "INT_USER:password" \
  "https://your-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/businessUnits?limit=500&totalResults=true" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json"

# Describe an API resource to check available fields and privileges
curl -s -u "INT_USER:password" \
  "https://your-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/invoices/describe" \
  -H "Content-Type: application/vnd.oracle.adf.resourcecollection+json"
```

## Version History & Compatibility

| Release | Date | Status | Data Security Changes | Notes |
|---|---|---|---|---|
| 25D | 2025-11 | Current | Enhanced data sovereignty controls for EPM | AI analytics for security audit |
| 25C | 2025-08 | Supported | No breaking changes | Minor security UI improvements |
| 25B | 2025-05 | Supported | No breaking changes | — |
| 25A | 2025-02 | Supported | Data securities REST endpoint added for Financials | First release with programmatic security query |
| 24D | 2024-11 | Supported | Improved security context management UI | — |
| 24C | 2024-08 | Supported | No breaking changes | — |

[src1, src3]

### Deprecation Policy

Oracle Fusion Cloud ERP follows a continuous delivery model with quarterly releases (A, B, C, D). Data security APIs and policies are additive -- new security contexts may be introduced but existing ones are not removed. Oracle provides at least one release cycle (3 months) notice before any security-related behavioral changes. Custom data security policies are customer-managed and not affected by Oracle's release cycle. [src1]

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| Integration user returns empty API results despite valid authentication | User gets HTTP 401/403 (authentication/authorization error) | Standard auth troubleshooting -- check credentials and functional roles |
| Need to scope integration data access to specific business units | Need to control which REST endpoints are accessible | Functional security (job roles and API duty roles) |
| Configuring a new integration user for cross-module data access | Setting up Oracle Integration Cloud adapter connections | OIC adapter security configuration |
| Auditing what data an existing integration can see vs what it should see | Troubleshooting REST API performance issues unrelated to security | API performance tuning (pagination, field selection) |
| Organizational restructuring requires updating integration data scope | Implementing row-level security in the target/consuming system | Target system's own security framework |

## Important Caveats

- Data security policy enforcement is consistent across all Oracle Fusion Cloud ERP editions -- there are no edition-specific differences in how data security filters API responses.
- Sandbox environments have separate security configurations from production. Data access grants configured in production do not automatically replicate to sandbox instances. Always verify integration user security in each environment.
- Data security policies generate SQL WHERE clauses at runtime. Complex custom policies with non-indexed conditions can cause significant performance degradation on high-volume API calls -- this effect compounds with the number of security contexts evaluated.
- The /dataSecurities REST endpoint (introduced in Release 25A) returns BU and other context assignments but does NOT return Data Access Set assignments for GL. Those must be checked through the Manage Data Access Set Assignments UI page or via BIP report.
- Oracle's quarterly release cycle may introduce new security contexts for new modules or features. Integration users may need additional grants when new modules are enabled. Always review release notes for security-related changes.

## Related Units
<!-- Generated from related_kos frontmatter -->

- [Oracle ERP Cloud REST API capabilities and authentication](/business/erp-integration/oracle-erp-cloud-rest-api/2026)
- [Oracle HCM Cloud security profiles for person/org data](/business/erp-integration/oracle-hcm-cloud-security-profiles/2026)
- [Oracle AP automation integration playbook](/business/erp-integration/oracle-erp-cloud-ap-automation/2026)
- [Oracle FBDI file-based import](/business/erp-integration/oracle-erp-cloud-file-based-import/2026)
- [Oracle functional security (menu/page access)](/business/erp-integration/oracle-erp-cloud-functional-security/2026)
