High-Level Overview for All Users

Following are some key points all users should consider while working within the Lumen Program proposal form:

• All fields should be entered completely and accurately, and all Guide integration points should be publish-ready when proposals are approved at the school/college-level unless otherwise agreed upon with Data, Academic Planning & Institutional Research (DAPIR).
• Approval information needs to be entered at each step, specifically the Department Approval, School/College Approval, Graduate Faculty Executive Committee (GFEC) Approval (if needed), and University Academic Planning Council Approval.
• Individuals in approval roles are expected to be experts on policy within their realm of approval and ensure that all expectations are met before advancing the proposal to the next step in workflow.
• While the Lumen software provides better transparency about programs in development, it does not substitute for communication among those with an interest through other means for new, substantially changed, and/or discontinued programs.
• Consultation with school/college academic planners and DAPIR prior to submitting to workflow is advantageous. 
• Any proposal that does not meet the expectations detailed within this document will be rolled back.
• Users working in the form should save often. The system times out after 90 minutes of inactivity. 
• While the system allows for easy collaboration, make sure only one person edits a proposal at a time. The system is not designed to have multiple people editing a single proposal at the same time.
• When submitting a change proposal, no data will be lost because the previous proposal retains everything approved. 

Role of Academic Planning and Governance

Academic planning and ultimately the routing of academic program proposals through the appropriate governance structures enables three important components of creating and delivering quality academic programs at UW–Madison:

• Thorough Communication: Through this process, key stakeholders are informed of and have a chance to assess new programs and/or changes to existing programs. This helps the university, the schools and colleges, and the departments consider potential impacts broadly.
• Adequate Peer Review: With substantive governance review, the university and its faculty can assess how/if a proposal meets all policy standards and the standards of the discipline. In addition, program faculty can be satisfied with the public discussion of an academic program proposal.
• Ready for Students: When a proposal is thoroughly evaluated, it allows all stakeholders to consider how/if the needs of students are being met and served.

Lumen Program Proposal Form - Available Actions

The Lumen Program proposal forms allows for the following actions and/or captures the following program details:

• Proposing a new program (degree/major, certificate, and/or named option)
• Changing the status/state of a plan or subplan (e.g., suspend/discontinue)
• Changing the ownership of a plan (e.g., changing a department and/or school/college)
• Adding a sub-plan (i.e., a named option) to a plan
• Adding/changing a plan to be collaborative or in a consortium
• Changing the mode of delivery
• Changing the geographic location of a program
• Updating program accreditation
• Updating certification and licensure details
• Updating details related to resources, budget, and finance
• Updating curriculum and requirements
• Updating learning outcomes and assessment
• Recording of all approvals and memo-related documentation
• Recording of Student Information System (SIS) and other administrative codes

Pre-Proposal Tasks and Responsibilities

Consultation

The complexity of the combined program proposal form has the potential to be confusing. Programs are encouraged to consult with school/college academic planners (as applicable) and DAPIR early in the process to help answer questions and minimize duplicated efforts in completing the proposal. It is much easier to have multiple parties work collaboratively on a proposal prior to submitting it to workflow than it is to have proposals rolled back once in workflow.

Before Submitting to Workflow - Points to Remember

Change Proposals and the Percent Curricular Change Question

It is very important to answer the Lumen Program proposal question that reads: "Is the change being proposed only a curricular change that would impact fewer than 50% of the credits in the program (i.e., plan or subplan) under consideration," before making any changes to the proposal form.

• The answer to this question is an underlying driver for the format of the form (i.e., what questions are asked) and to subsequent governance approval.
• The response of No indicates a more substantive change to the program, which then provides more options/questions within the form to detail the requested change.
• If changes are made to sections that are disabled when the answer is Yes it will be rolled back with instructions to answer No and fill out the rest of the fields on the form.
• If the proposer selects Yes, some of the fields that are normally required (i.e., fields with red boxes) are disabled. Required questions will remain outlined in red, but the proposer will not be able to answer the question.

Form Fields and Required Responses

Regardless of the change percentage, all fillable fields should be completed prior to submitting a proposal into workflow by the proposer in consultation with the school/college academic planners and DAPIR. Many of the fields are blank because this data has never been populated. Many of the fields, once filled out, will retain the data in the proposal. Thus, there will be a slightly larger workload associated with the first change proposal.

