Triton Student System (TSS)

Starting March 2, 2026, the TSS Project Change Management and Training Teams will host weekly office hours. 

Office hour schedule: 

Mondays: 3–4 p.m. 

Wednesdays: 9–10 a.m. 

(Zoom link for office hours - opens in a new tab) 

Vision

• The TSS Project's strategic vision mirrors that of the overall SIS Project portfolio. View the SIS Project Vision.

Guiding Principles

• The TSS Project's guiding principles mirror those of the overall SIS Project portfolio. View the SIS Project Guiding Principles.

Shared Expectations

• The TSS Project's shared expectations mirror those of the overall SIS Project portfolio. View the SIS Project Shared Expectations.

**Need to Zoom in? Need additional viewing support? Please access these slides via the following link: TSS Project: Timeline. Descriptive and explanatory text has been added in the speaker notes of each slide.**

Below, find the detailed list of past, current and upcoming project milestones. Please note that upcoming milestones are subject to change.

• Pre-work: Process Mapping, Ideal State Development, RFPs/Vendor Selection (2019-2023)
  • Project Initiation (August 2019)
  • Process Landscape Approved by Stakeholders (December 2019)
  • Request for Proposal (RFP) #1 Released to Vendors (March 2020)
  • Current State Process Mapping (July - December 2020)
  • Conference Room Pilots with RFP #1 SIS Vendors (Nov 2020 - Jan 2021)
  • Ideal State Process Mapping Sessions with SMEs (February - May 2021)
  • Request for Proposal #2 Seeking a Vendor Partnership Released (October 2021)
  • Request for Proposal #3 Released (September 2022)
  • Conference Room Pilots with RFP #3 SIS Vendors (March - May 2023)
  • New Student Information System Vendor Selected (December 2023)

• Plan: Prepare (2023-2024)
  • Project Kickoff (March 2024)
  • Advisory Committee Meeting Kickoff (June 2024)

• Execute: Design, Build, Test & Train (2024-2026)
  • Process Design Workshops (May 2024 - March 2025)
  • System Testing (TBD)
  • System Training (TBD)
  • Initial Release Go Live (Summer 2026 Quarter)

• Close: Hypercare (2026)

Escalation Process

• TSS Implementation Team Members
• TSS Advisory Committee Members

Learn more about the roles of this team in the SIS Project Teams article.

If you have difficulty accessing these links, please contact esr-student@ucsd.edu.

Articles shared below are listed from newest (top) to oldest (bottom). Please note that some content of older articles may be slightly out of date. To ensure you review the most accurate content, we recommend to review the most recent (newest) project information or articles. 

• TSS Project: You Said, We Did (March 2026)
• TSS Scheduling Training: Coming Soon! (February 2026)
• Triton Student System (TSS): Demonstrations Recap (January 2026)
• Triton Student System (TSS): System Testing (October 2025)
• Prepare for Launch in Summer 2026: Triton Student System (TSS) (October 2025)
• Triton Student System (TSS): Impacts on Applications You Use (October 2025)
• TSS Process Group 4: Design Done, Build Begins (June 2025)
• Revised TSS Timeline: SU26 Release (May 2025)
• TSS Process Group 3: The Joy of Progress (March 2025)
• TSS Process Group 2: The Journey Continues (February 2025)
• Navigating New Systems: The Role of Training (January 2025)
• That's a Wrap on Process Group 1 (October 2024)
• They Advise, We Revise: TSS Project Advisory Committee Kickoff (August 2024)
• Sharing the Wealth: Learning about SLcM from the University of Kentucky (August 2024)
• New SIS, New Name: Introducing the Triton Student System (June 2024)
• Initial Release of the New SIS Explained (June 2024)
• Let's Get Down to Business: Process Design Workshops (May 2024)
• SLcM Training: Setting the Stage (April 2024)
• Project to Replace ISIS Moves Forward (March 2024)
• System to Replace ISIS Selected (December 2023)
• Backfill: Prioritizing Staff Expertise for the SIS Project (August 2023)
• Time to Upgrade: Why We Must Replace ISIS Now (June 2023)
• Preparing for Change Freezes (May 2023)
• Moving the SIS Project Forward After a Second No Award (September 2022)
• The Future State of SIS Reporting (March 2022)
• RFP for SIS Vendor Partnership Released (November 2021)
• Next Steps Toward a New SIS (February 2021)
• Information and Understanding Exchange (January 2021)
• SIS Moves Forward with Executive Support (July 2020)

If you'd like to learn more about the continuity planning & report remediation efforts, please see these articles:

