Standard Configuration Steps (Required)

There are a number of configuration steps that you must complete to use Dayforce Web Services. Because these steps involve system security and feature access, they must be completed by a user who has the Client Admin role.

Important: The following procedures are required for all uses of Dayforce Web Services. For more details about how to perform each step, see the Dayforce Implementation Guide.

To use Dayforce Web Services, you must:

Create a Common Password Policy for all Consumers.
Create a Primary Role for Each Consumer.
Configure Access to Web Services Features for Each Consumer’s Role.
Create a User Account for Each Consumer.
Configure IP Address Filtering (Optional).

1. Create a Common Password Policy for all Consumers

To avoid issues with expired passwords, create a password policy that has non-expiring, complex passwords. This policy can be applied to all roles created for web services consumers, but note that it must not be marked as the default password policy.

2. Create a Primary Role for Each Consumer

Each web services user account should have its own primary role in Dayforce.
Only one role should be assigned to the user account for the consumer because the account’s web services permissions are derived solely from the role marked as Primary. An existing role should never be used for web services, because changes to the role for other users might result in data becoming available in web services features for the consumer when it hasn’t been authorized, and vice versa.
For security purposes, roles with access to web services shouldn't be allowed to access Dayforce UIs. This type of configuration prevents people with access to the consumer’s credentials from accessing or adding features, access authorizations, data elements, or reports without authorization.

Important: Add the password policy created in the first section to each new role as it's created.

3. Configure Access to Web Services Features for Each Consumer’s Role

The primary role assigned to a consumer’s account must have access to the appropriate web services role features for that consumer’s authentication to be successful. You can configure role access in the Features tab of System Admin > Roles, under HCM Anywhere > Web Services.

User roles that are used by web services consumers must be assigned the HCM Anywhere and Web Services role features. Additionally, one or more of the following features must be assigned, depending on which operations the consumer performs:

Delete Payroll Elections: Grants the ability to delete payroll elections data using the PATCH method in the Payroll Election API. The user role also needs to be assigned the Patch/ Post Payroll Elections role feature to delete data using the PATCH method. Also see Patch/Post Payroll Elections.
Delete Payroll Time Data: Grants the ability to delete imported time and attendance data using the PATCH method in the Payroll Time Data Import API. The user role also needs to be assigned the Payroll Time Data API - Delete Imported Data access authorization in the Authorizations tab in System Admin > Roles to delete the imported data.
Explorer: Enables HCM Anywhere > Web Services > Explorer, which is a feature in Dayforce where you can learn about the operations available in the SOAP API. In Explorer, you can test the instance’s web services security configuration, retrieve sample code, and troubleshoot client-side applications.
Notification Status: Enables HCM Anywhere > Web Services > Notification Status, which is a feature in Dayforce where administrators can view the status of SOAP notifications for their subscribers and reset any that are in the Max Retry Reached state.
Notification Subscriptions: Enables HCM Anywhere > Web Services > Notification Subscriptions, which is a feature in Dayforce where administrators can create and manage SOAP notifications and subscriptions.
Patch/Post Candidate and Job Application Sourcing: Enables web services consuming applications to insert and update candidate job applications that include questionnaires.
Patch/Post Candidate Assessment Data: Allows the role to be used when integrating with assessment service providers.
Patch/Post Candidate Screening: Enables web services consuming applications to insert and update background screening data in Recruiting using the RESTful POST and PATCH operations.
Note: This role feature should be assigned to the role used for the integration user. You don't have to assign it to any other user role in Dayforce.
Patch/Post Client Payroll Country: Enables web services to retrieve, add, or update the list of countries for Dayforce and ConnectedPay to configure pay groups.
Patch/Post Configuration Data: This role feature and its two subfeatures, Organization Setup and OrgUnits, must all be selected to enable web services consuming applications to insert and update org unit data using the POST and PATCH operations.
Patch/Post Employee Balance Transaction: Enables web services consuming applications to insert and update employee balance transactions using the RESTful POST and PATCH operations.
Patch/Post Employee HR Data: Enables web services consuming applications to insert and update employee HR data using the RESTful POST and PATCH operations.
Patch/Post Employee Schedules: Enables web services consuming applications to insert and update employee schedules using the RESTful POST and PATCH operations.
Patch/Post Employee Time Off: Enables web services consuming applications to insert and update time away from work using the RESTful POST and PATCH operations.
Patch/Post HireRight Candidate Screening: Enables web services consuming applications to insert and update HireRight background screening data in Recruiting using the RESTful POST and PATCH operations.
Note: This role feature should be assigned to the HireRight Integration System Role. You don't have to assign it to any other user role in Dayforce
Patch/Post Labor Metrics Code: Enables web services consuming applications to insert and update labor metric codes using the RESTful POST and PATCH operations.
Patch/Post Labor Metrics Type: Enables web services consuming applications to insert and update labor metric types using the RESTful POST and PATCH operations.
Patch/Post Operating Hours: Enables web services consuming applications to insert and update operating hours using the RESTful POST and PATCH operations.
Patch/Post Pay Adjustment: Enables web services consuming applications to insert and update employee pay adjustments using the RESTful POST and PATCH operations.
Patch/Post Payroll Elections: Enables web services consuming applications to insert and update employee payroll elections using the RESTful POST and PATCH operations. Also see Delete Payroll Elections.
Patch/Post Payroll Quick Entry: Enables web services to add or update payroll quick entries for employees in the Quick Entry tab in Payroll > Pay Run Management.
Patch/Post Projects: Enables web services consuming applications to insert and update projects data using the RESTful POST and PATCH operations.
Past/Post/Delete Employee Time Entry: Enables web services consuming applications to insert, update, and delete employee time entries using the Employee Punches API’s POST, PATCH, and DELETE operations.
Patch/Post/Delete KPI Data: Enables web services consuming applications to insert, update, and delete KPI data using the RESTful POST, PATCH, and DELETE operations.
Patch/Post/Delete Legacy Labor Metric: Enables web services consuming applications to insert, update, and delete legacy labor metrics using the RESTful POST, PATCH, and DELETE operations
Patch/Post/Delete Plan Targets: Enables web services consuming applications to insert, update, and delete plan targets using the RESTful POST, PATCH, and DELETE operations.
Post Document Import: Allows the role to use the Documents Import API to import file metadata using the RESTful POST operation.
Post Employee Availability: Enables web services consuming applications to insert employee availability records using the RESTful POST operation.
Post Employee Raw Clock Entry: Enables web services consuming applications to insert employee raw clock entries using the RESTful POST operation.
Post Right To Work Data: Enables web services consuming applications to insert candidate right to work survey data in Recruiting using the RESTful POST operation.
PutWorkflowValidationAction: Enables the external validation node in the workflow configuration to allow web services consuming applications to use the GET Employee request to retrieve the minimum employee HR information required by local payroll systems (or “in-country providers”) for validations, to indicate when external review and action is required for payroll changes.
Read Data: Controls the ability to retrieve data from Dayforce using SOAP and RESTful GET requests. The ability to retrieve specific response types is controlled separately using the settings in the Web Services Field-Level Access tab in System Admin > Roles.