Some fields are required, indicated by the red outline. All fillable questions should be completed. The form is dynamic and will change depending on answers to some questions.   

Vested Interest Table

The vested interest table should list departments or schools/colleges that would be interested in the proposal, such as departments with courses used in the curriculum, departments that have overlapping subject matter, and/or schools/colleges that may be interested in the program/curriculum. It is imperative that the vested interest table in the form be completed prior to submitting the proposal into workflow so the relevant parties receive the auto-generated FYI email in Lumen and can thus add their comment and support to the proposal. 

If vested interests are added after the proposal is in workflow, the proposer must reach out to the vested interest department/school/college outside of the proposal system or roll back the proposal completely out of workflow (to the original submitter) and re-submit after adding vested interests. 

Guide Integration Points 

All Guide integration points (e.g., Accreditation, Certification/Licensure, Admissions/How to Get in, Requirements, Four-Year Plans, Graduate Policies, Learning Outcomes) must be publish-ready when the proposal is advanced from the school/college workflow step. This includes, for example, courses being either in tables or linked to the database, no spelling errors, content aligned with formatting standards set by either the school/college or Graduate School, etc. These integration points display in Guide on the corresponding tabs and are the public-facing approved version of the proposal.

The integration points are published as-is in the Guide. While questions are answered in the Lumen Program proposal form, there may need to be information in the integration points that seems duplicative. For example, students working toward a certificate credential need to meet a minimum GPA in the coursework. There are questions in the Commitments section of the form regarding this, but the information published in Guide must be comprehensive and include all details students might need to complete the program. The content listed in the Curriculum and Requirements section also indicates to the Degree Audit Reporting System (DARS) encoders how requirements should be set up in the encoding system. All requirements should be included in the Requirements and/or Policies sections of the form and align with the information provided in the Commitments section of the form.

For support in entering the Guide content in the proposal form, please refer to the Guide KnowledgeBase topic library. 

Workflow Step Tasks and Responsibilities

Program Proposer

The curriculum is owned and maintained by the faculty in the department, which must be consistent with school/college expectations and follow what was approved for any new program proposal through the Board of Regents. The program proposer should engage with their school/college curriculum coordinator and/or academic planner and consult with APIR prior to creating a new Lumen Program proposal or if they are proposing substantial changes to an existing program. Including governance approval bodies early in the proposal process ensures the curriculum retains the heart of what the faculty desire while adhering to governance policies.

The Program Proposer should also: 

• Answer all questions on the form to the best of their ability. All data in Lumen Program is retained and will be utilized, so proposers should ensure all questions are addressed in a professional manner.
• Conform to school/college (and/or Graduate School) formatting and/or required elements in the Guide integration points (i.e., Guide published content).
• If proposing changes to learning outcomes, reach out to the Student Learning Assessment office early in the process to ensure that assessment plans and reports are up-to-date and learning outcomes are assessible. For more information, refer to the Program Proposal: Program Learning Outcomes and Assessment KB document.

Department Review and Approval

The department approval role includes the department chair and others designated by the chair to have approval authority. This individual must review the content of the proposal and ensure that it meets departmental standards and has gone through departmental governance. Individuals filling out the approvals are entering information on behalf of the department, not the individual.

Once the proposal has been reviewed, a comment must be entered in the Approvals section. It is helpful to include how the approval was determined, by what means, participating individuals (or roles), and when. If there was discussion at the meetings that is relevant for posterity, that information should be included as well. The Entered by and date fields must be filled out and should indicate the induvial entering the approval and the date of the entry. For more information on approvals, refer to the Program Proposal: Approvals KB document.

Following are specific expectations for the Department Approver:

• Review the answers to the questions
• Make sure no information/answers are missing
• Review the Guide integration points:
  • Check for spelling and grammar issues
  • Make sure the information presented conforms to departmental policies.
  • Review the curriculum, ensuring the curriculum is publish-ready (i.e., entered either in course lists or connected to the database)
  • Make sure all essential elements are entered in the Guide integration points
• Correct content, as needed; the proposer and department approvers are expected to be the content experts of requirements and policies within the department. If programs do not meet standards, the department approval should roll the proposal back to the Program Proposer
• Enter approval
• Advance to the next step of workflow