• Retirement of Student QueryLink Reports & Updates (January 2026)
• Student QueryLink Reports Remediation Updates (November 2025)
• Second Round of Student Reports Now Available (August 2025)
• The First New Student Reports Are Here! (July 2025)
• Get Ready: New and Improved Student Reports Coming to the Business Analytics Hub (June 2025)
• A New Chapter for Report Remediation (March 2025)
• Planning for Continuity Planning (May 2024)
• Preparing Stakeholders for Reporting Changes (November 2023)
• SIS Project Preparation Work: Report Remediation (June 2022)
• Minimizing Disruptions and Supporting Report Access (December 2021)
• Reporting in Focus (July 2021)
• Focus on Reporting and “Pre-habilitation” Activities (May 2021)

OVERVIEW

What functions and processes will be available when the new student information goes live?

The initial release of TSS will prioritize the university’s critical functions and processes when we go live. Additional features will be introduced in follow-up releases as time and resources allow. For a system of this size and scope, a phased rollout is standard practice, with additional releases continuing to add more functionality.

Will we retain all the same functionality when we move to the new system?

The short answer is no. Because our current functionality is the result of many years of creating workarounds to support poor or missing functionality in ISIS, we are untangling functionality from processes. Some functionality may be approached differently in the future state. We will develop future state processes in conversations with stakeholders using the knowledge of our subject matter experts and aligned with our guiding principles. This future state process design will begin with the Process Design Workshops and continue in an iterative fashion throughout the build phase of the project.

What is “MVP”?

You may hear this initial release sometimes referred to by the software development industry-standard term of “Minimum Viable Product” or “MVP”.

CRITICAL FUNCTIONS

What are critical functions?

Critical functions and processes are those which we must be able to execute to maintain the ongoing operations of the university, such as those required to deliver transcripts and diplomas to students. The initial release of the new TSS must be stabilized before any future releases can be made.

What are the features included in the initial release and why were they prioritized? 

The project’s design team has already put a great deal of intentional thought into what will be in the initial release and has consulted with many functional subject matter experts from across the university, including Registrar, Division of Extended Studies (DES), Student Financial Solutions, Division of Graduate Education and Postdoctoral Affairs (GEPA), Financial Support Unit, Financial Aid and Scholarships, Business & Financial Services and others. 

What is included in the list of critical functions?

While these resources do not provide a comprehensive list, you can learn more about some of the critical processes and functions from the Process Design Workshops and Process Design Documents. A list of what functions have been identified as critical and therefore prioritized for the initial release will be made available for the university community to review.

How is it decided which functions and processes will be prioritized for the initial release?

In addition to the design team and the functional subject matter experts (SMEs) already consulted, the project’s advisory committee and governance committee will also have opportunities to review and provide feedback on the list of critical functions prioritized for the initial release. 

Who decides what is included in the initial release?

Final approval of the list, following review and feedback, lies with the Business Process Owner (Cindy Lyons), Service Owner (Jonathan Whitman), and Governance Chair (Christine Alvarado).

How will we be sure that all critical functions and processes are included in the initial release?

Even with the large amount of time and input that has already gone into determining what will be prioritized for the initial release, we are certain that we have not captured everything yet.

How do we know we've captured all the critical priorities for the initial release?

As we continue through the design and build phases of the project, we will continue to refine what will be included in the initial release and consult with stakeholders from across the university to review and provide input on what will be included.

PROVIDING FEEDBACK 

Who can provide input into the priority list for the initial release?

We rely on our university community with their own specialized knowledge to help us identify critical functionality that we may not have identified yet, so it can be prioritized for the initial release. Both the advisory and governance committees for the project will be engaged for their review and feedback.

How can someone outside of the project teams and committees review and provide input for the priority list?

Additionally, for those not directly involved in the project teams or committees, there will be opportunities for review and feedback throughout the project, including listening sessions, which will be announced via existing project communications channels.

MOVING TO THE NEW SYSTEM

What if something critical is missed and not included in the initial release? Once realized, how will this be handled by the team?

The project teams execute ongoing risk assessment and management and gather input from a wide-range of subject matter experts throughout the project to attempt to mitigate the risk of missing critical functionality for the initial release. However, given its immense complexity, even with continued review, feedback and refinement throughout the project, we may still miss something critical for the initial release. Identifying and closing these functionality gaps is a key aspect of the stabilization phase of the project, and the full attention and effort of both our business and technical implementation team members will be on closing any gaps during stabilization.

Will we retain all the same functionality when we move to the new system?

The short answer is no. Because our current functionality is the result of many years of creating workarounds to support poor or missing functionality in ISIS, we are untangling functionality from processes. Some functionality may be approached differently in the future state. We will develop future state processes in conversations with stakeholders using the knowledge of our subject matter experts and aligned with our guiding principles. This future state process design will begin with the Process Design Workshops and continue in an iterative fashion throughout the build phase of the project.

How can we be sure the team truly understands what functionally may change and how that might impact my work?

