Skip to main content
Connect Dayforce to Oleria to use your HR system as the source of truth for who works for you. Oleria reads employees, people, departments, manager relationships, each employee’s Dayforce login, and the Dayforce security roles each login holds. It then compares identity provider (IdP) and SaaS access against that worker record, so a leaver who still holds access somewhere else becomes visible. To set it up, you give a dedicated Dayforce web-services user a role with read access to the RESTful Web Services. You then enter your environment, client namespace, and that user’s username and password in Oleria. There’s no OAuth application to register. One Oleria connection maps one Dayforce client namespace in one environment.
This integration is for Dayforce (formerly Ceridian Dayforce HCM).

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from Dayforce:
  • Employees - every employee, including terminated employees, with employee number, name, business email, hire date, termination date, title, job code, job family, job function, pay class (shown as Employment type, or Unknown when the employee’s current status has no pay class), their department’s name (shown as Cost Center), and legal entity (shown as Company Name). If an employee was rehired after a termination, Oleria treats them as current. A future termination date is kept only when the employee’s status is already terminated.
  • People - the person record for each employee.
  • Accounts - each employee’s own Dayforce login, for employees who have a login ID or an SSO login name. Each account shows the login ID, federated ID, business email, whether it signs in with SSO, a Dayforce password, or both, its default role, and its other roles. A login is shown as disabled when the employee is terminated, when the login isn’t approved, or when it can’t sign in at all (password sign-in is off and it has no SSO login). The web-services user Oleria connects with is marked as having API access.
  • Roles - the Dayforce security roles that at least one login currently holds.
  • Role assignments - which roles each login holds.
  • Departments - your Dayforce department catalog.
  • Manager relationships - each employee’s current managers, used to build your reporting hierarchy. Oleria uses work-assignment managers, and falls back to employee managers when an employee has none.
  • Department assignments - the department of each employee’s primary work assignment.
Oleria refreshes this data on its regular sync schedule. Each sync reads every employee through the Dayforce HR bulk export, in jobs of up to 500 employees. If the web-services user isn’t allowed to run the bulk export, Oleria reads each employee one at a time instead, at Dayforce’s limit of 100 employees a minute. For example, a company with 10,000 employees then takes about 100 minutes to sync.
Oleria never requests or stores sensitive personal data from the employee record. That includes Social Security and taxpayer numbers, birth date, gender, home phone, addresses, emergency contacts, and pay, tax, and direct deposit details.

​
Prerequisites

  • Administrator permission on the Oleria workspace.
  • A Dayforce administrator who can create users and edit roles in System Admin -> Roles.
  • Your environment: Production, or a Test, Stage, Config, or Train environment.
  • Your client namespace: your company ID in Dayforce. It’s the Company you enter when signing in, and the namespace in your Dayforce URL, for example mycompany in https://www.dayforcehcm.com/mydayforce/mycompany.

​
Set up a web-services user in Dayforce

1

Create the user

In Dayforce, create a dedicated web-services user for Oleria, or reuse your existing web-services user. Note its username and password. You’ll need both when connecting in Oleria. Oleria signs in with them through Dayforce ID.
2

Grant read access

In System Admin -> Roles, give that user’s default role the following. The integration’s Capabilities and operation readiness section shows the same names.Dayforce doesn’t publish the exact names of the items marked (name may vary), so your Dayforce release may label them differently. In System Admin -> Roles, grant the item with the closest name under the same parent, for example RESTful Services -> Human Resources. Grant only these fields: Oleria doesn’t need pay, tax, or other sensitive employee data.
3

Grant access for remediation (optional)

Only if Oleria should remove Dayforce SSO sign-in for leavers, also give the role the permissions listed in Remediation actions.
4

Save and refresh

Save the role, then click Refresh so Dayforce applies the change.
Dayforce doesn’t report missing field access as an error. It returns the field blank instead. Because of this, Oleria refuses to connect when the hire dates, employment statuses, or termination dates it needs come back blank, rather than syncing every leaver as a current employee.

​
Connect Dayforce to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Dayforce.
2

Complete the connection form

Select Continue and provide the following:
3

Confirm the connection

Select Authenticate. Oleria gets a Dayforce ID token for the user, finds your client’s Dayforce service address, lists employees, reads up to 10 employee records (terminated employees first), and lists departments. Find the newly connected client on the Connected tab of your Oleria Integrations page.
You can connect each Dayforce client namespace in an environment to Oleria once. You can’t change the Environment or Client Namespace after the integration is connected. If you change the username when you edit the integration, enter its password again. To keep the stored password when you edit only other fields, leave the field empty.

​
Verify the integration

Confirm the Dayforce client appears on the Connected tab of your Oleria Integrations page with a status of Healthy. To see more detail about its health, select View Details on the Dayforce instance to open the side pane. After the first sync completes, go to Posture -> Access Inventory -> Employees to review the Dayforce employees. Oleria shows HR employee records there when Dayforce is your employee source of truth. To select it, go to Settings -> Employee Information. In the integration’s Capabilities and operation readiness section, Read users, Read roles, Read employees (including their manager), and Read departments show as Available. Read groups shows as Not available for this integration, because Dayforce has no groups in its API.
Dayforce doesn’t signal a missing permission, so these rows never show Needs permission. If a check can’t read Dayforce, Oleria keeps the last saved capabilities until the read works again.

​
Remediation actions

