ESBD_510666_1778524132274_Addendum - Vendor Questions - RFP 739-SL3799217 Universal Slate Instance v5.11.2026.pdf

REQUEST FOR PROPOSALS

Universal Slate Instance

Addendum No. 1

RFP 739-SL3799217

Addendum No. 1

Universal Slate Instance

RESPONSE TO QUESTIONS

The following responses to participant questions are fully incorporated into RFP 739-SL3799217.

Question TTUHSC Response

1. What is the authoritative definition of clean data from Liaison CAS prior to ingestion?

“Clean data” is the data presented by the applicant that corresponds to a specific data definition that is embedded within the singular Slate instance. Presently, we have 5 different instances, so the migration from these systems to our Banner ERP includes version-specific data definitions that are not centralized, causing their integration into Banner to be different from the other instances.

For example, the definition of permanent address versus mailing address might not feature the same prioritization, causing some addresses in Banner to be listed one way or another. These variances exist across application records and manifest in critical areas (student types, decision codes, etc.) where variance in the interpretive meaning must be cleaned up by centralizing the data-gathering and the forced integration into Banner by standardizing the protocol for all.

2. Who has final authority for enterprise data standardization across schools?

Representatives of the Provost’s Office, namely the project lead (Vice Provost for Enrollment and Student Services) and the (vice provost) team responsible for institutional research and effectiveness will collaborate to define the final enterprise data.

These enterprise data elements are already being applied to the Liaison CAS application structure for the new UNI CAS process, so the data being delivered to the Slate system should already be standardized when Slate receives it.

There will be autonomy for the schools to determine some of their own data needs through a process of extending essay questions, resume requests, etc. that are unique to their application review processes. These are not going to be migrated to Banner universally (we’ll review the need to consider adding to an integration on a case-by-case basis).

There will be standardized codes for decision-making (i.e., using an admit response versus using a contingent admit response) such that all the colleges will be eligible to use only the choices that all share. This consistency will also manifest with the identification of whether a student is a FTFY, a TRN, a GRAD, a degree-seeker, or a non-degree-seeker, etc., which should provide great clarity for reporting and appropriate candidate communication needs.

3. Are all five Slate environments fully documented? No, and we would not use them for this project if they were. The goal is to create a unique system that operates as it needs to from a data infrastructure component. The schools will be adding their nuances to the existing infrastructure to incorporate communication protocols, itemization needs for completing applications, events and interactions – both from the school specifically but also from the institution (IT messages, FA messages, etc.).

4. What historical data must be migrated vs archived? The answer to this question is multi-faceted. The project scope is the call for the organic, single instance infrastructure that will be prepared to receive the Fall 2028 application cycles across all 6 different colleges, accounting for their geographical location alternatives along the way. There is not an inherent presumption of archiving older data sets (they will exist within the current states of the individual School instances). There will not be a migration of older data included for the 3rd party to build out formally.

There is a need to produce an integration tool that takes the data from Slate to Banner. We have 5 existing examples of data being integrated from Slate to Banner which can be used as a template to help establish this integration, but each of these versions don’t place the data into Banner in the same place or with the same field values. It will be important for the selected firm to recognize that we’ll need a new integration tool that satisfies the single-instance system they produce for us, but candidate firms should note that we need not build integration systems from scratch (unless it is preferred) provided we can accommodate how the single-instance is the source of truth for the integration and not what the previous integrations might suggest to be true.

The RFP project calls for am ongoing maintenance arrangement to be part of the proposal. Migration and standardization will be a part of the long-term plan to help “clean” the data that already exists between the existing school-instances and their Banner transitions. However, these will occur after the building of the single instance is completed. We see the migration protocol occurring during the period of July 2027 and beyond as the institution works to install a data lake and data warehouse (currently under construction). When the historic data is moved to the single instance of Slate, the plan is to use the existing mapping and the new data to ensure that the Banner data replicates these historic data elements in the right ERP structure locations with consistent data definitions to ensure reporting accuracy improvements on efficiency and results.

Therefore, we have time on this front. We’ll plan to use the transition to the school instances into the single instance for “historical comparisons and consistency” with the data reporting needs (recognizing that if we do not migrate old data to the new structure, reporting can continue to be a nemesis).

However, we’ll migrate as we establish controls over how to fill the data warehouse and data lake and not delay the processing of our single instance in any way. We have a February 2027 date tied to the infrastructure being complete, so we can get the schools into the system to deploy their own nuances. We do not want the schools to have edit rights to the infrastructure, so the selected firm will need to work with the schools to install their needs to their unique evaluation systems and communication (not infrastructure). We will work with the selected partner to manage their relationships with the schools to ensure proper controls are mitigated relative to access and influence to maintain the strict standards of the infrastructure being built.

