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 DAPIR 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.

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

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. 

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. 

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.

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.

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

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.

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).

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

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

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

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.

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.