Skip to main content

​
About Dayforce

Dayforce (formerly Ceridian Dayforce) is a human capital management platform covering HR, payroll, benefits, workforce management, and talent. The Serval integration connects to your Dayforce tenant as a dedicated web services user, so workflows can look up employees, pull time clock and time-away data, read org and payroll metadata, and update employee records - all on demand.
The Dayforce integration works against Dayforce’s V1 REST API only; SOAP web services are not supported.
Authentication: A dedicated Dayforce web services user with HTTP Basic authentication. Serval signs every request to your tenant automatically. There is no OAuth flow and no token refresh - the stored password simply has to keep matching Dayforce. (Dayforce also offers a token-based sign-in for its API; Serval does not use it.) Data sync: On demand only. There is no background or scheduled sync, no Dayforce data is pulled into Serval entities automatically, and no pre-built workflows are installed with this integration. All reads and writes happen inside workflow runs, and four health checks verify the connection.

​
What the Dayforce integration enables

​
Get your credentials

Serval connects to Dayforce as a dedicated web services user (a service account) assigned to a role whose Features grant REST API access. You also need your Dayforce server host and your tenant’s client namespace. The feature minimums below match exactly what Serval’s health checks verify. For Dayforce’s own reference, see the Dayforce RESTful Web Services Developer Guide.
1

Sign in to Dayforce as an administrator

You need admin access to create users and roles.
2

Create a dedicated service user

Open People, then Profiles, then Users (or search for Users) and click Add. Create a dedicated service user (for example, serval-integration) with a strong password. It does not need to be tied to a real employee.
3

Exempt the user from password expiration

If your tenant enforces password expiration on regular users, exempt this web services user - otherwise the integration breaks silently when the password rotates.
4

Create a role for the integration

Search for Roles, click Add, name the role (for example, Serval Integration Role), and open its Features tab.
5

Enable web services read access

Expand HCM Anywhere, then Web Services, and enable Read Data. This is required for any REST access.
6

Enable the features the Serval health checks verify

Also enable: Employee (with XRefCode enabled), RESTful Services then Configuration then Departments, and RESTful Services then Configuration then Pay Groups.
7

Enable optional features for your workflows

Optionally enable Employee Punches, Employee Raw Punches, Employee Time Away From Work, and RESTful Services then Configuration then Jobs and Locations for time and org workflows. Enable Employee Write Data only if your workflows will update employee records.
8

Assign the role to the service user

Add the role under the user’s Authorizations/Roles and save.
9

Note your server host and client namespace

The server host is, for example, www.dayforcehcm.com for production, or an environment-specific pod host such as ustest61.dayforcehcm.com (test) or usconfigr57.dayforcehcm.com (config) for sandboxes. The client namespace is the segment that appears after /Api/ in your tenant’s Dayforce web addresses.
Only enable the role features your workflows actually need. Dayforce role features are additive, so it is much easier to grant access incrementally than to walk it back later.
Keep the web services user exempt from password-expiration policies. With Basic authentication, the password Serval stores must match Dayforce at all times - if it rotates, the connection fails with no other warning.

​
Connect in Serval

1

Open the Dayforce connect form

In Serval, add the Dayforce integration to open the connect form. All four fields are required.
2

Server

Paste only the bare Dayforce hostname - no https://, no path, no trailing slash. Use www.dayforcehcm.com for production, or your test-pod host (for example, ustest61.dayforcehcm.com) for sandboxes. The field accepts exactly one name segment before .dayforce.com or .dayforcehcm.com, so a value with extra dots in front is rejected, while hyphenated pod hosts such as us252-services.dayforcehcm.com pass. If the value does not match, you’ll see “Must be a Dayforce host (e.g. www.dayforcehcm.com or ustest61.dayforcehcm.com)”. If you leave the field blank, you’ll see “This field is required”.
3

Client Namespace

Your Dayforce client namespace - the segment that appears after /Api/ in your tenant’s REST web addresses (for example, MyCompany). If you leave the field blank, you’ll see “This field is required”.
4

Web Services Username

The dedicated web services user you created. Its role must allow REST API access. If you leave the field blank, you’ll see “This field is required”.
5

Web Services Password

The web services user’s password. This field is required too, but the form does not check it inline - if you leave it blank on first connect, the save fails with a general installation error rather than a message under the field.
6

Save the connection

Serval composes your API address from the Server and Client Namespace values and names the connection after it (for example, www.dayforcehcm.com/Api/MyCompany).
When you reopen the connection to edit it, Server, Client Namespace, and Web Services Username show their saved values, and the saved password appears masked (bullets with only the last 4 characters visible) next to a Replace button. Leaving the password untouched - or clicking Replace and saving with the field still blank - keeps the stored password, so you can safely change one field at a time, for example updating the username without re-entering the password. Server and Client Namespace are stored together as one address: if either is blank when you save, the saved address is kept unchanged, so fill in both to point the connection at a different host or namespace.