5. Does TTUHSC use an enterprise integration platform? TTUHSC does not utilize an enterprise integration platform.

6. What are Banner data ingestion constraints? The Banner ingestion is managed by the System (TTUS) and controls what can be ingested into Banner. We have working knowledge of what is already ingested into Banner from the working instances, but changes will need to be navigated with the System. The ESS team will be your primary conduit for interactions with the System in these capacities.

Currently, we use Axiom to export data from Slate into Banner. TTUS manages this protocol as well.

7. What is projected growth for micro-credential programs?

This question is a little hard to answer as the micro-credential solution is new as a formal operation to be included. I believe that the potential is to produce 100-500 (maybe more, maybe fewer) applications for micro-credential candidates in a given calendar year.

There will also be somewhere between 25-100 non-degree candidates who are going to be identified annually as we tease out these non-degree candidates from our current, embedded processes. Presently, we have partnerships with other institutions, consortium agreements, and passive starters that we are processing within some of our other application protocols that are not possible to report on because their uniqueness is lost within the application capacities.

8. Will ESS have full authority over document intake? Yes. Documents will be coming directly to ESS, but these submissions can come through multiple channels. There will be documents that are submitted to TTUHSC through the Liaison relationships, through direct submissions into the school-specific queries (including potential portfolio content, resume submissions, manual transcript delivery for both college and high school records, electronic transcript receipts from services like Parchment, NACES providers, and even letters of recommendation). However, all should arrive within the boundaries of ESS for documenting receipt and standardizing data entry into the information contained on the document (GPA data, enrollment period data, degree-completion data, etc.) – some of which will be stored for the schools to use for their decisions and other data will be included in the migration to Banner.

9. What TX-RAMP level is required? At the time of contract award a minimum of Provisional Status must be obtained.

10. What is the preferred cutover approach? The cutover approach for the Universal Slate Instance is a layover timeline, coordinating with the deployment of the Universal CAS Application infrastructure going in before it. The Liaison product will formally go live

(anticipated) in July 2026. The timing of this RFP is designed to identify a partner to start in June/July 2026 with the anchor being this standard Liaison UniCAS product to use as the procedural anchor. Between July 2026-February 2027, the Universal Slate Instance will be built, but the individual schools will continue to operate from their own separate instances as they process Fall 2027 matriculation cohorts. Between Fall 2027 and July 2027, the schools will deploy their existing infrastructures into the finished Universal Slate Instance to prepare for go-live in July 2027, which will initiate with the processing for Fall 2028 matriculation cohorts. There will be a period where schools will work in their individual instances while they process Fall 2027 applications and a firm cutover where Fall 2028 applications will be processed entirely within the new single instance.

11. What is TTUHSC’s target total cost of ownership? This question is difficult to answer. The pricing of the development of the single instance is the primary driver for the institution. Given that the institution is operating with 5 different Slate instances and one outside product for the School of Medicine. The plan calls for a full deployment of a single instance of Slate in the first part of the year to allow the schools to integrate their own nuance into the built-out infrastructure. The schools will not be given the opportunity to modify the infrastructure and will have to work with the selected partner to install their systems. By July 2027, there must be a fully operational, stand-alone Slate system that will work to process Fall 2028 applications.

The annual maintenance cost structure is considered the secondary priority.

Firms may choose to budget that component out differently. However, the principle of the maintenance plan is not just to accommodate fixes to components that need to be updated. There is likely to be on-going process improvement development that will need to require that TTUHSC staff will need deployed within the single instance of Slate, and (since we’re not allowing internal audiences the opportunity to influence the infrastructure) these solutions will be tied to partnership with the selected firm. For example, building out scholarship distribution plans that connect with financial aid programming; special dashboard/reporting functions; student-driven communication deployment (working with schools that are needing to deploy communication channels who have not been doing so); unanticipated adjustment for School of Medicine (who has never operated in Slate and may need accommodations or adjustments to operate correctly); student-college communication channels that have never been available (FA, mental health, registration windows, missing material messages, etc.); federal/state compliance related to licensure and practicing in different states after graduation, etc. The intention is that the core system will need to be built out, but there will be individual, small projects that will need to be handled one-at-a-time to make the single instance operate to its optimal effectiveness for all the schools at TTUHSC.

The maintenance will be overseen by contacts within the ESS unit at TTUHSC under the authority of the Provost’s Office.

