# 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. > [!NOTE] > > To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes]() page. ## 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 > [!NOTE] > > The Workday connector uses Workday's SOAP API, which is independent of the Workday system version, and is backward compatible. ## 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](<#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](<#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](<#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](<#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. > [!NOTE] > > The Workday fields in the Workday Managed System that are marked as private are not accessible through the Workday API. The fields marked as public are accessible. To ensure that the Workday source aggregates all applicable attributes, you must mark them as public. ### 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](<#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: | Workday Web Services | GET Permissions | PUT Permissions | | --- | --- | --- | | Get References | Yes | NA | | Maintain Contact Information | Yes | Yes | | Home Contact Change | NA | Yes | | Work Contact Change | NA | Yes | **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](<#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](<#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. > [!NOTE] > > If schema attributes are not related to any of the following events, then the permission for that Business Process Type is not required. 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](<#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](<#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. > [!NOTE] > > Configure OAuth 2.0 authentication using a designated service account. Ensure this service account has all the required permissions and access scopes, as defined in the Basic Authentication configuration section. ### 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]().