# SailPoint Workday Students Connector Documentation > Workday Students Connector Documentation # Documentation # Aggregation of Multi-Status Student Records In Workday, a single individual may hold multiple concurrent roles throughout the student lifecycle. These roles may include: - Prospect - Applicant - Pre-Matriculant - Matriculant - Graduate This scenario is referred to as a **Multi-status Individual**, where the person record is associated with several active statuses simultaneously. ### Status Hierarchy When retrieving student records from the **Workday Students** connector, the system applies a status hierarchy to determine which status takes precedence in cases of multiple statuses are active. The connector returns only one record per individual, corresponding to the highest-priority active status. The status precedence is defined as follows (from highest to lowest priority): 1. Matriculant 2. Pre-Matriculant 3. Applicant 4. Prospect 5. Inactive Matriculant For example, If all status options are selected, and a person holds both a Matriculant and Applicant status, the connector will fetch the Matriculant record, as it holds higher precedence in the defined hierarchy. | Student Statuses | Fetched Record | | --- | --- | | Matriculant, Pre-Matriculant, Applicant, Prospect, Inactive Matriculant | Matriculant | | Matriculant, Applicant, Prospect | Matriculant | | Pre-Matriculant, Applicant | Pre-Matriculant | | Applicant, Prospect | Applicant | | Inactive Matriculant, Prospect | Prospect | # Configuring Workday Students for Integration ## Obtain a Workday ID 1. On the Workday system, search for the **View Academic Unit** task. 2. Enter **academic unit name**, Select **Save**. 3. Navigate to **Actions \> Integration IDs \> View IDs** 4. Verify the **Workday ID**. # Connecting SailPoint and Workday Students To connect SailPoint with Workday Students, perform the following tasks: ## Adding the Source in SailPoint To connect to SailPoint, perform the following steps. Once the connection is made, you can configure it to meet your company's needs. > [!IMPORTANT] > > By default, the provisioning feature is **disabled**, and the connector only supports read-only operations. To support provisioning operations, you must manually enable the feature in the source configuration. **To configure a new source:** 1. Sign in to SailPoint. 2. Go to **Admin \> Connections \> Sources**. 3. Select **Create New**. 4. Search for the connector by entering the name in the search box, and then select **Actions**. 5. In the **Actions** dropdown list, select the setup method: - [**Express Setup**](<#configuring-a-source-using-express-setup>) - Quickly create a read-only connection to your target system by providing minimal configurations and authentication. On completion, aggregation is automatically started. > **Note** > > Express Setup supports Credential Providers. For information on supported credential providers and configuration, refer to [Credential Providers](). For more information, contact your SailPoint Customer Service Manager. - [**Standard Setup**](<#configuring-a-source-using-standard-setup>) - Provide detailed basic configuration to create the source. Once the source is created, continue with source setup. ### Configuring a Source Using Express Setup Express Setup minimizes the initial configuration process so you can quickly connect the application and immediately begin aggregating user account and entitlement data. 1. Review the directions and select **Start Express Setup**. 2. Review the pre-populated **Source Name**, **Source Owner**, and **Description**. To update, select **Edit**. > **Note** > > The source name must be unique. You can change these settings later in the source configuration. 3. (Optional) If enabled for your organization, select the **Use a Credential Provider** checkbox to manage the source's authentication using a credential provider. > **Note** > > To add a Credential Provider in SailPoint, go to **Admin \> Connections \> Credential Providers**. For more information about credential providers, refer to [Credential Providers](). 4. Configure the authentication to allow SailPoint to connect to the source. For more information, refer to the **Connection Settings** section. 5. Select **Finish**. After a successful test connection, the system creates your source and prompts you to run an aggregation. - If you want to aggregate now, select **Aggregate**. - To see the latest account aggregation history, go to **Account Management \> Account Aggregation**. - To see the list of aggregated source accounts, go to **Account Management \> Accounts**. - If you want to aggregate later, select **Exit**. This returns you to the **Sources** page. Your new source is listed, but contains no accounts or aggregation history yet. ### Configuring a Source Using Standard Setup Use Standard Setup to configure the connector for full feature support. 1. In the **Source Name** field, enter a unique and descriptive name for your source. Source names cannot exceed 128 characters. 2. In the **Description** field, provide additional details about the source to help distinguish it from similar sources. This field allows a maximum of 2,000 characters. 3. In the **Source Owner** field, begin typing the name of an owner. Matches appear after you type two or more letters. For more information, refer to [Assigning a Source Owner](). 4. (Optional) Select a governance group to grant its members [source]() or [role]() sub-admin level oversight of the source and its access. For more information, refer to [Creating and Managing Governance Groups](). 5. If this source represents a primary system containing your organization's personnel records, select the **Authoritative Source** checkbox. For more information, refer to [Creating Identity Profiles](). 6. Select **Continue**. The source is created, and you are navigated to the **Source Setup \> Base Configuration** page. Continue to configure your connected source there. ## Connection Settings Provide the information required to connect and interact with the source. > [!NOTE] > > **Screenshot** > > [![Connection Settings]()]() To configure your connection settings, complete the following: 1. Go to **Connection Settings**. 2. Enter the **Workday URL** that SailPoint uses to connect to the Workday Students module. 3. Select **OAuth 2.0** as an authentication type. 4. Select the **Grant Type** used for authentication. 5. Enter the Workday API **Client ID** and **Client Secret**. 6. Enter a **Refresh Token** that doesn't expire or has a long expiration period. 7. Enter the **Token URL** to request an access token for a user. 8. Enter the **Workday ID** of **Academic Unit** to aggregate the student records associated with that unit. 9. In the **Connection Timeout in Minutes** field, enter the time span after which an attempted connection terminates. 10. Select **Save**. ## Aggregation Settings For more information about aggregation, refer to [Loading Account Data](). Use the settings available in **Aggregation Settings** to adjust aggregation processes as required for your organization. > [!NOTE] > > **Screenshot** > > [![Aggregation Settings]()]() 1. Select **Manage Prospect Students** checkbox to aggregate Prospects accounts. 2. Select **Manage Applicant Students** checkbox to aggregate Applicants accounts. 3. Select **Manage Pre-Matriculant Students** checkbox to aggregate Pre-Matriculant accounts. 4. Select **Manage Matriculant Students** checkbox to aggregate Matriculated accounts. 5. Enable **Manage Inactive Matriculant Students** checkbox to aggregate Matriculated accounts. 6. In **Inactive Offset** field, enter the offset value in days, which indicates the number of days in the past since students graduated. 7. In the **Page Size** field, enter the number of records to aggregate in a single page when iterating over large datasets. You can set from 1 to 999. The default is 500. 8. Select **Save**. ## Review and Test Perform a test to confirm the connection to SailPoint. 1. Go to **Review and Test**. 2. Confirm that the entries in each field are correct. If you note any mistakes, return to the section and make corrections. 3. Select **Test Connection**. ## SailPoint Application Onboarding SailPoint application onboarding enables you to easily onboard new applications and create sources following the successful onboarding of a discovery source. To use this feature, continue to **Discovered Applications** in the SailPoint user interface. For more information, refer to [Application Onboarding]() in the SailPoint SaaS documentation. # Integrating SailPoint with Workday Students The Workday Students connector manages student identities by retrieving relevant data from Workday Student module for identity governance and access management. This guide is designed to give specific information about the requirements and field definitions needed to get a working instance of a Workday Students connector. > [!NOTE] > > To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes]() page. ## Supported Features The SailPoint Workday Students connector supports the following features: - Account Aggregation - Aggregation of Workday Student Prospects - Aggregation of Workday Student Applicant - Aggregation of Workday Student Pre-matriculate - Aggregation of Workday Student Matriculants - Aggregation of Inactive Workday Student ## Supported Managed Systems The Workday Students connector supports the following versions of the Workday System: - Workday API version 43.2 > [!NOTE] > > The Workday Students connector uses Workday's SOAP API which is independent of the Workday system version, and is backward compatible. ## Prerequisites - Ensure you have an integration user, refer to [Creation of Integration User](<#creation-of-integration-user>). - Oauth 2.0 is configured in your Workday tenant and that the required credentials (Client ID, Client Secret, Token URL, etc.) are available for integration. For detailed instructions, refer to the [OAuth 2.0 Authentication](<#oauth-20-authentication>). - You must have the Workday ID for the Academic Unit, refer to the [Obtain a Workday ID](). ## Required Permissions This section describes the permissions required for the Workday Students source on the Workday managed system. ## Creation of Integration User 1. On the Workday system, search for the **Create Integration System User** task and enter the required details for Account Information in the task (User Name, Password, etc) for the first integration user. For example, `SailPoint_User.` ## Creation of the Integration Security Group This section describes creation of the integration security group for constrained and unconstrained security groups. ### Constrained 1. On the Workday system, search for the **Create Security Group** task. 2. Select **Integration System Security Group (Constrained)**. 3. Provide a name to the integration group. Create group as follows: - For the Read group (**SailPoint\_Read\_Group**) 4. Add the Integration System Users (SailPoint\_User) created in [Creation of Integration User](<#creation-of-integration-user>) to the respective groups. ### Unconstrained 1. Create the **Integration System Security Group (Unconstrained)**. 2. Perform the following for the Integration System Security Group: - Add the Integration System Users (SailPoint\_User) created in [Creation of Integration User](<#creation-of-integration-user>) in the Integration System Security Group (Unconstrained). The permissions are given to integration system groups that are attached to the integration system. > [!NOTE] > > The Workday fields in the Workday Managed System that are marked as **private** are not accessible through the Workday API. The fields marked as **public** are accessible. To ensure that the Workday Students connector aggregates all applicable attributes, you must mark them as **public**. ## Assign Permission to the Security Group 1. On the Workday system, go to the **Actions** item of the group created in [Creation of the Integration Security Group](<#creation-of-the-integration-security-group>) and select **Security Group**. 2. On the **Security Group** menu, select **Maintain Domain Permissions for Security Group** from the list. 3. Add the domain security policies permitting the access list for the groups, respectively, from the following table: | Domain | Category | Permission | | --- | --- | --- | | Workday Query Language | Report/ Task Permissions | Modify access | | Reports: Students | Report/ Task Permissions | View access | | Audit: Academics Data | Report/ Task Permissions | View access | | Reports: Students | Report/ Task Permissions | Get access | | Integration Build | Report/ Task Permissions | Get access | | Person Data: Name | Report/ Task Permissions | Get access | | Student Data: Personal Data | Report/ Task Permissions | Get access | 1. Select **Done**. 2. Search for the **Activate Pending Security Policy Change** task and run it. ## OAuth 2.0 Authentication The following permissions are required for OAuth 2.0 Authentication Type: 1. Create the API Client. For more information on API Client creation, refer to [Create the API Client for Integration](<#create-the-api-client-for-integration>). 2. Ensure the Workday Account used for the API Client to generate the refresh token must be an integration user. For more information the permissions, refer to [Creation of Integration User](<#creation-of-integration-user>). 3. Add the following functional area under the API Client Integration used for OAuth 2.0: - Student Records - Student Core - Contact Information - Integration - Personal Data - System > [!NOTE] > > OAuth 2.0 authentication should be implemented using a designated service account. This service account must be provisioned with all necessary permissions and access scopes, as previously defined in the Basic Authentication configuration section. ## Create the 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): - Student Records - Student Core - Contact Information - Integration - Personal Data - System 2. Use **View API Client** to generate a refresh token. 1. Go to **API Client for Integrations** tab. 2. Select **API Client** from the list. 3. Go to **Actions \> API Client \> Manage refresh for integrations**. 4. Select the Workday Account for which the refresh token must be generated and select **Next**. 5. Select the **Generate New Refresh Token** option and select **OK**. # Schema Reference The application schema is used to configure the objects returned from a connector. > [!NOTE] > > - The **Account Schema** tab is used to define the attributes for each object type in the application being configured. The schema attributes can be defined as **Entitlement** or **Multi-Valued**. Refer to [Managing Source Account Schemas]() for more information. > - The schema attributes that are not present by [default](<#default-account-schema>) must be defined as strings if not specified. The Workday Students connector uses the following default correlation and object configurations. ## Default Correlation Configuration Before you aggregate accounts from this source, you can map account attributes with their corresponding identity attributes based on your requirements. You can customize the correlation configuration. Refer to [Assigning Source Accounts to Identities]() for more information. When you first create the Workday Students source, the default correlation mapping is: | Account Attribute | Operation | Identity Attribute | | --- | --- | --- | | User\_Name | Equals | SailPoint User Name (uid) | | Email\_Address\_Work | Equals | Work Email | ## Default Account Schema Each source supports a variety of details, or attributes, about each user who has an account, such as their name, email address, manager name, and location. The set of account attributes each source stores and how they're organized is known as the account's *schema*. To best represent your data, you can configure sources to use an account schema matching the one you use in the external connector. Refer to [Managing Source Account Schemas]() for more information. ### Default Account ID SailPoint requires that certain attributes remain in your configuration. These attributes are referred to as *account IDs*. > [!CAUTION] > > Changing the attribute marked as the account ID after aggregating accounts can result in duplicate accounts being created. To avoid this, either reset the accounts on this source before editing the account ID attribute or edit the account ID attribute before aggregating accounts. > > To resolve issues caused by changing account IDs, reconfigure them to their default values. The following table lists the default account IDs for this connector: | Account ID | Schema Object Type | | --- | --- | | WID | Account | ### Default Account Attributes The Workday Students connector supports the following default account schema attributes and customer configurable attributes. The attributes must be defined as strings if not specified. | Attribute Name | Description | | --- | --- | | WID | The user's unique ID. | | User\_Name | The user name of the workday account. | | First\_Name | The First Name of the Student | | Last\_Name | The Last Name of the Student. | | Full\_Legal\_Name | The full legal name of the student. | | Legal\_Name | The Legal for the Student. | | Academic\_Level | The student's Academic Level. | | Prefix | The prefix of the student's legal name. | | Address\_Home | The primary home address of the student. | | Email\_Address\_Home | The primary home email address of the student. | | Address\_Work | The primary work address of the student. | | Student\_ID | The student ID of the student. | | Universal\_ID | The universal ID of the student. | | Academic\_Unit | The academic unit of the application for this student prospect record. | | Home\_Mobile | The primary home phone number of the student. | | Email\_Address\_Work | The primary work email address of the student. | | Work\_Mobile | The primary home phone number of the student. | | Student\_Type | The type of the student. | | Academic\_Person | The Academic person. | | Student\_Record\_Status | The student record status. | | Additional\_Email\_Address\_Home | The additional home email address of the student. | | Additional\_Email\_Address\_Work | The additional work email address of the student. | | Student\_Program\_of\_Study\_Record\_Status | The program of study record status of student. | # 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]() ## Debug Logs For information about managing additional source settings, including debug logging and downloading connector logs, refer to [Managing Additional Settings]().