School/College Admin Reviewer

The School/College Admin Reviewer role includes individuals with approval authority at the school/college-level who can help administer program content and structure. These individuals have a good grasp on how to utilize the Lumen system and can help format or curate content submitted by the department in preparation for formal school/college review and approval. This step of workflow does not require entry of approval information but will require individuals in the role to advance proposals to the School/College Review and Approval step. Typically, this step serves as a prep-step prior to academic planning council meetings.

Following are specific expectations for the School/College Admin Reviewer:

• Review the answers to the questions; if there are any missing answers to the questions, fill in as able or roll back to the department and indicate what is missing or insufficient
• Review the Guide integration points:
  • Check for spelling and grammar issues
  • Make sure the information presented conforms to the school/college policies
  • Review the curriculum, ensuring the curriculum is publish-ready (i.e., entered either in course lists or connected to the database).
  • Make sure all essential elements are entered in the Guide integration points
• Correct content, as needed; the school/college-level users (i.e., School/College Admin Reviewer and School/College Review and Approval) are expected to be the software and/or policy experts of their own school/college and enforcers of the school/college expectations. If programs do not meet standards, the proposal should be rolled back to either the Department Approver or the Program Proposer
• Verify approvals have been entered at the department level
• Advance to the next step of workflow

Note: If curricular changes or modifications happen at the School/College Admin Reviewer-level, individuals at the prior proposer/approver stages will need to be notified outside of the Lumen system. The system does not notify individuals in prior workflow stages of subsequent changes. 

School/College Review and Approval

The School/College Review and Approval role includes the dean and others designated by the dean as having approval authority for the school/college. This individual must review the content of the proposal and ensure that it meets school/college standards, which should include some level of discussion from academic planning or curriculum committees. Individuals filling out the approvals are entering information on behalf of the school/college, not the individual.

After reviewing the proposal, a comment indicating approval must be entered in the Approvals section. It is helpful to include how the approval was determined, by what means, participating individuals (or roles), and when. If there was discussion at the meeting relevant for the future posterity, please include as well. If the changes do not necessitate an academic planning council vote or review, please indicate that. The Entered by and date fields must be filled out and should indicate the induvial entering the approval and the date of the entry. For more information on approvals, refer to the Program Proposal: Approvals KB document.

Following are specific expectations for the School/College Approver:

• Review the answers to the questions; if there are any missing answers to the questions, fill in as able or roll back to the department and indicate what is missing or insufficient
• Review the Guide integration points:
  • Check for spelling and grammar issues
  • Make sure the information presented conforms to the school/college policies
  • Review the curriculum, ensuring the curriculum is publish-ready (i.e., entered either in course lists or connected to the database)
  • Make sure all essential elements are entered in the Guide integration points
  • Courses that are included in the curriculum must be approved through the school/college governance. If courses are new or changed and impact the overall program but are not approved through the school/college, the proposal may be rolled back, withheld from a publication, and/or not advance for any other approvals required beyond the school/college (e.g., Graduate Faculty Executive Committee, University Academic Planning Council, UW System Admin, Board of Regents, Higher Learning Commission, etc.).
• Correct content, as needed. The school/college-level users (i.e., School/College Admin Reviewer and School/College Review and Approval) are expected to be the software and/or policy experts of their own school/college and enforcers of the school/college expectations. They are also expected to be knowledgeable about campus policy and ensure that relevant policies have been followed. If programs do not meet standards, the proposal should be rolled back to either the Department Approver or the Program Proposer. 
• Verify approvals have been entered at the department level
• Enter school/college approval
• Advance to the next step of workflow

Note: If curricular changes or modifications happen at the School/College Approver-level, individuals at the prior proposer/approver stages will need to be notified outside of the Lumen system. The system does not notify individuals in prior workflow stages of subsequent changes. 

DARS FYI (if applicable)

