> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # Dayforce > Connect Dayforce to Oleria to bring employees, people, departments, manager relationships, Dayforce logins, and their security roles into your identity and access graph as the authoritative worker record. 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. > [!NOTE] > > 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](https://docs.oleria.com/integrations/overview.md#sync-model). 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. > [!NOTE] > > 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 permission | Used for | | :- | :- | | Role feature: HCM Anywhere > Web Services > Read Data | Every read | | Role feature: HCM Anywhere > Web Services > PATCH/POST HR Bulk Job | Reading employees, logins, and roles through the HR bulk export. Without it, syncs read each employee one at a time and take much longer. | | Role feature: HCM Anywhere > Web Services > PutWorkflowValidationAction | Recommended by Dayforce for every web-services role | | Web Services Field-Level Access: RESTful Services > Human Resources > Employee (XRefCode, HireDate, EmployeeNumber, DisplayName, FirstName, LastName, OriginalHireDate, TerminationDate, LoginId, FederatedId, UserAccount) | Employees, people, and accounts | | Web Services Field-Level Access: RESTful Services > Human Resources > PersonContact | Business email | | Web Services Field-Level Access: RESTful Services > Human Resources > EmployeeWorkAssignment | Title, job, department, and legal entity | | Web Services Field-Level Access: RESTful Services > Human Resources > EmployeeEmploymentStatus (name may vary) | Employment status and pay class | | Web Services Field-Level Access: RESTful Services > Human Resources > EmployeeManager | Manager relationships | | Web Services Field-Level Access: RESTful Services > Human Resources > EmployeeWorkAssignmentManager (name may vary) | Manager relationships | | Web Services Field-Level Access: RESTful Services > Human Resources > EmployeeSSOAccount (name may vary) | SSO logins | | Web Services Field-Level Access: RESTful Services > EmployeeExportBulkResponse, EmployeeExportBackgroundJobStatus, EmployeeExportParameters | The HR bulk export | | Web Services Field-Level Access: RESTful Services > Human Resources > EmployeeRole | Roles and role assignments | | Web Services Field-Level Access: RESTful Services > Configuration > Departments | Departments | | Authorization (Can Read): Employee Personal Information | Employees, people, and accounts | | Authorization (Can Read): Employee Contact Information – Business | Business email | | Authorization (Can Read): Employee Status Information | Employment status | | Authorization (Can Read): Employee Work Assignment – Primary/Secondary Records | Work assignments | | Authorization (Can Read): Employee Profile – Security Settings – Roles | Roles and role assignments | | Location Access: the company-level location | Every employee read. Include the locations of terminated employees, or leavers are missing. | 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](#remediation-actions). **4. Save and refresh** Save the role, then click **Refresh** so Dayforce applies the change. > [!NOTE] > > 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: | Field | Notes | | :- | :- | | Environment | Required. The Dayforce environment the client namespace and web-services user belong to: **Production** (the default), **Test**, **Stage**, **Config**, or **Train**. | | Client Namespace | Required. Your company ID in Dayforce, for example `mycompany`. Letters, digits, `-`, and `_` only, up to 64 characters. | | Web Services Username | Required. The username of the web-services user you set up. | | Web Services Password | Required. That user's password. | **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. > [!NOTE] > > 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. > [!NOTE] > > 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: | Dayforce permission | | :- | | Role feature: HCM Anywhere > Web Services > Read Data | | Role feature: HCM Anywhere > Web Services write subfeature for employee subordinate POST/DELETE (name may vary) | | Role feature: HCM Anywhere > Web Services > PutWorkflowValidationAction | | Web Services Field-Level Access: RESTful Services > Human Resources > EmployeeSSOAccount (name may vary), and UserAccount on Employee | | Authorization (Can Edit): Employee Profile – Security Settings (name may vary) | | Location Access covering the target employee | 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](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.