Integrations are connections between different information systems that enable the sharing of data to complete steps in a process.
We are integrating Workday Student with many of our student information systems to support our core academic and student processes.
Which systems will integrate with Workday Student?
Following more than 60 discovery meetings with WashU system stakeholders, the Student Sunrise team determined that 80+ systems need to exchange data with Workday. Each of these systems requires at least one integration for a total of 240+ integrations.
Exploring integrations
The integrations process is a collaborative effort that requires system development at both ends. Workday is at one end. On the other, there’s a “downstream” system such as:
- A school- or unit-managed system
- A central system that’s used by multiple schools/units and is supported by the WashU IT Enterprise Applications department, or
- An application programming interface (API*).
Some downstream systems will need refactoring, or updating, to send to or receive data from Workday. These updates may include changing a system’s business logic, changing a system’s technical design, or adding, removing or merging database fields or tables.
*An API is a method of integration that enables two systems to communicate with each other. An example of an API that many WashU systems currently use is /person/students.
What are the types of integrations and how do they work?
An integration that takes data from a system and loads it into Workday Student
- Example: SLATE UG Student Applications Inbound – loads student applicant information from Slate Undergraduate into Workday Student to create the student record and begin the student matriculation process
An integration that takes data from Workday Student and loads it into a system
- Example: Canvas Course Sections Outbound – loads course section data from Workday Student into Canvas to link faculty and students to the Canvas learning activities for a specific section
The syncing of two datasets in two different systems so that they behave as one while also respecting the need for both datasets to be independent
- Example: BookNow Student Charges Punchout Bi-directional – inserts a link into Workday Student that when clicked takes students to the bookstore system to view and acquire course materials for their enrolled courses
Extracting data from Workday Student and then reloading it back to Workday Student
- Example: Instructor Eligibility Addition Boomerang – updates course instructor records in Workday Student to identify instructors who are eligible to teach based on HR data stored in a different location of Workday
Creating Integrations
We are scheduling the development of each integration so that it’s ready to supply or receive data for processes as we activate them in Workday during our rolling go-live. Developing an integration consists of two important phases: design and build & unit testing.
1. Design
Creating a successful integration begins with design. During the design process, we meet with our campus partners to learn about their academic processes and data needs. The product of the design discussions is an integration design document. This document serves as a blueprint for building an integration that can be updated as needed. For example, Student Sunrise may need to revise it to make the integration work with the software updates that Workday releases every six months.
2. Build & Unit Testing
Using the integration design document, a developer from our team writes the software code for the Workday side of the integration. The campus partner builds their side of the integration and may need to refactor, or reprogram, their system to exchange the new types of data in Workday Student.
Each team runs test data through their side of the integration in a process known as unit testing. If the integration doesn’t work on one or both sides, the developer(s) will fix the code until the data transfers with no errors. When both sides of the integration work as they should, the integration is ready for end-to-end testing.
End-to-End Testing
After unit testing is successful, the integration is ready for end-to-end testing. During this process, test data travels through Workday and any integrated systems to complete an academic or student process. If the integration passes end-to-end testing, it’s ready for when it will go live in Workday. If it doesn’t pass, the developer(s) re-code and unit test the integration(s), and the team performs another end-to-end test. This process repeats until the integration works as intended.
Questions?
Contact your school or unit’s IT Leader Advisory Group member, or you can submit questions or comments through this form.