Intentionally, TTUHSC is not outlining expected costs to keep firms who choose to bid free to identify potential components that RFP-writers had overlooked, didn’t realize, or failed to include. This opportunity allows participating firms to recognize how TTUHSC can establish a best-in-class environment that advances efficiency at the school level, the administrative level, and even the student experience along the way.

The goal is to find a partner who wants to help set TTUHSC a single instance of Slate that is a true advantage of the institution’s operation.

Additional complexity prevails as the institution offers 6 different colleges in 6 different regional locations, stretching as far away as 5-6 hours by car.

12. Is the destination Slate instance an existing TTUHSC-owned environment, or will a brand-new instance be provisioned for this project? If new, what is the target availability date for build activities to begin?

A brand-new instance of Slate will be secured. We are already in discussions for a new Slate transitional environment that can be built absent any “live components” inhibiting any of the existing school-specific Slate environments.

This instance will be stood up during construction, but then it will become the single instance when ready – ideally by July 2027 to process the Fall 2028 candidate pools across the board.

13. Does the School of Medicine and central communications use Slate today or will they be new users and new use cases represented in the new unified org?

Neither SOM or Communication and Marketing presently use Slate within the confines of what we are projecting. SOM doesn’t use Slate at all, so ESS will be teaching them how with this single instance as the training tool. There will be representative SOM leadership involved in the entire way to ensure that unit knows what is coming, how, and why related to these changes and how they will be expected to use the tool. Communications and marketing are currently included within the school-specific Slate environments and has working knowledge of how to interact within these frameworks. However, they’ve not had to operate within a global environment, so their rules related to communication audience segmentation will need to be revisited based on the security/setup of the single instance. There will likely be much to learn from both units referenced in the new single instance, but we have team members on campus who can help teach/train them how to get more out of these tools.

14. Are TTUHSC’s five existing Slate environments utilizing current versions of Slate functionality where possible, or is there a patchwork of use? For example, Configurable Joins as the default query tool throughout (or only in some environments), use of the current version of Reader Workflows tool for all application review processes, etc.

There has not been an intentional effort to identify if all the teams are using Slate the same way, maximizing the tools that are available to all, etc. My answer comes from speculation, but I suspect that there is no reason to believe that everyone is operating in Slate to maximum capacity. Skill-wise, architect-wise, and complexity-wise, we appreciate that all the schools require completely different components and needs (some easy and straightforward and some not). We do not believe a selected partner should assume that all players have the same working experience.

That said, we will not be trying to build out a single instance to the level of the least-common denominator. Instead, our single instance will be built along the framework of a common set of firm data and the best practice for using these tools to accomplish what colleges want to accomplish. The schools will be invited to add their communication and flair to the interactions, but the structure of how the processes work will be standardized. We will produce completed records the same way, feed the reader the same way, offer decisions the same way, and force decision-reasons the same way. The schools will be able to ensure we add whatever they want, but they will not be encouraged to change the infrastructure to suit their needs.

There will be opportunities to speak with the different schools to learn more about their environments as the selected partner sees fit; however, it is the presumption that a selected partner has produced enough Slate environments for other institutions that it will appreciate what the best practice approach should be to accommodate our needs and establish a working protocol we can train others to use.

15. Does TTUHSC have a draft data dictionary or field-mapping inventory for the universal model, or is full discovery and definition expected within Phase 1 (Architecture)?

The short answer to this question is that “No, we don’t have a working, final data dictionary for field-mapping for the universal model.” It is our desire that this process will produce exactly this outcome in addition to the workable instance. The selected partner will have the ability to work with a pre-vetted volume of questions off the Liaison applications that will be finalized before work on a single instance begins. While not a process mapping tool directly, there will be a roster of a set number of questions (imagine: 150 universal questions) that will be on the application that will need to be accommodated into the infrastructure. We’ll use the best practice methodology our selected partners are familiar with related to the questions we know we need to have, and together a working draft dictionary should emerge in real time. That process should help inform data reporting and confidence for all parties, particularly knowing that the single instance will set the foundation for the rest instead of trying to accommodate existing architecture.

16. How many distinct degree programs across all colleges (including the School of Medicine) must be represented in the universal application status and decision framework?

The short answer is “all the others,” and it measures about 35.

17. Approximately how many active applicants and historical records exist across the five legacy instances combined, and is migration of historical applicant/decision data in scope or excluded?

