Configuring Workday for Integration

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

Support for Filtering Using Organization

The Workday source can be configured to support account filtering based on organization. These organization filters can be applied in two ways:

Organization Type - The Workday source can be configured to support the fetching of active and future worker accounts based on the type of organization. For example, SUPERVISORY, COST_CENTER.
Organization Reference - The Workday source can be configured to support the fetching of worker accounts based on the type of specific organizations. You can find the Organization Reference IDs as follows:
1. Go to your Workday tenant and search for the required organization.
2. Hover over the action and then select Integration ID.
3. Select View IDs and note the ID present in front of the organization.

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

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

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.

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:

Sign in to the Workday managed system.
Search for View Custom ID Types and select an Identifier Type of the required custom ID.
Go to Integration IDs > View IDs.
Under Reference IDs, copy the ID value and place it at <Custom_ID_Type_ID> in the XPath.

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:

Add the attributes to the account schema.

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

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.

Aggregating Multi-Valued Attributes

When aggregating attributes that contain multiple values, such as Leave of Absence types, additional configuration is required on the Workday source. This ensures the attribute is correctly mapped and stored as a list of values rather than a single value.

To aggregate multi-valued attributes:

Add the multiValueAttr parameter to the source configuration using the REST API. Include each attribute name you want to aggregate as multi-valued in the array. For example, to aggregate Leave of Absence types, add the following:
```
[
    {
        "op": "add",
        "path": "/connectorAttributes/multiValueAttr",
        "value": [
            "LEAVE_OF_ABSENCE_TYPE"
        ]
    }
]
```
Replace LEAVE_OF_ABSENCE_TYPE with the attribute name you add to the account schema.
Add the XPath for the multi-valued attribute in the XPath schema mapping. For example, to retrieve Leave of Absence types, add an entry as follows, where the value of the entry is the XPath required to fetch the required field:
```
key="LEAVE_OF_ABSENCE_TYPE"
value="ns1:Worker_Data/ns1:Employment_Data/ns1:Worker_Status_Data/ns1:Leave_Status_Data[*]/ns1:Leave_of_Absence_Type_Reference/ns1:ID[@ns1:type='Leave_of_Absence_Type_ID']"
```
Note

The asterisk [*] in the XPath selects all instances of Leave_Status_Data, allowing multiple Leave of Absence type values to be collected during aggregation.

Refer to XPath Schema Mapping for more information.
Add the multi-valued attribute to the account schema and select Multi-Valued. This ensures the attribute is recognized during aggregation.

Refer to Default Account Attributes for more information.

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.

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:

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.

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

Update your existing Workday source with the following:

Key: connector_version

Value: use 30.1
Add or update the respective attribute XPath and schema as required based on Workday API version 30.1.

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:

Search for Create Integration Field Override Service in Workday, and create a new Integration Field Override Service.
Assign a name to the Integration Field Override Service and select the business object as Worker.
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.
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.
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.
Note the System ID for this Workday Integration System. It is required to retrieve the custom or calculated attributes.
Search for View Integration System.
Enter the name of the Workday Integration System you created in Step 4.
Select OK.
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.
When applicable, grant the required permissions to the Service Account associated with the SailPoint application to aggregate the new custom or calculated fields.
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.

Create API Client for Integration

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

Additional Schema Attributes must be added manually.

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.