The automatically generated DARS FYI email notification is sent when the proposal is advanced by the department to the school/college workflow steps. The expectation is that the DARS encoders will review the curriculum for any glaring issues that cannot be encoded in DARS. Since the proposal is not yet approved by the school/college curriculum committee, no changes should be made in DARS at this stage. While DARS encoders should be consulted for feasibility, it is important to remember that while a requirement might be able to be encoded in DARS it might still not be academically sound. The final approval of the curriculum and DARS encodability comes after UAPC approval. If there are problems with the curriculum, the DARS encoder(s) will work with the appropriate school/college to rectify encoding discrepancies.

Assessment Admin FYI

The Student Learning Assessment (SLA) office also receives an FYI email notification when the proposal is advanced by the department to the school/college workflow steps. The expectation for learning assessment review only applies when a proposal is new or represents a change greater than 50%. In general, program proposers and school/college academic planners are advised to reach out to the SLA team early (via email or phone) and not to rely solely on the automatically generated message in Lumen. The SLA team will use the Add Comment functionality on the form to verify that program learning outcomes and the assessment plan are acceptable, and that the program is up to date on required annual assessment reports. It is important to note that a proposal cannot advance to UAPC until the SLA team has confirmed, within the Lumen form, that the outcomes are acceptable, the assessment plan is acceptable, and all assessment reports are current. Therefore, program proposers are encouraged to work directly with the SLA team, outside of the Lumen workflow if necessary, to receive required assessment-related approvals. For more information about the Assessment review/approval, please refer to the Program Proposal: Program Learning Outcomes and Assessment KnoweldgeBase document.

APIR Admin

Once a proposal reaches the DAPIR Admin step, which follows school/college approval, it indicates the proposal is ready to be scheduled for the GFEC (if a graduate program) and UAPC. At the APIR Admin step, there is planning for scheduling at upcoming GFEC/UAPC meetings and often other communication between the school/college, the Graduate School (as needed), and APIR. APIR reviews the proposal to ensure all questions have been answered sufficiently, the program aligns with policy, Guide integrations are populated, and the department and school/college approvers have fulfilled their expectations. No curriculum will be adjusted at this step unless done in consultation with the appropriate school/college approvers, for example, to remove red-boxed courses.

If there are additional governance approval steps after UAPC (such as UW System or Higher Learning Commission), they will be added to the workflow by DAPIR at this time. If a down-stream adjustments in Lumen workflow are needed, the additional roles that could be added are APIR-Board of Regents; APIR-HLC; APIR-UW System. These roles are designed to better communicate with campus stakeholders as to the status of proposals post-UAPC approval.

Post-DAPIR review, there are a few paths forward a proposal can take:

• If the program is at the undergraduate level and does not require UAPC review/approval, workflow will be modified to remove the UAPC step. An approval note will indicate that the item does not need to be reviewed at UAPC and the proposal will be advanced to the Office of the Registrar step of workflow. Usually this applies to proposals that are proposing a less than 50% curricular change only.  
• If the program is graduate-level or needs Graduate School approval, DAPIR will approve the proposal and advance to the next step of workflow (i.e., GFEC). Certain special student programs will follow the graduate workflow, as they are governed, in part, by the Graduate School.
• If a proposal is incomplete either because proposal questions have incomplete answers or the Guide integration points are incomplete, DAPIR will roll the proposal back to the School/College Approver with information about needed changes.

Following are specific expectations for the APIR Admin step:

• Review the answers to all the questions for completeness; if questions are not sufficiently answered or are skipped but are pertinent, proposals will be rolled back with a request to further clarify answers.
• If the Student Learning Assessment office indicated that changes needed to be made to the assessment report or learning outcomes, but they haven’t been made, the proposal will be rolled back.
• Review the Guide integration points:
  • Make sure they conform to the university policies
  • Ensure they are Guide-publish ready
• Verify approvals have been entered at the department and school/college-level

GFEC Approver (if applicable)

The GFEC Approver role includes the dean of the Graduate School and others designated by the dean to have approval authority. The GFEC Approver must review the content of the proposal and ensure that it meets the standards of the Graduate School. Entering approval at this step means that GFEC has approved the proposal, or the changes are small enough that approval may be given by a designee. Individuals filling out the approvals are entering information on behalf of the Graduate School, not the individual.

After reviewing the proposal, a comment must be entered in the Approval section. It is helpful to include how the approval was determined, by what means, participating individuals (or roles), and when. If there was discussion at the meetings that is relevant for posterity, that should be included as well. The Entered by and date fields must be filled out and should indicate the induvial entering the approval and the date of the entry. For more information on approvals, refer to the Program Proposal: Approvals KB document.