The current estimate (without SOM and micro-credentials/non-degree) suggests there are about 11,500 applications that exist across all the existing school Slate partners. With the other tools added, we project the total would push 15,000 total applications, if not slightly above. We do NOT expect that total to grow substantially pas that 15,000, potentially peaking at 17,500 in our biggest years (if some of our smaller programs suddenly become popular).

As for the legacy information, there is not a process embedded “in-scope” to capture legacy information. The in-scope protocol is to capture an ongoing service estimate in which the potential to work with legacy data would be considered. Our goal is to organize the data, surely, but the scope of this project is to get a single instance built and to accommodate the application season for Fall 2028 in a way that incorporates all the schools in that one instance.

18. For elimination of "interpretation creep," can TTUHSC provide examples of data elements currently captured inconsistently across colleges (e.g., race/ethnicity coding, residency, prerequisite tracking) so the Contractor can scope normalization rules?

The goal is to keep the selected partner out of the business of correcting our inconsistent data output history in favor of locking down consistent data output going forward. We will use the strategy of the single instance and the potential for loading legacy data into the single instance after the formal go-live for Fall 2028 processing, but the primary scope is to keep the single-instance build at the forefront and let the institution deal with correcting inconsistent data later.

It is essential that we use this construction effort to establish the consistency we need, not to retroactively go clean data that was otherwise inconsistent.

Examples of inconsistent data were provided in the answers to other questions.

19. Which specific Liaison CAS products are in use today

(e.g., AMCAS, NursingCAS, PTCAS, OptomCAS, PharmCAS, the Universal CAS, WebAdMIT API)?

Please list each by program.

The existing CAS applications have already been deployed to individual versions of Slate. These CAS products will be retrofitted to produce the standard “150” questions that will derive from the new Universal CAS, and these edits to the existing CAS services will occur across the next year as the edit windows for the CAS applications ebb and flow in their existing cadence.

In the case of the Universal CAS app, we built it from the questions we get on the other CAS applications, so the questions on the existing CAS applications should already have a home in the transition to Slate and are represented in the Universal CAS infrastructure. The existing CAS products will need to be modified to include the questions that are NOT asked on the individual CAS applications to match the data output from the Universal CAS.

TTUHSC uses the following CAS products as of 5/2026” School of Pharmacy

PharmCAS

School of Health Professions

Master of Physician Assistant Studies (CASPA) Doctor of Occupational Therapy (Entry Level) (OTCAS) Doctor of Physical Therapy (PTCAS) Master of Science Speech-Language Pathology (CSDCAS) Doctor of Audiology (CSDCAS) Master of Athletic Training (ATCAS)

School of Population and Public Health

SOPHAS

SOPHAS Express

20. The RFP states that that “the Contractor will not be delivering an accessible Slate application for admission into any of the degree programs”. For the avoidance of any doubt, does this mean that TTUHSC plans to rely exclusively on CAS applications for the student-facing experience from app start through admissions decision?

Or, does TTUHSC expect CAS to be the “front-door” for students to apply but that post application submission those downstream functions will be handled in the universal Slate instance (e.g application review, decisioning, etc.)

TTUHSC will feature Liaison’s CAS application structure as a front door.

TTUHSC will rely on the Liaison CAS application structure for their degree-seeking application tools exclusively. These applications will be standardized and produce the “150” questions that are needed to resolve the data inconsistencies that exists downstream in Banner.

The Slate environment will still be necessary for the schools to produce secondary application requests (essay questions, resumes, other needs) that will not be included in the Liaison application infrastructure. The individualism of each of the schools will allow them to capture remaining needs within the Slate environment.

Slate will be used for decision-making, communication related to decision-making, and requests for missing materials to be submitted. The Slate portal will be used to communicate decisions to students as well.

We will create the security and privacy such that the schools cannot see the records of the candidates applying to the other programs for privacy purposes, but there will need to be centralized identification for biographical data to avoid duplicate records, communication and marketing messages, and the ability to have applications submitted to multiple schools from the same candidate.

21. Which version of Ellucian Banner is in production (8.x, 9.x), and is Banner Self-Service or Ellucian Experience the user-facing layer? Is Ethos Integration in production?

TTUHSC uses Banner 9.x using Banner Self-Service. There is Ethos integration, but it is important to identify that this is controlled by TTUS.

22. Is the existing Slate-to-Banner integration based on Ethos APIs, , flat-file SFTP, or a combination? A summary of current pipelines would help scope the replacement.

Slate to Banner integration is flat-file SFTP via Axiom.

23. Will the Contractor be granted access to a Banner test/sandbox environment, or will all data exchange testing run through TTUHSC IT staff via tickets?

