Communication is key

While much of the information needed for implementation is found in the proposals, additional clarification may be needed. If so, communication via email is the preferred method for documentation purposes.

Timeliness is important.

Foundational aspects of the academic structure can impact reporting and should be done promptly to ensure accurate data is provided. For example (not exhaustive), department/academic organization changes impact faculty assignments; subject changes impact CDR reporting.

Accuracy is paramount.

• The Student Information System (SIS) data feeds various data-driven systems and must be accurate at all times. Inaccuracy has serious downstream impacts. For example (not exhaustive), dates relate to application availability and declarations can have serious implications on students; tuition data (CAF values) determines how the Madison Budget Office builds tuition tables; CIP codes impact National Student Clearinghouse reporting; STEM OPT relates to international student visas.
• As the office responsible for maintaining the academic structure, the RO should review all assigned SIS values that impact the academic structure for accuracy. If something seems amiss, staff should coordinate with DAPIR to resolve any discrepancies.

Respect each other’s process when in workflow.

• Proposals are revised many times throughout the process. Ideally, all aspects of a proposal are finalized by each approving body before advancing through workflow.
• Once a proposal advances from the last DAPIR step of workflow, DAPIR will not edit a proposal without prior consultation with the RO. Similarly, if departments or school/college partners reach out to the RO to update any aspect of the proposal once it is in an RO step of workflow, the RO will alert DAPIR and determine the appropriate course of action (be it adjusting the proposal or rolling back to DAPIR).
• Any proposal approved beyond an DAPIR step of workflow may not be rolled back to a school/college or department without authorization from DAPIR. All proposals needing to be rolled back at this stage can only be rolled back to DAPIR Admin.

Administrative saves are not allowed.

If there are changes that need to be done administratively, the ‘administrative’ type of approval should be selected at the top of a form and then submitted to workflow. The workflow is: DAPIR -> RO. This ensures that there is accurate information in all required fields, which in turn makes the data visualizations work as intended.

• Add/remove workflow steps based on governance requirements.
  1. Remove University Academic Planning Council (UAPC) on undergraduate programs when a proposal does not need go to UAPC (typically a change less than 50%). Still enter approvals.
  2. Add steps for: UW System, Board of Regents of the University of Wisconsin System, Higher Learning Commission (HLC), and DAPIR-Hold, as appropriate/necessary. Anyone with questions regarding the status of a program in these steps can contact: Allison La Tarte, Karen Mittelstadt, Melissa Schultz, Abbie Windsor, or Michelle Young. Proposals requiring these steps will not advance in workflow until approval has been received.
     • DAPIR-UW System
       • Anything requiring notification or approval from the UW System Academic Planning Administrators.
     • DAPIR-Board of Regents
       • Anything that requires Board of Regent meeting approval (held throughout the state during the year). Things may sit in this queue for months, pending a Regents meeting or action.
     • DAPIR-HLC
       • Anything that requires Higher Learning Commission (HLC) approval (usually an institutional change). Things may sit in this queue for months, again pending HLC action.
     • DAPIR-Hold
       • Items in the DAPIR-Hold generally are not necessarily being held up by governance approving bodies, rather they are more administrative holds. Typical ‘administrative holds’ would be proposal holds due to tardiness on program review, action required at a later point in time, or proposals missing an accompanying parent/child proposal.
  3. Lumen Structures proposals have a shorter default workflow because of the wide variability in types of proposals, which does not initially include the Registrar’s Office. Based on the proposal, DAPIR will assign the appropriate steps once arrives at the DAPIR Admin queue. Items that will come through that require RO action include (but not limited to): subjects, departments, graduate additional major, graduate/professional career certificate codes, Guide school/college shared content.
     • If an item requires UAPC approval, Karen Mittelstadt (DAPIR Academic Planner) will add the various governance bodies needed.
