​@dana I’ll paste it here...a bit long:-)  

Dayforce Identity Integration Password Policy, Role and User

The security components associated with Dayforce web services must be configured to support Dayforce Identity Integration. You need to configure:

• A specific password policy for web services
• An integration-specific role and user accounts
• Employee property access settings, if employee properties are used in the integration

Adding Web Services Password Policy

For web service integrations, using a password policy with separate requirements (other than employee users) is recommended to allow automation to run without interruptions. The same password policy can be used for all web service integrations.

1. Go to System Admin > Password Policy.
2. Click Add and enter policy details.

   The minimum settings for the configuration policy should include the following:

   Properties

   • Name: Web Services Password Policy
   • Description: Web Services Password Policy for API Integrations

   Password

   • Minimum Length: 6

   Password Lockout Rules

   • Failed Login attempts before Lockout: 5
   • Lock Account for (minutes): 1
3. Click Save.

Creating a Dayforce Identity Integration Role

In Dayforce, role-level security controls a user's access to features and access authorizations. For web services accounts, it also controls field-level security. A separate role should be defined for each web services.
To create a role for Dayforce Identity Integration and apply configurations as a starting point for the integration’s overall permissions:

1. Go to System Admin > Roles.
2. Click Add.
3. In the General tab, enter these details:
   • Name: Dayforce Identity Integration
   • Description: Dayforce Identity Integration
   • Password Policy: Web Services Password Policy
   • Reference Code: Identity API Integration
4. In the Features tab, select the checkboxes for HCM Anywhere > Web Services and the sub-features, Explorer, Patch/Post Employee HR Data, and Read Data.

   

5. In the Authorizations tab, configure these Access Authorizations:

   Name	Can Create	Can Read	Can Update	Can Delete
   Employee Contact Information	X	X	X	X
   Employee Contact Information - Business	X	X	X	X
   Employee Key Information		X
   Employee Number		X	X
   Employee Personal Information	X	X	X	X
   Employee Personal Information XRefCode	X	X	X	X
   Employee Profile - Security Settings - SSO Logins	X	X	X	X
   Employee Properties		X
   Employee Status Information		X
   Employee Work Assignments - Primary Records		X
   Management Assignment		X
   User Information		X	X

6. In the Web Services Field-Level Access tab, expand RESTful Services > Human Resources > Employee and select the checkboxes for these items:
   • Addresses
     • Address
     • Address2
     • Address3
     • Address4
     • Address5
     • Address6
     • City
     • ContactInformationType
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
     • Country
       • LastModifiedTimestamp
       • LongName
       • Name
       • ShortName
       • XrefCode
     • EffectiveEnd
     • EffectiveStart
     • LastModifiedTimestamp
     • PostalCode
     • State
       • LongName
       • Name
       • ShortName
       • XrefCode
   • Contacts
     • ContactInformationType
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
     • ContactNumber
     • EffectiveEnd
     • EffectiveStart
     • ElectronicAddress
     • Extension
   • EmployeeManagers
     • DerivationMethod
     • EffectiveEnd
     • EffectiveStart
     • LastModifiedTimestamp
     • ManagerFirstName
     • ManagerLastName
     • ManagerMiddleName
     • ManagerXRefCode
   • EmployeeNumber
   • EmployeeProperties
     • BitValue
     • DateTimeValue
     • EffectiveEnd
     • EffectiveStart
     • EmployeeProperty
       • DataType
       • DataTypeParam
       • EmployeeCardinality
       • LastModifiedTimestamp
       • LongName
       • Sequence
       • ShortName
       • XrefCode
     • LastModifiedTimestamp
     • NumberValue
     • OptionValue
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
     • StringValue
   • EmploymentStatuses
     • EffectiveEnd
     • EffectiveStart
     • EmployeeGroup
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
     • EmployeeNumber
     • EmploymentStatusGroup
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
   • EmploymentTypes
     • DBAName
     • EffectiveEnd
     • EffectiveStart
     • EmploymentType
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
     • LastModifiedTimestamp
   • FederatedID
   • FirstName
   • HireDate
   • HomePhone
   • LastName
   • LoginID
   • MiddleName
   • OrgUnitInfos
     • Department
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
     • LastModifiedTimestamp
     • OrgUnitDetail
       • Address
         • Address1
         • Address2
         • Address3
         • Address4
         • Address5
         • Address6
         • City
         • Country
           • LastModifiedTimestamp
           • LongName
           • Name
           • ShortName
           • XrefCode
         • EffectiveEnd
         • EffectiveStart
         • LastModifiedTimestamp
         • PostalCode
         • State
           • LongName
           • Name
           • ShortName
           • XrefCode
       • EffectiveEnd
       • EffectiveStart
       • IsPhysicalLocation
       • IsPrimary
       • LastModifiedTimestamp
       • LedgerCode
       • LongName
       • OrgLevel
         • LastModifiedTimestamp
         • LongName
         • ShortName
         • XrefCode
       • ShortName
       • XrefCode
   • OriginalHireDate
   • PreferredLastName
   • PreStartDate
   • SeniorityDate
   • StartDate
   • TerminationDate
   • UnionMemberships
     • EffectiveEnd
     • EffectiveStart
     • LastModifiedTimestamp
     • Union
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
     • UnionMembershipDate
   • WorkAssignments
     • BusinessTitle
     • EffectiveEnd
     • EffectiveStart
     • IsPrimary
     • IsVirtual
     • LaborPercentage
     • LedgerCode
     • Location
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
     • Position
       • Department
         • LastModifiedTimestamp
         • LongName
         • ShortName
         • XrefCode
       • Job
         • EffectiveStart
         • EffectiveEnd
         • LedgerCode
         • LongName
         • ShortName
         • XrefCode
       • LastModifiedTimestamp
       • LongName
       • ShortName
       • XrefCode
   • XRefCode
