System owner roadmap

Ancillary systems that manage business processes necessary outside of Workday will be “kept”; to continue operating after the Workday implementation, many will need updated data integrations. It is also an opportune time to evaluate the long-term viability and security of these systems and consider appropriate actions to manage risks.

Following are the key steps for “keep” systems in the roadmap to Workday implementation:

Step 1: ASP work planning and prioritization

ASP business analysts reach out to all schools, colleges, institutes, and divisions (SCIDs) with a link to a spreadsheet, the purpose of which is to collect additional information on each specific system to help with ASP planning.

Step 2: Integration recommendation

Any system that integrates with the current HR or financial system will require Workday data in the future. The goal is to identify a modern integration method that provides the necessary data.

Step 3: Security review

The Office of Cybersecurity conducts security assessments of most “keep” systems. Risk Executives review the findings and determine appropriate actions if necessary.

Step 1 addresses all “keep” systems belonging to a campus unit at once whereas Steps 2 and 3 are done system-by-system, one at a time. Campus units will iteratively go through Steps 2 and 3 for each “keep” system they have.

Step 1: ASP work planning & prioritization

Information collection

Primary technical contact or business contact for the system receives a spreadsheet listing all “keep” systems and 11 questions, many that require selection of one answer from several choices.


Responses will be used to plan and prioritize the work in subsequent Steps 2 and 3.

Next step

Work on Step 2, integration recommendation, will start for higher priority systems.

Step 2: Integration recommendation

Information collection

Primary technical contact or business contact for the system receives a survey of about 15 questions specifically around the system’s integrations. Support for completion of the survey is available via open office hours with the ASP integrations team.

Next step

Integrations team member/s and a business analyst meet with system contacts and/or unit leadership to discuss the integration recommendation and considerations including:

    • Types of integrations available to the system and the recommended type of integration
    • Impacts to vended solutions and ability of vendor to respond
    • People/skills available within the campus unit to update the integrations
    • Cost considerations (licenses, external support if necessary)
    • Timeline

Analysis & recommendation

The integrations team reviews the survey responses and follows up as necessary to arrive at a recommended approach for integration.


System owners evaluate the benefits of the ancillary system against potential costs, effort, and time needed to update the integrations. Ultimately, the system owner and campus unit leadership decide whether to proceed with the integration recommendation or to retire the ancillary system and seek other options for completing the necessary work.

This is an accordion element with a series of buttons that open and close related content panels.

Integration principles for system stakeholders

Integration pattern Modality Description Rationale
Direct integration with Workday Cloud Connect Pre-delivered connectors to cloud services Connectors are the preferred approach where direct integration with Workday is warranted. Direct integration creates a tight coupling, so this should be used only where required. Tight coupling is warranted when a connected system requires close knowledge of the internal operations of Workday (such as the need to manipulate data within Workday).
Direct integration with Workday Enterprise Interface Builder (EIB) Custom reports, extracts and ELT Batch integrations against ERP systems are warranted when there is a high degree of specific domain knowledge or data, and a tight coupling with domain data is justified. Examples of this include: state or federal reporting where the data provided requires precise interpretation, or where regulatory changes must be regularly assessed and implemented within the ERP.
Direct integration with Workday Workday APIs Access to Workday APIs and Reports as a Service (RaaS) Direct access to Workday APIs creates a tight coupling, and in many cases will provide more data than is needed for the specific business purpose. This integration pattern is most suitable for building out functionality within the Workday platform itself (e.g. Workday Extend), or within systems that operate as sidecars alongside Workday.
Integration via Integration Hub Integration Platform (IICS) Integration with HR or Finance data via IICS The Integration Platform provides a loosely coupled integration pattern that does not create a new direct dependency on the ERP platform. The interface can provide some normalization of data formats between different domains so that clients do not need to navigate radically different structures or modalities to consume data from multiple domains.
Integration via Integration Hub APIs and Events Integration with Person or other institutional APIs or events Institutional APIs will rationalize data presentation across different business domains to allow for consistency and ease of use. Institutional APIs will also be integrated with institutional data approval and security review (RMF) processes to allow for unified data approval and inherited security controls.
Integration via Integration Hub IAM / Provisioning Infrastructure Integration with grouping, provisioning or login infrastructure IAM systems calculate effective rights based on ‘additive privilege’ and, therefore, require aggregation of roles across a number of sources. Effective rights may also need to be adjusted or terminated based on factors in a number of different systems (HR/student role changes, security actions) so require an aggregated view of a person across different business and data domains.
N/A Variable System stakeholders are responsible for integration In these situations, integrations are the responsibility of the system stakeholders:

  • The ancillary system feeds a system other than Workday that’s either internal to the campus/UW System or external (vendor or supplier system).
  • The integration involves student/academic data and does NOT involve “person” data (identity and access), nor UDDS. Examples are data sourced from SIS, CAOS or other ERPs.
  • The integration is currently manual; either ancillary system data is manually uploaded or entered from the ancillary system into Workday (future) OR data is manually pulled and uploaded or entered into the ancillary system.

Step 3: Security review

Information collection

Members of the Cybersecurity team will initiate an abbreviated risk assessment questionnaire and will meet with business contacts to collect and document the necessary information.

Next step

Security analysts work with system owners to create action plans.

Due to the number of systems involved and the complexity of the risk assessment, review, and action planning process, this step will likely continue beyond implementation of Workday.

Analysis and report

After analyzing the information collected, the security analyst will issue a risk review report with recommended actions to mitigate identified risks.


Ultimately, the unit risk executive has responsibility for ensuring each identified risk is either addressed or acknowledged and accepted.