Following are specific expectations for the GFEC Approver step:

• Review the answers to the questions
• Review the Guide integration points:
  • Make sure they conform to the Graduate School policies
  • Review the curriculum and admissions sections
  • Ensure the curriculum is publish-ready (i.e., entered either in course lists or connected to the database)
  • Make sure all essential elements are entered in the integration points and conform to the standards set by the Graduate School
• Correct content, as needed. The Graduate School approvers are expected to be the policy and curricular experts for all graduate programs. If programs do not meet standards, the proposal should be rolled back to either the school/college, department, or proposer. 
• Verify approvals have been entered at the department and school/college-level
• Enter approvals and memo (if applicable)

If items require UAPC approval/review, these should be advanced as soon as possible to ensure APIR has enough time to prepare materials for the UAPC meeting.

UAPC Approver

DAPIR coordinates the scheduling of UAPC, in collaboration with the Graduate School for items needing GFEC approval. Once items are at the UAPC Approver stage, they have been reviewed and approved by the department, school/college, GFEC (if applicable), and APIR. If programs require rollback for adjustments or corrections due to UAPC comments, they will be rolled back to the School/College Approver step in workflow. Programs requiring GFEC approval may not get advanced from GFEC to the UAPC queue until all approvals are entered and questions are answered/addressed. It is possible items will not be in the UAPC step until the day of UAPC meeting. 

Upon approved at UAPC, APIR academic planners enter the approval information from the UAPC meeting. All data values needed for SIS are entered or updated. DAPIR does a final check to make sure that all documentation is attached to the proposal, as applicable. If there are extenuating circumstances for holding onto proposals before they advance to any additional steps of workflow, programs will advance to the APIR Hold stage until the circumstances have been addressed. APIR is not authorized to make changes that are not approved through governance.  

Following are the specific expectations for the UAPC Approver:

• Review the Guide integration points for red-boxed courses and include university-level shared content (if applicable). DAPIR does not review curriculum beyond the level of ensuring courses are set up correctly in the system and/or ensuring the curriculum does not violate university policy.
• If there are questions regarding any of the integration points or answers to any of the form questions, DAPIR will consult with the school/college academic planner to resolve issues. If the program needs to be rolled back, APIR will ensure the changes will not require re-approval from GFEC or UAPC.
• Enter approvals and attach any memos or other formal documentation (if applicable).

APIR-UW System (if applicable)

If DAPIR must send acknowledgement or request approval to UW System Admin, this step of workflow will be added. (For more information on what academic actions require UW System approval, refer to the UW–Madison Array Management and Program Planning Process document.) At this step, the submission and acknowledgment will be added prior to advancing to the next step of workflow. Any approval information will be entered in the UAPC approval box.

All attached documentation will utilize the following naming convention: SystemAdmin [program name + degree] [New/Change/Discontinue “Request/Approval/Acknowledgment”] [Year+Month+Day]. For example: SystemAdmin_AppliedBiotechnologyMSNewRequest20190215

APIR-Board of Regents (if applicable)

If an item needs Board of Regent approval (refer to the UW–Madison Academic Program Approval Overview), it will sit in this queue until the meeting and approval memos are received by DAPIR. Submission documents to the Board of Regents and the approval memos from the Board of Regents will be added prior to advancing to the next step of workflow. Any approval information will be entered in the UAPC approval box.

All attached documentation will utilize the following naming convention: BoR [program name + degree] [New/Change/Discontinue “Request/Approval/Acknowledgement”] [Year+Month+Day] For example: BoR_AppliedBiotechnologyMS_NewApproval20190405; or BoR_AppliedBiotechnologyMS_NOIRequest20181206

APIR-HLC (if applicable)

Any item that needs approval from the Higher Learning Commission (HLC) (refer to the UW–Madison Array Management and Program Planning Process document), will sit in this queue until approved. At this step, the submission documents to HLC and the approval memos/email from HLC will be added at this step prior to advancing to the next step of workflow. Any approval information will be entered in the UAPC approval box.