7. Click Save.

Add a Dayforce Identity Integrations User

Add a new non-employee user that is specific to Dayforce Identity Integrations. This user is not intended to have UI access to the Dayforce application, instead, the account will be configured to make Dayforce web services API requests.

1. Go to System Admin > User.
2. Click New and enter these details:
   • User Name
   • Culture
   • Numeric Culture
   • Approved: Select this checkbox.
3. Click Add User Role and enter these details:
   • User Roles: Select the new Dayforce Identity Integration role you created
   • Is Default: Select this checkbox.
   • Start Date: Enter a Start Date that is prior to all employees’ original hire dates.
4. In the Location Access section, click Add Location to add employee access by location for the new user and enter these details for each location:
   • Locations
   • Primary: Select this checkbox.
   • Start Date: Enter a Start Date that is prior to all employees’ original hire dates.

   Note: The selected org unit should usually be the highest level of the organization so that all employees in the system are available to the new Dayforce Identity Integration account. If the Dayforce Identity Integration will be limited to specific org units, a more granular configuration with specific locations can be applied. The Start Date should be the same date used in the Roles section of the prior tab.

5. Click Save.

Add Employee Properties for the Web Service Role (Optional)

Employee properties can be used in Advanced integrations, and the system-level “Identity Provider Integration” property can be used to limit the included employees in the Standard integration. When Employee Properties are used, the web services role must have specific permission to access each enabled property.

1. Go to HR Admin > Employee Properties.
2. Select the property from the left pane.
3. In the Role Security field, select the roles that should have access to the property.
   Note: The Dayforce web application makes an employee property available to all users when no roles are selected. If any role is selected in Role Security, the web application applies the security to the property and limits access to only the configured roles. To meet privacy expectations, Dayforce web services requires individual permission for each property to be included.
    

Integrating a Subset of the Employee Population

Customers requiring a specific set of employees to be included in the integration can use a combination of two configuration approaches to achieve the desired results, which include:

• Adjust the Integration User Account’s Permissions
• Use the Identity Provider Integration Employee Property to Flag Included Employees

Adjusting the Integration User Account’s Permissions

If the employees that need to be included in the integration are in specific org units, it might be possible to limit the integration’s user account to specific areas.

1. In Dayforce, go to System Admin > Users and open the user account.
2. In the Location Access tab, add a location record to the grid for each org unit containing employees that will be included in the integration.
3. Click Save.

Using the Identity Provider Integration Employee Property to Flag Included Employees

If further filtering of the employee population is required, the system-level “Identity Provider Integration” Employee Property can be used.
To enable the property for use with the integration:

1. Add role access permissions to the property as described above to ensure:
   • The integration user account’s role has access to the property.
   • Any Dayforce user roles who need to maintain the property’s values for employees have access to the role.
2. Populate the value for the employees that will be included in the integration.
   • This can be accomplished using the employee profile details from the People to update specific employees or using the HR Import process to modify the necessary employees in mass.

Testing the Dayforce Configuration