We spent over a year inventorying and analyzing how current work is conducted with input from subject matter experts across the university. As we implement new systems, especially the new TSS, which will replace ISIS, we will rely on this baseline to help us understand and communicate changes. We will also continue to involve subject matter experts throughout the project and especially in advising our decisions.

STABILIZATION

What is stabilization?

Identifying and closing functionality gaps and addressing any bugs identified after go-live are key aspects of the stabilization phase of the project. The full attention and effort of both our business and technical implementation team members will be addressing gaps and bugs during stabilization.

What is the team focused on during the stabilization phase of the project?

The initial release of the new TSS will not be considered stabilized until we have closed all identified critical functionality gaps. Once the initial release has been stabilized, then the team will focus on the future releases.

Will the new TSS and ISIS run in parallel?

We will not turn off ISIS until we are certain that the new TSS is functioning as expected and we can maintain the ongoing operations of the university.

Will we be creating duplicate entries in ISIS and TSS post go-live of TSS?

While we plan to have ISIS and TSS running in parallel for some period of time, we do not expect that we will be creating transactions in both systems post-go-live of the new TSS. Should there be an urgent need to return to using ISIS after going live with TSS, we will have a clearly defined rollback plan to follow. Due to the disruption and manual work that would be required to return to using ISIS, the decision to rollback would only be made if absolutely necessary.

When will ISIS be shut off?

The decision to shut down ISIS entirely will follow a robust and structured process that will include key functional and technical stakeholders. Exactly when ISIS will be shut down and the framework that will be followed in doing so will be communicated to the wider university community via existing project communications channels as those details become available.

NON-CRITICAL FUNCTIONS

What features are excluded from the initial release?

Non-critical functions and processes will be deprioritized for the initial release and only included in the initial release if time and resources allow.

What is the plan for future inclusion of functions excluded from the initial release?

Following the stabilization of the initial release, there will be subsequent releases, which will include the functions not included in the initial release.

Will there be workarounds for functionality not included in the initial release?

The Design Team will provide thought partnership to units on addressing limitations and developing workarounds for those functions and processes not included in the initial release. The TSS Project advisory committee will also assist in addressing limitations and developing temporary workarounds.

Who will participate in the creation of workarounds?

It is not known at this time what workarounds may be needed for the initial release. As we know more, we will share that information with the university community via existing project communications channels.

OVERVIEW

Will there be updates to the system after the initial release?

Following the stabilization of the initial release, there will be subsequent releases, which will include the functions not included in the initial release. Input from functional subject matter experts from across the university will inform which non-critical functions are prioritized for which future release and in what order.

Who will determine what will be included in future releases?

The project will continue to be supported by functional, technical and organizational change management (OCM) teams for the future releases.

EXPECTATIONS AND CADENCE 

Will there really be future releases?

We know that, based on past experience, some of you may rightfully have doubts about when or perhaps even if future releases of the new Triton Student System will come to fruition. We know that in the past, especially with our homegrown systems, updates after an initial release have been inconsistent and sometimes even nonexistent.

How can we be sure that future releases will actually happen?

With the new system not being a custom-developed, homegrown system, we will be able to be much more agile and able to support releasing additional functionality much more quickly than if we had to develop it ourselves. Additionally, resourcing for future releases will be prioritized to ensure their execution.

How often will new functions be released?

The cadence of the future releases is still to be determined. ]

What will the cadence of the future releases be?

Once it has been determined, it will be documented in the service’s sustainment plan and shared with the university community.

FUTURE RELEASE INPUT

How will SME feedback influence future releases?

Input from functional subject matter experts from across the university will inform which non-critical functions are prioritized for which future release and in what order (known as the “roadmap” for the TSS).

Who will prioritize the features for future releases?

We expect that there will be an advisory committee or group supporting the prioritization of features for the TSS future releases. This may be the existing advisory committee or a different committee formed specifically for the post-project sustainment of the TSS; this decision has not yet been made. Exactly how SME and stakeholder feedback will be gathered and incorporated into future release planning, including what kind of approval processes will exist for the roadmap, will be determined prior to the closing of the project, documented in the service’s sustainment plan, and shared with the university community.

COMMUNICATIONS

How will we know when future releases will be happening and what will be included in them?

Communications channels that will be used post-project to share about future releases and their deployment have not been determined yet, but will be determined prior to the closing of the TSS Project, documented in the service’s sustainment plan, and shared with the university community.

PROJECT CLOSING

Will future updates/releases be part of the Triton Student System Project?

Following the hypercare and stabilization phases of a project, the project typically ends and new, smaller projects are created to manage future releases. We anticipate the TSS Project will follow this typical pattern; however, it has not yet been decided whether or not that will happen. Once those decisions have been made, they will be documented in the service’s sustainment plan and shared with the university community.

PROJECT TEAMS

What will happen to the current project teams post go-live of the TSS?

