Integrating SailPoint with Workday

The SailPoint Workday connector extends a deep level of management on your Workers and Contingent Workers present in Workday HCM. It offers the seamless automation of Joiner, Mover, and Leaver use cases.

This guide is designed to give specific information about the requirements and field definitions needed to get a working instance of a Workday source in SailPoint.

Supported Features

The Workday source supports the following features:

• Account Aggregation

  • Aggregate Workday worker records
  • Aggregation of records based on future hire, terminations, and onboarding events
  • Aggregation of Custom IDs
  • Aggregation of Rescinded Past Hire Records
  • Aggregation of Rescinded Future Hire Records
  • Aggregation of Custom and Calculated Attributes

  • Aggregation of Pre-Hire Records

    Note

    Pre-Hire records are supported only for OAuth 2.0 authentication and for full aggregation.

  Note

  The schema attribute for a Custom ID should be added with the __CUSTID suffix, and the XPath entry should be added in the XPath Schema Mapping section.

• Delta Aggregation

  Note

  Delta aggregation is not supported for calculated attribute changes and Custom ID changes in the Workday connector.

• Account Update

  • Update and deletion of email and phone information:

    • EMAIL_ADDRESS_HOME
    • EMAIL_ADDRESS_WORK
    • ADDITIONAL_EMAIL_ADDRESS_HOME
    • ADDITIONAL_EMAIL_ADDRESS_WORK
    • WORK_MOBILE
    • WORK_TELEPHONE
    • HOME_MOBILE
    • HOME_TELEPHONE

    For more information, refer to Support for Deletion of Contact Information.

  • Update of custom attributes and IDs. Refer to Aggregation and Provisioning of Custom IDs for more information.

  • Update of USERID.

  Note

  The USERID is internally mapped to the USER_NAME of the Workday managed system. To update the USERID, it is required to have a Workday account associated to that worker.

• Pre-Hire Records

  • Update and deletion of email and phone information:

    • EMAIL_ADDRESS_HOME
    • EMAIL_ADDRESS_WORK
    • ADDITIONAL_EMAIL_ADDRESS_HOME
    • ADDITIONAL_EMAIL_ADDRESS_WORK
    • WORK_MOBILE
    • WORK_TELEPHONE
    • HOME_MOBILE
    • HOME_TELEPHONE

  Note

  For Pre-Hire records, username updates are not supported.

Supported Managed Systems

The Workday connector supports the following versions of the Workday system:

• Workday API version 44.2
• Workday API version 40.2

Required Permissions

This section describes the permissions required for the Workday source on the Workday managed system.

Permissions for Basic and OAuth 2.0 authentication types:

• For Basic authentication, refer to Basic Authentication.

• For OAuth 2.0 Authentication, the following functional areas under the API client integration are required: Staffing, System, Contact Information, Personal Data, Integration, Organization, and Roles.

• For Delta Aggregation permissions, refer to Permissions to Business Processes for Delta Aggregation.

The account used under the API Client to generate a refresh token must be an Integration user and must have all the permissions. For more information about API client creation and permissions, refer to Create API Client for Integration.

Basic Authentication

This section provides the details of the required permissions for the Basic Authentication type.

Creation of Integration User

1. On the Workday system, search for the Create Integration System User task and enter the required details for Account Information in the task (User Name, Password, etc) for the first integration user. For example, SailPoint_Read_User.

Creation of the Integration Security Group

This section describes creation of the integration security group for constrained and unconstrained security groups.

Constrained

1. On the Workday system, search for the Create Security Group task.
2. Select Integration System Security Group (Constrained).

3. Provide a name to the integration group. Create two groups as follows:

   • For the Read group (SailPoint_Read_Group)

4. Add the Integration System Users (SailPoint_Read_User, SailPoint_Write_User, or both) created in Creation of Integration User to the respective groups.

5. Select single or multiple organizations for whom the integration group would have access.

   Note

   The organizations selected have to be of the same type (such as SUPERVISORY, COST_CENTER).

6. For access rights to organizations, select the option for Applies to Current Organization Only.

Unconstrained

1. Create the Integration System Security Group (Unconstrained).

2. Perform the following for the Integration System Security Group:

   • Add the Integration System Users (SailPoint_Read_User, SailPoint_Write_User, or both) created in Creation of Integration User in the Integration System Security Group (Unconstrained). The permissions are given to integration system groups that are attached to the integration system.
   • Modify the Integration System Security Group to associate the Maintain Contact Information domain.
   • Modify the Integration System Security Group to associate the domains required by the Workday Integration System.

Assign Permission to the Security Group

1. On the Workday system, go to the Actions item of the group created in Creation of the Integration Security Group and select Security Group.

2. On the Security Group panel, select Maintain Permissions for Security Group from the list.

3. Add the domain security policies permitting the GET access list for the Read groups, respectively:

   Get Permissions for Read
   Worker Data: Public worker reports Worker Data: Current staffing information Worker Data: General staffing information Worker Data: Time in position Worker Data: Active and terminated workers Manage: Organization Integration Person Data: Home Email Person Data: Home Phone Person Data: Work Email Person Data: Work Phone Workday Accounts Workday Accounts (Functional area: System)

4. Select Done.

5. Search for the Activate Pending Security Policy Change task and run it.

Permissions to Workday Web Service

Modify the Integration System Security Group to associate required permissions for the following Workday Web Services:

Get References