• Assign SIS codes and CAF values through Lumen Programs, determined by the answer to related questions.
  1. Generally, the data needed to be entered in SIS is in fields that begin with “caf_[…]”, “sis_[…]”, “parent_caf[…]”, or “parent_sis[…]”.
• For programs that have previously been discontinued through governance, Initiate the proposal to remove pages from Guide/SIS. These are ‘deactivation’ proposals and include information about the approval related to discontinuation. SIS codes should be inactivated at this time. Melissa run’s this process to identify the programs that need to have their deactivation proposal submitted to the RO on an annual basis. All discontinuations will be effective fall and the process will only need to be run annually in the summer.
• Create/update the Guide URL in the administrative section of the Lumen Program form. This is the URL that should be used for the Guide page.
  1. See KB for more info: https://kb.wisc.edu/lumen/88357
• Review Guide integration points.
  1. Red boxes
     • If a proposal has red boxes around courses (subject + catalog number), the proposal will get rolled back to the school/college step before heading to UAPC (if applicable). All red boxes must be resolved before advancing to the next step of workflow.
     • If a proposal has new courses that are not yet approved (currently not indicated in Lumen) and not approved through the school/college (determined by the data), the proposal will be rolled back to the school/college until the course(s) have been approved.
     • If red boxes appear after the DAPIR steps of workflow, the school/college must work with DAPIR/RO to update the curriculum. If there are substantial curricular changes required due to red-box courses that were not planned for, a proposal may need to be rolled back and is subject to additional governance as a consequence. DAPIR will determine whether a proposal needs to be rolled back to an earlier step in workflow based on the changes required to correct the red-boxed courses.
  2. Named option set-up
     • The named option tiles do not show up until the URLs have been created in Guide. The parent proposal will need to be refreshed (edit the program while in the RO step, save) to display the subplan list.
     • The set-up of the mapping can be inserted based on the structure of the requirements. At the graduate level, named options tile lists are in the same spot. At the undergraduate level, there is more interpretation based on how the named option fits into the major requirements.
  3. General review of formatting
  4. Ensure curriculum meets policy
     • If a proposal violates policy, the proposal is rolled back to the school/college approver step with a request to update the content. Examples (but not limited to): indicating some credit by exam does not count for the course equivalent; credits on certificates totals more than the acceptable number; ensure that the curriculum stays tight on 131 programs.
     • The Graduate School reviews proposals under its purview to ensure they meets policy.
     • DAPIR does not review curriculum for accuracy or have jurisdiction over the content of curriculum. Curriculum is owned by the faculty and may follow individual school/college guidelines.
  5. Add certificate eligibility shared content and header on undergraduate certificates based on the question of who can earn the certificate.
  6. Look for a comment from the DARS encoder. If there is a comment indicating that there are questions or further clarification is needed, the proposal will be rolled back to the school/college step in workflow with a request to revise the curriculum so it can be coded in DARS.
• Graduate proposal review
  1. Once a graduate program is advanced into the DAPIR Approver stage, it can fall into two categories: 1. Program less than 50% changes and do not need UAPC review; 2. Program greater than 50% changes and may need UAPC review.
     • 1) When a program has less than 50%, DAPIR (Melissa Schultz) reviews the program form to ensure that the ‘less than 50%’ question has not been changed (this can be subjective – sometimes people have it one way and change, but they haven’t made any changes to things that would have been unavailable had they selected the correct radio button). If the proposed changes are minimal in nature and follow the ‘less than 50%’ change, the proposal is approved and advanced to the GFEC Approver step of workflow. Once the Graduate School reviews, approves, and enters an approval statement, the proposal advances to the UAPC step of workflow. DAPIR adds an approval comment that DAPIR is administratively approving the proposal on behalf of UAPC and without formal UAPC action, sending the proposal to the Registrar’s workflow step.
     • 2) If a program is greater than a 50% change, it will require additional review. Typically, new programs are reviewed by Karen Mittelstadt in DAPIR. Once ready to advance, Karen will advance to the GFEC step. Once the Graduate School reviews, approves, and enters an approval statement, the proposal advances to the UAPC step of workflow. Karen enters an approval indicating DAPIR is administratively approving the proposal on behalf of UAPC and without formal UAPC action, or a statement indicating the proposal was reviewed/approved by UAPC and the meeting date where this happened. Melissa reviews the proposal’s integration points and academic structure-related fields at that time.
       • If a proposal requires additional approval beyond UAPC (e.g., Board of Regents), Karen will approve the proposal into the next step of workflow. Once the additional approval notifications are received from the approving bodies (generally sent to Allison), Allison forwards to the academic planners (Karen, Michelle, Melissa) and Melissa attaches the documentation and approves out of the current workflow step (repeat as necessary).
       • If a proposal does not require additional approvals beyond UAPC, Melissa will advance once the Provost memos are sent to the school/college deans.
         1. Karen writes the memos and Melissa fills in the SIS codes (logic of: fill in the Lumen Program fields, the next day pull the data double check it).
