Checkmark Plagiarism Logo
Checkmark Plagiarism
Menu
Back to Learning
How It Works~7 min read

User Permission Tiers Explained: Who Can See and Do What

A plain-English guide to user permission tiers in school software: what admin, teacher, and student roles can do, why the differences exist, and how to avoid common mistakes.

The Checkmark Plagiarism Team
User Permission Tiers Explained: Who Can See and Do What

A user permission tier is a named bundle of rules that decides what a person can see and do inside a piece of software. In a school plagiarism and AI-detection platform, your tier is the difference between being able to read every report in the district and being able to read only your own. It is not a measure of how important you are. It is a description of your job, translated into software.

If you have ever logged in and wondered why a colleague can see a button you cannot, or why a student account never shows the originality score, the answer is almost always the permission tier. Once you understand how tiers are built and why they exist, the whole system stops feeling arbitrary and starts feeling like a map.

How permission tiers actually work

Under the hood, a permission tier is just a list of yes-or-no answers attached to a role. Can this role create a class? Yes. Can it delete another teacher's submission? No. Can it export the whole school's data? No. Software designers group these answers into roles so that nobody has to set permissions one checkbox at a time for every single user.

Three ideas do most of the work.

The first is the role. A role is a label like "Teacher" or "Administrator" that carries a default set of permissions. When you create a new teacher account, it inherits the teacher role's whole list automatically. This is why onboarding a new staff member takes seconds rather than an afternoon.

The second is scope. Two people can have the exact same role and still see different things, because scope controls how much the role applies to. A teacher's scope is usually their own classes. A department head might have a teacher role with a wider scope that covers a whole subject area. The verb is the same; the territory is different.

The third is inheritance. Higher tiers almost always include everything the tier below them can do, plus more. An administrator can typically do anything a teacher can do, and then some. This stacking keeps the system predictable: you rarely have to wonder whether a higher tier is missing a lower tier's ability.

Put together, your effective access is your role, narrowed or widened by your scope, stacked on top of whatever you inherit. That single sentence explains the vast majority of "why can't I see this" questions.

The common tiers, from least to most access

Most school platforms, including ours, settle on a small number of tiers. The names vary, but the shape is remarkably consistent across products.

Student. The narrowest tier. Students can usually submit their own work, see whatever feedback a teacher chooses to release, and not much else. They generally cannot see their raw originality or AI-likelihood scores unless a teacher turns that on, and they can never see another student's submission. This is deliberate. The student tier is built to protect other students' privacy and to keep the detection score in the teacher's hands, where context lives.

Teacher or instructor. The working tier, where most of the day-to-day happens. Teachers create classes, collect submissions, run reports, read originality and AI-writing results, and leave feedback. Their scope is their own classes. A teacher generally cannot peer into a colleague's class or change account-wide settings. This boundary is not a lack of trust. It keeps each teacher's roster clean and prevents accidental edits to someone else's gradebook.

Department head or team lead. A middle tier that many schools use and many overlook. It is essentially a teacher role with a broader scope: visibility across several classes or an entire subject area, often with the ability to compare results or pull a summary across the team. It usually stops short of billing, user creation, or deleting accounts.

Administrator. The widest tier. Administrators manage users, set policies that apply to everyone, configure integrations, and see reporting across the whole school or district. They can create and remove accounts, decide whether students see their scores by default, and handle the settings that shape every other tier's experience. With that reach comes the most responsibility, which is exactly why this tier is given to the fewest people.

Owner or billing contact. Sometimes folded into the administrator tier, sometimes separate. This is the person tied to the subscription, payment, and contract. Splitting it out means the people managing money are not necessarily the same people managing student data, which is a healthy separation in larger organizations.

What the tiers mean in practice

The tier names are easy. The implications are where schools get tripped up.

Visibility flows downhill, not up. A higher tier can almost always see the work of a lower tier within its scope. A lower tier can almost never see up. An administrator can review a teacher's class reports; a teacher cannot review the administrator's account settings. When you are deciding who needs which tier, ask what they need to see, not just what they need to do. Visibility is the quieter half of permissions and the half that carries the most privacy weight.

Destructive actions cluster at the top. Deleting a class, removing a user, exporting bulk data, changing a school-wide setting: these live in the higher tiers because they are hard to undo and they affect many people at once. This is why handing out administrator access casually is risky. It is not that you distrust the person; it is that a single mistaken click at that tier reaches further than a mistaken click at the teacher tier.

Defaults are decisions. Many platforms ship with a default such as "students do not see their AI score." That default was set by someone at the administrator tier, and it can be changed. If your students are seeing something you did not expect, or not seeing something you wanted them to, the cause is usually a default chosen above the teacher tier, not a bug.

The tier follows the person, not the device. Permissions travel with the login, not the laptop. A teacher who logs in on a student's Chromebook still sees the teacher view. This is obvious once stated, but it matters: shared devices are safe precisely because the tier is tied to the account.

Misconceptions worth clearing up

"More access is better." It is not. The healthiest setup gives each person the least access that still lets them do their job. This is the principle of least privilege, and it is good for everyone. Fewer people with wide access means fewer accidental deletions, a smaller target for compromised passwords, and a clearer story if you ever have to explain who could see student data.

"Admins can read everything, so the tier is just for show." Administrators have broad reach, but well-built platforms log significant actions. The tier is not only a gate; it is also an accountability trail. Who exported the data and when is a question the system can usually answer.

"Changing someone's tier is a big technical job." It rarely is. Tiers exist precisely so that promoting a teacher to department head, or demoting a former administrator, is a quick change to one account rather than a rebuild. If your platform makes role changes painful, that is a product shortcoming, not a law of nature.

"Students are locked out of everything important." The student tier is narrow on purpose, but narrow is not powerless. Students still own their submissions and the feedback released to them. The restriction is about other people's data and raw scores, not about shutting students out of their own learning.

A short checklist for getting tiers right

Start every account at the lowest tier that fits the job, and widen only when there is a concrete need. Review your administrator list once a term and remove anyone who has changed roles or left. Decide your student-facing defaults on purpose rather than inheriting whatever shipped. And when someone asks why they cannot see a button, resist the urge to grant a higher tier on the spot; check the scope first, because the answer is usually there.

Permission tiers are not bureaucracy for its own sake. They are the quiet structure that lets a hundred people share one platform without stepping on each other or on a student's privacy. Get the tiers right, and the rest of the system mostly takes care of itself.

User Permission Tiers Explained: Who Can See and Do What