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.
- 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.
- 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
- 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
- On the Workday system, search for the Create Security Group task.
- Select Integration System Security Group (Constrained).
- Provide a name to the integration group. Create group as follows:
- For the Read group (SailPoint_Read_Group)
- Add the Integration System Users (SailPoint_User) created in Creation of Integration User to the respective groups.
Unconstrained
- Create the Integration System Security Group (Unconstrained).
- Perform the following for the Integration System Security Group:
- Add the Integration System Users (SailPoint_User) created in 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
- On the Workday system, go to the Actions item of the group created in Creation of the Integration Security Group and select Security Group.
- On the Security Group menu, select Maintain Domain Permissions for Security Group from the list.
- 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 |
- Select Done.
- 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:
- Create the API Client. For more information on API Client creation, refer to Create the API Client for Integration.
- 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.
- 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
- Using the Register API Client for Integrations task, register a new API Client for Integrations with the following configurations:
- Client Name
- Grant type: Authorization Code Grant
- Access token: Bearer
- Select the Non-Expiring Refresh Tokens option.
- Uncheck the Disabled option.
- Select the Scope (Functional Areas):
- Student Records
- Student Core
- Contact Information
- Integration
- Personal Data
- System
- Use View API Client to generate a refresh token.
- Go to API Client for Integrations tab.
- Select API Client from the list.
- Go to Actions > API Client > Manage refresh for integrations.
- Select the Workday Account for which the refresh token must be generated and select Next.
- Select the Generate New Refresh Token option and select OK.
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.