• Governance approvals
  1. Ensure that all governance approvals have been entered. In the UAPC approval, include additional bodies of required governance (Board of Regents, HLC).
• Reporting to UW System Admin
  1. After approval from UAPC, Allison La Tarte or Karen Mittelstadt will continue with communication to UW System Admin. Currently, Karen sends notice of intent and new major proposals and communicates the rest of plan level changes to UW System Admin through the forms on the UW System website and attaches the form submission to the proposal. Allison forwards any additional communication from UW System Admin to the planning team. Melissa adds this documentation and ensures that the academic structure values match before sending to the RO.
• Communication/Memos
  1. Proposals that require UAPC review include memos from the Provost indicating the approval of the proposal. The memo generally includes (but is not limited to) first term of enrollment, tuition, and transcript description. Additionally, values pulled from the Lumen Data Views/warehouse are appended to the memo. Karen writes the memos and Melissa adds the SIS values. Karen alerts the Provost’s Office of the memo completion. Once the memos are sent from the Provost’s Office alerting the school/college/ deans and individuals associated with the proposal, Melissa adds this documentation and ensures that the academic structure values match before sending to the RO. The purpose of the memo is to alert the community beyond the Lumen users that something significant is happening to people outside the UW-Madison community.
  2. When a new proposal is advanced to System Admin or the Board of Regents step of workflow, DAPIR will work with Diana Maki to assign filters associated with a program. Karen will provide a list of all current filters used in Guide and will request, up to 5 filters for each program. This documentation will be uploaded for the RO to implement in Guide.
  3. If a proposal does not require UAPC review, it will not include additional documentation indicating if SIS/Guide information is being updated (i.e. tuition). The administrative values are updated indicated by the red/green markup in the proposal.
