Oracle HCM (platform)
Oracle Fusion Cloud HCM is the worker and position system of record on the permanent-hiring channel, and holds contingent workers as a worker type alongside employees. Its REST surface (hcmRestApi) exposes positions, jobs, departments, locations and workers, plus job requisitions where Oracle Recruiting is licensed, with tenant-configured Descriptive Flexfields (DFFs) exposed as child resources. composerID publishes the decision as a Position through the positions resource, stamps the Intent ID into a DFF segment on that position (the positionsDFF child), and reads the eventual hire back from the workers resource and HCM change feeds.
The public API facts composerID's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.
| Authentication | OAuth 2.0 via OCI IAM identity domains: register a confidential application (JWT user assertion or client credentials for server-to-server) and mirror its identity as a Fusion user holding the HCM roles and data security the write needs; a token alone is not enough. HTTP Basic is accepted but fails once MFA is enforced, so treat OAuth as the production path. |
|---|---|
| API style | REST, JSON (ADF-based resources with child collections such as positionsDFF); offset/limit pagination with hasMore; q= filter syntax on top-level attributes. The same version string is used across resources; pin it rather than relying on the latest alias. |
| Base URL | https://{host}/hcmRestApi/resources/{version} (version string such as 11.13.18.05; HCM Data Loader remains the bulk path) |
| Objects | positions (+ positionsDFF child), jobs, departments, locations, grades, workers (workRelationships, assignments; employee and contingent worker types), recruitingJobRequisitions (Oracle Recruiting, read documented), HCM Atom feeds |
| Events / webhooks | No plain webhook registry on the REST resources. Changes are exposed as HCM Atom feeds under hcmRestApi/atomservlet (employee newhire, empassignment, empupdate and similar) that a consumer polls, and as HCM business events consumed through Oracle Integration (OIC). Direct HTTP callbacks are indicative until confirmed at onboarding. |
| Rate limits | Not published by Oracle for HCM REST; requests are throttled per identity domain and return 429 on breach. Keep publishing transactional and use HCM Data Loader for volume. Any figure is indicative until confirmed at onboarding. |
“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary, especially around custom fields, approval flows and object extensions.
Deterministic mapping
Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).
Tenant discovery
composerID can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.
Enrichment loop
If the target platform requires a field the Intent record doesn't yet have, composerID emits an enrichment_request back to the intake layer.
An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.
| Object | Canonical fields | Platform target | Required status | Notes |
|---|---|---|---|---|
| Position Create the headcount to hire against |
role_title -> Name, PositionCode, BusinessUnitId, DepartmentId, JobId, LocationId, EffectiveStartDate, HeadCount, FullTimeEquivalent, HiringStatus | POST /hcmRestApi/resources/{version}/positions | Required | PositionCode is the tenant's business key (usually auto-numbered, 30 characters) and is left to tenant policy, not overloaded with the Intent ID. Job, department, location and business unit must already exist; preflight resolves names to their IDs. |
| Intent ID correlation Carry the Intent ID |
intent_id -> positionsDFF.<segment> (tenant-named Descriptive Flexfield segment on the position, proposed intentId) | positionsDFF child resource of positions | Required | DFF segments are tenant-configured and surface in REST under the segment's API name with a __FLEX_Context attribute; agree the segment (proposed intentId, text) at onboarding. The value is read back by GET on the positionsDFF child. Server-side q= filtering on a DFF attribute and the position deep link are illustrative and indicative until confirmed at onboarding. |
| Job Requisition (Oracle Recruiting) Open the requisition where Recruiting is licensed |
role_title, PositionId, hiring_manager, openings, location | recruitingJobRequisitions resource | Tenant (Recruiting licensed) | Read access is documented; requisition creation through REST is indicative until confirmed at onboarding, with HCM Data Loader as the fallback. Linking the requisition to the stamped Position carries the correlation without a second stamp. |
| Hire / assignment back-sync Close the loop |
worker filled into the Position (PositionId on the assignment), start date, worker type | GET workers + HCM Atom feeds (employee newhire, empassignment) | Read scope only | Poll the Atom feeds or consume the business event via OIC; the assignment's PositionId ties the hire back to the stamped position and so to the Intent ID. Confirm Atom feed support for the tenant, since Oracle's forward path is business events. |
Idempotency & drift: publish + reconcileExpand
Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, composerID supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.
Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). composerID is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.
How scanning works
High-level flow
What gets produced
Portable artefacts
Important: where this platform is tenant-definedExpand
Auth is per identity domain: register the confidential app in OCI IAM and mirror its Client ID as a Fusion user with HCM roles and data security for the business units it will write to. Version strings matter (resources exist in several versions) and the pod host shape differs between older and newer tenants, so the host and version are taken from the tenant. DFF segments are tenant-configured, so the Intent ID segment on positionsDFF is agreed per tenant and its REST attribute name follows from the segment's API name; PositionCode numbering follows tenant policy. Oracle Recruiting is a separately licensed module: confirm it, and REST create support for requisitions, before planning the requisition step. Whether the tenant still runs Atom feeds or has moved to business events through OIC decides the read-back path, and the position deep link objType is confirmed from the tenant's Deep Links work area. Contingent workers are a worker type in HCM, not a sourcing workflow: the VMS remains the sourcing destination on that channel.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.