Presently, and unless the strategy produces some challenges, we do not immediately see, the expectation is that our TTUHSC team will be the primary drivers of data exchange testing. Those who are most prominently involved with that process are already included in the process. Our expectation is for minimal TTUHSC IT involvement, but in this specific capacity – we anticipate the TTUHSC IT team to lead that stage of the testing of data exchange.

24. For automated registration of non-degree/CE students (Section 5.4 §3), is the preferred mechanism Banner SRARREG, an Ethos endpoint, Banner Workflow, or another method?

Ideally, a SRARREG protocol would be our preference, but if efficiency and best-practice suggest we should consider an alternative – we’re open to that discussion.

25. Is EdVisorly already contracted and deployed at TTUHSC, with an integration specification and partner contact in place? If not, is establishing that partnership and contract within Contractor scope?

Edvisorly was acquired within the last 90 days and is in the process of implementation. Presently, that integration is moving through the existing Slate protocol (meaning, there are 5 instances, so the Edvisorly relationship is with each school). However, we will bring the Edvisorly relationship back to ESS given that ESS will hold the record when it arrives, preparing the transfer credit evaluation in advance of the college review process. This transition will be complicated for the colleges since they are accustomed to the responsibility, but given the records being received at a different location in the new protocol, the EdVisorly relationship needs to be reimagined accordingly.

26. For transfer-credit equivalencies sourced from EdVisorly, are values displayed only inside Slate, or must they also post to Banner (e.g., SHATATR / SHATAEQ) and which system is the source of truth?

Given that we are building out a single instance of Slate that meets the expectation of best practice, the answer to this question is open to interpretation. We hold all the transfer credit rules with in the purview of the registrar and live within ESS. Should the best practice be to include transfer credit tables within Slate and to build an integration such that whatever gets added to the Banner tables is integrated back to Slate for the next candidate – we are open to that exchange as a viable alternative to establishing a single instance with the best value. Presently, we had planned to calculate these equivalencies manually, but understanding the upside of an automated opportunity – we’re prepared to listen to that innovation.

27. For D2L Brightspace assignment triggers, which integration method does TTUHSC prefer — Valence API, IPSIS provisioning, LTI 1.3 deep-linking, or a hybrid?

Brightspace recommends using LTI 1.3 for integration.

28. What is the required latency from Slate non-degree enrollment → Banner registration → D2L assignment availability (real-time, hourly, nightly)?

It would be our preference that the transition from Slate to Banner would occur overnight in some way. We recognize that the transition from Banner to D2L might take another overnight process. It’s entirely possible that these students begin throughout the year (not necessarily at the hard start of a term), so the potential of the 2-day window isn’t strong enough to leverage a faster transition currently. Should we feel we need to accelerate the frequency of data transmission, we can revisit later.

29. Will TTUHSC provide an existing PayPal merchant account, or is a new PayPal Business/Education account being established for the universal instance, and which PayPal product (Hosted Checkout, Payflow, Braintree) is in use?

We are in the process of establishing a PayPal merchant account as of this writing, and we expect that protocol to be resolved prior to the construction cycle of single instance of Slate regardless of which selected partner is chosen.

A new PayPal Business/Education account is being established for the universal instance. It is our understanding that it will be a hosted checkout.

30. Should application fees and enrollment deposits post to Banner Accounts Receivable (TBRACCD) automatically, or remain reconciled within PayPal/Slate only with manual GL posting? Is PCI DSS scope reduction via hosted checkout a requirement?

The accounts will be posted to TTUHSC automatically. It is our hope that these transitions happen on a regular basis (maybe nightly?). State policy prohibits an off-site account that accumulates revenue on the institution’s behalf.

We are unclear as to whether the PCI DSS scope reduction via hosted checkout is a requirement or not. We believe the answer is knowable on campus, but we are not in a position where we know the answer at this moment.

If PayPal integration capabilities are available, automatic posting to Banner would be strongly preferred. Additionally, a hosted checkout solution is required to reduce PCI DSS scope.

31. What is the anticipated initial catalog size and annual enrollment volume for the micro-credential / continuing-education pathway?

Presently, there are about 35 badges within our system. It’s possible that the number could grow to ~45 at the time of the initial catalog creation. We haven’t awarded more than 750 or so badges annually, so a healthy estimate might be to consider results at 1,000/year is where our expectations are.

32. Should the in-system "credential resolution" tool issue verifiable digital credentials (Open Badges, Credly, Parchment), or is a Slate-internal certificate of completion sufficient at launch?