• Attachments
  1. Attach all approval documentation from each approval step. Anything that needs to be retained for archival/imaging purposes will follow a standard naming convention [https://kb.wisc.edu/lumen/95967] and will be centrally located in a file upload field in the administrative section.
• Faculty directory data upload and refresh (each March)
  1. Michelle collects the data, formats the file, uploads into the Leepfrog server, and refreshes the data.
• User provisioning
  1. Michelle is the contact for any questions about who is included in CourseLeaf user provisioning. The current upload process will overwrite any manual changes made in CourseLeaf. If someone needs to be added, contact Michelle.
     • There is a manifest group that manages the people not in the regular user provisioning draw. The nightly query pulls the appropriate group of users from HRS. The list is sent through the pipeline, which then picks up the list of individuals in the manifest group. This data is combined and then is sent to a folder that gets uploaded to the SFTP server that automatically sends the file to LeepFrog. The file is uploaded and applied to our site daily.

• Add workflow step(s) based on implementation step(s). (Roles pulled from LP Roles and Responsibilities KB: https://kb.wisc.edu/lumen/134357). The DARS for EDU, EGR, and GSTS are FYI only, supporting the minimization of curricular updates past governance approval steps of workflow.
  1. Registrar-DARS Encoding
  2. Registrar-EDU Encoding (FYI ONLY)
  3. Registrar-EGR Encoding (FYI ONLY)
  4. Registrar-GSTS Encoding (FYI ONLY)
  5. Registrar-Guide Update
  6. Registrar-Publication Ready-Jan
  7. Registrar-Publication Ready-June
  8. Registrar-Publication Ready-Oct
  9. Registrar-SIS Entry
  10. Registrar-SIS Inactivate
  11. Registrar-Institutional Crosswalk
• SIS
  1. Implements SIS codes and CAF values. The values are found in Lumen data, either through the Lumen Programs form, or TCFDB data. Provost memos are still attached to proposals; however, the expectation is that the data used in SIS comes from the Lumen data. All changes will be indicated by the red/green markup; however, some values are eliminated from the form when the answer to a question is ‘No’ and will not have a strike-through on codes or values affected.
  2. Verify the data entered in Lumen is correct. If something seems wrong, contact DAPIR (Melissa Schultz).
  3. Not all changes will have Provost memo’s attached with SIS values.
     • Items that require UAPC, BoR, or HLC approval will typically include memos with SIS values. A good guide for what needs which kind of review, see this grid: https://uwmadison.app.box.com/file/258466206290?s=3zrhd79rf6qf8dlkga9shd7lw14rljup
     • If a proposal does not require UAPC review, it will not include additional documentation indicating if SIS/Guide information is being updated (i.e. tuition). The administrative values are updated indicated by the red/green markup in the proposal. These proposals are normally less than a 50% change to the overall program (Yes to the question, “Select yes if this proposal is only to add, remove, or rearrange curricular requirements, and will change less than 50% of the curriculum.”)
  4. Historical Context: With the academic structure clean-up (effective 5/14/2017), memos were included on UAPC actions to indicate what needed to be changed/implemented in SIS to ensure the academic structure remained accurate. Code tables are only included non-UW-Madison employees (UW System). Any UW-Madison employee should use the data in Lumen.
• Guide
  1. Implement Lumen programs/structures changes in Guide, if applicable (name changes, department mergers, creating of new awards/subjects, etc.).
     • Guide pages (full and promotional) are determined when the first term of enrollment and academic year. See KB: https://kb.wisc.edu/lumen/88387.
  2. Guide integration point set-up
     • Ensure all integration points on Guide pages match the corresponding Lumen Program number.
     • Remove/add integration points based on the answers to questions and whether content exists. Examples (not exhaustive):
       • If a three-year plan does not have content in Lumen Programs, the integration point should not be added in Guide.
       • If an accreditation answer is changed from ‘No’ to ‘Yes’, an integration point should be added in Guide.
       • If a certification/licensure is changed from ‘Yes’ to ‘No’, an integration point should be removed in Guide.
  3. Integration point review
     • Basic copy-editing updates can be made, relating to headings, toggles, capitalization, etc. If it looks like changes to curriculum should be made, consult with DAPIR on the best course of action. If there are substantial changes that need to be made, roll back to the APIR Approver step of workflow. If school/college contacts request that changes be made in any of the steps of workflow, direct their request to DAPIR.
     • Add URLs to named options (grad specific) once the Guide pages have been built.
     • Refresh parent proposals when children are added or removed.
     • Red boxes
       • If courses acquire red boxed status (subject + catalog number not found) in any of the Registrar workflow steps the school/college will need to work with DAPIR to update the curriculum as removing or changing red boxes can alter the curriculum substantially. No updates should be done to curriculum past any of the DAPIR steps of workflow without direction from an DAPIR academic planner. Any request to update red boxes should be diverted to DAPIR. If changes substantial in nature are required, the proposal should be rolled back and is subject to a secondary review of the entire proposal.
  4. General Guide maintenance
     • Photos
     • Apply filters to programs assigned by Wren Singer/Diana Maki and DAPIR.
     • Non-governed content
     • PDF management
     • Primary contact for Guide: guideeditor@office365.wisc.edu
     • Ensures that all shared content, without and proposed changes through Lumen Structures, have workflow started prior to the June publication.
• DARS
  1. As time allows, and if appropriate given the scope of the proposed curricular changes, proposals will be reviewed by a DARS encoder once the first FYI email notification is sent. DARS encoders are expected to review proposals at the 2^nd FYI between School/College Admin Reviewer and School/College Approver. If something is not clear for entry into DARS, the encoder should leave a comment within the Lumen form that indicates there are questions or that something cannot be encoded as written. DAPIR will not advance proposals that do not have resolution related to DARS.
     • If the encoder has no questions, concerns, or requests for clarification after reviewing the proposal at either FYI step, a comment should be added indicating as much.
     • In some circumstances, the extent of curricular changes to be reviewed by a DARS encoder will make it impossible to fully review at an FYI step. In such cases, the expectation is that the DARS encoder will complete their review and add the appropriate comment at the Registrar- DARS Encoding workflow step.
  2. If any questions or clarifications are needed after the second DARS FYI step that require updates to how the curriculum is written in Lumen, the proposal should either be: 1. Rolled back to DAPIR Admin with a comment requesting to update the curriculum and DAPIR will work with the school/college to update the content; 2. Contact DAPIR and ask if the change can be made in the current step either by DAPIR or the RO.

Once a program is sitting anywhere between DAPIR and the RO and the department/school or college requires additional changes, DAPIR and the RO will work together to ensure that the requested changes will not circumvent governance or create additional work in SIS or DARS. Once DAPIR approves a program, the following principles should be followed:

General Principles

• Any changes requested from departments, schools/colleges, or other groups outside of DAPIR/RO should be routed to DAPIR.
  1. This can vary depending on how the request was submitted. Ideally, requests will be done through email, however, if requests are submitted by chat or telephone calls, connecting via the Lumen Admin MS Teams channel is also acceptable.
• As a standard practice, proposals should not be rolled back once they’ve gone through governance.
  1. If something does necessitate a roll-back, it may require additional governance approval. Both DAPIR and the RO need to review the program as if it hadn’t gone through workflow previously.
• DAPIR will not make additional changes to anything in Lumen Programs once at a Registrar Step, without first consulting with the RO. (Note: if additional approval documentation/memos come through, DAPIR will add this with a heads up given to the RO.)
• RO will not make any changes to content in Lumen Programs once at a Registrar step without first consulting with DAPIR.
  1. Copy editing is fine. If it isn’t clear whether the copy editing might impact substance or meaning, RO will consult with DAPIR. The RO does not need to notify DAPIR of copy editing.

Other tidbids:

• CIP code changes should only be done for fall. These must be implemented as soon as feasible, post-summer reporting and before August 1 with a fall effective date.

• All changes to courses must be sent through with a course proposal.
• Administrative saves should be limited and only done if both DAPIR and the RO are in agreement.
1. If an administrative save is required, a rationale should be entered in the “Explain the rationale for the changes,” prior to submitting to the PeopleSoft step of workflow (admin save).

• Review requisites to ensure they follow the established guidelines; reformat if necessary.
  • Building Requisites: https://kb.wisc.edu/apir/110378
  • Student Groups for requisites: https://kb.wisc.edu/apir/114321
• Ensure all proposals include the correct Administrative Use information.
  • Attribute for Practical Experience: https://kb.wisc.edu/apir/116440
  • CDR assignment: https://kb.wisc.edu/apir/116403
  • Career: Undergraduate = <699; >700 = Graduate; Medicine = subjective; usually based on requisite/subject/catalog number – allows scheduling in the medicine career.
• Verify the effective date is appropriate.
  • Deadlines: https://kb.wisc.edu/lumen/94417
  • Discontinued courses are inactivated for the current term, following best practices for the course draw and archiving principles: https://kb.wisc.edu/lumen/104224; https://kb.wisc.edu/lumen/94021

A course in the regular course proposal process

• Review course proposals at the Registrar-Course Data Entry step to determine whether or not:
  • A new requisite needs to be built
    • If so, build new requisite with effective dated term that matches the course change proposal
  • A current requisite needs revision
    • Review other courses using this same requisite? If being used, create a new one?
    • If the requisite is only being used by this course, update requisite as needed with effective dated term that matches the course change proposal
  • Special characters such as quotation marks, hyphens, apostrophes, and question marks, need to be edited
    • If so, edit the proposal, delete the special character, retype the special character, and click ‘save’
  • All components used in the requisite exist as stated. For example, if the requisite utilizes a course that does not exist in the current state due to newness or proposed changes, it will utilize the placeholder.

• If not, use ‘need to create’ requirement group (1567) as a placeholder until all components exist

• Advance course proposals to the PeopleSoft step
• Review courses in the PeopleSoft step for accuracy
• Bridge Courses to SIS using CourseLeaf Catalog Update
  • If the bridge is not working as expected, troubleshoot the bridge and/or enter course changes manually into SIS
• Attach requisite to course catalog in SIS (if applicable)

Courses edited and submitted for administrative purposes

Administrative proposals may be submitted, with rationale entered, for:

• • Updating requisites to reflect a new subject/catalog number related to an existing course change proposal (ie: a course changing its subject, adding/removing a cross-list partner, or changing a catalog number).
  • Correcting administrative values (CDR), spelling errors, or technical corrections related to data issues (special characters).
  • Implementation of credit-by or departmental placement exams, AP, IB, CLEP, etc., or transfer equivalencies in requisites
  • Revision to shortened words that may be inappropriate.

Administrative proposals should not be submitted for:

• • Program names used in catalog content (titles, description, requisites, etc.) related to new, change, or discontinuations.

Regular course maintenance

• Run weekly audits to ensure course catalog information matches section level information
• Complete maintenance on a semester and annual basis such as updating general education academic requirement groups, term specific concurrent enrollment requisites, and requisites that use inactivated courses.

• Build and maintain the Placement Exam in Guide.
• Alert school/college contacts of revised requisites.
• Adds the placement exam scores in the Google sheet of requisites.

• Build and maintain test components.
• Add new/revised exam to the e-form.
• Revise Requisites.
• Provide a list of impacted course requisites.

1. DAPIR reviews the proposal and verifies the effective term aligns with the deadline for course changes.
2. RO Student Services enter test components into SIS for use in requisites. For each new exam, they add a new row in the test ID table. There are sub-tables within that table where the scores are entered.  Note that the effective date cannot be the same as the term in which the exam becomes effective (e.g. 12/27/21 for Spring 2022) if it needs to be in place for that term’s enrollment cycle.  The requisite set-up will not “find” the test component if it is future-dated.
3. RO Student Services works with developers to set-up the e-form, incorporating the new exam and associated test scores.
4. RO Course Specialist updates the Lumen Exam form with the test components that Student Services created.
5. RO Course Specialist sets up the placement in exam in SIS so they can be utilized in requisites.
6. RO Course Specialist queries for a list of all courses and requisites impacted by the placement exam. Update those course requisites to include the test component and revise the long descr to indicate a placement exam may also satisfy the requisite. Attach a list of the impacted courses in the Lumen Exam form.
7. DAPIR emails school/college partners providing a list of courses where the requisites were updated with the effective term.

• No new row will be added in the course catalog for the requisite change. The requirement group indicates when the course requisite changes.
• Departments enter student placement scores through the e-form in Student Services. That report routes to Student Services for data entry on the student’s record.
• The effective date for changes to requisites follows the course change deadline, with a preferred term of fall for implementation. Departmental placement exams are centrally located in the Guide front matter, which updates once a year (no mid-cycle updates) to coincide with the June publication. Revisions to program proposals to include departmental placement exams would not be applicable for a mid-cycle update.