Oracle HCM

Configuring the Oracle HCM integration for Veza Lifecycle Management.

Overview

The Veza integration for Oracle HCM enables automated identity lifecycle management with support for identity synchronization and email write-back capabilities. Oracle HCM is designed to serve as a source of identity for Lifecycle Management workflows.

Action Type
Description
Supported

SOURCE_OF_IDENTITY

Oracle HCM provides worker data as input for identity lifecycle policies

EMAIL_WRITE_BACK

Writes email addresses from target systems back to Oracle HCM worker records

SYNC_IDENTITIES

Synchronizes identity attributes to Oracle HCM (as target)

CREATE_IDENTITY

Creates new user accounts or worker records

MANAGE_RELATIONSHIPS

Controls entitlements such as group memberships and role assignments

DEPROVISION_IDENTITY

Safely removes or disables access for identities

CREATE_ENTITLEMENT

Creates entitlements such as groups or roles

This document includes steps to enable the Oracle HCM integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.

Enabling Lifecycle Management for Oracle HCM

Prerequisites

  1. You will need administrative access in Veza to configure the integration and appropriate access in Oracle HCM.

  2. Ensure you have an existing Oracle HCM integration in Veza or add a new one for use with Lifecycle Management.

  3. Verify your Oracle HCM integration has completed at least one successful extraction

  4. The Oracle HCM service account requires specific permissions for different operations:

    REST API Permissions (Read-only):

    • /hcmRestApi/resources/11.13.18.05/workers - View worker records

    • /hcmRestApi/resources/11.13.18.05/jobs - View job information

    • /hcmRestApi/resources/11.13.18.05/actionsLOV - View available actions

    SCIM API Permissions:

    • /hcmRestApi/scim/Users - User management endpoint

      • GET: Read user by ID, person number, or username

      • PATCH: Update user email addresses only (write-back functionality)

      • Note: Only email updates are performed; full user creation/deletion not used

    BI Publisher Permissions:

    • Execute reports via the QueryDM interface

    • Access to custom report path (must start with /Custom and end with .xdo)

    • Retrieve CSV-formatted report output

    • Uses same BI Publisher infrastructure as Oracle Fusion Cloud integration.

Important: Oracle HCM integration requires specific report configurations and API access. Ensure your Oracle HCM user account has sufficient privileges to read worker data and update email addresses.

Technical Requirements:

  • Oracle HCM REST API version: 11.13.18.05

  • REST Framework version: 4

  • SCIM 2.0 support for user operations

  • HTTP Basic Authentication

  • Concurrent request limit: 8 (for optimal performance)

Configuration Parameters:

  • url: Oracle HCM instance URL (required)

  • username: Service account username (required)

  • password: Service account password (required)

  • report_path: BI Publisher report path starting with /Custom (required)

  • additional_columns: Comma-separated list of additional CSV columns to extract (optional)

  • identity_mapping: Custom identity mapping configuration (optional)

Configuration Steps

To enable the integration:

  1. In Veza, go to the Integrations overview

  2. Search for or create an Oracle HCM integration

  3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your Oracle HCM data remains current:

  1. Go to Veza Administration > System Settings

  2. In Pipeline > Extraction Interval, set your preferred interval

  3. Optionally, set a custom override for Oracle HCM in the Active Overrides section

To verify the health of the Lifecycle Management data source:

  1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

  2. Search for the integration and click the name to view details

  3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

BI Publisher Report Configuration

Oracle HCM integration relies on BI Publisher reports to extract worker data. The report must be properly configured with specific requirements:

Report Path Requirements

  • Must be an absolute path starting with /Custom

  • Must end with .xdo extension

  • Example: /Custom/HCM/WorkerDataReport.xdo

Required CSV Column Headers

The BI Publisher report must output CSV data with these exact column headers:

Core Required Columns:

  • CORRELATION_ID - Unique worker identifier (required)

  • EMPLOYEE_ID - Employee number/ID (required)

  • FIRST_NAME - Worker's first name (required)

  • LAST_NAME - Worker's last name (required)

  • STATUS - Employment status (must be "ACTIVE" for active workers)

  • START_DATE - Employment start date in YYYY-MM-DD format

Additional Standard Columns:

  • NAME - Full name

  • COMPANY_NAME - Company name

  • PREFERRED_FIRST_NAME - Preferred first name

  • DISPLAY_NAME - Display name

  • CANONICAL_NAME - Canonical name

  • USER_NAME - Username

  • EMAIL - Primary email address

  • PERSONAL_EMAIL - Personal email

  • HOME_LOCATION - Home location

  • LOCATION - Work location

  • COST_CENTER - Cost center code

  • DEPARTMENT_NAME - Department name

  • MANAGER - Manager's correlation ID

  • ACTIVE - Active flag (Y/N)

  • TERM_DATE - Termination date in YYYY-MM-DD format

  • TITLE - Job title

  • EMPLOYEE_TYPE - Employment type (full time, part time, contractor)