We issue verifiable digital credentials through Accredible. Accredible is linked through the D2L solution, so we anticipate our badges will continue to be issued through our LMS system directly.

33. Section 5.4 §3 calls for "course selection" within the native Slate non-degree application but does not specify whether this is a single-offering enrollment form or a multi-course marketplace experience (catalog browsing, shopping cart, single-checkout, automated content access). Please confirm which model is in scope, and confirm whether PayPal is intended to process course tuition for these offerings or only application fees / enrollment deposits as currently stated.

For the time being, we’ll consider the micro-credentialing to be a single-offering enrollment form (one application for one course). If a student wanted to take another course, they would apply again in a new term (or another time, depending on when they finished the first one). We’ll need to be able to add/edit the course offerings and be able to transition the new offerings to the sections of the application that address the courses in question.

There will be a need to the ability to accept an application fee (presently only $10) with this micro-credentialing application. There will not be an application fee for the non-degree applications that are looking to take a general course from our regular curriculum.

34. What is the expected daily/peak volume of inbound documents (transcripts, recommendations, test scores) into ESS, and which intake channels must be supported

The daily volume of inbound documents is expected to encompass application volumes between dozens to hundreds – depending on the proximity of program deadlines. We anticipate the greatest amount of application volume to enter TTUHSC through the Liaison application protocols. These protocols will

(Parchment, National Student Clearinghouse, mailed paper, emailed PDF, applicant upload)?

include the applications and additional, conditional documents that were included in support of the application as appropriate - all contained in that transition process like how it is done now with Liaison’s national CAS applications to which we already subscribe. Presently, these are distributed to the different schools, but they will all be centralized in ESS with this new single instance.

There will be a need secure documents (transcripts) from Parchment, National Student Clearinghouse, applicant upload documents, WES/ECE foreign verification document submissions, as well as emailed PDF documents and traditional paper submissions.

It is our hope that any internal document automation will be included as is available to allow for rapid transcript collection, automated document identification, and application checklist closure with transitions right from the partner company directly into the Slate environment.

35. Should reader assignments and bins be configured per college, per program, per committee role, or all of the above, and approximately how many reviewer profiles / committees are anticipated at launch?

The reader assignments will be configured per school and to their specifications. There will be variety of processes to identify, though we’ll try to standardize the readers into common protocols wherever possible. Because there will be enhanced security at the organizational level of the single instance of Slate, the reader will have to maintain school-specific access and limit shared data points that can be seen across the candidate pools.

It is hard to project how many review teams will be necessary, but we’ll be meeting with the different school representatives to learn their methods, their preferences, and expectations. In almost all cases, there is a working experience they have built into their existing systems, but it is unclear if there will be a desire for increase efficiency and strategy now that the opportunity to reconsider a process is available. There is at least one school (Medicine) which operates outside of Slate, and the number of reviewer committees that school uses is currently unavailable.

There may need to be some best practice discussions with school partners to consider processes that may not have been previously imagined with their initial infrastructure that is available to the teams in this single instance. Plus, solutions made available for one school might be seen as an attractive model to be used by another/other schools for their infrastructures.

36. Please describe any differences in reader workflows and requirements across your existing Slate database(s), including program- or school-specific variations.

There is such a wide variety of schools using Slate, we don’t have centralized answers to this inquiry. In fact, we’re recognizing that with somewhere near 45 different degree programs and paths, we are preparing for substantial process improvement opportunities in this space, specifically when it comes to workflow documentation movement, final decision-making, and a new process that is being initiated – the confirmation of a decision by citing a decision-reason that will be a required field in Slate for each candidate (whether admitted or denied). We will want a partner with best practice recommendations who can help our colleges maximize the time, speed, and access they need to be as efficient as possible.

37. Should the new centralized Slate database accommodate these program- or school-specific reader workflows, or is a standardized approach preferred?

Each school will be using a Reader on their own, but each Reader will likely feature different attributes, committee sizes, and review requirements. We aspire to take advantage of best-practice references wherever possible related to Slate workflows (including the use of the Reader by every school), but there is no intention of a standardized review approach in a way that forces the schools to follow a uniform protocol.

38. Is OCR/digitization of paper documents performed by the Contractor's workflow inside Slate, or by an upstream TTUHSC scanning service that delivers searchable PDFs?

Presently, the plan for paper documents is largely manual. The principles of trying to secure data entry automation with paper documents are not in scope.

