School Systems, Campuses, Schools, and Cohorts

iGradePlus 12 will introduce a clearer way of describing how your institution is put together — from a single classroom program all the way up to a multi-campus district. Most of it will feel familiar, but two pieces will be genuinely new: Campuses and Cohorts.

This post explains the four building blocks of that model. Before we get to the new academic-calendar features in the next post, they’re worth understanding, because everything else — calendars, grading periods, rosters, reporting — will hang off of them.

How it works today

Currently, an iGradePlus account can contain one or more schools. There is a “school system,” but it exists only as a field on each school’s profile — a name attached to schools, not a structural level that owns anything in its own right. Nothing sits between your account and its schools.

That has two consequences:

• There’s no way to represent multiple physical locations. An organization that operates several buildings — a district, or a college with a main campus and a satellite — has to be flattened into a single list of schools with no location layer between them.
• Students are organized only around the traditional school year. Within a school, classes belong to the school year, and there’s no way to describe a group of students who enroll together and move through a program on their own schedule.

For a single school, today’s flat structure works fine. For anything larger or less traditional, it leaves a lot unsaid.

What will change in iGradePlus 12

In version 12, that flat arrangement will become a real hierarchy, and the “school system” will stop being a label and become the top of it:

School System   ← your account: the whole institution
    └── Campus   ← a physical location  (NEW)
          └── School   ← where teaching happens
                ├── Classes   ← a traditional school’s classes sit directly under the school
                └── Cohorts   ← a cohort-based school groups its classes into cohorts  (NEW)
                      └── Classes

Each level will contain the one below it. A School System will have one or more Campuses; a Campus will have one or more Schools; and a School will group its students — traditionally by school year, or, when it makes sense, into Cohorts.

Let’s take them one at a time.

School System — your account

The School System will be the top of the hierarchy: no longer just a field on a school profile, but the tenant that everything else lives inside. If you administer iGradePlus, this will be your account.

It will own the things that should be defined once and shared everywhere:

• Institution identity — name, addresses, contact information, web presence
• System-wide rosters of students and guardians, and the household model that links families
• The grade levels you use (K–12 plus any custom levels)
• Your student-ID format and how new IDs are generated
• The profile fields you collect on students and guardians
• Default grading options that flow down to every campus and school

A School System will also have a structure that tells iGradePlus what shape your institution is:

Structure	Who it’s for
Single-Campus	One location. The default, and what most schools will use.
Multi-Campus	Several locations under one organization.
District	A district overseeing multiple schools across campuses.

This setting is what will make the Campus layer meaningful — which brings us to the first new concept.

Campuses — the physical-location layer (new)

A Campus will sit between the School System and its Schools, representing a physical location: its own address and contact details, its own administrators, and its own default settings that the schools at that campus inherit.

Why add this layer? As it stands, iGradePlus has no way to represent an organization that operates in more than one place. A district with three buildings, or a college with a main campus and a satellite, has to be forced into a single flat list of schools. The Campus layer will fix that: each location will be a first-class part of your organization, with administrators assigned to it and its own defaults.

What a Campus will own:

• Its own identity — name, description, addresses, contact info, web presence
• Campus administrators — staff assigned to manage that location
• The schools that belong to the campus
• A default academic calendar that its schools inherit (more on calendars in the next post)
• Default grading options — assignment categories, grade scales, category and assignment weights, and drop-score policies — that schools at the campus inherit and can override

If you run a single location, you will still have a Campus — you just won’t notice it. For a single-campus customer the campus will be implicit: iGradePlus will manage it for you, the interface won’t change, and you’ll set up your school the same way you do today. The Campus layer will only become something you actively work with when your organization actually spans more than one location.

Schools — where teaching happens

A School will be the bottom of the organizational hierarchy and the level most of the product operates at. Every School will belong to a Campus, and it will remain where staff, students, and classes come together.

A School will own:

• Its identity — name, code, description, addresses, contact info, web presence
• Its staff and students, connected through membership records so a person can belong to more than one school where that applies
• Its classes, grouped for the school (see Cohorts below)
• Its own profile fields and grading options

Schools will inherit from the campus above them. A school’s academic calendar, grading scales, assignment categories, weights, and drop-score policies will all default to what the campus provides — and a school will be able to override any of them when it needs to differ. That inheritance will run all the way up the chain (School System → Campus → School), so a setting can be configured once at the level it applies to and flow down, rather than being repeated everywhere.

Each school will also have a class model that determines how its students and classes are grouped — and that’s where Cohorts come in.

Cohorts — grouping students who move together (new)

Today, every school in iGradePlus runs on one model: a school year, divided into grading periods, with classes organized for that year. Version 12 will keep that model as the default — but it will no longer be the only option.

Not every program fits a school year. Career and technical programs, bootcamps, adult education, certificate tracks, and other continuous-enrollment programs enroll a group of students who start together, move through a set of classes together, and finish together — on their own schedule, independent of the traditional calendar. In version 12, that group will be a Cohort.

A school will run in one of two models:

• Traditional — the school’s classes are organized around the school year. This will remain the default and cover most K–12 and higher-ed use.
• Cohort-based — the school is organized into multiple Cohorts, each a peer group with its own calendar and its own set of classes.

In a traditional school, this will stay behind the scenes — there will be no cohorts to manage. Cohorts will only become visible when a school actually uses them.

A Cohort will carry:

• Its own identity — name, code, description
• Enrollment rules — a minimum and maximum size, whether late enrollment is allowed, and the window during which students may enroll
• Its own calendar, so a cohort that runs March–November won’t be bound to an August–June year
• Its own set of classes

The key idea: in a cohort-based school, the cohort — not the school year — will be the unit that organizes a group of students and their classes through time. That’s what will let a single iGradePlus school serve rolling-intake programs that never fit the traditional calendar.

A note on terminology for the next post: a Cohort will be the group of students. Its calendar will be a separate thing called a Cohort Timeline. The two are kept distinct on purpose — the group and the schedule it runs on are different concepts. The Timelines post covers the calendar side in detail.

Set once, override where needed

The thread running through the whole hierarchy will be inheritance. Defaults will flow downward, from the account to each school below it:

School System  →  Campus  →  School

Grade scales, assignment categories, weights, and grading policies set at the top will apply everywhere beneath them, unless a lower level deliberately overrides. A grading scale set once at the School System will reach every campus and school below it; a particular campus will be able to adjust it, and a single school inside that campus will be able to fine-tune it further — without anything that didn’t change having to be re-entered.

For a single-school customer this will be invisible. For a district it will be the difference between configuring one policy and configuring it dozens of times.

This cascade — a feature we call Scoped Options — applies to more than grading defaults, and it will get its own post later in this series.

What this will mean for you

• If you run a single school or multiple schools at one location, nothing will change in how you work. Your campus will be implicit, your setup will be the same, and the hierarchy will simply exist in the background.
• If you run multiple locations or a district, the Campus layer will finally let you model your organization as it really is — locations with their own administrators, calendars, and defaults, under one system.
• If you run non-traditional, continuous-enrollment programs, Cohorts will let a single school serve rolling-intake groups on their own schedules, instead of bending them into a school year.

Coming next: Timelines

This post covered how your organization will be structured. The next one covers how time will be structured within it — the new Timelines feature that will replace the legacy School Years model, including the campus academic calendars and cohort timelines mentioned above, configurable grading periods, grading-period locking, and a lifecycle for planning, activating, and archiving a school year.