Secondary systems are department- or unit-owned software tools that support local operations and are managed — both functionally and technologically — outside UF’s main enterprise system, which is administered by UF Information Technology (UFIT).
In preparation for UF’s transition to Workday in July 2027, the Empowering UF team surveyed colleges and units to identify their secondary systems that support human resources, payroll and finance activities with the goal of reducing reliance on secondary systems and leveraging Workday as a unified platform. The team finished the initial discovery to review the secondary-system inventory and has met with colleges and units to understand each system’s purpose. If you have a secondary system that has yet to be reviewed, please email the project team (empowering@ufl.edu).
The Empowering UF Project Team hosts Secondary Systems Monthly Forums to share information about Workday in order to help colleges and units plan how to update their secondary systems so they continue to function alongside Workday after go-live in July 2027.
Forums are held at 2-3 p.m. on the last Wednesday of each month via Zoom.
Please scroll down for Secondary Systems Monthly Forums FAQs.
Q: How are topics selected for the Secondary Systems Monthly Forums?
Forum topics are shaped by project planning and participant needs. Project team members propose subjects based on key information they know units will need as Workday is implemented (such as the Foundation Data Model and customer accounts), and they also adjust and refine future topics based on questions submitted by participants and the data elements and processes managed in secondary systems. Participants are encouraged to send detailed questions and topic ideas to empowering@ufl.edu to help guide future sessions.
We can revisit past topics, such as FDM information. Meanwhile, please explore the Foundation Data Model page for an overview, worktag definitions, video and interactive current-to-future-state tool.
Q: Why are both functional and technical staff invited to the Secondary Systems Monthly Forums?
The forums are intentionally designed to include both functional business owners and technical staff who support unit systems. The combination of business process expertise and technical knowledge is important to ensure secondary systems are remediated effectively and that units understand how Workday operates in support of their processes.
Q: Who is responsible for remediating secondary systems, and what support is available?
System owners are responsible for remediating their own secondary (non‑enterprise) systems to align with Workday. The project team provides guidance and support through this forum, but the primary responsibility for driving remediation efforts rests with the owners of each system.
Q: How were “retire,” “keep,” and “decision pending” determinations for secondary systems made?
During discovery calls, the project team performed a fit‑gap analysis: they compared what Workday can do to what each secondary system currently does. Systems marked “retire” are those where Workday can fully meet the need. Systems marked “keep” support functions Workday will not cover (for example, certain inventory systems, because UF does not have the Workday inventory module). “Decision pending” systems are still under review while the team confirms Workday’s capabilities and shows units how those needs might be addressed.
Q: Is the current Department Transaction Financial Review (DTFR) reconciliation dashboard process expected to carry forward into Workday, and is it worth continuing to invest time in it now?
The future state of the DTFR reconciliation dashboard in Workday is not yet fully defined, but the Workday Foundation Data Model (FDM) is designed to improve transparency and comparability across units by enforcing consistent worktag definitions and usage. Reconciliations will still be required in Workday; however, there will be a stronger emphasis on getting transactions right the first time, so units spend less time validating allocations and funding sources and more time on higher‑level analysis (such as budget-to-actual performance and identifying unusual costs). Units are encouraged to continue using the DTFR for now.
Q: Is there an approved list of secondary systems?
During discovery, units identified secondary systems that could be replaced by Workday’s built‑in functionality. Example: A unit uses ABC Software to track inventory. Since Workday inventory is not being implemented with the Empowering UF project, that unit will need to continue using ABC Software. Another unit uses the same software to produce invoices. However, because Workday offers invoicing, that unit will choose to retire ABC Software in favor of handling invoices with the integrated/unified and enterprise-supported Workday system.
The central decision is whether Workday can replace a secondary system or if the system must be remediated and maintained alongside Workday. A system may be retained for a unit‑specific need in one case and retired in another.
Note: Visit the Foundation Data Model page for additional information, including an introductory video, current-to-future-state interactive tool, FDM worktag definitions, and more.
Q: During our discovery session with the project team about secondary systems, I was advised to use worktags for the items I needed to track. If our department has to request a new worktag through the governance process, what turnaround time should we expect when we’re mid-process and need the tag to proceed?
[As of February 2026] The governance structure for creating new worktags is still being finalized, so detailed procedures are not yet available. The plan is to have a streamlined online request process, where each request is reviewed to confirm that the proposed worktag aligns with the established definitions. If there are questions, the governance team will follow up with the requester; otherwise, the worktag will be created and communicated back. The goal is to achieve a fast turnaround time (often around 24 hours), particularly in the early months after go-live when request volume is typically high, but specific service levels for this project are still being determined.
Q: Can departments request the worktags they need in advance, for example during the mapping process, so they are already in place before we start using them in transactions?
Yes. During the ongoing FDM mapping process, units will be able to request needed worktags (for example, activities) in bulk through the project team so they are set up before go-live. After go-live, any additional needs—such as new activities you identify once you start working in Workday—will go through the governance request process. Workday relies on default and driver worktags and other behind-the-scenes configurations, so maintaining governance over new worktags is important to ensure the system remains well-structured and its tools function as intended.
Q: If we already have a robust internal reconciliation process, how will Workday and the FDM help with internal data review and management?
Workday’s FDM and stricter use of worktags are intended to make it easier to understand and analyze unit activity, even for units that already perform detailed reconciliations. While some local review steps — such as validating supporting documentation — will continue to be necessary, the goal in Workday is that transactions are coded correctly at the time of entry. This should reduce duplication of effort and shift reconciliations away from fixing coding errors toward using Workday reporting for higher‑level oversight and management of the unit’s data.
Q: Asset Management and Space Reporting all reflect the Dept ID. Will these systems eventually cross over to Workday as well?
Yes, STARS and myAssets will both have coordinated updates to tie out to the new FDM when Workday goes live. Dept ID is a complicated one. In general, the answer will be that secondary systems will be remediated to handle cost centers instead of department IDs, typically through a mapping/crosswalk exercise. There are some instances in which Dept ID will have to stay — the Lenel system, for example, uses Dept ID to identify the home department of the employee. In these cases, we’ll be using a ‘Dept ID’ worktag in Workday to assist with integrations. All systems will use cost centers as the financial home of operations — some will have a Dept ID tag to help the systems shake hands. Lots more to come on this.
Q: Where is the best place to find definitions for worktags?
Visit the Empowering UF website’s Education section for the Foundation Data Model page. Scroll down and see the FDM Worktag Definitions link.
Q: We operate off “project based” versus “Chartfield based.” When will mapping opportunities begin?
Mapping is already underway for mapping Dept IDs to Cost Centers. Mapping for other Chartfields to worktags will begin in March.
Q: Will there be a way to distinguish a capital project versus any other type of project?
Yes – there is an attribute on the Project set up that will designate whether it is a capital project.
Q: Your FDM dimension format examples have the first two characters, but I’m not sure if that is just the example. Example, for Fund = ‘FD123’ will the fund codes be five characters or three characters with the leading FD?
The fund code will be FD + three digits. The format for all worktags will begin with two characters, followed by digits, except for Ledger Account.
Q: Will areas be able to create their own worktags at the lower level?
Departments will be able to request creation of new worktags through the FDM Governance process.
Note: Visit the Empowering UF website About section for the Data Reporting & Enterprise Data Warehouse page.
Q: Where can we find information about the data access request process?
The data.ufl.edu site includes information on data governance, the data access request process, and the business flow for how that process is initiated.
Q: If we are not ready for review yet, is April the target for when data sets will become available for people to start viewing and reviewing them, assuming they have the appropriate data access in place?
Yes. The goal is to make data testing access available when end-to-end testing begins. By that point, documentation such as the data dictionary and related materials should be in place. Access will be controlled through a security layer, with some of that security configured via the data access request process, to ensure that users only see data consistent with approved sharing agreements and filters.
Q: Can we start reviewing the completed data models?
Not yet. The data models are planned to be made available for review when end‑to‑end testing begins (targeted around April), once the supporting documentation (such as the data dictionary) and security configurations are in place.
Q: Will we need to reinitiate our data access requests in Workday, or will access be granted automatically based on our current permissions?
That is still to be determined. The project team is working with the data trustees to decide how to handle existing access. The current plan is to start from the list of individuals who are already consuming specific data elements, confirm with the data trustees whether that access should continue, and then determine what additional access is needed going forward. For secondary systems that will remain in use, the data needs for those integrations will also be defined through updated data sharing agreements with the data trustees.
Q: Will there be test access to Workday data for remediating secondary systems?
Yes. For secondary systems undergoing parallel development or remediation, there will be a test location in UF OneLake (the enterprise data warehouse). The project team is developing data models, documentation, and a data dictionary for this environment, and the goal is to have the necessary documentation (Data Trustee approval) and security in place before sharing the contents of those models.
Q: We currently use Enterprise Analytics to run pre-built data requests or create our own, including reports that cross companies or departments. In the new model, will cross-company or cross-department reporting be limited? And will we still be able to access information about someone outside our own company?
The existing Enterprise Reporting access to PeopleSoft data will remain for a time as an archival solution, but going forward our reporting strategy will be “Workday First.” Many transaction-level needs now handled in Cognos will be addressed through Workday reports, which use row-level security, so you only see the data needed for your job or that has been approved. Where Workday reporting is not the best fit, UF OneLake will provide data models to support analytics in both Cognos and Power BI; the same filters and security (including company-based restrictions) will apply as consistently as possible across Workday, UF OneLake, Cognos, and Power BI. Legacy PeopleSoft HR and Finance data will ultimately be archived in UF OneLake once those systems are shut down, and UF OneLake will be the primary way to access those historical records.
Q: Will archived or legacy PeopleSoft HR and Finance data reside in UF OneLake, which serves as the enterprise data warehouse?
Yes, PeopleSoft data will reside in OneLake.
Q: How do the Secondary Systems Monthly Forums relate to the Data at UF meetings?
The Secondary Systems Monthly Forums focus on our business understanding of Workday — how it functions, how it affects unit operations and what you need to know to remediate your secondary systems and learn Workday in general.
The monthly Data at UF meetings cover deep technical content about data objects, OneLake tables, crosswalks and similar details. That team also provides updates on Empowering UF components and ongoing work with data trustees.
Q: Will the worksheet template be specific to each unit? Will we be able to have a drop‑down for all of our customers, or do we have to use a cheat‑sheet and plug it in?
The template is generic and generated by Workday for the EIB. The structure of the template should not be modified; columns should not be deleted, added, or rearranged. In Excel, users may add local data validation (such as drop-downs) for their own use, as long as the structure of the template is not changed. Users can also run delivered reports to view active customers and sales items and use the relevant reference IDs to populate the template.
Q: How can we see all fields, including hidden ones, in the upload template?
The team will provide the exact spreadsheet template created. It marks each column as Workday‑required, UF‑required, optional, or hidden, allowing you to review every field before uploading.
Q: What does the customer see on the invoice? What does the invoice look like?
The invoice is a PDF generated by Workday, showing itemized details for each billed service line.
Q: How will customers receive invoices, and what happens if an electronic invoice fails to deliver?
Invoices are generated in Workday and sent via email. Each delivery records success or failure in an audit trail that Workday logs. If an invoice fails, the system logs the specific customer and invoice ID so you can identify the cause and resend the PDF if needed.
Q: How should a unit handle sales‑item mapping and potential omissions (e.g., missing sales item on an invoice)?
Sales items can be configured at any desired level of granularity, but each must map to a specific revenue category. Units should discuss with the implementation team any ambiguities in the mapping process before finalizing the definitions. If a sales item is omitted accidentally on an invoice, the audit trail will reveal the missing line; you can then create or correct the sales item in Workday and resend the invoice.
Q: Where does the memo field go?
Based on the current configuration, the header memo is required. The line memo is optional by default, but it becomes required under certain scenarios. The spreadsheet template includes columns for both locations.
Q: Can we attach supporting documents to an invoice?
Yes. Workday allows you to link backup or supplemental documents to the invoice before it’s emailed, so you can attach detailed breakdowns or other supporting information.
Q: Where does the PO number come from?
It is a free‑text optional field on the invoice. If a customer requires a purchase‑order reference, they can enter it; otherwise, the field remains unused.
Q: What defines low, medium, and high invoicing volume?
Volumes are calibrated from the survey data we collected and our GL data. A single deposit in PeopleSoft can equate to many more invoices, so we used that as a baseline. Beyond that, the split into low, medium, and high is unit‑dependent; units decide internally whether they will use manual invoices or spreadsheet upload,
Q: Is there a discount capability?
Yes. Discounts are handled by creating separate sales items for each pricing tier, such as a non‑profit rate item and a corporate rate item. The discount is applied at the sales‑item level, so the invoice reflects the appropriate rate.
Q: Are ‘invoices’ meant for both external customers and internal UF customers (e.g., account transfers)?
No. External customer invoices and internal UF invoices (i.e., Internal Service Delivery transactions) are maintained in separate modules with distinct data objects.
Q: How are Workday values (customers, sales items) maintained? How will we request new customers or new sales items?
All customer and sales‑item records are centrally maintained. Requests are routed through Workday’s request‑framework to the core office that creates and updates those values.
Q: Who will load customers into Workday?
The project team will perform the initial load of customers. Once we go live in July 2027, that responsibility will shift to the core office.
Q: What data do we need to prepare, cleanse, and submit for the Workday customer‑account upload?
Prior to submitting customer, sales item, and catalog item data to the implementation team via the provided Excel template, units should consider the following “tips.” Units may also schedule time with the implementation team to address specific data mapping questions for these business objects:
Q: If a customer is managed by two different units, will they have separate customer records or share one?
Workday uses a shared customer database. A single customer can have multiple email or physical addresses, and multiple contacts linked to them, so you don’t create duplicate records unless the customer truly requires a distinct entity.
Q: Could you share the customer template in case we need to load all customers into Workday?
Yes. The team will provide the spreadsheet‑upload template that was demonstrated during the session, which contains all required columns, and it has Workday‑required versus UF‑required fields clearly marked.
If your unit is not included below but should be participating, please contact us at empowering@ufl.edu.
If you have questions or need further clarification on these secondary systems efforts, please email us at empowering@ufl.edu.