The one exception is transferring postsecondary credits. Because TTUHSC is already partnering with EdVisorly, the plan will be to utilize their transfer credit efficiency tools to maximize efficiency around transfer credit articulation. Keeping that data collected from EdVisorly in Slate and pushing to Banner with the integration is part of the global efficiency gain from a single instance of Slate. Depending on complexity, if this solution takes a little longer to develop than is possible within the short time frame of the planned completion of the single instance, we may need to defer the EdVisorly solution until later in the sequencing, but the only document OCR plans now are embedded with the EdVisorly relationship.

39. For the permission-based architecture that silos college data while sharing biographical/demographic core data, can TTUHSC describe the current role inventory or expected number of role profiles so the Contractor can scope Slate user/permission configuration?

Unfortunately, the role inventory is likely not an option to state in this answer.

We’ll plan to navigate the needs/expectations of these roles with the selected vendor during the discovery phase. It is our hope that the proposals might express some recommendations for how to stack role inventories based on experience from prior deployments, but our position is to ask our selected partner to assist TTUHSC in building out an environment with maximum security separations with easy-to-manage role divisions within each of the separations. Our goal is to prevent lateral access creep while maximizing access within each vertical for those who “need to know” within each school. There is an appetite to come to a solution quickly, and we are hoping for a best practice solution for how to establish, maintain, and measure the effectiveness of a secure environment that provides the necessary access to those who need it.

There are some certainties that people may wish to understand on the front end.

First, the ESS team will need to have access to the student records for all the schools since the applications, documents, and record-keeping will occur with the ESS team across the board. The ESS team will author global communication for processing efficiency, financial aid, military information, disability information, etc. The schools’ teams (their admissions teams) will need to access the students and application data for those who express interest in their individual verticals. The schools’ teams will send communications, record interactions and respond to inquiries. It is vital that they see the communication timelines for all their candidates. The communication and marketing team need to be able to see prospect records, including communications and queries. The Communication and Marketing people will not need to see candidate records within the colleges, but they will write communications that will address candidates from every school, department, and program. The IT teams will need to send technology instructions to students at various times in the application cycle – particularly with instructions for the establishment of student accounts and other standard protocols. These messages can be issued through the ESS and/or Communication and Marketing teams, but access to students would also stretch across all the disciplines. The reviewing admissions teams may only need to see the readers for their respective areas (depending on who the reviewers are for each program).

I do want to point out the critical need for established naming convention rules where appropriate and the expectation that many of the areas in Slate where the entire volume of users contribute to the same space will become cluttered quickly. Letting the schools and departments establish a protocol will occur too late to be effective, so we’ll need to build the system with a planned expectation for a naming convention to structure the environment from the very start.

One other area of concern is the building of queries and reporting access for the schools. The selected partner needs to build security in such a way that considers what the schools may need to do internally to effectively manage their environment. That effectiveness has a strong potential to include the ability to run their own (or many of their own) queries – again, naming conventions will be important. It would be best if queries and reports could be separated by the same security divisions as everything else, but that separation may not be possible. Whatever the solution there, we’ll need to build the environment preparing for those eventualities.

40. Are SSO and MFA requirements limited to the existing TTUHSC IdP (eRaider / Microsoft Entra ID via SAML or OIDC), or will external committee reviewers and CE learners require a separate credentialing model (Slate Reader accounts, Microsoft B2B, etc.)?

The expectation going in is that all participants using Slate will fall into the expectation of having secure TTUHSC credentials and that the principles of single-sign-on will be in play. That reality already exists with other software managed by the institution, so the expectation is that SSO and MFA relationships will be installed on the Slate experience as well at all levels of access.

41. Is a parallel-run period expected between legacy instances and the universal instance, or a hard cutover at each go-live milestone? If parallel, for how long and which environment is system of record during overlap?

There is a parallel period expected during the building of a new instance to keep current and future states of the Slate experience separate. The goal will be a full cutoff for the application season for the Fall 2028 matriculation season.

At that point, all application behavior will transition to the new, single instance of Slate as of July 1, 2027.

During the time between now and then, as the new, single instance of Slate is being configured, schools will continue to build out their Fall 2027 enrollment protocols following their existing paths of procedure within their own Slate environments.

There will be overlap in that the schools will need to manage the transition of their unique protocols, communication, and workflows into the new system while those solutions operate effectively in their current state. To manage the transition of those existing features into the new, single instance, the schools will be expected to collaborate with the selected partner to understand what modifications are possible and which are not. Some of the schools’ current expectations may stem from an infrastructure environment that exists only in their instance. So, new processes may need to be developed since infrastructure changes in the new, single instance will not be possible unless these changes are manifested across all schools and candidates within the single instance.

