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'll need to create enough future school years to accommodate the inclusion of the new, incoming students for the lowest grade.

You must create terms before creating Courses, Activities, Advisories, and Dorms.

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

Term dates can overlap in parallel termsets, but term dates within the same term 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.

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.

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, teacher, etc.).

Review and update manager role membership.

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

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

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.

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.

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,

    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.

      For example, the integration manager or Connect Raiser’s Edge manager can log into Raiser’s Edge and edit the Settings for the Connect Raiser’s Edge plug-in. See Setup Connect Raiser's Edge.

    • 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?

To discuss best practices with your peers, visit the K-12 user community .