Annual Procedures

Each year, managers must complete several tasks to successfully close out the current year and prepare for the upcoming year. Use this document as a checklist to ensure that all of the necessary tasks have been completed. Depending on which modules are used at your school, some of these tasks may not be applicable.

Platform managers should create or review the upcoming school year.

You must createsessions before creating Courses, Activities, Advisories, and Dorms.

For the appropriate school levels, create sessions for Academics, Activity, Advisory and/or Dorms.

Note: Session dates can overlap in parallel sessionsets, but session dates within the same session set cannot overlap. For details, see years and terms.

Platform managers should publish upcoming school years to users.

This enables constituents to view athletic teams, academic courses, etc. for the next year.

Tip: To prevent users from accessing past information, edit the previous year and clear the Is Published option.

Enter the fall, winter and spring seasons and dates for Athletics. For details, see years and terms.

Note: Athletics seasons can overlap. However, the start and end dates should not be the same.

Platform managers can manually add new users to the database and then edit them to assign them to the appropriate personas (student, parent, faculty, etc.).

Review and update manager role membership.

Schools can withdraw employees individually or in bulk to move them into the Past Faculty/Staff role.

and calculate classifications

Platform managers can graduate, , withdraw, and repeat current students.

Platform managers can also promote students if they have a session per school year. If your higher ed school has multiple sessions per year, use the Create Future Enrollment import instead instead of promoting students.

Platform managers also run classification calculations, typicality for each session or term, including the end of the year.

Platform managers can use the master rollover process to move information from the current school year to the upcoming school year.

Roll over Gradebooks before Grading. You'll need gradebook marking periods set up for the upcoming school year.

Warning: If you plan to import this data, then do not use data rollovers. Performing both import and rollover will duplicate data.

If necessary, data managers can import any of the following data that was not rolled over or entered manually:

Complete all data rollovers.

After all data rollovers are complete, a platform manager can edit the upcoming school year to make it the current year.

For details, see years and terms.

After the upcoming year has been set as the current year, reclassify incoming students as students.

Review the public and private content throughout your school website and the community to ensure that it is up to date.

Tip: Remember, public content is visible to anyone who signs into your school's instance of Education Management, even if their only role is All School.

Managers can update group page settings and access for

  • academics,

  • activity,

  • advisory,

  • athletics,

  • and dorms.

Platform managers can determine which school years appear on the inquiry forms as "Entering Year" options.

You'll also designate the upcoming admissions year as the current admissions year.

Admissions managers can enroll accepted candidates in the school and move them to the Incoming Student or Student role.

You'll probably also inactivate candidates who are not enrolling in the school and move them to the Past Candidate persona.

A user with the ON API Access Manager role should go to Core, Security, Authentication settings, ON API Access. From there,

  • review existing authentications,

  • grant or revoke access for users who manage corresponding integrations,

  • regenerate expired tokens and ones that expire soon,

    Tip: Authentication tokens (keys and secrets) expire every 365 days.

  • provide updated tokens (keys and secrets) to their corresponding apps or developers. Based on the specific app, you'll either:

    • enter the information using the app's user interface.

    • provide the information to the developer so the developer can update the app's POST method.

For details, see "legacy" ON API tokens.

Review your school's certificates and keys for Blackbaud ID Single Sign-On (SSO) to ensure they don’t expire during the upcoming the school year. Update these during the summer when minimal users log in.

Additionally, ensure your school has an organization admin whose email address isn't part of your school’s claimed domain. To learn why, see the KnowledgeBase.

For details, see:

You may be required to take action for some integrations. For details, review the help documentation for the integration.

For example, you'll likely need to take action for:

  • Connect 5 Managers can set the emergency contacts for new students.

  • BrightArrow

  • CrisisGo

You'll also need to review access and regenerate authentication tokens for "legacy" ON API applications and integrations.

Your admissions workflow may vary based on your school's policies and procedures. We recommend describing this in your school's "policies and procedures" guide. Consider including approximate dates, reasons for your workflow, and any known exceptions.

  • Can candidates apply for the current year or only future ones? Are enrollment for the current year accepted all year?

  • Will you de-activate candidates in bulk after a deadline has passed?

  • Do candidates have to reapply for future years if they were accepted into the current year?

  • How will you inform active candidates that admissions for the current year have ended or that they will need to complete a new applications for a future year?

  • Do you use a wait list? How are candidates on the wait list handled?

  • Do you use a different workflow or different dates for candidates on a wait list, children of faculty, siblings of current students, children of alums, or other individuals?

Tip: To discuss best practices with your peers, visit the Higher Ed user community.