To assign web services access to a role:

Go to System Admin > Roles.
In the Features tab, select the web services role that you are configuring.
Locate and expand HCM Anywhere, then expand Web Services.
Select HCM Anywhere, Web Services, and each of the sub-features as necessary.
Click Save, then click Refresh.

Workflow Validation Feature

Dayforce offers the ability to use web services notifications as a vehicle for validating and taking action on workflow transactions. If you have very complex data validation requirements, you can create applications that ensure that your unique business needs are accounted for prior to data being committed to the database. This process is triggered using a new External Validation workflow configuration object. When a transaction reaches this object in the process flow, Dayforce creates a Workflow Notification event that can either be pushed to a client-hosted receiver service or that can be retrieved by a Get Notifications request.

To avoid confusion, the External Validation workflow configuration object isn’t available in the Workflow Manager screen by default.

You must add the feature specifically. If you plan on using the web services Workflow Validation process, you must specifically add the feature to a role by taking the following steps:

Go to System Admin > Roles.
Select the role that you’re adding the feature to.
Locate and expand Workflow Administration > Workflow Designer.
Select the External Validation Admin role feature.
Click Save, then click Refresh.

You must select the Workflow Administration > Workflow Designer > External Validation Admin feature in for the object to be available in the workflow configuration area.

Note: Consider giving this role access to the Home > Welcome feature. Adding this feature provides a consistent starting point for the user account if it's used to log in to Dayforce directly.

4. Create a User Account for Each Consumer

Consumers must always authenticate with Dayforce to retrieve detailed information from the application.

As with UI users (users of the application via the user interface), an account must be established for each consumer using web services features. This allows Dayforce to properly track a given consumer’s usage and activities and allows Dayforce to properly secure data for ongoing use as well as to meet the general security audit requirements of most customers.

Configure Location Access for Each Consumer’s User Account

A consumer’s access to employee information is controlled by the org locations attached to their user account. Only the employees in the allowed locations are included in web services interactions.

5. Configure IP Address Filtering (Optional)

You can restrict the IP addresses and ranges that can originate web service requests. This is an optional level of security that you can apply by creating Dayforce service entries in System Admin > IP Network Filtering.

See Restrict Dayforce Web Services by IP Address in the Dayforce Implementation Guide.