How the current teams and committees supporting the TSS Project will transition post-project is still to be determined, but will be determined prior to the closing of the project, documented in the service’s sustainment plan, and shared with the university community.

CONTINUITY PLANNING

OVERVIEW

What is Continuity Planning?

As part of the ESR Program, Continuity Planning is taking place for the Student Information System (SIS) Project to ensure a smooth transition for local business operations as UC San Diego replaces the legacy systems with new ones. This includes maintaining critical functionality and minimizing disruption as legacy systems are retired. Key activities include identifying impacted systems, clarifying business objectives, and determining a remediation strategy that balances long-term sustainability with practical constraints such as resource availability and limitations.

Who is involved in the Continuity Planning process?

The Continuity Planning team collaborates with business process owners and technical teams to evaluate solutions for remediation of their owned applications, integrations and reports to ensure the solution meets the needs of each process.

How is remediation part of Continuity Planning?

Ensuring that business processes supported by current applications, reports, and integrations continue to function after the Triton Student System (TSS) go-live is critical to the success of the TSS Project. This may involve migrating functionality into TSS or updating existing tools to align with it.

In what ways are reports part of remediation efforts?

We know that student data-related reports and applications are critical to campus operations, and maintaining their continuity during the transition from ISIS to TSS is a top priority. Remediation plans are designed by the technical owners of the application/report and the business owner/unit, with input from the Continuity Planning team, with the goal of balancing long-term viability, resource availability, and operational constraints. Through collaborative execution, the Continuity Planning team helps ensure that transition plans are implemented effectively to ensure timely remediation.

MASTER INVENTORY (AKA DATA USE INVENTORY)

Why is there a master inventory list and what is it?

As new processes and technologies are implemented through the SIS Project, some current systems and data sources will be retired, changing how the university community accesses student data. The Continuity Planning team is partnering with campus stakeholders to help ensure their existing tools and processes continue to function by connecting to the new data sources, such as the Student Analytics Hub (SAH). The first step is identifying the business processes within departments and units that rely on student data. To support this, there have been multiple calls for inventory, resulting in a master inventory list that captures existing business processes and applications that rely on student data sources and the Data Warehouse.

Continuity Planning Master Inventory (VPN or campus connection required)

Master Inventory submission form

What is my role with the master inventory and self-remediation?

Each unit/department is responsible for managing the remediation of its own reports and applications. If you haven’t already, we encourage all units to review the master inventory and submit any new requests as soon as possible. Detailed instructions regarding submitting reports to the master inventory are available on the Continuity Planning website.

Who should I contact with questions?

If you or your team needs more information or support with this, please contact your IT Lead. If you have questions about who your IT Lead is, contact esr-continuity@ucsd.edu.

Report Remediation One-Pager (Resources for Self-Remediation)

TIMELINE

What does the timeline look like for this work? How is this work in alignment with the TSS Project’s timeline?

Reports, applications, and integrations still in progress have been deemed as either critical or not critical for TSS go live. Those that are critical for TSS go-live will be completed in advance of the go-live of the new student information system, Triton Student System (TSS). By doing so, when TSS is launched, this ensures uninterrupted access to reports and applications before, during, and after the TSS implementation.

STUDENT ACTIVITY HUB (SAH)

OVERVIEW

What is the Student Activity Hub (SAH)?

The Student Activity Hub (SAH) is a central repository for multiple sources of student data, which allows for reporting and analysis of enrollment, demographics, major/minor changes, progression, retention, graduation, time to degree, and more.

What can the SAH do? How does it help us?

The SAH is a crucial tool for learning analytics, as it integrates data from various sources including our student information system, learning management system, and other tools. With the ability to analyze student engagement, performance and behaviors, the SAH can help identify patterns, trends and predictors of student success. Leveraging this information, analysts can develop interventions and strategies to support students throughout their learning journey.

REASON FOR CHANGE

Why is the current Data Warehouse being replaced by the Activity Hubs?

Activity Hubs are UC San Diego's modernized data warehouse environment, transforming the way the university collects and aggregates data to meet analytic and reporting needs. There are 5 primary data domains (Activity Hubs): Employee, Facilities, Financial, Research, and Student data. Each domain contains a carefully curated collection of data (a.k.a Curated Views), ensuring a single source of truth for optimized analysis and reporting.

The SAH is driven by the need to modernize the data infrastructure in preparation for the new student information system, the Triton Student System (TSS).

SAH DETAILS

What is the primary function of the Student Activity Hub? 

Like other projects that created the Finance Activity Hub, Employee Activity Hub, and Research Activity Hub, the Student Activity Hub will serve as the central repository for student data from which reports, applications, and integrations will rely on.

Will the switch from the Data Warehouse to the Activity Hubs provide real-time data?

Reports built on data from the Activity Hubs will continue to have an overnight data refresh (i.e., the data will not be real-time).