Data Format Requirements

  • Date Format: All dates must use YYYY-MM-DD format

  • Employment Status: Must be exactly "ACTIVE" for active workers (case-sensitive)

  • Boolean Values: Use "Y" or "N" for the ACTIVE column

  • Duplicate Records: System handles duplicates by keeping the most recent active record

Supported Actions

Oracle HCM serves as a source for identity information in Lifecycle Management Policies. Based on the implementation configuration, Oracle HCM supports only two specific actions:

Source of Identity

Oracle HCM provides authoritative worker information for identity lifecycle policies:

  • Data Flow: FROM Oracle HCM TO target systems (unidirectional)

  • Purpose: Serves as the authoritative source for worker identity data

  • Scope: Worker records from BI Publisher reports are made available to lifecycle policies

  • Usage: Target systems can query Oracle HCM worker data for provisioning decisions

Available Worker Attributes for Lifecycle Management:

Oracle HCM uses a multi-layer attribute system:

  1. BI Publisher Report Fields: Over 20 fields available for reading worker data (see BI Publisher Report Configuration)

  2. Lifecycle Management Attributes: Only 3 attributes are available for synchronization:

Property
Required
Type
SCIM Mapping
Description
Notes

user_name

Yes

String

userName

Worker username

Primary identifier, required for all operations

email

No

String

emails[0].value

Worker's email address

Can be updated via write-back, single email only

display_name

No

String

displayName

Worker's display name

May experience update delays

Important: The SCIM API only supports these three attributes for write operations. All other worker data from BI Publisher reports is read-only.

Worker Identification Methods

Workers can be identified using multiple approaches:

  • Person Number (Preferred): Extracted from entity ID for most operations

  • Entity ID: Used for direct operations and testing scenarios

  • SCIM User ID: Used specifically for email write-back operations

Email Write-Back

Oracle HCM supports writing email addresses from target systems back to worker records:

  • Direction: Unidirectional - writes email addresses FROM provisioned target systems TO Oracle HCM worker records

  • Method: Uses SCIM PATCH operation to update worker email addresses

  • Worker Identification: Supports both entity ID-based and person number-based worker identification

  • Limitation: Oracle HCM SCIM API supports only one email address per worker record

  • Logic: Only updates if the new email address differs from the existing value

When an email address is created in a target system (such as Exchange or Google Workspace), the write-back action updates the corresponding Oracle HCM worker record with the new email address via the /hcmRestApi/scim/Users endpoint.

Workflow Examples

New Hire Onboarding

Oracle HCM can serve as the source of truth for new hire provisioning workflows:

  1. Worker Added in Oracle HCM: New worker record is created with basic information

  2. Identity Sync: Worker attributes are synchronized to target systems (Active Directory, Okta, etc.)

  3. Email Creation: Corporate email account is created in the target email system

  4. Email Write-Back: The newly created email address is written back to the Oracle HCM worker record

Employee Information Updates

When worker information changes in Oracle HCM:

  1. Attribute Changes: Worker attributes are updated in Oracle HCM (department, title, etc.)

  2. Continuous Sync: Changes are automatically propagated to connected target systems

  3. Consistency Maintenance: All systems maintain consistent worker information

Email Address Provisioning

For workers who need new email addresses:

  1. Email Creation: Target email system creates a new email account

  2. Write-Back Process: Oracle HCM worker record is updated with the new email address via SCIM API

  3. Identity Sync: Updated email information is synchronized across all connected systems

Troubleshooting

Common Configuration Issues

Report Path Errors:

  • Ensure report path starts with /Custom and ends with .xdo

  • Verify the report exists and is accessible

  • Check BI Publisher permissions

Column Mapping Issues:

  • Verify all required column headers are present in CSV output

  • Check column name spelling (case-sensitive)

  • Ensure date columns use YYYY-MM-DD format

Authentication Failures:

  • Verify HTTP Basic Authentication credentials

  • Check user has access to required API endpoints

  • Confirm SCIM permissions for email write-back

Data Processing Problems:

  • STATUS column must contain "ACTIVE" for active workers

  • CORRELATION_ID must be unique for each worker

  • Handle duplicate records appropriately

Email Write-Back Issues:

  • Verify worker exists and is identifiable by person number or entity ID

  • Check SCIM endpoint permissions

  • Only one email address per worker is supported

Last updated

Was this helpful?