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:

["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.

Prerequisites:

• 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:

      {
        "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:

      {
        "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

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

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.

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:

[
    {
        "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.

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 (<underscore><underscore>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:

   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_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 <Custom_ID_Type_ID> in the XPath.

5. Ensure that the final XPath is as follows:

   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:

   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
   

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:

   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:

[
    {
        "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:

[
    {
        "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.

The following table describes the different scenarios:

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.

   {"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:

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.

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.

Future_Termination_Events

This list contains events from which workers can be terminated in Workday. These events are used while fetching future terminating workers.

<entry key="Future_Termination_Events">
  <value>
    <List>
      <String>End Contingent Worker Contract</String>
      <String>Terminate Employee</String>
    </List>
  </value>
</entry>

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.

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:

<entry key="Include_Reference_Descriptors_In_Response" value="true"/>

The XPath of the respective attribute must be modified as shown in the following example for the COUNTRY attribute:

<entry key="COUNTRY" value="ns1:Worker_Data/ns1:Personal_Data/ns1:Contact_Data/ns1:Address_Data/ns1:Country_Reference/@ns1:Descriptor"/>

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.

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.

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.

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.

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.

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:

  PATCH https://{orgName}.api.cloud.sailpoint.com/v3/sources/{workdaySourceID}
  
  Form-Data:
  key: connector_version
  value: <Workday API version>
  

  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

Documentation Feedback

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