SAH SCALABILITY

Will all student data be added to the Student Activity Hub before TSS goes live? What about departmental databases?

Building a comprehensive data repository capable of meeting the university’s needs cannot be accomplished overnight. The development of the Data Warehouse spanned many years, and ongoing refinement and expansion of the Student Activity Hub will likely be required for the foreseeable future. While various departments currently maintain their own databases, the long-term goal is to eventually consolidate all data into the Activity Hubs to streamline university operations. This transition will understandably require time.

How will the Activity Hubs scale in the future?

The immediate focus is on integrating essential student data into the SAH to maintain current reporting and data needs, mirroring those of the Data Warehouse. Looking ahead, the Activity Hub will continue to be enhances beyond the TSS Project. The Activity Hub is designed to seamlessly accommodate the institution's growth, supporting larger datasets and more complex integration requirements while ensuring optimal performance.

SAH ACCESS & APPROVAL PROCESS

How can I get access to the Student Activity Hub?

We encourage individual departments/units to evaluate their business needs for a report developer. Complete the steps listed in the Student Activity Hub Blink page to submit an SAH Report Developer Access Request Form.

• Note that there are several required steps before receiving access to the SAH, one of which includes completing required FERPA & Privacy at UC San Diego trainings in UC Learning Center.

Who approves access to the Student Activity Hub?

All requests will be reviewed by the requestor’s manager and the SAH Data Steward (aka the University Registrar).

SAH USER TRAINING AND SUPPORT

What training and support exists for report developers with access to the Student Activity Hub?

Understanding the business, the information within the Student Activity Hub, and the skills to utilize this data are essential for informed decision-making. Members of the Student Analytics Community of Practice (SACoP) provide business insight to SAH users through the discussion of SAH data. Individuals with SAH access can utilize the following resources:

• Participate in monthly Student Analytics Community of Practice meetings
• Refer to the SAH Quick Start Guides  for insights into data, relationships, and perspectives.
• Review BI tool (Cognos & Tableau) training materials
• Engage in discussions via the Student Analytics Community of Practice Teams chat

SAH DATA ACCURACY

Why is the data I need not in the SAH?

There are several reasons why results might differ. The most common reason is the timing of the snapshots; the SAH collects data at midnight, while the DW gathers data for each table on various schedules (for example, a manual snapshot at 7 AM). This discrepancy will be resolved once everything is managed through the SAH.

Why are the results in the new Cognos report different than the results in the old QueryLink report? Why doesn’t the Student Activity Hub (SAH) match the Data Warehouse (DW)?

Another factor could be filters in the DW that the Report Developer was unaware of and therefore didn't include in the SAH report when remediating. The DW is quite complex on the backend, and a key objective of this project is to develop new reports with fully documented filters, calculations, and field names, which are currently lacking for the DW.

SAH DATA SECURITY

How will data be managed in the Student Activity Hub, ensuring we keep student data secure?The need to keep student data secure is paramount. That’s why the Student Activity Hub was created to be much more secure than our current Data Warehouse. In addition to using security best practices, access to data will be based only on legitimate business needs. Additionally, access to data will be divided into groups based on security. (See Data Buckets after Data Definitions section)

SAH DATA DEFINITIONS

What is the process for defining and classifying SAH data fields? How does the SAH Data Definitions process ensure data consistency and security across the University?

Building out the SAH and establishing comprehensive data definitions is an ongoing, collaborative effort. The data warehouse has evolved over many years, and the same will apply for the SAH. The data definition process is highly collaborative, involving subject matter experts (SMEs), and data analysts. Their goal is to ensure that field labels and definitions are accurate, clear, and useful for end users.

• Each SAH data field goes through the SAH Data Definitions Committee which includes Registrar SMEs, IR and School analysts.
• Once the field is labeled and defined it goes to the data steward—the University Registrar—to assign the protection classification level based on the UC Protection Level Classification Guide.
• Once the classification level is confirmed, the field name, definition, and protection classification level get loaded into the Metadata Tableau.

SAH DATA BUCKETS

How is the SAH data organized?

The Student Activity Hub (SAH) is divided into view groups (buckets) based on security. Each requires and goes through a review and approval process.

1. Core Data - available to all SAH Developers upon request & approval
2. Restricted Demographic Data - available to Institutional Research (IR) & Enrollment Management
3. Admissions Data - available to Institutional Research (IR) & Enrollment Management
4. Financial Aid & Scholarship Data - available to the Financial Aid and Scholarships Office
5. Graduate Financial Support Data - available to Graduate Department and GEPA Financial Support Unit
6. Accounts Receivable & Payments Data - availability to be determined (among those who work directly with accounts receivable and financial support payments)

Can a developer have access to multiple buckets?

Most report developers across campus will only need access to Core Data based on their reporting needs. However, if there is a true need for access to others based on your role, requests will be reviewed accordingly.