All attached documentation will utilize the following naming convention: HLC [program name + degree] [New/Change/Discontinue “Request/Approval/Acknowledgement”] [Year+Month+Day]; or HLC_AppliedBiotechnologyMS_NewApproval20190406; or  HLC_AppliedBiotechnologyMS_NOIRequest20181206

DARS FYI (if applicable)

The DARS FYI email notification is sent after all governance decisions have been made. All changes should be made in DARS at this time. If there are additional clarifying questions regarding the organization of curriculum, the DARS encoders will work with the appropriate school/college contacts to ensure they are providing the output that the faculty/department intended. Curricular changes that deviate from the original intent are not allowed.

Registrar (Office of the Registrar)

The Office of the Registrar (RO) oversees a variety of roles supporting the completion of academic programs. To better communicate with campus partners, additional roles have been created to indicate where a program is in the process. These roles will be added once proposals reach the Registrar step in workflow and they have been reviewed for actions needed. Guide Promo Pages will not be created until a program reaches this step-in workflow. The RO is not authorized to make changes that aren’t approved through governance.

• Registrar-DARS Encoding: When an undergraduate program requires campus encoding, this role will be added. A program will stay in this step until completed by the appropriate DARS encoder. 
• Registrar-EDU Encoding: When an undergraduate program requires encoding for School of Education programs, this step will be added as an FYI. Once the proposal works through the workflow in the Registrar’s step, the School of Education will receive an email indicating that a program has completed the approval steps and can be encoded.
• Registrar-EGR Encoding: When an undergraduate program requires encoding for College of Engineering programs, this step will be added as an FYI. Once the proposal works through the workflow in the Registrar’s step, the College of Engineering will receive an email indicating that a program has completed the approval steps and can be encoded.
• Registrar-GSTS Encoding: When a graduate program requires encoding, this step will be added as an FYI. Once the proposal works through the workflow in the Registrar’s step, the Graduate School will receive an email indicating that a program has completed the approval steps and can be encoded.
• Registrar-Guide Update: When a program necessitates changes to a Guide page (e.g., name, department, school/college change) this role will be added. A program will stay in this step until completed by the Guide Administrator.
• Registrar-Publication Ready-Jan: Once a program is completed and ready for the January midcycle update (effective summer), it will be advanced to this step of workflow. A program will stay in this step until ready for publication. Generally, once a proposal is in a Publication Ready step, additional changes will necessitate discussion with the RO/APIR to ensure no substantial additional work is being proposed. This step indicates all DARS, SIS, and Guide work has been completed and the proposal is ready to be published.
• Registrar-Publication Ready-June: Once a program is completed and ready for the June publish (effective fall), it will be advanced to this step of workflow. A program will stay in this step until ready for publication. Generally, once a proposal is in a Publication Ready step, additional changes will necessitate discussion with the RO/APIR to ensure no substantial additional work is being proposed. This step indicates all DARS, SIS, and Guide work has been completed and the proposal is ready to be put back on the shelf.
• Registrar-Publication Ready-Oct: Once a program is completed and ready for the October midcycle update (effective spring), it will be advanced to this step of workflow. A program will stay in this step until ready for publication. Generally, once a proposal is in a Publication Ready step, additional changes will necessitate discussion with the RO/APIR to ensure no substantial additional work is being proposed. This step indicates all DARS, SIS, and Guide work has been completed and the proposal is ready to be put back on the shelf.
• Registrar-SIS Entry: When a program necessitates changes in SIS this role will be added. A program will stay in this step until completed by the SIS Academic Structure Administrator.
• Registrar-SIS Inactivate: When a program is discontinued and the Guide page needs to be deleted and the program inactivated in SIS, this step indicates it is pending finalization of the inactivation. Degrees must post for students completing within the time limit necessitating the program to remain active. Once degrees are posted, the program can be inactivated.

Implementation Meetings

Once a new or substantially changed proposal is approved through governance steps (i.e., when the proposal is at any of the Registrar steps), implementation meetings can be scheduled. Implementation meetings are not required but are immensely helpful for ensuring all involved parties are aware of what will happen with the program post-approval. The school/college is responsible for coordinating and scheduling the implementation meeting. For more information on implementation meetings and logistics, including a draft agenda, refer to the New Program Implementation and Logistics Meeting KnowledgeBase document.