​
Verifying the connection

Dayforce connections run four health checks. Each failure message names the exact Dayforce role feature that is missing. Test Dayforce Connection - signs in to your tenant by fetching a single employee record.
  • Pass: “Successfully connected to the Dayforce REST API and authenticated.”
  • Fail: “Unable to connect to Dayforce. Verify that the server, client namespace, username, and password are correct, and that the Dayforce web services role is enabled.”
List Dayforce Employees - confirms the web services user can read employee records.
  • Pass: “Successfully retrieved employee records from Dayforce (sample size: [number]).”
  • Fail: “Unable to list employees from Dayforce. Confirm the web services role has Read Data on HCM Anywhere > Web Services > Employee (with XRefCode enabled).”
List Dayforce Departments - confirms read access to department metadata.
  • Pass: “Successfully retrieved [number] departments from Dayforce.”
  • Fail: “Unable to list departments from Dayforce. Confirm the web services role has Read Data on HCM Anywhere > Web Services > RESTful Services > Configuration > Departments.”
List Dayforce Pay Groups - confirms read access to pay group metadata.
  • Pass: “Successfully retrieved [number] pay groups from Dayforce.”
  • Fail: “Unable to list pay groups from Dayforce. Confirm the web services role has Read Data on HCM Anywhere > Web Services > RESTful Services > Configuration > Pay Groups.”
If Test Dayforce Connection passes but a later check fails, your credentials are fine - the role is just missing that check’s specific feature. The failure message spells out the exact feature path to enable in the role’s Features tab in Dayforce; enable it and re-run the checks.

​
Gotchas and troubleshooting

The field accepts only a bare Dayforce hostname: exactly one name segment followed by .dayforce.com or .dayforcehcm.com. No https://, no path, no trailing slash, and no extra dots in the prefix - foo.bar.dayforcehcm.com is rejected, while hyphenated pod hosts like us252-services.dayforcehcm.com pass. If you pasted a full address from your browser, trim it down to just the hostname.
“Unable to connect to Dayforce…” means one of the four form values is wrong, or the web services role is not enabled for the user. Re-check the server host and client namespace (the segment after /Api/ in your tenant’s web addresses), confirm the username and password, and make sure the role with HCM Anywhere > Web Services > Read Data is actually assigned to the user.
Each check maps to one Dayforce role feature: the employees check needs Employee (with XRefCode enabled), the departments check needs RESTful Services > Configuration > Departments, and the pay groups check needs RESTful Services > Configuration > Pay Groups - all under HCM Anywhere > Web Services. The failure message tells you which one to enable.
Basic authentication means the password Serval stores must match Dayforce at all times. If the web services user’s password expires or rotates, the connection breaks with no other warning - Test Dayforce Connection starts failing with the credentials message. Exempt the user from password-expiration policies, and when you do rotate deliberately, edit the connection and enter the new password (the other fields can stay as they are).
The Dayforce API request action supports exactly nine endpoints: the employee list, single-employee lookup and update, processed punches, raw punches, time away from work, departments, jobs, locations, and pay groups. There is no fallback for calling other Dayforce endpoints, and SOAP web services are not supported. If a workflow needs data outside this set, it cannot fetch it through this integration today.
An employee update changes the live HR record as soon as it runs - there is no draft or approval stage on the Dayforce side. Use the update’s validate-only mode to check a change without saving anything, and test write workflows against a test or config pod before pointing them at production. Updating employees also requires the Employee Write Data role feature, which the health checks do not cover.
Every request must include the employee’s reference code, a start date, an end date, and a status. The start date is inclusive but the end date is exclusive - records on the end date itself are not returned. Status is case-sensitive and must be exactly one of APPROVED, PENDING, CANCELED, DENIED, or CANCELPENDING.
Raw punch lookups always require both a UTC start and end transaction time. Processed punch lookups need either that UTC window or a business date - but this rule is enforced only when the request runs, so a missing window fails at run time rather than while building the workflow. The location, position, department, job, docket, project, and pay-adjustment reference-code filters on processed punch lookups are case-sensitive.
List responses return one page of results plus a link to the next page when more pages exist. Workflows must keep following that link until it is absent to read everything. Most list endpoints accept a page-size option, but not all - the pay groups list takes no options at all.
Each connection is named after the API address composed from your entries - the server, then /Api/, then the client namespace (for example, www.dayforcehcm.com/Api/MyCompany). If you connect both production and a test pod, this name is how you tell them apart in Serval.
Need help? Contact support@serval.com for assistance with your Dayforce integration.