# 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.