Oracle PeopleSoft and BambooHR integration

What moves between them

The main flow runs from BambooHR into Oracle PeopleSoft. New hires, terminations, rehires, job and department changes, and compensation updates move from BambooHR into the PeopleSoft employee master through PERSON_BASIC_CI and JOB_CI, so PeopleSoft headcount and org data reflect what HR maintains. Department and division values from BambooHR job info are aligned to PeopleSoft departments and ChartField dimensions so people land on valid org units. BambooHR webhooks trigger updates as changes happen, and a scheduled poll of the BambooHR employees list backfills anything a webhook missed. BambooHR has no finance records, so vendors, invoices, and GL postings are out of scope; the sync is people data only.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the BambooHR side it runs OAuth 2.0 with offline_access so it can refresh the one-hour access token unattended, and it keys the authorize and token URLs to the customer subdomain because BambooHR has no single global token endpoint. On the PeopleSoft side it accepts the customer base URL, port, and node name, sends Basic Auth with the OPRID and password, and writes the employee master through SOAP Component Interfaces rather than REST, since the delivered HCM REST endpoints are read-only inquiry. BambooHR webhooks carry only the employee id and a changedFields list, so each event is verified against the HMAC-SHA256 signature with a constant-time compare, then ml-connector calls GET employees with an explicit fields list to pull the current values before posting. Department and division are mapped first so every job change references a PeopleSoft department that already exists. BambooHR throttling returns 503 with a Retry-After header, which ml-connector honors, and PeopleSoft 500 or 503 errors get exponential backoff because the self-hosted server has no published rate limit. PeopleSoft has no idempotency keys, so the BambooHR employee id is tracked and the PeopleSoft EMPLID is matched on write to avoid duplicate person records. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturer with roughly 1,200 employees runs Oracle PeopleSoft for finance and the official HCM employee master, while HR manages day-to-day people changes in BambooHR. Before the integration, an HR coordinator entered each hire, transfer, and termination twice, once in BambooHR and again in PeopleSoft, and the two systems drifted apart between updates, so cost reports tagged to the wrong department showed up at month-end. With Oracle PeopleSoft and BambooHR connected, a change made in BambooHR flows into the PeopleSoft employee master within the sync window, mapped to the correct department, and the double entry is gone. Finance and HR work from one agreed headcount instead of reconciling two lists.

What you can do

• •Sync BambooHR hires, terminations, and rehires into the Oracle PeopleSoft employee master.
• •Push job and compensation changes from BambooHR into PeopleSoft through PERSON_BASIC_CI and JOB_CI.
• •Map BambooHR departments and divisions to PeopleSoft departments and ChartField dimensions.
• •Bridge BambooHR OAuth 2.0 on the per-customer subdomain to PeopleSoft Basic Auth on the customer base URL and node.
• •React to BambooHR webhooks by re-fetching the changed employee, with retries and a full audit trail on every record.

Questions

Which direction does data move between Oracle PeopleSoft and BambooHR?

The main flow is BambooHR into Oracle PeopleSoft. Hires, terminations, job changes, and compensation move from BambooHR, the live HR source, into the PeopleSoft employee master, while departments and divisions are aligned so people land on valid org units. BambooHR has no vendors, invoices, or GL accounts, so no finance records flow in either direction.

How does ml-connector write employees into PeopleSoft when its REST APIs are read-only?

The delivered PeopleSoft HCM REST endpoints, such as the employee directory, are read-only inquiry services. To create and update people, ml-connector calls the SOAP Component Interfaces PERSON_BASIC_CI and JOB_CI through the Integration Broker. PeopleSoft provides no idempotency keys, so the EMPLID is matched on write to avoid creating duplicate person records.

How are BambooHR webhooks handled, and what about PeopleSoft having none?

BambooHR signs each webhook with HMAC-SHA256, which ml-connector verifies with a constant-time compare before acting. Because the payload only names the changed employee and fields, it then calls GET employees with an explicit fields list to fetch current values. PeopleSoft has no self-service webhooks, so it is read by polling on the schedule you set.