Is there more detailed information on the types of data for each group?

For more detailed information on the types of data included in each view group, please view the “Student Activity Hub” section in Report Remediation: General Overview (OCM Starter Deck).

• Report Remediation One-Pager (Resources for Self-Remediation)

QUESTIONS & RESOURCES

Who do I contact if I have questions?

Report a SAH issue or get help by contacting busintel@ucsd.edu.

What support resources are available

• There are many available resources and guides. Please note that some guides/resources are only available for those who have been approved for SAH access.
  • Student Analytics Community of Practice
  • Student Activity Hub
  • SAH Quick Start Guides
  • SAH FAQ
  • SAH Support for SIS Reporting

REPORT DEVELOPERS & REPORT CONSUMERS

OVERVIEW

What is the difference between a Report Developer and a Report Consumer?

Report Developers typically work within a business unit and dedicate some or most of their time to working with data and analytics tools like Cognos or Tableau. They have a deep understanding of data sources, including table structures, joins, and other technical elements needed to build and refine reports.

Report Consumers primarily view and run pre-built reports to analyze data but do not use analytics tools for report development. They know where to find reports, how to apply filters or prompts, and how to interpret the results—but they are not responsible for creating or modifying reports. 

What if I need more clarification to understand the difference with these roles?

Please view the detailed table on this Blink page for further clarity between these roles. 

ADVANCED CONSUMER OVERVIEW

What if I don’t fit into either the Report Developer or the Report Consumer role?

If any of the below apply to you, then you are considered an “Advanced Consumer”:

• Primarily consume reports but sometimes take the results from a QueryLink report and manipulate it in SQL
• Create a bunch of formulas and macros in Excel to get the report to do what you need it to do
• Spend more time organizing data than actually using it

If none of these apply to you and are you unsure about your role, please contact busintel@ucsd.edu.

What is the future role for Advanced Consumers? What should Advanced Consumers do to prepare for future state?

The Advanced Consumer role will not exist in the future state. Users who are currently Advanced Consumers will either be Report Developers or Report Consumers in the future state.

The best way to find out who currently has access to data is by working with your Departmental Security Administrator (DSA). Don’t know who your DSA is? Find out here: dsasearch. From there, determine if those folks should simply be Report Consumers, or if they should be Report Developers, and take the appropriate steps to request SAH access.

SELF-REMEDIATION SUPPORT

What if my department has reports that require self-remediation, but we do not have a dedicated Report Developer/data analyst to complete this?

We recommend one of the following options if your department does not have a dedicated Report Developer/data analyst:

• Train an existing staff member who will then work on remediating reports
• Hire a new position for your unit or to be shared with other units, who will then work on remediating reports (the Business Intelligence and Analytics (BIA) Team can provide interview questions and/or panel members)
• Hire a consultant to complete the initial remediation

What if my report requires blended data from other Activity Hubs?

In order to create reports with blended data across multiple Activity Hubs, you will need Report Developer access to those Activity Hubs. Access to the Activity Hubs is provided differently across each data domain, with the workflow for requesting and granting access defined by its respective data steward. In each case, the requestor fills out a form for manager and data steward approval. Once permission to access is granted, Report Developers use Cognos or Tableau to view and report on the data. Access forms can be found via the needed Data Source found here.

REPORT CONSUMERS

Who is considered to be a Report Consumer?

Report Consumers use tools like Cognos and Tableau to run pre-built reports, select prompts, and retrieve the information they need. However, unlike Report Developers, they do not design or build the reports themselves. While Report Consumers rely on these tools to access data, Report Developers are responsible for creating the report content, documentation and interactivity. This division allows Report Consumers to easily access insights without needing to understand the underlying report development process.

What support/resources are available for Report Consumers?

Generally speaking, Report Consumers can get training and support from the report owner/developer. Additionally, Cheryl Kettnich, Lead Analyst for Student Operational Reporting, will offer weekly office hours to provide ongoing support and guidance to report consumers once the remediated QueryLink reports enter the user acceptance testing (UAT) phase. More information can be found in the Student Operational Reporting.

What is changing for Report Consumers?

Below is a sample (not exhaustive) list of some of the changes impacting Report Consumers:

• Field names may appear to be different (now more precise)
  • Current: “Date” (type of date known based on the context of the report) →
  • Future: “Enrollment Date”
• New reporting tools (Cognos & Tableau)
  • Note: Cognos and Tableau are not new to UCSD, but may be new to those consuming reports
• Look and feel of running a remediated report will be different 
  • Ex: QueryLink reports will have a new interface since they are being recreated in Cognos
• Enterprise-wide reports will now be accessed via the Business Analytics Hub

Will BAH and SAH replace data collection tools and systems?

The Business Analytics Hub (BAH) and Student Activity Hub (SAH) will not replace data collection tools/systems or their in-system reporting capabilities. 

