IFS Cloud and Dayforce integration

What moves between them

The primary flow runs from Dayforce into IFS Cloud. Employee records (hire, termination, rehire, job change) flow from Dayforce into IFS Cloud, and organizational units in Dayforce are synced to IFS Cloud cost centers so payroll expense allocations land on valid dimensions. Job codes and position titles from Dayforce are aligned with IFS Cloud project codes and cost center mappings. Payroll cost allocation data and employee status changes move on a schedule tied to your payroll calendar. IFS Cloud financial records remain read-only from Dayforce; payroll does not post GL entries into IFS Cloud in this integration.

How ml-connector handles it

ml-connector stores both credential sets encrypted and handles the different authentication patterns: Dayforce ROPC bearer tokens are refreshed every 55 minutes to stay ahead of the 1-hour expiry, while IFS Cloud OAuth 2.0 Client Credentials tokens are refreshed at 50 minutes. The Dayforce client-specific base URL is queried daily via /V1/ClientMetadata and cached to avoid redirect overhead. On the IFS Cloud side, employee records are created or updated using OData PATCH operations with ETag headers to enforce optimistic concurrency, and duplicate detection occurs by querying for existing employee records before creating new ones (no universal idempotency key exists). Cost centers and job codes are mapped first so every employee sync references valid IFS Cloud dimensions. Both systems are polled on your payroll cycle, and if a call to IFS Cloud or Dayforce returns HTTP 429 (rate limit), ml-connector backs off and retries with exponential jitter. Every record carries a full audit trail.

A real-world example

A mid-sized discrete manufacturer operates IFS Cloud for procurement, manufacturing, asset management, and finance across four locations, and uses Dayforce for payroll and HR for 250 employees. Before the integration, HR exported employee rosters from Dayforce monthly and the finance team manually entered new hires, terminations, and job changes into IFS Cloud as cost center dimensions. Payroll expense registers were printed and re-entered by hand into IFS Cloud's journal entry module, creating a two-week close cycle with inevitable mismatches between HR headcount and IFS Cloud cost center allocations. With IFS Cloud and Dayforce connected, each employee lifecycle event flows automatically, cost centers are validated before sync, and month-end close now starts with payroll expense pre-mapped and ready to post.

What you can do

• •Sync employees, organizational units, and job codes from Dayforce into IFS Cloud cost centers and project dimensions.
• •Refresh Dayforce ROPC tokens on a 55-minute cycle and IFS Cloud OAuth tokens at 50 minutes to prevent expiry-induced outages.
• •Query the Dayforce client-specific API base URL daily and cache it to eliminate redirect overhead on every call.
• •Map Dayforce job titles and org units to IFS Cloud GL accounts, cost centers, and project codes before posting employee data.
• •Poll both systems on your payroll calendar with automatic retries, ETag-based concurrency control, and full audit trails on every record.

Questions

Which direction does data move between IFS Cloud and Dayforce?

The primary flow is Dayforce into IFS Cloud. Employees, organizational units, and job codes flow from Dayforce into IFS Cloud so that cost allocations land on valid cost centers and dimensions. IFS Cloud financial records remain read-only and do not flow back into Dayforce.

How does ml-connector handle the different token expiry windows for Dayforce and IFS Cloud?

Dayforce ROPC tokens expire in 1 hour and ml-connector refreshes them every 55 minutes. IFS Cloud OAuth 2.0 Client Credentials tokens expire in approximately 60 minutes and are refreshed at 50 minutes. Both refresh windows start early to guarantee a fresh token before any call fails due to expiry.

What happens if an employee already exists in IFS Cloud when Dayforce sends a sync?

ml-connector queries IFS Cloud for the employee record before creating a new one, and if found, uses OData PATCH with the ETag header to update the existing record. This prevents duplicate employee records and enforces optimistic concurrency so IFS Cloud can detect conflicting concurrent updates.