1. Search for the Create Integration System Security Segment task and provide the required details.
2. Add the Specific Integration System or select All Integration Systems, and then select Done.
3. Search for the Create Security Group task.
4. Select the Type of Tenanted Security Group as Segment-Based Security Group and provide a name to it.
5. Add the integration group (read) created in Creation of the Integration Security Group to Group Criteria > Security Groups.
6. Add the segment created in Step 5 to Access Rights > Access to Segments.
7. Select OK.
8. Go to Actions of Segment-Based Security Group and select Maintain Security Permissions from the Security Group.
9. Add Integration Build as the Domain Security Policies permitting Get access.
10. Select OK > Done.
11. Search for the Activate Pending Security Policy Change task and run it.

Maintain Contact Information, Home and Work Contact Change:

1. Depending on the type of Workday Web Services, search for the respective business process:

   Workday Web Service	Business Process
   Maintain Contact Information	Contact Change (bp:contact change)
   Home Contact Change	Home Contact Change (bp:home contact change)
   Work Contact Change	Work Contact Change (bp:work contact change)

2. Go to Business Process Policy > Action of Contact change business process and select Edit.

3. Depending on the type of the Workday Web Services, add the Security Group created in Creation of the Integration Security Group (for example, SailPoint_Read_Group and SailPoint_Write_Group) to the Initiating Action of the respective Workday Web Services:

   Workday Web Service	Business Process
   Maintain Contact Information	Maintain Contact Information (Web Service)
   Home Contact Change	Change Home Contact Information (Web Service)
   Work Contact Change	Change Work Contact Information (Web Service)

4. Select OK > Done.

Permissions to Business Processes for Delta Aggregation

The Integration System Security Group which has the respective administrator user associated with it must have the View Completed Only permission for the related Business Process Security Policy.

Perform the following procedure to provide permissions to business processes for delta aggregation:

1. Search for the Personal Information Change business process.
2. Go to Personal Information Change > Business Process Definition > Business Process Policy > Actions > Edit.
3. Select Edit and then go to the Who Can Do Action Steps in Business Process section.
4. Add the read security groups created in Creation of the Integration Security Group (SailPoint_Read_Group) to the View Completed Only security groups list.

5. The steps above should be followed for all the Business Process Types in this table:

   Events	Business Process Type
   Hire Employee	Hire
   Onboarding	Onboarding
   Terminate Employee	Termination
   Change Personal Information	Personal Information Change
   Contact Information Event	Contact Change
   Change Job	Change Job
   Change Legal Name	Legal Change Name
   Change Business Title	Title Change
   Add Retiree Status	Add Retiree Status
   Assign Organization Roles	Assign Roles
   Change Owner	Assign Self-Assign Roles
   Assign Superior	Assign Superior
   EMERGENCY_CONTACT_EVENT	Change Emergency Contacts
   Change Organization Assignments for Worker	Change Organization Assignments for Worker
   Change Primary Address	Change Primary Address
   Contract Contingent Worker	Contract Contingent Worker
   Create Change Order from Contingent Worker Contract	Create Change Order from Contingent Worker Contract
   Create Primary Address	Create Primary Address
   Edit Worker Additional Data	Edit Worker Additional Data
   Maintain Employee Contracts	Employee Contract
   End Additional Job	End Additional Job
   End Contingent Worker Contract	End Contingent Worker Contract
   Change Marital Status	Marital Status Change
   Move to New Manager	Move to New Manager
   Assign Worker	Move Worker (By Organization)
   Move Workers Staffing	Move Worker (Supervisory)
   Assign Workers	Move Workers (By Organization)
   New Hire Provisioning	New Hire Provisioning
   Change Preferred Name	Preferred Name Change
   Request Worker	Request Worker
   Submit Resignation	Submit Resignation
   Transfer Contingent Worker	Transfer Contingent Worker
   Transfer Employee	Transfer Employee

6. Search for the Activate Pending Security Policy Change task and run it.

Permission to Workday Query Language Domain

1. On the Workday system, search for Domain Security Policies for Functional Area. Enter system in the Functional Area text box.
2. Search for Workday Query Language and select edit permission.
3. Provide view and modify access to the Integration security group created in earlier steps.

Permission to the Worker Data Source

1. On the Workday system, navigate to Domain Security Policies for Functional Area. Enter staffing in the Functional Area text box.
2. Search for Worker Data: Staffing and select Edit Permission.
3. Provide view and modify access to the Integration security group created in earlier steps.

OAuth 2.0 Authentication

This section provides the details of the required permissions for the OAuth 2.0 Authentication type:

1. Create the API Client. For more information on API Client creation, refer to Create API Client for Integration.
2. The Workday Account used by the API Client to generate a refresh token must be an integration user, and it must have all the permissions as described in Basic Authentication.

3. Add all of the following functional areas under the API Client Integration used for OAuth 2.0:

   • Staffing
   • System
   • Contact Information
   • Personal Data
   • Integration
   • Organization and Roles

4. Provide access to the Integration security group for the Workday Query Language domain in the System functional area.

5. Provide access to the Integration security group for the Worker Data source.

Permission to the Pre-Hires

The following permissions are required for the user in Workday.

Aggregating Pre-Hire Data:

To enable aggregation of Pre-Hire data, add the following permissions. These permissions should be configured only if the user is interested in aggregating Pre-Hire information.

1. Under Domain Security Policies permitting View access:

   • Manage Pre-Hire Data
   • Manage Pre-Hire Process
   • Worker Data: Worker ID

2. Under Domain Security Policies permitting Get access:

   • Manage Pre-Hire Process: Manage Pre-Hires

Updating the Provisioning Pre-Hire Data:

If an update is required for Pre-Hire data, add the following permission:

• Functional Area: Pre-Hire Process

• Under Domain Security Policies permitting Put access:

  • Manage Pre-Hire Process: Manage Pre-Hires

(Optional) Additional Administrator Permissions

To access additional standard attributes, the user must have access to the corresponding standard attributes. For more information, refer to XPath to Support Additional Standard Attributes in Schema.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.