School personnel will not have security access to build/modify existing infrastructure to satisfy their own preferences.

The long-term plan for the schools’ current instances of Slate will be to transition to the new system for the Fall 2028 enrollment cohorts (staring in July 2027). However, while the new application procedures are live in the single instance of Slate, TTUHSC will be considering the transfer of older data from the individual instances into the single instance “behind the live data” to allow for proper comparison data and long-term planning. After a decision has been made on the older Slate data for prior academic cycles, the individual Slate systems will be eliminated permanently. By July 2028 on the calendar, the expectation is that only the single instance of Slate will remain.

42. The published timeline targets Universal Instance go-live in February 2027 with Liaison (March 2027) and Banner (April 2027) integrations following. Can the universal instance accept and process applications prior to Banner integration completion, or must Banner cutover precede applicant-facing launch?

The plan is for the universal instance to be built by February 2027, but the construction will continue between February 2027 and June 30, 2027, to incorporate the school-specific environment needs within the single instance.

The identification of a February 2027 completion date is to give the construction protocol over the schools to have time to deploy their respective nuances prior to opening the instance to applicant records.

There is no plan, nor priority, to accept applications and process prior to that July 2027 date (except in testing capacities) because there is not an appetite for simultaneous processing environments. There is no anticipation to work in multiple Slate instances and feed both into the same Banner instance. We will protect the integrity of Banner data by only feeding it with data from the “live source” at every turn.

43. Under "Perpetual Maintenance," what monthly cadence of macro-level changes does TTUHSC anticipate (Slate releases, regulatory updates, new program launches), and is the Contractor expected to provide tier-1 end-user support, or only tier-2/3 administrative and configuration support?

The simple answer is that we do not know the answer to that currently. We anticipate that some of what we had hoped would be live at the time we cutover will not be live as expected. Or examples of the changes and updates listed in the question will of course happen. Similarly, TTUHSC is pursuing a major upgrade to data lake, data warehouse, and long-term storage solutions that will need to be fed from the Slate instance over the next two years. We anticipate the Slate data will live at least within the data lake environment when its built.

Because the schools will be operating within a “new” environment from their previous expectation, we anticipate there will be “edits/updates” that college-specific teams will request once the produce formally launches. There will need to be flexibility and structure to maintain a serviceable expectation of support.

We understand the need to be responsible for planning and prioritizing such that every need will not be honored as a priority, but we also recognize that (depending on the need) there could be an importance for fixes to deployed post haste. Our goal is to not to extend developer security to the representatives of the schools because of the perpetual maintenance relationship with the selected partner. Our expectation is that the partner sees themselves as the primary developer of the system and establish a cadence and protocol consistent with that expectation.

44. What service-level expectations (response/restoration targets, hours of coverage, on-call posture) should the Contractor reflect in the maintenance pricing line, and are integration breakages (Liaison/Banner/EdVisorly/D2L/PayPal) covered under the same SLA?

The goal for perpetual maintenance is to seek an annualized estimate for service to allow the institution to properly budget and maintain the relationship accordingly. We recognize the value of quantifying the support to accommodate the billing thresholds most effectively, but the realistic deployment of operational work will likely ebb and flow such that there will likely be no way to predict standard components for a full year. The chances that there will be an emergency that warrants “on-call” services 24/7 are not likely since Banner is the institution’s system of record and Liaison is the institution’s application tool – neither of which would be hampered by a problem with Slate as each would hold their data effectively while we wait for a fix within the Slate environment. However, within the business day, there may be a need to secure timely responses depending on the severity of the problems.

The expectation is that the go-live period will produce an effective, fully functioning tool. The only prediction is that the system will likely transition to other effective solutions that can be built up over time, making the Slate system more effective to the institution with each passing month/year, etc. For example, the institution may choose to add student success initiatives in the future or develop graduation applications within Slate. We may choose to deploy student survey tools in the future, or we might want to add an outside 3rd party option into the Slate environment to maximize student outcomes.

These solutions would be the kinds of solutions we would expect to get resolved through the ongoing maintenance agreement. Of course, there may be trouble, and we’d need to address those. But, the bigger expectation is to look forward for ways in which we could improve the environment and get more success out of the environment than we’ve been able to secure before now.

As it relates to the integration breakages, the plan would be for the first line of defense with these breakages to live with our on-campus teams (IT, for example). However, because of their limited exposure to these tools, it may be necessary to secure resources from the selected partner to help eliminate these challenges. Sometimes these efforts may be consultative and other times more direct intervention needs.