• Tools and systems that will be maintained post-TSS go-live will continue to utilize in-system reports (Example: ProSAM)

If the tool/database is going away with the implementation of TSS, then the data will need to be migrated to SAH with any reports recreated via Cognos or Tableau.

REPORT DEVELOPERS

Who is considered to be a Report Developer?

Report Developers are people with a strong understanding of the business processes and data flows who are looking to get more involved with the data, or people that have experience working with data and using analytics tools (like Cognos or Tableau). This allows them to gain a solid understanding of the various data sources, including their differences, table structures, and joins, which are essential for creating reports and analyzing data.

What resources are available for Report Developers to share best practices and get questions answered?

Developers who work with tools like Cognos, Tableau, and other reporting and analytics platforms are encouraged to join the Student Analytics Community of Practice (SACOP). This community serves as an excellent resource for asking questions and exploring real-world examples of student data at UC San Diego.

Student Activity Hub Report Developer access is required to attend the SACOP meeting due to the sensitivity of information shared in these meetings.

RESPONSIBILITIES

Will Report Developers have any new responsibilities in the future state?

Yes, Report Developers who create reports from the SAH will now be responsible for managing access to reports via folders and Active Directory (AD) groups, which may be unfamiliar to some developers. This is an important change as it guarantees that access is restricted to the relevant audience(s), safeguarding student data obtained through reports for those who require it.

• The Report Developer should work with their local ITS or Departmental Security Administrator (DSA) to ensure they have the appropriate AD groups set up, and the Report Developers will then provision access to reports accordingly.

How can Report Developers request new additions to the Student Activity Hub?

Report Developers will be able to liaise with the Lead Analyst for Student Operational Reporting to request new additions to the Student Activity Hub. Submit a SNOW ticket to BIA with your request.

What responsibilities will continue to belong to Report Developers?

Report Developer responsibilities include (but are not limited to) the following:

• Building reports using supported BI tools;
• Ensuring reports are accurate using source systems and/or reports found on the Business Analytics Hub (BAH);
• Requesting folders in BI tools to group reports for consumer audiences;
• Providing training to Report Consumers regarding how to use reports

ACCESS

How can our data analyst obtain Report Developer access to the Student Activity Hub?

We encourage individual departments/units to evaluate their business needs for a Report Developer. To obtain access to the SAH to be a Report Developer:

1. Take FERPA & Privacy at UC San Diego trainings in UC Learning Center
2. Submit request for access 
3. Requestor’s manager is notified for review/approval 
4. Data Steward reviews request for approval
5. Attend 90m onboarding with BIA Team

COGNOS & TABLEAU

Will Cognos/Tableau/any reporting system be able to pull identity information from My Personal Details? i.e. student demographic info

Yes. Demographic data is currently accessible in Cognos and will continue to be with TSS. However, many pieces of demographic data are categorized as P4 (in UCOP privacy parlance); access to that data on an individual student basis is tightly controlled and so not accessible to many users. Aggregate data is compiled in some reports by Institutional Research. The Data Stewards for student data review every piece of data that is loaded into the SAH to determine its privacy level. 

What is the future state of the New Reporting System (NRS)? (This is specifically about Students of Concern, Regent Scholars, Official IGETC vs Self reported already in Cognos)

While the NRS application itself is not being remediated and will be retired, the individual reports are being rebuilt in Cognos or Tableau as part of the transition. The designated report developer meets regularly with CDAA who guide prioritization of the reports to remediate, as well as identifying which reports should be consolidated and which may be retired. For questions about access to the new reports, please contact your college’s Dean of Academic Advising.

OVERVIEW

Why are we updating our current student information system?

There are many reasons why the university has decided to update our current student information system, known as ISIS. 

The top three reasons are:
(1) ISIS is outdated and no longer meets the university’s growing needs
(2) ISIS is inefficient, and its manual processes have inhibited the development of new features
(3) maintaining the system’s manual processes is costly and only a handful of people know how to do this work

What is the overall impact of the TSS Project?

By replacing the legacy system, ISIS, with the new Triton Student System (TSS), the project will modernize workflows, streamline processes, and enhance system integrations. The overall impact of the TSS Project is to reduce inefficiencies, improve user experience, and better support the university’s academic and administrative goals.

What changes will the TSS Project bring to the university?

The TSS Project is not just about technology replacement, but also about re-evaluating and improving existing processes to align with the new system. This is accomplished through detailed business process mapping, analysis and improvement, using the Lean Six Sigma methodology. This process-oriented approach seeks to optimize university operations for greater effectiveness.

How will these changes be managed?

We recognize that the TSS Project represents a significant change with the potential to disrupt existing processes and workflows. As such, the project includes a comprehensive organizational change management (OCM) strategy that involves tailored communication, managing concerns and expectations, and offering coaching and support.