Dayforce has no API to lock or disable a login. Instead, Oleria can remove a login’s SSO sign-in.
  • Remove Dayforce SSO sign-in removes every SSO login from a login that can sign in only through SSO, so the employee can’t sign in to Dayforce. In Oleria this action is labeled Disable account, and the Capabilities and operation readiness section lists it as Disable user accounts. The employee record, dates, status, and roles don’t change. Reverting the action re-adds exactly the SSO logins it removed.
The action needs these permissions on the web-services user’s default role, in addition to the read access above: Oleria follows these rules:
  • Only SSO-only logins. Oleria refuses, without making a change, when the login may also sign in with a Dayforce password, or when Dayforce doesn’t return whether it may. Removing SSO wouldn’t block access. Turn off native authentication or terminate the employee in Dayforce instead.
  • SSO logins must be readable. If Dayforce doesn’t return the employee’s SSO logins, Oleria can’t tell which exist, so it refuses without making a change. Allow the role to read them (EmployeeSSOAccount).
  • Its own login is protected. Oleria won’t remove the SSO sign-in of the web-services user it connects with.
  • Unchanged logins are left alone. If the login has no SSO logins, the action makes no change, and reverting it does nothing.
  • Changes are confirmed. Oleria confirms each removal by reading the employee’s SSO logins again. If Dayforce accepted a removal but the confirming read doesn’t show it yet, the action reports success as unverified.
  • Unconfirmed changes are reported. If Oleria can’t tell whether a removal was applied, the action reports that it may have been applied. Check the employee’s SSO accounts in Dayforce before running it again.
  • Partial changes are undone. If a login has several SSO logins and one removal fails, or Dayforce doesn’t confirm whether it went through, Oleria checks which SSO logins are missing, re-adds them, and reports the failure. If Oleria can’t confirm that every SSO login is back, the failure names the ones to check, so you can re-add any that are missing in Dayforce.
  • Reverts re-add only what was removed. An SSO login that’s already present again counts as restored. If the employee no longer exists in Dayforce, the revert can’t run.
  • Sessions aren’t ended. The action doesn’t end sessions the user already has open in Dayforce or in your identity provider.
  • There’s no hire or termination action. A Dayforce hire needs your company’s position, location, pay, and default-role settings, which Oleria doesn’t collect. Hire and terminate employees in Dayforce as part of your HR and payroll process.

​
Troubleshooting

If Authenticate fails, Oleria shows the reason:
  • Username or password rejected - check them, that the user isn’t locked, and that its default role has the Web Services feature.
  • Access token refused - the user may not be configured for Web Services.
  • Client namespace not recognized - check the Client Namespace and Environment.
  • Missing access - add the access the message names to the user’s default role.
  • No hire dates, employment statuses, or termination dates - let the role read HireDate and OriginalHireDate for hire dates, EmploymentStatuses (field-level access EmployeeEmploymentStatus and the Employee Status Information authorization) for statuses, and TerminationDate for termination dates.
  • No terminated employee - shown when at least 200 employees are listed and none is a leaver. Either the role’s location access excludes leavers, or Dayforce holds no leaver yet. Include the leavers’ locations, or connect again once Dayforce has its first leaver.
  • Rate limit reached - retry in a minute.
A sync fails, and keeps the last synced employees, when:
  • Dayforce lists no employees, or more than a few listed employees return no record. This usually means the role’s location access or field-level access hides them.
  • Hire dates, employment statuses, or termination dates come back blank, for example because access was narrowed after you connected. Grant the access listed above.
  • An HR bulk export job fails or doesn’t finish within 30 minutes. The next sync tries again.
Oleria never reports a partial or empty workforce. After you fix access in Dayforce, the next sync picks up the missing data.

​
Known limitations

  • Activity - Dayforce has no sign-in or audit log API, so this integration has no activity.
  • Last sign-in and MFA - Dayforce doesn’t expose last sign-in time, password change date, lock state, or multi-factor authentication (MFA) settings through the API. Oleria can’t flag dormant logins from Dayforce alone.
  • Login status is inferred - Dayforce has no login status field, so Oleria works out whether a login is enabled from the employee’s status, approval, and sign-in settings. Some companies let terminated employees keep self-service access, and those logins still show as disabled.
  • Role permissions and administrators - Dayforce doesn’t expose what a role permits, so Oleria doesn’t flag administrators. Roles nobody currently holds aren’t shown, because Dayforce has no role catalog API.
  • Groups and resources - Dayforce has no groups in its API. Module-specific grants, such as authorization assignments, document management security groups, and pay adjustment code groups, aren’t imported.
  • Non-human identities and AI agents - Dayforce has no API keys, OAuth applications, or service accounts in its API. Web-services users appear as ordinary accounts. No AI agents are discovered.
  • Flat departments - Dayforce departments have no parent, so department hierarchy isn’t discovered. Org units aren’t imported. The legal entity of each employee’s primary location appears as the company instead.
  • Department names - if the role can’t read a department’s details, Oleria shows the department’s code as its name.
  • Changed employee codes - if an employee’s XRefCode changes in Dayforce, Oleria sees one leaver and one new employee.
  • Sync speed - each bulk export job is checked every 15 seconds, for up to 30 minutes. Without the bulk export, Oleria reads at most 100 employees a minute. If a sync fails partway, the next attempt starts again from the first employee, so granting the bulk export matters most for large companies.
  • Network - Oleria connects only to hosts under dayforcehcm.com. It refuses a service address or redirect outside that domain.

​
Contact us

For questions about this integration, contact us at support@oleria.com.