After the web services security configuration steps are complete in Dayforce, confirm the security settings using the Dayforce Developer Network site (https://developers.dayforce.com). The purpose of this process is to confirm the security access to the data elements that are available for use with Dayforce Identity Integration. The tools in the Dayforce Developer Network site help testing at this level without the risk of changing any data in your Dayforce instance.
For this process, you will need:

• Your Dayforce Company Name
• The credentials (Username and Password) for the user account established in the previous section
• XRefCodes for employees whose data you can confirm
  Recommendation: Select employees from multiple locations and departments so you can confirm security access to the individuals and compare data.

Establishing a Dayforce Developer Network Account

Dayforce provides a Developer Network site for clients and third parties to learn about the available web service operations, download developer documentation and test security configurations before turning the web services user account over to development or third-party resources. There is no cost associated with using the site, and anyone can register.
To create a new account:

1. Go to https://developers.dayforce.com.
2. Click Register.
3. Complete the user registration screen:
   • The Environment field is used to direct the web services operation to the correct instance for your company. The field value is defaulted to Sample, which enables users to execute API requests against a sample instance of Dayforce. Select the correct environment (for example, Production) where your instance resides. Changing the value to something other than Sample will result in the Dayforce Company field being displayed.
   • The Dayforce Company field provides the Company Name that is used in the Dayforce login process (for example, the Namespace of your Dayforce instance) to the web services login process.
     Note: The Environment and Dayforce Company fields can be changed at any time by clicking your name in the upper right corner of the screen and selecting the Edit Your Profile option after you sign in. Changing the Environment value to Sample will result in API requests using the sample instance of Dayforce.
4. Review the Terms of Use and Privacy Policies.
5. Click Register.
6. The screen will direct you to check your email for the confirmation message sent by the site. Open your email client.
7. Open the “Confirm Your Registration” message from donotreplyweb@Dayforce.com.
   Note: If you do not see the message in your Inbox, please check your Junk folder.
8. Click on the link in the message body to confirm your account. Your account cannot be used until this step is completed.
9. The site will open in your default web browser. Click Confirm Registration to complete the registration process.

Confirm the Person- and Field-Level Security Configuration

When a new user account is created for web services use, or an existing web services user account is changed, use the Dayforce Developer Network to ensure the person- and field-level security are acceptable prior to releasing the credentials to another party.

1. Go to https://developers.dayforce.com.
2. Click Sign In.
3. Provide your user account credentials for the site and click Sign In.
4. In the upper right corner of the screen, click your name and select Edit Your Profile.
5. Ensure the Environment and Dayforce Company values are correct for the instance of Dayforce you need to test.
6. Click Save to save changes and return to the main screen.
7. In the left-side navigator, expand API Explorer.
8. Expand Employee.
9. Click GET Employee Details.
   • This web services operation is used by the Dayforce Identity Integration process to retrieve the currently effective details for a specified employee.
10. Click in the section under (Click method to expand) to display the API user interface for the operation.
    Note: When the API user interface expands, it will be defaulted to read only.
11. Click Try it out to switch to edit mode.

    

12. Enter the XrefCode for your first test employee in the xRefCode field.
13. Copy the following string and paste it into the expand field:
    Addresses,Contacts,EmployeeManagers,EmployeeProperties,EmploymentStatuses,EmploymentTypes,UnionMemberships,WorkAssignments
    Note: The GET Employee Details operation retrieves only information from the Employee master record by default. The expand field is used to specify additional child records that should be included in the response.
14. If the clientNamespace value is not defaulted properly, enter the Company Name (client Namespace) used to sign into the Dayforce web application.
15. Click Execute.
16. A prompt will display requesting your credentials. Provide the Username and Password created for Dayforce Identity Integrations and click Sign In.
    • Depending on your browser settings, the credentials might be cached so the site does not repetitively prompt for the credentials.
    • If at any point you need to clear the cached credentials, hold down [Control] + [Shift] + [Delete] to open a screen that allows you to select information to clear. Clearing cookies, passwords and sign-in data should remove the credentials in the background and allow the credentials prompt to appear the next time Execute is clicked.
    • Clicking Sign in will attempt authentication with your Dayforce instance. If the attempt is successful, your web services request will execute. If the sign in attempt is not successful, you will be prompted again for credentials.
17. When the request successfully executes, the Server Response section under the Execute button will display “200” as the response Code, and the Response Body area will contain information for the fields that are allowed.
    • If the Code value is not 200, review the error message in the Response body to determine the source of the issue and adjust the Dayforce User and Role configurations as needed.

      

18. When the request completes successfully, only the fields with populated values that are allowed for the user account’s (primary) role will be included in the results. The response is displayed in the JSON format, where:
    • Field names appear on the left side of the colon. These are the names that were configured in the Web Services Field-Level Access section.
    • Field values appear on the right side of the colon.
    • Child tables appear as “TableName” with the corresponding fields indented underneath:

      

19. Scroll through the Response body section to verify that only the allowed fields are included and that the field values appear as expected.

    Note: This process is easiest using two browser windows to do a side-by-side comparison of the results in the Dayforce Developer Network site with the information in the People > Employee Profile in Dayforce.

20. If necessary, adjust configurations as needed in Dayforce to refine access to specific fields.

    Note: It is not necessary to start a new Dayforce Developer Network session when permissions are changed in Dayforce. The new permissions should be respected when the next request is executed.

21. Repeat the process to verify the information for your remaining test employees.
22. After your testing is complete, the user credentials can be used within the Aquera application to retrieve data from your Dayforce instance.