IMPACT ON STAFF

What is the impact on staff?

The implementation of TSS represents a significant shift in how staff will carry out their roles. To support this transition, the project team is designing a comprehensive OCM and training strategy to address various staff needs and challenges. Staff will receive consistent updates on project progress, available resources and support mechanisms to keep everyone informed. Training initiatives will ensure staff are equipped to use TSS effectively and will be customized to meet specific needs.

What changes should departments expect in their workflows?

Though the changes are still being determined, the replacement of ISIS with TSS will affect departments that rely on student data. Business process mapping will lead to revisions in how tasks are performed in order to simplify workflows across departments. Staff will need to adapt to new interfaces and data structures, which may involve adjusting how student information is accessed and managed. Ongoing training will help staff adapt to new systems and procedures, with support resources available to ease the transition.

Who will guide these changes?

Communication from the project team will keep departments informed and allow them to provide feedback. The project’s change coalition will help guide staff through the transition, addressing concerns, building trust and increasing readiness for change. Mechanisms like surveys and feedback forms are used to gather input, enabling the team to respond to concerns and refine processes as needed.

IMPACT ON FACULTY

What is the impact on faculty?

As we actively work to understand the full impact of TSS, our goal is to ensure that faculty needs are thoroughly considered. While we don’t have all the details yet, we’re committed to sharing updates as soon as we have more concrete information.

How will faculty stay up-to-date on forthcoming changes?

Currently, faculty are informed via updates to Senate Leadership and represented by a faculty member on the governance committee. All university community members, including faculty, are encouraged to stay informed on project progress by subscribing to the project’s communications channels (see the “Get Involved” link to the right). As the project progresses and more is known about the specific impacts to faculty and the staff who support them, additional communications and engagements with faculty will be planned with the guidance of Senate Leadership.

IMPACT ON STUDENTS

What is the impact on students?

The new TSS will replace our current legacy student information system (known as ISIS) and many of the applications connected to ISIS, modernizing how students access their academic and financial information. Currently, students use MyTritonLink as their main tool for activities like registering for classes and viewing financial aid, and we expect that MyTritonLink will be replaced with a new tool provided by TSS. Other familiar tools, like the financial aid portal, are likely to stay the same. These updates aim to make things run more smoothly, though we’re still working out exactly what the student experience will look like.

Will TSS enhance the student experience?

Part of the broader goal of the TSS Project is to enhance the student experience and simplify processes. 

Will TSS disrupt the student experience?

While the transition to TSS may involve temporary adjustments or disruptions, the project team is committed to minimizing these impacts through extensive testing, feedback loops and communication.

• TSS Project Overview Presentation
• TSS Project One-Pager (General)
• TSS Project One-Pager (People Leaders)

The procurement process for the SIS Project is ongoing. Below are key milestones in the procurement process.

Request for Proposal and Conference Room Pilots

A Request for Proposal (RFP) was issued in Spring 2020, inviting vendors to bid to provide UC San Diego with their student information system solution. It contained questions designed to capture what we need to know to assess the capability of their software, contract terms and conditions, around 200 detailed questions, and Conference Room Pilot (CRP) scripts with detailed business scenarios.

Understanding and insight from business process landscape and mapping sessions were used to create these materials. For the SIS Project and other ESR projects, the ability of each vendor to execute crucial processes and meet the needs of our students is critical, as is total cost.

Vendors sent us their RFP responses, which were scored by the SIS Project and procurement teams. Next were the virtual CRP sessions, held November 2020 through January 2021, when finalists spent two weeks each showing exactly how their software would meet our needs. Subject matter experts (SMEs) from across the university participated and scored with the project team and technical experts on how well the software handled our real-life scenarios.

• Learn more about the Conference Room Pilot (CRP) sessions.
• Read a recap of the CRP sessions.

First Request for Proposal Closed without Award

After a rigorous and inclusive one-year process of proposal, review, consideration, and discussion, the initial RFP for a new student information system was closed without award.

• Read the full announcement regarding the closing of the RFP without an award.

RFP for Vendor Partner Released

On October 18, 2021, a second RFP was released, seeking a vendor to partner with UC San Diego to create a student information system able to meet the needs of the university at the time.

• Learn more about the release of the RFP for a vendor partner.

Second RFP Closed without Award

After more than six months of proposal, review, consideration and discussion, the RFP for a student information system development partnership has been closed without award.

• Read the announcement regarding the closing of the second RFP without award.
• See additional information about the closing of the second RFP.

Contract Awarded

After four years, three RFPs and much consideration and discussion, the contract for a new student information system has been awarded to invenioLSI, SAP’s North American distributor for their Student Lifecycle Management (SLcM) product.

• Read the announcement regarding the awarding of the contract for a new SIS.
• Review additional information about the system selection.