# SailPoint Workday Connector Documentation > Workday Connector Documentation # Documentation # Configuring Workday for Integration ## Future Dated Workers The Workday source fetches future-dated workers for the following events: Hire Employee, Terminate Employee, Onboarding, and End Contingent Worker Contract. This creates a mismatch in the Delta Aggregation task result, as the source receives two records in the following scenarios: - A Contract Ended employee is hired in the future within the Effective Offset Date. - A Terminated employee is hired as a Contingent worker in the future within the Effective Offset Date. - A Contracted employee is hired as a full-time employee in the future within the Effective Offset Date. For example, Account scanned 446 and the actual account count would be 445. To fetch future data using any additional business process apart from the events listed above, the **Future\_Hire\_Events** and **Future\_Termination\_Events** keys contain hiring and termination events respectively. **Key**: `connector_Future_Hire_Events`, `connector_Future_Termination_Events` **Value**: value of the key. For example: ```text ["Contract Contingent Worker","Edit Position","Change Business Title","Transfer Employee"] ``` For example, if a contractor is a future hire using the Contract Contingent Worker event (which is not part of the default business processes above), and `FUTURE_ACTION` and `FUTURE_DATE` are required, you would update the XPath of `FUTURE_ACTION` and `FUTURE_DATE` to include that business process type alongside the defaults (Hire Employee, Terminate Employee, Contract Contingent Worker, End Contingent Worker Contract). ## Managed System Attributes Mapping and Synchronization You can add and synchronize attributes such as user name, phone numbers, and email addresses by mapping the source attributes to the identity attributes. You then map those identity attributes to the Workday managed system attributes using the SailPoint REST API. > [!NOTE] > > SailPoint does not recommend changing the value of Identity Attributes, as the Workday source aggregation logic is based on the provided default value of the Identity Attributes. **Prerequisites:** - Get the [source ID](<#get-the-source-id>). - Add the PROVISIONING [feature string]() in the Workday source. - In the Workday tenant, the Integration group needs to be given Get and Put permissions to Maintain Contact Information (Web Service). Perform the following steps for attribute mapping and synchronization: 1. Perform a GET request: `GET https://{orgName}.api.cloud.sailpoint.com/beta/sources/{workdaySourceID}/attribute-sync-config` 2. Set the managed system value: `PUT https://{orgName}.api.cloud.sailpoint.com/beta/sources/{workdaySourceID}/attribute-sync-config` 1. To set up `WORK_TELEPHONE` as a target attribute, use the following command in the body: ```json { "attributes": [ { "name": "telephone", "displayName": "telephone", "enabled": true, "target": "WORK_TELEPHONE" } ] } ``` > **Note** > > You can set up other attributes (`WORK_MOBILE`, `HOME_MOBILE`, `HOME_TELEPHONE`) in the same way. 2. For setting up `USERID` as a target attribute, use the following command in the body: ```json { "attributes": [ { "displayName": "userid_value", "enabled": true, "name": "userid_value", "target": "USERID" } ] } ``` For updating the user name in Workday, set `USERID` as the target in the Identity mapping. For example, if you want to update Active Directory's `samAccountName` to a Workday `USERID`, define the identity mapping using the SailPoint API: for Source mapping, the Source Application is Active Directory and the source attribute is `samAccountName`; for Target mapping, set Workday as the Target Application and `USERID` as the Target attribute. To update the `USERID`, a Workday account must be associated to the worker. ## Get the Source ID 1. Sign in to SailPoint and go to the Admin interface. 2. Go to **Connections \> Sources**. 3. Search for the Workday Source, and select **Edit**. The cloud source ID is displayed at the end of the URL in your browser address. ## Fetch Workers by Organization Type When the Don't allow terminated account option is selected, the Workday source uses the default **COST\_CENTER** organization for full aggregation. To change the default organization type, update the **Organization Type** configuration parameters per your requirement. For example, the value can be `SUPERVISORY`. **Key**: `connector_Organization_Type_ID` **Value**: `SUPERVISORY` ## Support for Filtering Using Eligibility Criteria Eligibility criteria are filters (Workday calculated fields) configured on the Workday system which are used to aggregate specific data in the Workday connector. The Calculated Field configured on the managed system acts as a filter based on the operators, regular expressions, or conditions. The Calculated Field can co-exist with other supported filters such as Organization filters and Future/Past offsets. Eligibility criteria configuration requires values of the following fields for configuration: - **Integration Field(s)** must be mapped with the Calculated Field (on the managed system). - **Integration System ID** - **Integration Field Override Service** > [!NOTE] > > To read the condition defined for eligibility criteria, the user must assign the read permissions to the integration user. **Examples of different scenarios:** The aggregation result is a UNION when multiple eligibility criteria filters are used. #### Example A: Multiple Eligibility Criteria Filters (Filter1 and Filter2) Condition for Filter1: Workers having a name starting with character A, the result is 50 records. Condition for Filter2: Workers having a name starting with character S, the result is 30 records. When both filters are set, aggregation retrieves the data of all workers having a name starting with A or S, that is, 80 worker records are aggregated \[Filter1 UNION Filter2\]. #### Example B: Eligibility Criteria Filter Combined with Other Filters (Organization Reference ID Filters) The aggregation result is an INTERSECTION for the eligibility criteria filter when configured with other filters (Organization reference ID filters). In addition to the above filters (Filter1 and Filter2 used in Example A), when the organization level filter (`IT_DEPT_ORG_REF_ID`) is added in the configuration, **IT\_DEPT\_ORG\_REF\_ID** has 100 records, of which the number of workers having A as initials is 15 and having S as initials is 15. When the organization reference filter is used in Example A, aggregation fetches 30 records \[IT\_DEPT\_ORG\_REF\_ID intersection (Filter1 union Filter2)\]. #### Example C: Eligibility Criteria Filter Added Based on Certain Calculations If the eligibility criteria filter is added based on certain calculations that will change the worker lifecycle, the added filter acts as a superset. **Condition**: Eligibility criteria filter is written on Job code = CSTA, so only those records are aggregated that have the job code CSTA. With additional conditions, you can retrieve terminated employees within 60 days, where 60 defines the offset. In such cases, if any of the terminated records do not have the Job Code, the records are excluded from aggregation. **Example**: JIM is an active worker with Job Code = CSTA. If you have defined eligibility criteria using JOB CODE, the record would be aggregated; however after the termination of JIM, the source does not aggregate JIM even if the configuration supports aggregation of terminated workers. After termination, the Job Code is removed from the worker record and the eligibility criteria filter is written on 'Job code' = CSTA, which takes precedence with other filters and configurations to retrieve additional data (that is, the terminated records, based on the past termination offset provided in the source). ## Rescinded and Corrected User Records The Workday source aggregates the following attributes for the rescinded and corrected user records: - `FUTURE_ACTION` - `FUTURE_DATE` - `LAST_DAY_OF_WORK` > [!IMPORTANT] > > When an account contains multiple `FUTURE_DATE` and `FUTURE_ACTION` records, the connector retrieves the record with the date closest to the `asOfEffectiveDate` (calculated using the effective offset). For example, if an account A has `FUTURE_DATE` and `FUTURE_ACTION` records for the 5th, 8th, and 10th date of a month and the aggregation is run on the 1st date of the month with effective offset as 15 days, the `asOfEffectiveDate` calculated is `AggregationDate + 15 = 16th` of the month. The `FUTURE_ACTION` and `FUTURE_DATE` record of the 10th is nearer to the `asOfEffectiveDate` (the 16th), so the connector aggregates the 10th record and skips the 5th and 8th records. | User Records | Description | | --- | --- | | Rescinded | Hire records: If the hired worker is rescinded on the Workday managed system, the source returns that record in full aggregation. | | Rescinded | Terminate records: If the worker is terminated and termination is rescinded on the Workday managed system, the source returns the updated data accordingly. The source deletes the Future\_Action and Future\_Date for future termination after the full aggregation. | | Corrected | Hire and Terminate records: If the future hiring/terminating worker process is corrected in the Workday system (that is, another hire date has been set up other than the existing one), the source corrects the data according to the Workday managed system. The specified corrected event date must be within the offset range. | ### Aggregation of Rescinded Future Hire Records The Workday source supports aggregation of the future rescinded hire records. The following are mandatory to support this feature: - Add the `IS_RESCINDED` attribute to the account schema. - Enable the **Aggregate Rescinded Future Hires** option in the UI. With this feature, the source maintains the account link for future rescinded hires, which can be used to trigger workflows. The link is maintained with the following attributes for rescinded future hires, after full or delta aggregation: email, file number, future action, future date, `IS_RESCINDED`, first name, and last name. On the Workday source UI, select **Aggregate Rescinded Future Hires** to retain the record for the canceled future hires to support the leaver workflows. ### Aggregation of Rescinded Past Hire Records The Workday source supports aggregation of the rescinded past hire records. To support this feature, add the `IS_RESCINDED`, `RESCINDED_DATE`, and `RESCINDED_DESCRIPTION` attributes to the account schema. With this feature, the source maintains the account link for rescinded past hires, which can be used to trigger workflows. On the Workday source, in the **Aggregation Settings \> Filter Settings** section, select **Aggregate Rescinded Past Hires** to retain the record for the canceled past hires to support the leaver workflows. > [!NOTE] > > - To fetch rescinded past hires data for a worker, their hire date must be in the **Past Rescinded Offset** range. > - The link is maintained for rescinded past hires after full or delta aggregation. ### Aggregation of Corrected Future Hire Records The Workday source supports aggregation of the corrected future hire records, whether or not they are in the Future Offset range, if the `deleteRescindCorrectedLink` attribute is marked as `false`. With the `deleteRescindCorrectedLink` attribute marked as `true`, the link for corrected future hire records falling outside the future offset range is not maintained. By default, `deleteRescindCorrectedLink` is `false`. If you do not include this attribute in your configuration, the source maintains the account link for corrected future hire records whether or not they fall within the Future Offset range. If you want to update the source with the flag, use the following API body: ```json [ { "op": "Add", "path": "/connectorAttributes/deleteRescindCorrectedLink", "value": "true" } ] ``` ## Aggregation and Provisioning of Custom IDs The Workday source supports the aggregation of Custom IDs along with the following features: - Updating and provisioning the pre-existing value of custom IDs. - Updating the Identification value/section of custom IDs. > [!NOTE] > > - Aggregation of custom IDs is supported for all Workday API versions. Provisioning of custom IDs is supported for all Workday API versions 32.1 and later. Delta aggregation does not retrieve updated values for custom IDs in the Workday connector. > - The Workday source supports updating a custom ID (other ID) even if it is blank on the Workday managed system. The PUT permission to change other IDs (Web Service), `change_other_id`, is required to provision custom IDs. Perform the following configurations: 1. The schema attribute must be added with the `__CUSTID` suffix (`CUSTID`) for the Custom ID. > **Note** > > `__CUSTID` is case sensitive. For example, if `Applicant_ID` is a custom ID, add `Applicant_ID__CUSTID` to the schema. 2. Add an entry in the XPath Schema Mapping for the custom ID schema attribute added in Step 1, where the value of the entry is the XPath required to fetch the required field: ```text ns1:Worker_Data/ns1:Personal_Data/ns1:Identification_Data/ns1:Custom_ID/ns1:Custom_ID_Data[ns1:ID_Type_Reference/ns1:ID[@ns1:type='Custom_ID_Type_ID']='']/ns1:ID ``` Perform the following steps to obtain the required value of `Custom_ID_Type_ID`: 1. Sign in to the Workday managed system. 2. Search for View Custom ID Types and select an **Identifier Type** of the required custom ID. 3. Go to **Integration IDs \> View IDs**. 4. Under **Reference IDs**, copy the **ID** value and place it at `` in the XPath. 5. Ensure that the final XPath is as follows: ```text ns1:Worker_Data/ns1:Personal_Data/ns1:Identification_Data/ns1:Custom_ID/ns1:Custom_ID_Data[ns1:ID_Type_Reference/ns1:ID[@ns1:type='Custom_ID_Type_ID']='CUSTOM_ID_TYPE-6-11']/ns1:ID ``` ## XPath to Support Additional Standard Attributes in Schema The Workday source provides support to aggregate fields in addition to the fields present in the default account schema. The default Workday source includes XPaths for all default business processes. If you must aggregate future data and future actions for a different business process, you must define the new XPaths for that business process. To fetch additional standard Workday fields during account aggregation: 1. Add the attributes to the account schema. 2. Provide the XPath for the attributes. For example, to fetch the work email address, add an entry in the **XpathAttributesMap**: **Key**: `EMAIL_ADDRESS_WORK` **Value**: ```text ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Email_Address ``` > [!NOTE] > > If you add the XPaths for a new business process, you have to provide all XPaths for all business processes. This must include the defaults along with the new XPaths. ## Support Additional Multi-value Attributes for XPath The Workday source provides support to aggregate multi-valued attributes. To fetch additional multi-value Workday attributes during account aggregation: 1. Add the attributes to the account schema and mark them as multi-valued. 2. Provide the XPath for those attributes. For example, to fetch roles, add an entry in the **XpathAttributesMap** where the value of the entry is the XPath required to fetch the required field: ```text key="Organization_Role" value="ns1:Worker_Data/ns1:Role_Data/ns1:Organization_Role_Data/ns1:Organization_Role[*]/ns1:Organization_Role_Reference/ns1:ID[@ns1:type='Organization_Role_ID']" ``` > **Note** > > The asterisk `[*]` is used to select a list of nodes matching the XPath expression. The expression `[*]` in the XPath fetches all the values pertaining to the attribute in the account schema. ## Support for Automatic Provisioning Approval You can configure the Workday connector to bypass the approval process for provisioning requests and automatically process any updates. To enable this functionality, add the following to SailPoint via REST API: ```json [ { "op": "add", "path": "/connectorAttributes/autoComplete", "value": "true" } ] ``` ## Support for Reference Descriptors in Response from Workday System The Workday source supports fetching reference descriptors in a response from the Workday System. If you want to include reference descriptors in a response, use the following API body: ```json [ { "op": "add", "path": "/connectorAttributes/addReferenceDescriptorsInResponse", "value": "true" } ] ``` ## Support for Deletion of Contact Information The Workday source provides support for deletion of contact information (phone and email attributes) of an employee record by using the following entry keys: - For phone, use the `connector_deleteAllPhoneRecord` key and value `false`. - For email, use the `connector_deleteAllEmailRecord` key and value `false`. > [!NOTE] > > This feature is supported for Workday API versions 30.1 and 32.1. The following table describes the different scenarios: | Attribute Type | deletePhoneRecord = True | deletePhoneRecord = False | deleteAllEmailRecord = True | deleteAllEmailRecord = False | | --- | --- | --- | --- | --- | | Primary | Delete all phone contact information (Primary and Additional) | If only the Primary Phone record is present, the source successfully deletes it. If the Primary Phone record is present with any additional Phone record(s), the request fails and the source logs an error. | Delete all mail contact information (Primary and Additional) | If only the Primary mail record is present, the source successfully deletes it. If the Primary mail record is present with any additional mail record(s), the request fails and the source logs an error. | | Additional | Delete all phone contact information (Primary and Additional) | If the Phone record is present with a unique contact type (mobile/telephone...), the source successfully deletes it. If the Phone record is present with two of the same contact type records, the request fails as the source cannot decide which entry must be deleted (for example, if the additional phone contact list consists of multiple phone entries with the type as telephone). | Delete all mail contact information (Primary and Additional) | If only one additional mail record is present, the source successfully deletes it. If more than one additional mail records are present, the request fails as the source cannot decide which email needs to be deleted (for example, a request to delete `Additional_Email_Address_Work` when there are two additional work emails for a worker). | ## Support for Additional Filters for Response Group Perform the following to support additional filters for the response group when using version 30.1 of the Workday APIs: 1. By default, the newly created Workday source supports the following additional response group filters: | Key | Value | | --- | --- | | `Include_Additional_Jobs` | false | | `Include_Multiple_Managers_in_Management_Chain_Data` | false | | `Include_Subevents_for_Corrected_Transaction` | false | | `Include_Subevents_for_Rescinded_Transaction` | false | | `Include_Collective_Agreement_Data` | false | | `Include_Probation_Period_Data` | false | | `Include_Extended_Employee_Contract_Details` | false | | `Include_Contingent_Worker_Tax_Authority_Form_Information` | false | | `Exclude_Funds` | true | | `Exclude_Fund_Hierarchies` | true | | `Exclude_Grants` | true | | `Exclude_Grant_Hierarchies` | true | | `Exclude_Business_Units` | true | | `Exclude_Business_Unit_Hierarchies` | true | | `Exclude_Programs` | true | | `Exclude_Program_Hierarchies` | true | | `Exclude_Gifts` | true | | `Exclude_Gift_Hierarchies` | true | The default values of the filters can be updated per your requirements. 2. For existing sources, if you want to use the additional response group filters, use the SailPoint REST API: > **Note** > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. **Key**: `connector_Configure_Response_Group` **Value**: the values are as follows. ```json {"Exclude_Companies":"false","Exclude_Company_Hierarchies":"true","Exclude_Contingent_Workers":"false","Exclude_Cost_Center_Hierarchies":"false","Exclude_Cost_Centers":"false","Exclude_Custom_Organizations":"false","Exclude_Employees":"false","Exclude_Location_Hierarchies":"true","Exclude_Matrix_Organizations":"true","Exclude_Organization_Support_Role_Data":"true","Exclude_Pay_Groups":"true","Exclude_Region_Hierarchies":"true","Exclude_Regions":"true","Exclude_Supervisory_Organizations":"true","Exclude_Teams":"true","Include_Account_Provisioning":"false","Include_Background_Check_Data":"false","Include_Benefit_Eligibility":"false","Include_Benefit_Enrollments":"false","Include_Career":"false","Include_Compensation":"false","Include_Development_Items":"false","Include_Employee_Contract_Data":"false","Include_Employee_Review":"false","Include_Employment_Information":"true","Include_Feedback_Received":"false","Include_Goals":"false","Include_Management_Chain_Data":"true","Include_Organizations":"true","Include_Personal_Information":"true","Include_Qualifications":"false","Include_Reference":"true","Include_Related_Persons":"false","Include_Roles":"false","Include_Skills":"false","Include_Succession_Profile":"false","Include_Talent_Assessment":"false","Include_User_Account":"false","Include_Worker_Documents":"false","Include_Additional_Jobs":"false","Include_Multiple_Managers_in_Management_Chain_Data":"false","Include_Subevents_for_Corrected_Transaction":"false","Include_Subevents_for_Rescinded_Transaction":"false","Include_Collective_Agreement_Data":"false","Include_Probation_Period_Data":"false","Include_Extended_Employee_Contract_Details":"false","Include_Contingent_Worker_Tax_Authority_Form_Information":"false","Exclude_Funds":"true","Exclude_Fund_Hierarchies":"true","Exclude_Grants":"true","Exclude_Grant_Hierarchies":"true","Exclude_Business_Units":"true","Exclude_Business_Unit_Hierarchies":"true","Exclude_Programs":"true","Exclude_Program_Hierarchies":"true","Exclude_Gifts":"true","Exclude_Gift_Hierarchies":"true"} ``` 3. Update your existing Workday source with the following: **Key**: `connector_version` **Value**: `use 30.1` 4. Add or update the respective attribute XPath and schema as required based on Workday API version 30.1. ## Support for Application Level Proxy The Workday connector supports connecting to the Workday HCM via an application-level proxy. To use this functionality, add the following parameters to the source via the REST API: | Parameter | Description | | --- | --- | | `http.proxyHost` | Proxy Server Host Name or IP | | `http.proxyPort` | Proxy Server Port Number | | `https.proxyPort` | HTTPS Enabled Proxy Server Port Number | | `http.proxyUser` | Proxy Server User Name | | `https.proxyUser` | HTTPS Enabled Proxy Server User Name | | `http.proxyPassword` | Proxy Server User Password | | `https.proxyPassword` | HTTPS Enabled Proxy Server User Password | > [!NOTE] > > - Ensure that the proxy server is reachable from the SailPoint VA environment. > - To use this functionality for existing connectors, ensure that the `encrypted` parameter has the following values set: `refreshToken,clientSecret,refreshTokenDummy,clientSecretDummy,provisioningPassword,oauth_token_info,http.proxyPassword,https.proxyPassword` ## Performance Improvement With the option to filter out response data, only the required data can be fetched for better performance in account aggregation. You can configure flags to filter data. These configurations are dependent on the default schema attributes, and you can change them as per your requirement. When you change the response filter configuration, you must perform a full aggregation. For a complete set of available configuration flags with the recommended values for the schema attributes, use the SailPoint REST API. **Key**: `Configure_Response_Group` **Value**: the values are as follows. | Key | Default Value | | --- | --- | | `Exclude_Companies` | false | | `Exclude_Company_Hierarchies` | true | | `Exclude_Contingent_Workers` | false | | `Exclude_Cost_Center_Hierarchies` | false | | `Exclude_Cost_Centers` | false | | `Exclude_Custom_Organizations` | false | | `Exclude_Employees` | false | | `Exclude_Location_Hierarchies` | true | | `Exclude_Matrix_Organizations` | true | | `Exclude_Organization_Support_Role_Data` | true | | `Exclude_Pay_Groups` | true | | `Exclude_Region_Hierarchies` | true | | `Exclude_Regions` | true | | `Exclude_Supervisory_Organizations` | true | | `Exclude_Teams` | true | | `Include_Account_Provisioning` | false | | `Include_Background_Check_Data` | false | | `Include_Benefit_Eligibility` | true | | `Include_Benefit_Enrollments` | false | | `Include_Career` | false | | `Include_Compensation` | false | | `Include_Development_Items` | false | | `Include_Employee_Contract_Data` | false | | `Include_Employee_Review` | false | | `Include_Employment_Information` | true | | `Include_Feedback_Received` | false | | `Include_Goals` | false | | `Include_Management_Chain_Data` | true | | `Include_Organizations` | true | | `Include_Personal_Information` | true | | `Include_Qualifications` | false | | `Include_Reference` | false | | `Include_Related_Persons` | false | | `Include_Roles` | false | | `Include_Skills` | false | | `Include_Succession_Profile` | false | | `Include_Talent_Assessment` | false | | `Include_User_Account` | false | | `Include_Worker_Documents` | false | > [!NOTE] > > The Workday source supports the aggregation of the `MANAGER_ID` attribute for both the 'contingent' and 'employee' worker types. > [!NOTE] > > The source containing the `Future_Data_Business_Process` key must be removed and the entry split into child entry format for accurate results - that is, `Future_Hire_Events` and `Future_Termination_Events`. For more information, refer to [Future Dated Workers](<#future-dated-workers>). ## Additional Configuration Parameters Configure any of the following parameters as needed to configure connector operations, aggregation, delta aggregation, and provisioning. Update the parameters using the SailPoint REST API. ### preferFutureTerminatedRecord To enable `preferFutureTerminatedRecord` on existing sources, add the following attribute using the SailPoint REST API: **Key**: `preferFutureTerminatedRecord` **Value**: `true` When a worker has both Future Termination and Future Hire events in Workday and those events are within the provided Effective Date offset, the connector shows the Future Hire details for the worker by default. To change the default behavior and give preference to Future Termination, add `preferFutureTerminatedRecord` as `true` in the connector configuration. ### disableMultipleWorkerRecords Boolean attribute to decide whether to perform aggregation depending on the `LATEST_WORKER_RECORD` calculated field result or not. **Key**: `(boolean)disableMultipleWorkerRecords` **Value**: `true` If the key is set to `true`, you must add the future event maps described in the following sections to capture future data while aggregating. ### Future\_Hire\_Events This list contains events from which workers can be hired in Workday. These events are used while fetching future hiring workers. For example: **Key**: `Future_Hire_Events` **Values**: `["Hire Employee", "Onboarding"]` You can append additional events. ### SKIP\_FUTURE\_TERMINATION Boolean attribute to decide whether to skip future termination events while requesting the future data. **Key**: `SKIP_FUTURE_TERMINATION_RECORDS` **Value**: `true` ### Past\_Termination\_Offset This offset is used while getting the past inactive workers through the past termination event list. **Key**: `Past_Termination_Offset` **Value**: Number of days. For example, `100`. > [!NOTE] > > If no offset is provided, the source uses the date 01 Jan 1970. ### Future\_Termination\_Events This list contains events from which workers can be terminated in Workday. These events are used while fetching future terminating workers. ```text End Contingent Worker Contract Terminate Employee ``` **Key**: `Future_Termination_Events` **Values**: `["End Contingent Worker Contract","Terminate Employee"]` You can append additional events. The following additional keys fetch the data based on various events or filters when `disableMultipleWorkerRecords` is set to `true`. The Workday source correctly aggregates the future-terminating worker records when the future date is updated on the Workday managed system. ### Termination\_Events Used for fetching past inactive workers up to the day of full aggregation. This list contains termination events through which workers were terminated in Workday. **Key**: `Termination_Events` **Values**: `["End Contingent Worker Contract","Terminate Employee"]` ### Termination\_Attributes The list contains additional attributes to be populated when certain workers are terminating in the future. Four default attributes are in the list. For example: **Key**: `Termination_Attributes` **Value**: `["TERMINATION_DATE", "LAST_DAY_OF_WORK", "CONTRACT_END_DATE", "PRIMARY_TERMINATION_REASON_REFERENCE"]` For the existing source, the `Future_Data_Business_Process` key (responsible for getting the future data) must be removed and split into the following child entries for accurate results: `Future_Hire_Events` and `Future_Termination_Events`. > [!NOTE] > > By default, the preceding attributes are part of the future Termination Attributes. You can append additional attributes to the list. ### useChangeContactInfoAPI (Supported only for Workday 30.1 API version onwards) These APIs are used by default in all new Workday sources. To enable the contact change API on existing sources that support the 30.1 API version, add the following attribute using the SailPoint REST API: **Key**: `useChangeContactInfoAPI` **Value**: `true` The new API used to update the contact information has strict validation on the format of the contact used during provisioning. SailPoint recommends including the country code as a prefix (the country code should be in sync with the home or work country address) along with the contact number to be provisioned. ### Include\_Reference\_Descriptors\_In\_Response When set to `true`, includes the reference descriptors in the response: ```text ``` The XPath of the respective attribute must be modified as shown in the following example for the `COUNTRY` attribute: ```text ``` > [!NOTE] > > Using this flag impacts performance. ### pastEffectiveDateOffset To aggregate an account using delta aggregation that has been back-dated (for example, account details such as a termination date that has been set prior to the last aggregation): **Key**: `connector_pastEffectiveDateOffset` **Value**: `30` In the above example, the connector includes account updates up to 30 days old in delta aggregation. > [!NOTE] > > The Workday source does not update the future-dated attributes before the correct effective date in delta aggregation. For accounts that have future termination records on the Workday source, delta aggregation does not fail using the `Organization_Reference_ID`. The Workday source manages the following change events in delta aggregation for workers having a future termination or conversion event: personal details change, job detail change. The Workday source does not aggregate partial records in delta aggregation if the future worker's data is changed beyond the future offset date. ### Delta\_Aggregation\_Events This list contains events that are used while performing delta aggregation. **Key**: `Delta_Aggregation_Events` **Value**: `["Change Personal Information", "End Additional Job"]` This list can be extended, or any event can be removed from the existing events list. The default list includes: Hire Employee, Onboarding, Terminate Employee, End Contingent Worker Contract, Change Personal Information, Contact Information Event, Change Job, Change Legal Name, Change Business Title, Add Retiree Status, Assign Organization Roles, Change Owner, Assign Superior, EMERGENCY\_CONTACT\_EVENT, Change Organization Assignments for Worker, Change Primary Address, Contract Contingent Worker, Create Change Order from Contingent Worker Contract, Create Primary Address, Edit Worker Additional Data, Maintain Employee Contracts, End Additional Job, Change Marital Status, Move to New Manager, Assign Worker, Move Workers Staffing, Assign Workers, New Hire Provisioning, Change Preferred Name, Request Worker, Submit Resignation, Transfer Contingent Worker, and Transfer Employee. > [!NOTE] > > To include or exclude any events in delta aggregation for an existing application, add the `Delta_Aggregation_Events` entry and modify accordingly. ### Provisioning **Effective\_Date\_For\_Contact\_Update**: Used in the provisioning policy to update contact details on a specified date. The allowed date formats are: - `yyyy-MM-DD` - `yyyy-MM-DD+TZ` - the `+TZ` represents a positive differential from UTC. For example, `2025-02-15+05:30` is interpreted as February 15, 2025, in a timezone 5 hours 30 minutes ahead of UTC (for example, India Standard Time). - `yyyy-MM-DD-TZ` - the `-TZ` represents a negative differential from UTC. For example, `2025-02-15-06:00` is interpreted as February 15, 2025, in a timezone 6 hours behind UTC (for example, Central Standard Time). - `yyyy-MM-DDTHH:mm:ss.msTZ` - the `T` serves as a separator between the date and time values and must be included. If the Worker is a future hire and `Effective_Date_For_Contact_Update` is not provided in the provisioning policy, the connector uses the Worker's hire date as the effective date to update the contact details. **autoComplete**: When set to `true`, this enables auto-approval on the contact change business process. In scenarios where approvals are mandatory and you want to skip them while updating attributes from the source, add the following attribute using the SailPoint REST API: **Key**: `autoComplete` **Value**: `true` **Default value**: `false` ### Additional attributes for filter supported in Workday aggregation The **Configure\_Response\_Group** map contains the list of attributes that can be customized based on the requirements. It filters out the data that is not required from aggregation. This is used to improve the performance of the Workday source. For more information, refer to [Performance Improvement](<#performance-improvement>). ## Configuration to Fetch the Custom Attributes in Workday The Workday source supports aggregating custom fields defined as part of the Worker attributes in a Workday tenant. To aggregate the values of custom and calculated fields from Workday into SailPoint, perform the following. > [!NOTE] > > Delta aggregation is not supported for Custom Attributes in the Workday connector. > [!NOTE] > > Aggregation takes more time for a larger number of configured custom attributes and calculated fields. Aggregation is delayed because the value of the calculated fields and custom attributes is calculated at run time, requiring extra time to fetch the calculated values, and because customization rules in the configuration can delay aggregation due to multiple database calls. ### Configuring an Integration System in Workday Perform the following steps to configure the Workday Integration System: 1. Search for Create Integration Field Override Service in Workday, and create a new Integration Field Override Service. 2. Assign a name to the Integration Field Override Service and select the business object as **Worker**. 3. Add the fields, as per your requirement, and provide a name for each field: 1. Select the **Plus** icon to add a new row, and then select **OK**. 2. Choose a name that matches the schema attribute in SailPoint. 3. Define the required settings for the new fields. 4. Select **Done**. 5. Repeat steps a-d for each new field. 4. Create a new Workday Integration System: 1. On your Workday Home page, go to **Integration System \> Create Integration System**. 2. Provide a name for the Integration System. 3. Select **New Using Template** and provide the value Document Transformation. 4. Select **OK**. 5. Go to **Actions \> Integration System \> Configure Integration Attachment Service**. 6. Select the Attachment column and select **Create Integration Attachment Service**. 7. Attach an empty text file and select **OK**. 5. In your new Workday Integration System, add the field override service created in steps 1-2: 1. Go to **Custom Integration Services**. 2. Select the **Plus** icon. Under **Custom Integration Services**, add the field override service created in step 1-2. 3. Select **OK**. 6. Note the System ID for this Workday Integration System. It is required to retrieve the custom or calculated attributes. 7. Search for View Integration System. 8. Enter the name of the Workday Integration System you created in Step 4. 9. Select **OK**. 10. Map the new fields to the correct value: 1. Go to **Integration System \> Configure Integration Field Overrides**. 2. Select the calculated or custom field and map the correct value to it in Override External Field. 3. Select **OK**. 4. Select **Done**. 11. When applicable, grant the required permissions to the Service Account associated with the SailPoint application to aggregate the new custom or calculated fields. 12. In SailPoint, add the following to the Workday source configuration: - Add the Workday Integration System ID from Step 6 to the Integration System ID field. - For each field in Step 3, add the related attributes to the account schema. > **Note** > > Custom and calculated attributes added to the Workday schema must have `__c` appended to the field names created in Workday. For example, if you added `PREVIOUS_EMPLOYER` to Workday, you would add `PREVIOUS_EMPLOYER__c` in the application schema. ## Configuration to Update Custom Attributes in Workday The Workday source supports fetching custom attributes for converted workers and future-dated workers in full and delta aggregation. > [!NOTE] > > In the Workday system, the effective-dated custom attribute is not transferred from contractor to converted employee. You must manually re-enter the details for the worker. The Workday source provides the ability to update custom attributes through REST APIs. Perform the following procedure to update custom attributes: 1. In the Workday managed system, search for the Create Custom Object task. 2. Select the **Workday business object** that the custom object extends from in the **Workday Object field**, and specify it accordingly. 3. Define a Custom Object Name, which is used to group custom fields throughout the application, and select **OK** to proceed. 4. Using the Edit Custom Object task, enter the custom object name. 5. Under the **Field Definitions** section, add the required field labels and specify their types. These fields are associated with the custom object. 6. Add the following security domain permissions to the custom object Integration Process: Integration Process and Integration Security. After applying the required permissions, select **OK**. 7. The Activate Custom Object page appears. 8. The custom object needs to be activated for the update process. Provide a Display Name and other relevant details, then select **OK** to activate the custom object. For example, if `vehicledetails` is the custom object and `vehicleType` is the field or custom attribute associated with the custom object, add the custom attribute `vehicleType__c` to the Workday application schema. Manually add the `restCustomObjectAliasMap` to the application map. If required, the map can have multiple values. Use the SailPoint REST API: **Key**: `(Map)restCustomObjectAliasMap` **Value**: `{"vehicletype__c":"vehicledetails.vehicletype"}` ## Create API Client for Integration 1. Using the Register API Client for Integrations task, register a new API Client for Integrations with the following configurations: 1. **Client Name** 2. Grant type: **Authorization Code Grant** 3. Access token: Bearer 4. Select the **Non-Expiring Refresh Tokens** option. 5. Uncheck the **Disabled** option. 6. Select the **Scope** (Functional Areas): Staffing, System, Contact Information, Personal Data, Integration, Organization and Roles. 2. Use View API Client for Integrations to generate a refresh token: 1. Select the API client (created above) and go to **API Client Actions \> API Client \> Manage Refresh Tokens for Integration**. 2. Select the Workday Account for which the refresh token must be generated and select **Next**. 3. Select the **Generate New Refresh Token** option and select **OK**. ## Upgrade Considerations - The Workday connector supports multiple versions, as mentioned in [Supported Managed Systems](). To specify the version, update the following entry key via the REST API: ```text PATCH https://{orgName}.api.cloud.sailpoint.com/v3/sources/{workdaySourceID} Form-Data: key: connector_version value: ``` Supported values for the API version are 24.1, 30.1, 32.1, 35.2, 37.0, and 39.1. - Depending on the version, the XPath for non out-of-the-box attributes might change for applications, so they may need to be updated. For example, the XPath for the `BIRTHDATE` attribute in Workday API versions 24.1, 30.1, 32.1, 35.2, and 37.0 is `ns1:Worker_Data/ns1:Personal_Data/ns1:Birth_Date`. For version 39.1, the following XPath must be updated in the UI on the XPath Schema Mapping tab: `ns1:Worker_Data/ns1:Personal_Data/ns1:Personal_Information_Data/ns1:Birth_Date`. - The following prerequisites are required for existing sources to use the Pre-Hire functionality: 1. Additional Schema Attributes must be added manually. 2. XPath Schema Mapping should be updated as follows: | Attribute | XPath | | --- | --- | | `PRE_HIRE_ID` | `ns1:Applicant_Data/ns1:Applicant_ID` | | `COMMENT` | `ns1:Applicant_Data/ns1:Recruiting_Data/ns1:Applicant_Comments` | | `DATE_PRE_HIRE_ADDED_TO_SYSTEM` | `ns1:Applicant_Data/ns1:Recruiting_Data/ns1:Applicant_Entered_Date` | | `ELIGIBLE_FOR_HIRE` | `ns1:Applicant_Data/ns1:Recruiting_Data/ns1:Eligible_For_Hire_Reference/ns1:ID[@ns1:type='Yes_No_Type_ID']` | | `REFFERED_BY` | `ns1:Applicant_Data/ns1:Recruiting_Data/ns1:Referred_by_Worker_Reference/ns1:ID[@ns1:type='Employee_ID']` | | `SOURCE` | `ns1:Applicant_Data/ns1:Recruiting_Data/ns1:Applicant_Source_Reference/ns1:ID[@ns1:type='Applicant_Source_ID']` | | `SUFFIX` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Suffix_Data/ns1:Social_Suffix_Descriptor \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Suffix_Data/ns1:Social_Suffix_Descriptor` | | `PREFIX` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Prefix_Data/ns1:Title_Descriptor \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Prefix_Data/ns1:Title_Descriptor` | | `ADDRESS_HOME` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data[ns1:Usage_Data/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='HOME']/@ns1:Formatted_Address \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data[ns1:Usage_Data/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='HOME']/@ns1:Formatted_Address` | | `ADDITIONAL_EMAIL_ADDRESS_WORK` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='false']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Email_Address \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='false']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Email_Address` | | `EMAIL_ADDRESS_WORK` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Email_Address \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Email_Address` | | `MIDDLE_NAME` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Middle_Name \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Middle_Name` | | `POSTAL_CODE` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data[ns1:Usage_Data/ns1:Type_Data/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Postal_Code \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data[ns1:Usage_Data/ns1:Type_Data/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Postal_Code` | | `EMAIL_ADDRESS_HOME` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='HOME']/ns1:Email_Address \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='HOME']/ns1:Email_Address` | | `FIRST_NAME` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:First_Name \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:First_Name` | | `LAST_NAME` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Last_Name \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Last_Name` | | `ADDITIONAL_EMAIL_ADDRESS_HOME` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='false']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='HOME']/ns1:Email_Address \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Email_Address_Data[ns1:Usage_Data[@ns1:Public='true']/ns1:Type_Data[@ns1:Primary='false']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='HOME']/ns1:Email_Address` | | `ADDRESS_WORK` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data[ns1:Usage_Data/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/@ns1:Formatted_Address \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data[ns1:Usage_Data/ns1:Type_Data[@ns1:Primary='true']/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/@ns1:Formatted_Address` | | `FILENUMBER` | `ns1:Worker_Data/ns1:Worker_ID \| ns1:Applicant_Reference/ns1:ID[@ns1:type='WID']` | | `LEGAL_MIDDLE_NAME` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Middle_Name \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Legal_Name_Data/ns1:Name_Detail_Data/ns1:Middle_Name` | | `COUNTRY` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data[ns1:Usage_Data/ns1:Type_Data/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Country_Reference/ns1:ID[@ns1:type='ISO_3166-1_Alpha-3_Code'] \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data[ns1:Usage_Data/ns1:Type_Data/ns1:Type_Reference/ns1:ID[@ns1:type='Communication_Usage_Type_ID'] ='WORK']/ns1:Country_Reference/ns1:ID[@ns1:type='ISO_3166-1_Alpha-3_Code']` | | `WORKER_NAME` | `ns1:Worker_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Preferred_Name_Data/ns1:Name_Detail_Data/@ns1:Formatted_Name \| ns1:Applicant_Data/ns1:Personal_Data/ns1:Name_Data/ns1:Preferred_Name_Data/ns1:Name_Detail_Data/@ns1:Formatted_Name` | # Connecting SailPoint and Workday To connect SailPoint with Workday, perform the following tasks: ## Adding the Source in SailPoint To connect to SailPoint, perform the following steps. Once the connection is made, you can configure it to meet your company's needs. > [!IMPORTANT] > > By default, the provisioning feature is **disabled**, and the connector only supports read-only operations. To support provisioning operations, you must manually enable the feature in the source configuration. **To configure a new source:** 1. Sign in to SailPoint. 2. Go to **Admin \> Connections \> Sources**. 3. Select **Create New**. 4. Search for the connector by entering the name in the search box, and then select **Configure**. 5. In the **Source Name** field, enter a unique and descriptive name for your source. Source names cannot exceed 128 characters. 6. In the **Description** field, provide additional details about the source to help distinguish it from similar sources. This field allows a maximum of 2,000 characters. 7. In the **Source Owner** field, begin typing the name of an owner. Matches appear after you type two or more letters. For more information, refer to [Assigning a Source Owner](). 8. Under **Connection Type**, select **Direct Connection** or **Flat File**. - **Direct Connection** - A direct connection fetches data from the **Virtual Appliance Cluster** you choose as the application connector for the source. A direct connection configuration allows for real-time updates. For more information about configuring and deploying virtual appliances, refer to the [Virtual Appliance Reference Guide](). - **Flat File** - Select the flat file if no connector is available, or if another system restricts the connection. This option allows only reading and aggregating data as a generic/delimited application. Provisioning activity is unsupported, and additional configuration pages like connection settings and aggregation settings are unavailable. 9. If you selected **Direct Connection**, in **Virtual Appliance Cluster**, select the virtual appliance cluster that will be used as the application connector for the source. 10. (Optional) Select a governance group to grant its members [source]() or [role]() sub-admin level oversight of the source and its access. For more information, refer to [Creating and Managing Governance Groups](). 11. If this source represents a primary system containing your organization's personnel records, select the **Authoritative Source** checkbox. For more information, refer to [Creating Identity Profiles](). 12. Select **Continue**. The source is created, and you are navigated to the **Source Setup \> Base Configuration** page. Continue to configure your connected source there. ## Base Configuration Provide the base configuration parameters. Information you entered in the Create New Source dialog is automatically entered into the fields in the Base Configuration page. You can edit this information if necessary. 1. Enter a unique name and description for the source. 2. In the **Source Owner** dropdown list, select the identity that owns this source. - To find a source owner, begin entering their name. 3. In the **Virtual Appliance Cluster** dropdown list, select the virtual appliance to use when communicating with your organization's systems. For more information, refer to [SailPoint Virtual Appliances](). 4. (Optional) If enabled for your organization, select the **Use a Credential Provider** checkbox to manage the source's authentication using a credential provider. > **Note** > > To add a credential provider, go to **Admin \> Connections \> Credential Providers**. For more information about credential providers, refer to [Credential Providers](). 5. Configure the authentication to allow SailPoint to connect to the source. Refer to [Connection Settings](<#connection-settings>) for more information. 6. (Optional) In the **Governance Group for Source Management** dropdown list, select a governance group to associate with this source. For more information about governance groups, refer to [Associating Governance Groups with a Source](). 7. (Optional) Choose whether to enable or disable provisioning for the source. Provisioning is disabled by default. - **Enable Provisioning** - Set the toggle to **Enabled** to allow the source to create, update, and deactivate accounts in the connected source system. - **Disable Provisioning** - Set the toggle to **Disabled** to disable provisioning for the source. Disabling provisioning will prevent the creation, updating, or deactivating of accounts on this source. 8. Select **Save**. ## Connection Settings Provide the information required to connect to the Workday source. [Basic Authentication](<#basic-authentication>) and [OAuth 2.0 Authentication](<#oauth-20-authentication>) types are supported. ### Basic Authentication > [!NOTE] > > **Screenshot** > > [![Basic Authentication connection settings]()]() 1. Enter the **Workday URL** that is used to connect to the Human Resource module of Workday. Use the following URL format: `https://wd2-impl-services1.workday.com/ccx/service/tenant1/Human_Resources`, where `tenant1` is the Workday tenant name. > **Note** > > The Workday source only supports the Human Resource module of Workday. 2. Select **Basic** as the Authentication Type. 3. Provide the following details for the Basic Authentication Type: - **Service Account** - The Workday account with required permissions. The account must be in this format: `@` - **Password** - The password that belongs to the service account. - **Provisioning Administrator** - The name of the provisioning administrator having permission to update the Workday account. - **Provisioning Administrator Password** - The password of the provisioning administrator with update permission. #### REST Client API Configuration For Basic authentication, enable the **REST API** option to perform the provisioning operation on custom objects. > [!NOTE] > > **Screenshot** > > [![REST Client API configuration settings]()]() 1. Enter the **REST API Endpoint** of the Workday server. For example, `https://WORKDAY_HOST/ccx/api/v1/TENANT_NAME` 2. In Token Endpoint, enter the Workday token API endpoint. For example, `https://WORKDAY_HOST/ccx/oauth2/TENANT_NAME/token` > **Note** > > The values of the REST API Endpoint and Token Endpoint can be obtained from the **View API Clients** report in the Workday application. 3. Enter the Workday API **Client ID** and **Client Secret**. 4. Enter the Workday API **Refresh Token**. > **Note** > > Ensure that the token never expires. ### OAuth 2.0 Authentication > [!NOTE] > > **Screenshot** > > [![OAuth 2.0 authentication connection settings]()]() 1. Enter the **Workday URL** that is used to connect to the Human Resource module of Workday. Use the following URL format: `https://wd2-impl-services1.workday.com/ccx/service/tenant1/Human_Resources`, where `tenant1` is the Workday tenant name. > **Note** > > The Workday source only supports the Human Resource module of Workday. 2. Select **OAuth 2.0** as the Authentication Type. 3. Provide the following details for the Refresh Token Grant Type: - **Client ID** - Workday API client ID. - **Client Secret** - Workday API client secret. - **Refresh Token** - Non-expiry Workday API refresh token. > **Note** > > To use OAuth 2.0 authentication in preexisting sources, update the source XML with `connector_key="encrypted" value="refreshTokenDummy,clientSecretDummy,oauth_token_info"` using the SailPoint REST API. - **REST API Endpoint** - The REST API Endpoint of the Workday server. For example, `https://WORKDAY_HOST/ccx/api/v1/TENANT_NAME`. ### Connection Parameters > [!NOTE] > > **Screenshot** > > [![Connection parameters]()]() 1. Enter the value for **Page Size** to fetch the number of records during aggregation in a single call (Limit 1 to 999). Default: 100. 2. Enter the **Connection Timeout** value in minutes. Default: 1 minute. 3. Enter the number of the **Aggregation Thread Size**. The default value is 4 (this is the maximum number of threads). You can set it to a lower value (for example, 2 or 3) depending on the system load. This parallel aggregation improves performance by reducing the time required to finish aggregation. The Workday source aggregates the active and terminated accounts. 4. Enter the value in **Effective Time Zone** that has the location and the time zone based on how the HR data (Hire, Termination, Re-hire, Conversion) is processed. Default: UTC. > **Note** > > SailPoint recommends the use of the Effective Time Zone parameter during aggregation to avoid account issues. For example, if the Workday server is in the PST time zone then enter the America/Los Angeles time zone in this field. The following examples are supported valid timezones for Effective Time Zone: - America/New\_York - America/Los\_Angeles - America/Chicago - PST - HST - Asia/Dubai - CET - GMT - ACT - Australia/Melbourne ## Aggregation Settings This section provides the details required for aggregating the user accounts. Refer to [Loading Account Data]() for more information about aggregation. > [!NOTE] > > **Screenshot** > > [![Aggregation Settings]()]() 1. Select **Delta Aggregation** to configure the delta aggregation parameters. 2. Enter the **Past Effective Date Offset** value to aggregate an account using delta aggregation that has been back-dated. For example, account details such as a termination date that has been set prior to the last aggregation. 3. Enter the **Delta Aggregation Events** list, which is used when performing delta aggregation. **Filter Settings** > [!NOTE] > > **Screenshot** > > [![Filter Settings]()]() > [!NOTE] > > **Screenshot** > > [![Filter Settings, continued]()]() 1. Select **Exclude Future Terminating Records** to skip future termination records during aggregation. > **Note** > > Selecting this option removes the values for the following attributes: Future action, Future Date, Last day of work, and Termination date. 2. Select **Aggregate Pre-Hires** to aggregate Pre-Hires ahead of their start date. 3. Select **Aggregate Rescinded Past Hires** to retain information for the rescinded past hires to support leaver workflows. 4. In Past Rescinded Offset, enter the number of days (in the past) to aggregate rescinded hires. Default: 60 days. To fetch the rescinded past hires data for a worker, their hire date must be in the **Past Rescinded Offset** range. 5. Select **Aggregate Rescinded Future Hires** to fetch information for the rescinded future hire Workday workers to support leaver workflows. 6. In Effective Date Offset, enter the number of days in advance to aggregate future hires and terminations. For example, enter 14 to aggregate Workday workers 14 days in advance of their hire date. > **Note** > > - If the Effective Date Offset is set as 0 (zero), the connector does not aggregate future hires and terminations. > - SailPoint recommends that you perform a full aggregation if the Effective Date Offset is changed. For more information, refer to [Future Dated Workers](). 7. Enter the **Organization Reference IDs** to filter the workers' records based on organization. The Organization Reference IDs can be found as follows: 1. Search for the required organization. 2. Hover over the action and then select **Integration ID**. 3. Select **View IDs** and note the ID mentioned in front of the organization type. 8. In Integration System ID, provide the System ID of the Integration System to fetch custom or calculated attributes. 9. Provide the Integration Field Override Service name. 10. In Integration Field(s), enter the integration service fields (with multiple fields separated by a comma) to aggregate workers based on the mentioned filter conditions. 11. The Past Termination Offset field determines the offset value in days, which indicates the number of past days to aggregate terminated workers based on their termination date. Default: 60 days. Use the following values for the offset: - 0 - aggregates all terminated workers - Blank - defaults the offset to 60 days - Any positive value - aggregates terminated workers within a specific number of days > **Note** > > For more information on support for filtering using eligibility criteria, refer to [Support for Filtering Using Eligibility Criteria](). 12. Specify the Future Hire Events to include, such as Onboarding or Contract Contingent Worker, by entering the name of the event and selecting **Enter**. You can add multiple events. Default: Hire Employee, Onboarding, Contract Contingent Worker. 13. Specify Future Termination Events to include, such as Terminate Employee or End Contingent Worker Contract, by entering the name of the event and selecting **Enter**. You can add multiple events. Default: Terminate Employee, End Contingent Worker Contract. 14. Add Termination Attributes that are included for future terminated workers, such as Termination\_Date or Contract End Date, by entering the attribute name and clicking **Enter**. You can add multiple attributes. Default: `TERMINATION_DATE`, `LAST_DAY_OF_WORK`, `CONTRACT_END_DATE`, `PRIMARY_TERMINATION_REASON_REFERENCE`. 15. To fetch terminated workers up to the aggregation date, specify Termination Events, such as Terminate Employee or End Contingent Worker Contract, by entering the event name and clicking **Enter**. You can add multiple attributes. Default: Terminate Employee, End Contingent Worker Contract. 16. Select **Fetch Workers By Organization** to fetch workers based on the organization type. When **Exclude Terminated Worker** is selected, Workday uses the default `COST_CENTER` **Organization Type**. To change the default, enter the organization type. 17. Select **Save**. ### XPath Schema Mapping The Workday source provides support to aggregate fields in addition to the fields present in the default account schema in the user interface. This option was previously only available using an API. > [!NOTE] > > The Workday connector reads the data using the Workday SOAP API and fetches the required attribute as per Account Schema by parsing the XML response. For efficient parsing, the connector requires the namespace to be provided using `ns1:`. The default Workday connector includes XPaths for all default business processes. If you must aggregate future data and future actions for a different business process, you must define the new XPaths for that business process. > [!NOTE] > > If you add the XPaths for a new business process, you must provide all XPaths for all business processes. This must include the defaults along with the new XPaths. > [!NOTE] > > **Screenshot** > > [![XPath Schema Mapping]()]() 1. Select **Add Another** for each attribute you want to add. 2. Add the Schema Attribute, and provide the XPath for the attribute. 3. Select **Save** after you have added all the attributes. ## Provisioning Settings Provide the attributes to use for provisioning. This information is not required for your connection. > [!NOTE] > > **Screenshot** > > [![Provisioning Settings]()]() 1. Provide the attributes to use for the Primary Home Phone Type and **Primary Work Phone Type**. 2. Provide the country code to use for the phone attributes. 3. Update the contact information by enabling Use Change Contact Info API. This option is only available when using API version 30.1 and later. 4. If the Use Change Contact Info API option is enabled, choose whether you want to delete phone or email records by selecting the following checkboxes: - **Delete All Phone Records** - **Delete All Email Records** 5. Select **Bypass Provisioning Approvals** to bypass the approval process on provisioning requests and automatically process changes. 6. Select **Save**. ## Review and Test Perform a test to confirm the connection to SailPoint. 1. Go to **Review and Test**. 2. Confirm that the entries in each field are correct. If you note any mistakes, return to the section and make corrections. 3. Select **Test Connection**. ## SailPoint Application Onboarding SailPoint application onboarding enables you to easily onboard new applications and create sources following the successful onboarding of a discovery source. To use this feature, continue to **Discovered Applications** in the SailPoint user interface. For more information, refer to [Application Onboarding]() in the SailPoint SaaS documentation. # 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`. - The HTTP and HTTPS proxy configurations. > **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 - Workday API version 39.1 - Workday API version 37.0 - Workday API version 35.2 - Workday API version 32.1 - Workday API version 30.1 - Workday API version 24.1 > [!NOTE] > > The Workday connector uses Workday's SOAP API, which is independent of the Workday system version, and is backward compatible. ## Prerequisites - Configure at least one [virtual appliance]() cluster and successfully test the connection. - Have a Workday administrator account and password for connecting to the given URL of the Workday tenant. > **Note** > > For more information on Workday permissions, refer to [Required Permissions](<#required-permissions>). - Create a Workday Integration System to fetch calculated or custom fields. For more information, refer to [Configuring an Integration System in Workday](). - Configure custom attributes (only required for updating custom attributes). For more information, refer to [Configuration to Update Custom Attributes in Workday](). - For existing sources, additional schema attributes need to be added manually in order to use the Pre-Hire functionality. ## Required Permissions This section describes the permissions required for the Workday source on the Workday managed system. The Workday connector supports the following operations: - Account Aggregation (Full and Delta) - Update: Email, Phone, User ID (internally mapped to username), Custom attributes > [!NOTE] > > For users with minimum permissions and no access to all organizations, aggregation will not work if the Exclude Terminated Worker option is selected on the Workday source UI. **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. 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`. 2. Create a second integration user for provisioning using the Create Integration System User task. For example, the second user can be named `SailPoint_Write_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**) - For the Write (provisioning) group (**SailPoint\_Write\_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. ### GET and PUT Permission to Read and Write 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 or PUT access list for the Read and Write groups, respectively: | Get Permissions for Read | Put Permissions for Write | | --- | --- | | 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) | 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. While requesting data, delta aggregation for the Workday source follows the time of the virtual appliance (VA), so that time must be in sync with the Network Time Protocol (NTP) server. 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](). # Schema Reference The application schema is used to configure the objects returned from a connector. > [!NOTE] > > - The **Account Schema** tab is used to define the attributes for each object type in the application being configured. The schema attributes can be defined as **Entitlement** or **Multi-Valued**. Refer to [Managing Source Account Schemas]() for more information. > - The schema attributes that are not present by [default](<#default-account-schema>) must be defined as strings if not specified. The Workday connector uses the following default correlation and object configurations. ## Identity Profile Mapping The Workday connector supports the following attributes in Identity Profile Mapping by default: | Identity Attribute | Schema Attribute | | --- | --- | | SailPoint User Name | FILENUMBER | | Display Name | WORKER\_NAME | | Work Email | EMAIL\_ADDRESS\_WORK | | Family Name | LAST\_NAME | | Given Name | FIRST\_NAME | | Middle Name | MIDDLE\_NAME | | Alternate Email | EMAIL\_ADDRESS\_HOME | | Work Phone Number | WORK\_TELEPHONE | | Alternate Phone Number | WORK\_MOBILE | | City | CITY | | Cost Center | COST\_CENTER | | Country | COUNTRY (Transform ISO3166 Country Format) | | Department | DEPARTMENT | | Employee Number | FILENUMBER | | End Date | TERMINATION\_DATE | | Start Date | HIREDATE | | Manager Name | MANAGER\_ID | | Organization | ORGANIZATION\_NAME | | Postal Code | POSTAL\_CODE | | Preferred Name | PREFERRED\_FIRST\_NAME | | State | STATE | | Street Address | ADDRESS\_WORK | | Time Zone | Time\_Profile\_ID | | Title | JOBTITLE | ## Default Account Schema Each source supports a variety of details, or attributes, about each user who has an account, such as their name, email address, manager name, and location. The set of account attributes each source stores and how they're organized is known as the account's *schema*. To best represent your data, you can configure sources to use an account schema matching the one you use in the external connector. Refer to [Managing Source Account Schemas]() for more information. ### Default Account ID SailPoint requires that certain attributes remain in your configuration. These attributes are referred to as *account IDs*. > [!CAUTION] > > Changing the attribute marked as the account ID after aggregating accounts can result in duplicate accounts being created. To avoid this, either reset the accounts on this source before editing the account ID attribute or edit the account ID attribute before aggregating accounts. > > To resolve issues caused by changing account IDs, reconfigure them to their default values. The following table lists the default account IDs for this connector: | Account ID | Schema Object Type | | --- | --- | | FILENUMBER | Account | ### Default Account Attributes The Workday connector supports the following default account schema attributes and customer configurable attributes. The attributes must be defined as strings if not specified. | Attribute Name | Description | | --- | --- | | USERID | The Worker ID associated with the worker. | | FILENUMBER | The user's unique ID. This is an Account ID which must not be changed. | | MANAGER | The worker's current manager. | | MANAGER\_ID | The worker's manager's Employee ID. | | JOBTITLE | The worker's business title. | | JOBCODE | The worker's job profile. | | EMPLOYEE\_TYPE | The user's classification type within the organization. | | FIRST\_NAME | The worker's legal first name. | | LAST\_NAME | The worker's legal last name. | | MIDDLE\_NAME | The worker's preferred middle name. | | LEGAL\_MIDDLE\_NAME | The worker's legal middle name. | | PREFIX | The user's prefix. For example, Mr. or Mrs. | | SUFFIX | The user's suffix. For example, Jr. or Sr. | | PREFERRED\_FIRST\_NAME | The worker's preferred first name. | | WORKER\_NAME | The worker's name. | | CLASS | A concatenation of the worker's position, time type, and employment type. | | DEPARTMENT | The worker's cost center. | | COST\_CENTER | The cost center's name in the worker's organization data. | | COST\_CENTER\_HIERARCHY | The worker's cost center hierarchy. | | COST\_CENTER\_REFERENCE\_ID | The cost center's reference ID in the worker's organization data. | | COMPANY\_NAME | The company to which the worker belongs. | | ORGANIZATION\_NAME
*(Not applicable for Workday API version 30.1)* | The worker's business unit's name. | | DIVISION | The sales channel in the worker's organization data. | | TEAM
*(Not applicable for Workday API version 30.1)* | The team in the worker's organization data. | | LOCATION | The worker's business site. | | HIREDATE | The worker's hire date. | | TERMINATION\_DATE | The date the worker was terminated. | | LAST\_DAY\_OF\_WORK | The worker's last working day. | | CONTRACT\_END\_DATE | The worker's contract end date. | | FULLPARTTIME | Indicates whether the worker is full time or part time. | | ON\_LEAVE | Indicates if the worker is on leave. | | FUTURE\_DATE | Represents the worker's next future milestone date. For example, future date of hire, termination date, onboarding date, or end of their contingent worker contract. | | FUTURE\_ACTION | Represents the worker's next future action. For example, Hire, Terminate, Onboarding, or End Contingent Worker Contract (Hire Employee). | | POSTAL\_CODE | The worker's business site's postal code. | | COUNTRY | The worker's business site's country. | | CITY | The worker's business site's city. | | STATE | The worker's business site's state. | | ADDRESS\_LINE\_1 | The worker's business site's street address. | | ADDRESS\_HOME | The worker's home address. | | ADDRESS\_WORK | The worker's work address. | | EMAIL\_ADDRESS\_HOME | The worker's home email address. | | EMAIL\_ADDRESS\_WORK | The worker's email address. | | ADDITIONAL\_EMAIL\_ADDRESS\_HOME | The worker's additional home email address. | | ADDITIONAL\_EMAIL\_ADDRESS\_WORK | The worker's additional work email address. | | WORK\_MOBILE | The worker's work mobile number. | | WORK\_TELEPHONE | The worker's work telephone number. | | HOME\_MOBILE | The worker's home mobile number. | | HOME\_TELEPHONE | The worker's home telephone number. | | ADDITIONAL\_PHONE\_WORK | Additional business phone number of the worker. | | ADDITIONAL\_PHONE\_HOME | Additional home phone number of a worker. | | LOCALE\_ID | The ID for the user's locale. | | Time\_Profile\_ID | The ID of the user's timezone. | > [!NOTE] > > For more information on Rescinded/Corrected Event for Hired and Terminated Workers, refer to [Rescinded and Corrected User Records](). The Workday connector can aggregate fields in addition to the fields present in the default account schema - for more information, refer to [XPath to Support Additional Standard Attributes in Schema](). ### Optional Attributes If you require the `image` attribute to be a String attribute type, add the following attributes: | Attributes | Description | Source Data Element WD Object /Field Web Service Element File field | | --- | --- | --- | | IMAGE\_NAME (type as String) | Image file name | `Worker_Data/Photo_Data/File name` | | IMAGE (type as String) | Image value as string | `Worker_Data/Photo_Data/Image` | | EMAIL\_ADDRESS\_WORK | Email address of the worker | `Worker_Data/Personal_Data/Contact_Data/Email_Address_Data[Usage_Data[@Public='true']/Type_Data[@Primary='true']/Type_Reference/ID[@type='Communication_Usage_Type_ID'] ='WORK']/Email_Address` | | EMAIL\_ADDRESS\_HOME | Home email address of the worker | `Worker_Data/Personal_Data/Contact_Data/Email_Address_Data[Usage_Data[@Public='true']/Type_Data[@Primary='true']/Type_Reference/ID[@type='Communication_Usage_Type_ID'] ='HOME']/Email_Address` | | ADDRESS\_HOME | Home address of the worker | `Worker_Data/Personal_Data/Contact_Data/Address_Data[Usage_Data/Type_Data/Type_Reference/ID[@type='Communication_Usage_Type_ID'] ='HOME']/@Formatted_Address` | | ADDRESS\_WORK | Work address of the worker | `Worker_Data/Personal_Data/Contact_Data/Address_Data[Usage_Data/Type_Data/Type_Reference/ID[@type='Communication_Usage_Type_ID'] ='WORK']/@Formatted_Address` | | ADDITIONAL\_PHONE\_WORK | Additional business phone number of the worker | `Worker_Data/Personal_Data/Contact_Data/Phone_Data[Usage_Data[@Public='true']/Type_Data[@Primary='false']/Type_Reference/ID[@type='Communication_Usage_Type_ID'] ='WORK']/@Formatted_Phone` | | ADDITIONAL\_PHONE\_HOME | Additional home phone number of a worker | `Worker_Data/Personal_Data/Contact_Data/Phone_Data[Usage_Data[@Public='true']/Type_Data[@Primary='false']/Type_Reference/ID[@type='Communication_Usage_Type_ID'] ='HOME']/@Formatted_Phone` | | ADDITIONAL\_EMAIL\_ADDRESS\_WORK | Additional Email address of the worker | `Worker_Data/Personal_Data/Contact_Data/Email_Address_Data[Usage_Data[@Public='true']/Type_Data[@Primary='false']/Type_Reference/ID[@type='Communication_Usage_Type_ID'] ='WORK']/Email_Address` | | ADDITIONAL\_EMAIL\_ADDRESS\_HOME | Additional Home email address of the worker | `Worker_Data/Personal_Data/Contact_Data/Email_Address_Data[Usage_Data[@Public='true']/Type_Data[@Primary='false']/Type_Reference/ID[@type='Communication_Usage_Type_ID'] ='HOME']/Email_Address` | | ORGANIZATION\_NAME (Not applicable for Workday API version 30.1) | Represent organization name whose type is BUSINESS\_UNIT | `Worker_Data/Organization_Data/Worker_Organization_Data/Organization_Data[Organization_Type_Reference[@Descriptor ='Business Unit']]/Organization_Name` | | CONTRACT\_END\_DATE | Represent the contract end date of worker | `Worker_Data/Employment_Data/Worker_Contract_Data/Contract_End_Date` | | ADDRESS\_LINE\_1 | Represent business site's Address\_line\_1 of worker | `Worker_Data/Employment_Data/Position_Data/Business_Site_Summary_Data/Address_Data/Address_Line_Data[@Type ='ADDRESS_LINE_1']` | | STATE | Represent business site's country region | `Worker_Data/Employment_Data/Position_Data/Business_Site_Summary_Data/Address_Data/Country_Region_Reference/@Descriptor` | | LAST\_DAY\_OF\_WORK | Represents the last day of work of the worker | `Worker_Data/Employment_Data/Worker_Status_Data/Termination_Last_Day_of_Work` | | COST\_CENTER\_REFERENCE\_ID | Represent reference ID of organization type COST CENTER | `Worker_Data/Organization_Data/Worker_Organization_Data/Organization_Data[Organization_Type_Reference[@Descriptor ='Cost Center']]/Organization_Reference_ID` | | COMPANY\_NAME | Represent organization name whose type is COMPANY | `Worker_Data/Organization_Data/Worker_Organization_Data/Organization_Data[Organization_Type_Reference/ID [@type='Organization_Type_ID']='COMPANY']/Organization_Name` | > [!NOTE] > > Adding the `image` attribute to the schema may increase the time taken to fetch a response from the Workday source. ### Additional Schema Attributes for Pre-Hire Functionality > [!NOTE] > > These attributes are available out of the box for new sources. For existing sources, additional schema attributes need to be added manually in order to use the Pre-Hire functionality. | Schema Attribute | Description | | --- | --- | | PRE\_HIRE\_ID | Pre Hire ID for the person. | | DATE\_PRE\_HIRE\_ADDED\_TO\_SYSTEM | The date when pre-hire is added in Workday. | | ELIGIBLE\_FOR\_HIRE | Specify whether Prehire is eligible for hire or not. | | REFFERED\_BY | Pre-Hires is referred by. | | SOURCE | Pre-Hire Source. | # Enable Connector Logging This topic provides the steps needed to enable logging on SailPoint using REST APIs. > [!NOTE] > > This topic only applies to VA-based integrations. > [!NOTE] > > The examples provided might not match your configuration. Use the logging levels and logging classes reference at the bottom of the topic to configure your API responses to match your connector. This process is broken up into four steps: 1. Identify the Virtual Appliance (VA) cluster on which you want to enable logging. 2. Get the logging configuration for the existing VA cluster. 3. Update the VA cluster to enable logging levels. 4. Observe logging changes to the logging levels. ### Identify the Virtual Appliance Cluster Select the VA on which you need to enable logging using REST API. If you already know the VA application's `id`, proceed to [Get the Logging Configuration](<#get-the-logging-configuration>). 1. Make the following call to the REST API to return a list of available VA clusters: GET /v3/managed-clusters The REST API returns a response that looks similar to the following: ```json [ { "id": "2c9180866166b5b0016167c32ef31a66", "name": "Development Cluster", "description": "Development Cluster", "clientType": "CCG", "ccgVersion": "373_535_70.2.0", "pinnedConfig": true, "logConfiguration": null }, { "id": "2c9180846a93ce60016ab29f039944de", "name": "Cloud Cluster", "description": "Cloud Cluster", "clientType": "CCG", "ccgVersion": "373_535_70.2.0", "pinnedConfig": true, "logConfiguration": { "clientId": null, "durationMinutes": 60, "expiration": "2020-12-15T19:13:36.079Z", "rootLevel": "DEBUG", "logLevels": { "sailpoint.connector.ADLDAPConnector": "DEBUG" } } } ] ``` > **Note** > > The previous example code shows two VA clusters. One VA cluster has a log configuration and the other does not (refer to the `logConfiguration` value in each returned VA cluster). This is because one of the clusters already has logging enabled. This is just an example configuration, and your environment may not have logging enabled on a cluster. 2. Identify the VA cluster that you want to enable logging on by its name or description and record its `id` attribute. ### Get the Logging Configuration Get your selected VA's cluster logging configuration and identify the values you need to update. 1. Make the following call to the REST API to return the VA cluster's logging configuration. Replace `{id}` with the VA cluster's `id` attribute value recorded earlier. GET /v3/managed-clusters/{id}/log-config - If the VA doesn't have a logging configuration currently set, it returns `204 No Content` as a response. - If the VA has an existing logging configuration, it returns something similar to the following: ```json { "clientId": null, "durationMinutes": 60, "expiration": "2020-12-15T19:13:36.079Z", "rootLevel": "DEBUG", "logLevels": { "sailpoint.connector.ADLDAPConnector": "DEBUG" } } ``` You'll need to configure the following information in the response: - `durationMinutes` is the number of minutes logging should remain enabled. - `rootLevel` is the default level for all logs. For more information, refer to [Logging Levels](<#logging-levels>). - `logLevels` is a map object with logging classes as keys and logging levels as values. - For keys, refer to [Logging Classes](<#logging-classes>) for commonly used logging classes. - For a list of available values, refer to [Logging Levels](<#logging-levels>). ### Update Logging Configuration Update the VA cluster configuration returned by the REST API to update the logging settings as needed. 1. Make the following call to the REST API to update the VA cluster's logging configuration. Replace `{id}` with the VA cluster's `id` attribute value recorded earlier. PUT /v3/managed-clusters/{id}/log-config 2. Submit your configuration changes to the REST API in a JSON body. - If the VA cluster did not already have a logging configuration and you received a `204 No Content` response, you can create a new one. - If the VA returned a configuration, you can edit it to include the changes. The JSON body should be as follows: ```json { "durationMinutes": 60, "rootLevel": "DEBUG", "logLevels": { "sailpoint.connector.ADLDAPConnector": "DEBUG" } } ``` Consider the following as you edit the JSON: - `durationMinutes` is the number of minutes logging should remain enabled. - `rootLevel` is the default level for all logs. For more information, refer to [Logging Levels](<#logging-levels>). - `logLevels` is a map object with logging classes as keys and logging levels as values. - For keys, refer to [Logging Classes](<#logging-classes>) for commonly used logging classes. - For a list of available values, refer to [Logging Levels](<#logging-levels>). If the update was successful, the REST API should return a response similar to the following: ```json { "clientId": null, "durationMinutes": 60, "expiration": "2020-12-15T19:13:36.079Z", "rootLevel": "DEBUG", "logLevels": { "sailpoint.connector.ADLDAPConnector": "DEBUG" } } ``` ### Observe Logging Changes Approximately five minutes after you update the configuration, the VA cluster starts generating log files you can review. You can view the log files in **ccg.log**. ### References The tables in this reference section list information that can be helpful when creating the JSON body you'll use to configure the VA cluster's configuration file. #### Logging Levels | Logging Level | Description | | --- | --- | | ERROR | Designates error events that might still allow the connector to continue. | | WARN | Designates potentially harmful situations. | | INFO | Designates information messages that highlight process at a coarse-grain level. | | DEBUG | Very verbose. Fine grain logging levels used for development and debugging. | | TRACE | Most verbose. Finer grain logging levels than debugging. | #### Logging Classes | Connector | Logging Class | | --- | --- | | Active Directory | sailpoint.connector.ADLDAPConnector sailpoint.connector.LDAPConnector | | AIX | openconnector.connector.unix.AIXConnector openconnector.connector.unix.UnixConnector | | Amazon Web Services | logger.aws.name=openconnector.connector.aws logger.aws.level=trace logger.aws.additivity = false logger.aws.appenderRef.rolling.ref = STDOUT | | Atlassian Suite Cloud | sailpoint.connector.OpenConnectorAdapter openconnector.connector.atlassian.AtlassianConnector | | Atlassian Data Center | sailpoint.connector.OpenConnectorAdapter openconnector.connector.atlassian.AtlassianDataCenterConnector | | Microsoft Entra ID | sailpoint.connector.AzureADConnector | | Box | openconnector.connector.BoxNetConnector sailpoint.connector.OpenConnectorAdapter | | Cerner | openconnector.connector.CernerConnector sailpoint.connector.OpenConnectorAdapter | | Delimited File | logger.DelimitedFileConnector.name = sailpoint.connector.DelimitedFileConnector logger.DelimitedFileConnector.level = debug logger.DelimitedFileConnector.additivity = false logger.DelimitedFileConnector.appenderRef.rolling.ref = STDOUT | | Dropbox | openconnector.connector.DropBoxConnector sailpoint.connector.OpenConnectorAdapter | | Epic | openconnector.connector.EPICConnector sailpoint.connector.OpenConnectorAdapter | | GE Centricity | openconnector.connector.GECentricity sailpoint.connector.OpenConnectorAdapter | | Google Apps / G Suite | openconnector.connector.GoogleAppsDirect sailpoint.connector.OpenConnectorAdapter | | IBM i | openconnector.connector.IBMiConnector | | Lotus Domino | sailpoint.connector.LotusDomino | | JDBC | sailpoint.connector.JDBCConnector | | Sun One LDAP | sailpoint.connector.LDAPConnector | | Linux | openconnector.connector.unix.LinuxConnector sailpoint.connector.OpenConnectorAdapter sailpoint.connector.UnixConnector | | Microsoft Office365 | sailpoint.connector.Office365Connector | | Microsoft SQL Server | sailpoint.connector.mssql.serviceimpl.MSSQLServerConnectorV2 | | Okta | logger.openconnector.name = openconnector.connector.okta.OktaConnector logger.openconnector.level = debug logger.openconnector.additivity = false logger.openconnector.appenderRef.rolling.ref = STDOUT | | Oracle Database | sailpoint.connector.OracleDBConnector sailpoint.connector.JDBCConnector | | Oracle E-Business | sailpoint.connector.OracleEBSConnector sailpoint.connector.JDBCConnector | | Oracle Fusion HCM | openconnector.connector.oraclefusionhcm.OracleFusionHCMConnector sailpoint.connector.OpenConnectorAdapter | | Oracle HCM Cloud | sailpoint.connector.oraclehcmcloud.OracleHCMCloudConnector | | Oracle HRMS | sailpoint.connector.OracleAppsHRMSConnector sailpoint.connector.JDBCConnector | | Oracle Netsuite | openconnector.connector.netsuite.NetsuiteConnector | | PeopleSoft ERP | openconnector.connector.PeopleSoftConnector sailpoint.connector.OpenConnectorAdapter | | PeopleSoft HRMS | sailpoint.connector.PeopleSoftHRMSConnector | | RemedyForce | sailpoint.connector.ForceConnector | | RSA Authentication Manager | openconnector.connector.RSAConnector openconnector.connector.rsa.RSAHTTPClient sailpoint.connector.OpenConnectorAdapter | | Salesforce | sailpoint.connector.ForceConnector | | SAP Concur | openconnector.connector.sapconcur.SAPConcurConnector | | SAP - Direct | sailpoint.connector.SAPConnector sailpoint.connector.SAPInternalConnector | | SAP GRC | logger.SAPGRCConnector.name = sailpoint.connector.sapgrc logger.SAPGRCConnector.level = debug logger.SAPGRCConnector.additivity = false logger.SAPGRCConnector.appenderRef.rolling.ref = STDOUT | | SAP HR/HCM | sailpoint.connector.SAPHRInternalConnector | | SCIM 1.1 | openconnector.connector.SCIMConnector sailpoint.connector.OpenConnectorAdapter | | SCIM 2.0 | openconnector.connector.scim2.SCIM2Connector sailpoint.connector.OpenConnectorAdapter | | ServiceNow | openconnector.connector.servicenow.ServiceNowConnector openconnector.connector.servicenow.ServiceNowRestClient sailpoint.connector.OpenConnectorAdapter | | ServiceNow Service Desk Integration | openconnector.connector.servicedesk.ServiceNowServiceDeskConnector sailpoint.connector.OpenConnectorAdapter | | Siebel | openconnector.connector.SiebelConnector sailpoint.connector.OpenConnectorAdapter | | Snowflake | openconnector.connector.snowflake.SnowflakeConnector sailpoint.connector.OpenConnectorAdapter | | Solaris | openconnector.connector.unix.SolarisConnector openconnector.connector.unix.UnixConnector sailpoint.connector.OpenConnectorAdapter | | SuccessFactors | sailpoint.connector.SuccessFactorsConnector | | Sybase | sailpoint.connector.SybaseDirectConnector sailpoint.connector.JDBCConnector | | Webex | openconnector.connector.Webex sailpoint.connector.OpenConnectorAdapter | | Workday | openconnector.connector.WorkDay sailpoint.connector.OpenConnectorAdapter | | Workday Accounts | openconnector.connector.workdayaccounts openconnector.connector.workdayaccounts.WorkdayAccountsConnector sailpoint.connector.OpenConnectorAdapter | | Web Services | sailpoint.connector.WebServices | | XML | openconnector.connector.XMLConnector sailpoint.connector.OpenConnectorAdapter | | Yammer | openconnector.connector.YammerConnector sailpoint.connector.OpenConnectorAdapter | | Zoom | openconnector.connector.zoom.ZoomConnector sailpoint.connector.OpenConnectorAdapter | # Troubleshooting If you encounter any of the following issues or errors, SailPoint recommends that you follow the guidance provided below to resolve the error before contacting SailPoint Support. For issues or errors that are not addressed in this connector guide, refer to the following resources for troubleshooting information: - [SailPoint Identity Services Documentation]() - [SailPoint Support Knowledge Base]() - [SailPoint Developer Community]() ## Workday API Operations Used by the Connector The Workday connector uses the following Workday web service operations. For Human Resources operation definitions, refer to the [Workday Human Resources web services](). | Connector Operation | Workday Web Service Operations | | --- | --- | | Test connection | Human Resources - `Get_Server_Timestamp` | | Worker aggregation | Human Resources - `Get_Workers`. The connector also uses `Get_Organizations` when organization filtering is enabled. | | Contact provisioning | Human Resources - `Change_Home_Contact_Information` and `Change_Work_Contact_Information` | | Custom ID provisioning | Human Resources - `Change_Other_IDs` | | Pre-hire | Recruiting - `Get_Applicants` and `Put_Applicant` | `Get_Workers` is a single Workday operation. The connector uses different request criteria depending on the scenario: Future Hire, Future Terminated, Active, Past Rescinded, Terminated, Delta, and Single Account Read. ## Daylight Saving Time (DST) and Effective Time Zone Cause Missing Future-Dated Workers **Issue**: Future-dated workers or new hires are present in earlier aggregations, disappear during the aggregation on the day before the hire date, and reappear after the hire date or in a later aggregation. **Description**: This behavior is typically related to a mismatch between the Effective Time Zone on the Workday source and the timezone in which Workday HR events (hire, termination, rehire, conversion) are processed. DST changes can make this mismatch more visible. Use valid tz database identifiers (for example, `America/Chicago`, `Australia/Melbourne`), not abbreviations such as `EST`, `PST`, or `IST`. In reported cases with `Australia/Melbourne`, workers with a hire date on the next day were dropped during aggregation, triggering account deletion or uncorrelation. Changing Effective Time Zone to `Australia/Queensland` mitigated the issue. > [!NOTE] > > `Australia/Queensland` does not observe DST. **Resolution**: 1. Review Effective Time Zone on the Workday source. 2. Confirm the value uses a valid tz database identifier. Workday sources require a full tz database name (for example, `Australia/Queensland`, `America/Los_Angeles`). 3. If the issue occurs around DST boundaries or affects future-dated hires, test a timezone configuration that does not observe DST, where appropriate for the customer's environment. 4. For the known Australian DST scenario, update Effective Time Zone from `Australia/Melbourne` to `Australia/Queensland`. `Australia/Queensland` does not observe DST, which prevents date-shift issues that can cause future-dated workers to be dropped during aggregation. 5. Run account aggregation again and verify whether future-dated workers continue to be dropped. ## Workday Aggregations Failing with "Page 1 Must Be Requested First" Message **Issue**: Aggregation fails with the error message: "Processing error occurred. Page 1 must be requested first." **Resolution**: 1. Lower the Page Size setting under Connection Settings on the Source configuration from the current value to improve session stability. 2. Re-run the aggregation after adjusting the page size to validate successful data retrieval without pagination errors. 3. If the issue persists, apply the following connector attribute update via PATCH request: ```json { "op": "add", "path": "/connectorAttributes/useSameAsOfEffectiveDateForAllRequests", "value": "true" } ``` This addresses effective date handling during peak volume times. For more information about using the PATCH API, refer to the [Update Source API documentation](). ## Provisioning Operations Fail with an Exception when Updating Phone, Email, or USER\_NAME Attributes The following error is received during the provisioning operation: ```text openconnector.InvalidConfigurationException: [ InvalidConfigurationException ] [ Possible suggestions ] You cannot initiate this action because there are other pending or completed actions for the person that conflict with this one. [ Error details ] Validation error occurred. You cannot initiate this action because there are other pending or completed actions for the worker that conflict with this one ``` **Resolution**: Enable the **Bypass Provisioning Approvals** flag in Source \> Provisioning Settings if this error occurs. > [!NOTE] > > This flag only works after pending action items for the worker are completed in the Workday Manage System. ## Account Aggregation Returns Zero Accounts Account aggregation completes successfully but returns no accounts from Workday. The integration user may lack the required domain security policy permissions, even if all documented permissions have been assigned. **Resolution**: Ask the customer's Workday administrator to verify and configure the following permissions: 1. In Workday, search for Domain Security Policies for Functional Area. 2. Select **Staffing** and go to **Worker Data: Workers**. 3. Under the **Integration permission** section, verify that the SailPoint security group is listed. If the security group is not present, add it to the Integration permission section. 4. Run the Activate Pending Security Policy Changes task. 5. Verify that the issue is resolved. ## Exception: net.sf.saxon.s9api.SaxonApiException: Errors Were Reported During Stylesheet Compilation The following error is received during stylesheet compilation: ```text Exception : net.sf.saxon.s9api.SaxonApiException: Errors were reported during stylesheet compilation ``` **Resolution**: Ensure that all XPaths added are correct and no space is in the XPath value. ## Workday Aggregation Fails with an Error **Issue**: ```text [ TimeoutException ] [ Possible suggestions ] a) Make sure Workday System is reachable b) Try after incrementing custom Connection Timeout value. [ Error details ] : Connect to wd2-impl-services1.workday.com:443 failed: Connection timed out (Connection timed out) ``` **Resolution**: 1. Increase the value of Page size to 999. 2. Increase the value of the retry count attribute to 10 using the v3 Sources API: `PATCH https://{orgName}.api.cloud.sailpoint.com/v3/sources/{workdaySourceID}` ```json { "op": "replace", "path": "/connectorAttributes/retryErrors", "value": [ "Connection timed out" ] } ``` ## Account Aggregation Fails with a NegativeArraySizeException Account aggregation fails with an error similar to the following: ```text Exception while aggregating workday account for page : 1 : java.lang.NegativeArraySizeException: -2104475932 ``` This can occur when a Workday API response is extremely large. For example, workers with a very large number of inherited role assignments can cause a page payload that exceeds the Java array size limit. **Resolution**: 1. Set `pageSize` to `1` and `aggregationThreadSize` to `4` on the Workday source to reduce the response size for each aggregation request: ```text PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID} [ { "op": "add", "path": "/connectorAttributes/pageSize", "value": "1" }, { "op": "add", "path": "/connectorAttributes/aggregationThreadSize", "value": "4" } ] ``` 2. Run account aggregation again. 3. If aggregation succeeds but takes longer than expected, increase `pageSize` and `aggregationThreadSize` based on available processors and memory. 4. (Optional) If the account schema includes `ORG_ROLE##ORG_NAME` and that data is not required, remove the attribute from the schema or aggregate roles separately. > [!NOTE] > > Setting `pageSize` to 1 increases the number of API calls and can increase aggregation runtime. ## Incorrect Termination Record Getting Picked Up During Aggregation for Multiple Termination Records of a Worker The **Past\_Termination\_Offset** parameter can be used to limit the aggregation of termination records based on offset days provided in the application. If there are multiple termination records for a worker, however, the user might experience the incorrect termination record getting picked up during aggregation. **Resolution**: If the problem persists even after using the **Past\_Termination\_Offset** parameter to extend or reduce the past termination date offset, add the `splitPastTerminationOffsetBy` parameter to split the terminated workers aggregation into two steps. For more information on the `Past_Termination_Offset` parameter, refer to [Aggregation Settings](). For example: - Today's Date: 31 May 2019; `Past_Termination_Offset`: 60; `splitPastTerminationOffsetBy`: 30. First iteration brings terminated accounts from 1 May 2019 to 31 May 2019. Second iteration brings terminated accounts from 30 Apr 2019 to 1 Apr 2019. - Today's Date: 31 May 2019; `Past_Termination_Offset`: Not specified; `splitPastTerminationOffsetBy`: 30. First iteration brings terminated accounts from 1 May 2019 to 31 May 2019. Second iteration brings terminated accounts from 30 Apr 2019 to 1 Jan 1970. The `splitPastTerminationOffsetBy` parameter is optional and fetches the latest record for multiple termination records for a file number in a short span of time. This ensures that the correct record is fetched and no multiple records are toggled during aggregations. ## Error: Workday Aggregation Is Failing with "Read Timed Out" Error Workday aggregation is failing with the following exception after initiating account aggregation: ```text Aggregation failed in one or more thread execution:: exception : openconnector.ConnectorException: [ ConnectorException ] [ Error details ] Exception : javax.net.ssl.SSLException: Read timed out ``` Or: ```text java.net.SocketTimeoutException: Read timed out ``` **Resolution**: To increase the retry count and add the error to the list of retryable errors, complete the following: 1. Increase the `retryCount` attribute using the v3 Sources API: ```text PATCH /v3/sources/{sourceId} [ { "op": "add", "path": "/connectorAttributes/retryCount", "value": "5" } ] ``` > **Note** > > Increase `retryCount` to 10 if 5 does not work. 2. Add the following errors to the list of retryable errors: ```text PATCH https://{orgName}.api.identitynow.com/beta/sources/{workdaySourceGuid} [ { "op": "replace", "path": "/connectorAttributes/retryErrors", "value": [ "Connection reset", "503 Service Unavailable", "javax.net.ssl.SSLException: Read timed out", "java.net.SocketTimeoutException: Read timed out" ] } ] ``` > **Note** > > By default, `Connection reset` and `503 Service Unavailable` are in the retryable errors list. 3. Set the connection timeout parameter to 2 or 3 on the **Connection Settings** page of the Workday connector. ## Error: Processing Error Occurred. PermGen Space The following error is received when testing the connection for the Workday connector: ```text Processing error occurred. PermGen space ``` This message is a Workday error that indicates the Workday server has run out of memory. For example, the server may be processing a report that is consuming the server's available memory. You need to work with your Workday team to resolve the server memory issues. ## Error: Test Connection Is Failing Because of Invalid Workday Host URL **Resolution**: The following lists the possible exceptions and their solution: - `Test Connection Failed` - `UnknownHostException` - `FileNotFoundException` - `HTTP response code: 500` Ensure that the Workday URL is correct and is case sensitive. ## Error: Test Connection Fails with an Error Message Test connection fails with the following error message due to the WebLogic Server not using the standard SUN HTTPS implementation provided by the JDK: ```text openconnector.ConnectorException: javax.net.ssl.SSLKeyException: FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received ``` The WebLogic Server uses the `weblogic.net.http.SOAPHttpsUrlConnection` class instead of the `javax.net.ssl.HttpsUrlConnection` class. **Resolution**: Start the WebLogic Server with the following argument so that it uses the SUN HTTPS default handler: `-DUseSunHttpHandler=true jvm` 1. Open the WebLogic Server installed directory and go to the `\user_projects\domains\base_domain\bin` directory. 2. Edit the `startManagedWebLogic.cmd` file and set `JAVA_OPTIONS=-DUseSunHttpHandler=true%JAVA_OPTIONS%`. 3. Save the `startManagedWebLogic.cmd` file. 4. Edit the `startManagedWebLogic.sh` file and set `JAVA_OPTIONS="-DUseSunHttpHandler=true" ${JAVA_OPTIONS}"`. 5. Save the `startManagedWebLogic.sh` file. 6. Start the Managed Server. ## Error: While Provisioning the PHONE\_HOME, PHONE\_WORK, ADDITIONAL\_PHONE\_HOME, and ADDITIONAL\_PHONE\_WORK Attributes an Error Message Is Displayed While provisioning the `PHONE_HOME`, `PHONE_WORK`, `ADDITIONAL_PHONE_HOME`, and `ADDITIONAL_PHONE_WORK` attributes, the following error message is displayed: ```text not Valid ID value for type="Phone_Device_Type_ID" ``` This error appears because the Workday connector uses the default phone device reference ID, which varies according to the tenant. The connector contains a `ReferenceIDMap` that contains the phone device type ID map. **Resolution**: To change the reference ID of a specific phone device type, modify the `Phone_Device_Type_ID` map using the REST API: ```json PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID} [ { "op": "add", "path": "/connectorAttributes/ReferenceIDMap", "value": {"Phone_Device_Type_ID":{"Mobile":"1063.1","Telephone":"1063.5","Fax":"1063.4","Pager":"1063.6"}} } ] ``` > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. To find `Phone_Device_Type_Reference_Id`: 1. Search for the View Workday ID report. 2. Enter **Phone Device Type** as the class name in the report and select **OK**. 3. Select **Related action of phone device type \> Integration IDs \> View Reference IDs**. The Reference ID values of the Phone Device Type ID are listed. ## Issue: If EMPLOYEE\_TYPE Value for Any Contingent Worker Is Not Correct If the `EMPLOYEE_TYPE` value for any contingent worker is not correct (for example, 382.2, which is the ID of the `EMPLOYEE_TYPE`): **Resolution**: The application contains a default map for mapping the incorrect IDs with employee type: ```json PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID} [ { "op": "add", "path": "/connectorAttributes/ReferenceIDMap", "value": {"Employee_Type_ID":{"382.1":"Consultant","382.2":"Contractor","382.3":"Vendor"}} } ] ``` > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. The above default map would map the 382.2 key with the `Contractor` string. If the correct string is not obtained for a numeric value in the `EMPLOYEE_TYPE` account attribute, copy the value of the appropriate reference ID for that employee type from the Workday managed system and add it to the Workday application `Employee_Type_ID` map. For example, for a value of 382.2 in `EMPLOYEE_TYPE`: 1. In the Workday managed system, search for Contingent Worker Type and select it. 2. For each row, open **Related action \> Integration ID \> View IDs** and find the type of contingent worker assigned to 382.2. 3. After finding the correct value of the contingent worker type, add the value to the `Employee_Type_ID` map in the application XML page. Perform a full aggregation task for the correct changes to be reflected. ## Error: While Updating Contingent Worker Data an Error Message Is Displayed While updating contingent worker data for existing applications, the following error message is displayed: ```text Invalid ID value. '21430' is not valid ID value for type='Employee_ID ``` **Resolution**: If the provided `Employee_ID` belongs to the contingent worker, add the following map using the REST API. > [!NOTE] > > This map is present for new connectors. > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. ```json PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID} [ { "op": "add", "path": "/connectorAttributes/EmployeeTypeMap", "value": {"EmployeeTypes":["Regular","Casual","Fixed Term Contract","Seasonal","Temporary"],"ContingentWorkerTypes":["Contractor","Consultant","Vendor"]} } ] ``` Complete the following to find the supported employee type: 1. In the Workday managed system, search for reports of type **Employee Types**. 2. In the displayed report, verify whether an additional employee type is listed on the Workday managed system. If a new employee type is listed, add it under **EmployeeTypeMap \> EmployeeTypes**. For example, if an additional employee type is found in **Trainee**, add the following entry under **EmployeeTypeMap \> EmployeeTypes**: ```xml Trainee ``` Complete the following to find supported contingent worker types: 1. In the Workday managed system, search for reports of type **Contingent Worker Types**. 2. In the displayed report, verify whether an additional contingent worker type is listed on the Workday managed system. If a new contingent worker type is listed, add it under **EmployeeTypeMap \> ContingentWorkerTypes**. For example, if an additional employee type is found in **Trainee Consultant**, add the following entry under **EmployeeTypeMap \> ContingentWorkerTypes**: ```xml Consultant ``` ## Error: While Updating Workday Account Email or Phone Attribute an Error Message Appears While updating the Workday account email or phone attribute, the following error message is displayed: ```text The task submitted is not authorized ``` **Resolution**: The error message indicates that the user is not authorized with some permission. The Workday administrator must verify if the specific integration security group is added to Maintain Contact Information (Web Service). ## Issue: While Retrieving the Workers, an Issue Is Observed for BenefitEligibility or Supervisory Organization Data By default, the connector retrieves `BenefitEligibility` data while retrieving the workers. **Resolution**: To exclude retrieving `BenefitEligibility` data, add the following using the REST API: ```json PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID} [ { "op": "add", "path": "/connectorAttributes/Configure_Response_Group", "value": {"excludeBenefitEligibility":"true"} } ] ``` > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. By default, the connector does not retrieve Supervisory Organization data while retrieving the workers. **Resolution**: To retrieve Supervisory Organization data, add the following using the REST API: ```json PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID} [ { "op": "add", "path": "/connectorAttributes/Exclude_Supervisory_Organizations", "value": {"excludeBenefitEligibility":"false"} } ] ``` > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. ## Issue: When Phone Reference, Employee Type, or Contingent Worker Type IDs Are Updated in the Workday Managed System, the Reference ID Map Is Not Updated **Resolution**: When Reference IDs are updated in Workday, complete the following: 1. Delete the `ReferenceIDMap` entry from the application XML page. 2. Delete the following relevant entries from the `XpathAttributesMap`: - (Phone Reference IDs) `WORK_MOBILE`, `WORK_TELEPHONE`, `HOME_MOBILE`, and `HOME_TELEPHONE` - (Employee Type Reference ID) `EMPLOYEE_TYPE` - (Contingent Worker Type Reference ID) `Contingent_Worker_Type` 3. Perform aggregation. The connector updates the latest IDs in the application along with the latest XPath for the attributes listed in Step 2. ## Error: When Access Token Expires an Error Message Appears When the access token expires, an error message appears. The Workday connector checks the following strings in error messages in order to generate a new access token: `400`, `401`, `Unknown Error`, `Invalid access token`. **Resolution**: In cases where the error message does not contain any of the above strings, configure the `oauth2Errors` attribute to accommodate additional error sub-strings: **Key**: `connector_oauth2Errors` **Value**: `["Token expired","MY_CUSTOM_ERROR"]` ## Error: During Aggregation Intermittent Errors Are Displayed During aggregation, due to network load or tenant/server connectivity issues, intermittent errors are displayed. By default, the Workday connector displays the following error: ```text Connection reset, 503 Service Unavailable ``` **Resolution**: Set the following attributes using the REST API to add this error to the retryable errors list: - **retryErrors**: The list of error strings. This can be configured in the source XML file. The default value is `Connection reset`, and more error strings can be added. Key: `connector_retryErrors`. Value: `["Connection reset", "failed to respond"]` - **retryCount**: The count of retrying the failed request. Default value is 1, and this can be edited. Key: `connector_retryCount`. Value: `1` > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. ## Improved Aggregation of Custom Attributes for Converted and Future Dated Workers The Workday connector correctly aggregates custom attributes for converted workers and future-dated workers, in both full aggregation and delta aggregation. > [!NOTE] > > In the Workday managed system, the effective-dated custom attributes are not transferred from contractor to converted employee. You must manually re-enter the details for the worker. ## Error: For Upgraded Applications, with "Aggregate Rescinded Past Hires" Enabled, Rescinded Past Hires Records Are Not Aggregated **Resolution**: To fetch rescinded past hires data for a worker, their hire date must be in the **Past Rescinded Offset** range. Make sure to provide the appropriate number of days in the **Past Rescinded Offset** field. ## Issue: Account Aggregation Not Fetching Terminated or Rescinded Records when Effective Date Offset Is Set to Zero Value **Resolution**: Make sure Effective Date Offset is either empty or a non-zero integer value per the requirement. Do not set it to `0`. ## Issue: Future Hire, Past Hire, and Terminated Records Are Being Skipped During Aggregation **Resolution**: The Workday connector requires the following schema attributes and associated XPaths for aggregation: - `HIREDATE` - Required for aggregating active workers. - `TERMINATION_DATE` - Required for aggregating terminated workers. - `CONTRACT_END_DATE` - Required for aggregating contract-terminated workers. - `FILENUMBER` - Unique identity of the worker. Do not remove these attributes and their XPaths from the application XML. ## Issue: While Performing Delta Aggregation in Workday, Aggregation Does Not Work when the Time Zone Is Set to UTC **Resolution**: This only occurs if Daylight Saving Time is in sync with the NTP server and the time zone is other than PST. PST is the default time zone handled by Workday APIs. Whenever daylight savings occurs, make sure that the installed VA server (if additional proxy configuration) is in sync with the NTP server and the NTP server has applied daylight savings. ## Issue: Workday Accounts Are Disappearing and Reappearing **Example**: A new hire's identity is removed during a Workday aggregation that occurs the day before the new hire starts. When the next Workday aggregation occurs, the identity is added once more. This behavior is caused by a mismatch between the Workday connector's Effective Time Zone configuration value within SailPoint and the timezone in which the HR data (Hire, Termination, Re-hire, and Conversion) is processed. Within SailPoint, the connector's Effective Time Zone must be set to the same timezone in which the HR data is processed. For example, if the HR data is processed in the Central timezone, set **Effective Time Zone** (on the **Connection Settings** page) to `America/Chicago`. > [!NOTE] > > If the Effective Time Zone field is left blank, the timezone defaults to UTC. **Resolution**: 1. Go to **Admin \> Connections \> Sources**. 2. Open your Workday connector. 3. On the **Connection Settings** page, locate the Effective Time Zone field. 4. Set the **Effective Time Zone** value to the timezone in which the HR data is processed. 5. Save the change. ## Issue: The ReferenceIDMap Updates for Employee\_Type\_ID, Contingent\_Worker\_Type\_ID, and Phone\_Device\_Type\_ID During the initial aggregation, the connector dynamically updates the source configuration with the ID-to-name mapping based on the Workday configuration. **Resolution**: If some mappings have not been updated and the account is being populated with an ID, you can run a non-optimized aggregation. If needed, remove the following entries from the source config using the API, then run a non-optimized aggregation for a clean start: `ReferenceIDMap`, and the Phone Reference ID entries (`WORK_MOBILE`, `WORK_TELEPHONE`, `HOME_MOBILE`, `HOME_TELEPHONE`), Employee Type Reference ID (`EMPLOYEE_TYPE`), and Contingent Worker Type Reference ID (`Contingent_Worker_Type`) from the `XpathAttributesMap`. ## While Updating Landline Number for Worker, Connector Throws an Invalid ID Value Error for Phone\_Device\_Type\_ID It is observed that some tenants have the Phone Device Type "Telephone" defined on the Workday managed system as "Landline", which results in an incorrect mapping: | Key | Value | | --- | --- | | Fax | Fax | | Landline | Landline | | Mobile | Mobile | This is incorrect, as the connector specifically looks for the "Telephone" key, which is not in the list, and uses the default device ID `1063.5` to update the landline number, which is not present, resulting in the error. **Resolution**: Change the mapping for "Landline" as follows: ```json "Phone_Device_Type_ID": { "Telephone": "Landline", "Mobile": "Mobile", } ``` ## Business Event List Internally Handled by Connector By default, the connector adds the following business events to the delta event list while preparing the request. There is no need to add these business processes to the `` additionally: - Hire Employee - Terminate Employee - Contract Contingent Worker - End Contingent Worker Contract ## Delta Aggregation Does Not Aggregate Corrected/Rescinded Data **Explanation**: Delta aggregation works on business events. Workday does not provide a business event for corrected or rescinded data, so delta aggregation does not get corrected or rescinded data. ## WORK\_TELEPHONE Provisioning Failed with an Invalid ID Value Error for Phone\_Device\_Type\_ID **Explanation**: This error appears because the Workday connector uses the default phone device reference ID, which varies according to the tenant. The connector contains a `ReferenceIDMap` that contains the phone device type ID map. **Resolution**: To change the reference ID of a specific phone device type, modify the `Phone_Device_Type_ID` map using the REST API: ```text PATCH https://{orgName}.api.identitynow.com/v3/sources/{workdaySourceID} [ { "op": "add", "path": "/connectorAttributes/ReferenceIDMap", "value": {"Phone_Device_Type_ID":{"Mobile":"Mobile","Telephone":"Landline"}} } ] ``` > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. To check and retrieve the `Phone_Device_Type_Reference_Id`: 1. Search for the Maintain Reference IDs task. 2. Select the Business Object as "Phone Device Types", then select **None of the above**. 3. Select **OK**. The Reference ID values of the Phone Device Type ID are listed. # Timeout Errors and Settings Timeout errors might occur when SailPoint is waiting for a response from the Virtual Appliance (VA). These errors are applicable to all connectors and tend to occur during the setup of sources or when sources are down. This document is designed to give specific information that can be used to resolve these errors. Each timeout attribute has a default time value that is listed in seconds or minutes. Increasing the time value may resolve the error as it will allow for longer communication time between the two systems, thus avoiding the timeout error. > [!IMPORTANT] > > Add the necessary attributes or values before performing the "replace" operation, as missing attributes will cause the operation to fail. To increase the communication time, increase the value of the appropriate timeout attribute. Then submit the change to the VA using the SailPoint REST API. > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. ### aggregateTimeout **Description:** This parameter is set for the aggregation timeout, measured in seconds. **Resolution:** Increase the `aggregateTimeout` value gradually to optimize aggregation. Start with 180, then increase to 600, 900, and finally 1800. The maximum value is 3600 seconds. For example: If your current time value is 180 seconds, update the `aggregateTimeout` attribute as follows: ```json [ { "op": "replace", "path": "/connectorAttributes/aggregateTimeout", "value": 600 } ] ``` ### healthCheckTimeout **Description:** This parameter is set for the test connection and health check timeout. **Resolution:** The default value is 30 seconds. If the timeout error continues, increase the value in 15 second increments and try again. For example: If your current time value is 30 seconds, update the `healthCheckTimeout` attribute as follows: ```json [ { "op": "replace", "path": "/connectorAttributes/healthCheckTimeout", "value": 45 } ] ``` ### provisioningTimeout **Description:** This parameter is set for provisioning timeout. **Resolution:** Increase the `provisioningTimeout` value gradually to optimize provisioning. Start with 180, then increase to 360, and finally 600. The maximum value is 600 seconds. For example: If your current time value is 180 seconds, update the `provisioningTimeout` attribute as follows: ```json [ { "op": "replace", "path": "/connectorAttributes/provisioningTimeout", "value": 360 } ] ``` ### timeout **Description:** This parameter is set for pass-through authentication timeout. **Resolution:** The default value is 15 seconds. If the timeout error continues, increase this value in 15 second increments and try again. For example: If your current time value is 15 seconds, update the `timeout` attribute as follows: ```json [ { "op": "replace", "path": "/connectorAttributes/timeout", "value": 30 } ] ``` ### apiTimeout **Description:** This parameter is set for API time tracking; customers can check it using an external tool. **Resolution:** The default value is 60 seconds. If the error continues, increase the value by 15 second increments and try again. For example: If your current time value is 60 seconds, update the `apiTimeout` attribute as follows: ```json [ { "op": "replace", "path": "/connectorAttributes/apiTimeout", "value": "75" } ] ``` ### timeoutInSeconds **Description:** This parameter helps prevent the VA from waiting indefinitely for an API response, ensuring efficient handling of API requests. For example: If your current time value is 30 seconds, update the `timeoutInSeconds` attribute as follows: ```json [ { "op": "replace", "path": "/connectorAttributes/timeoutInSeconds", "value": "15" } ] ```