Roles and permissions is where access is defined. Giving a member of staff a role is what makes a menu appear in their sidebar; a menu that does not appear is a screen they cannot open, however much they may need it. There are two screens here — Roles and Permissions — and only a super administrator sees either.

You will not normally create roles. Ekati ships with six, each one matching a job a school actually has, and each one already carrying the right set of permissions. What you do is give people those roles and read what they can reach. A head of school asking why the bursar cannot open Academics is answered here rather than by argument.

The practical value is quiet. Nobody has to be told what they may not do, because the screen they were not cleared for is not in front of them. A secretary who should not see wages is not resisting a rule — the Finance menu simply is not there.

Access is decided by the sidebar

A role does not raise anybody above anybody else. It decides which entries appear in a person’s sidebar, and therefore which screens they can reach. The bursar is not junior to the secretary; the bursar simply has a different set of doors. Nobody here can see another person’s doors from their own screen, so there is no accidental discovery of a salary by clicking further than expected.

The six roles are the six jobs a school has

Read the Roles table and each row carries a Name, a Display Name, a Type, a Guard, a description and the number of permissions attached. The Type tells you where a role belongs: system roles run the platform, institution roles run a school, and student roles run a learner’s own portal. Ekati’s six working roles are all institution or system roles — they are the ones a school actually assigns on Monday morning.

A person can hold two roles and be entirely normal

The commonest arrangement in a small school is one person who is both secretary and bursar, or a teacher who also coordinates a level. That is not a workaround: it is the shape of a small school. Give the person both roles and they see both menus, with no duplication and no extra configuration.

Read the permissions count before you grant anything

The Permissions column on a role tells you how many abilities are attached. A newly created role with few permissions opens almost nothing — which is the correct starting point for a job you have not yet mapped, rather than a role you should grant and hope is right.

The school owner’s administrator

Almost everything, and scoped to one school. Users, staff, the academic structure, admissions, messaging, finance, assessment and scheduling, the school’s website, its settings, and its own subscription. The one thing this role does not reach is Ekati itself: no institution list, no applications queue, no role editing.

The secretary

The front office. Admission forms, applications and enrolments; the academic structure — years, classes, courses, booklists, library; messaging; assessment templates, grading scales and class broadsheets; timetables; staff records; the report slip designer. This role takes fees at the counter, which is why it does not carry the Finance menu — the figures themselves live with the bursar.

The bursar

The money and the people who cost money. Fee structures, payments, reconciliation, payouts, payroll, expenditures and orders; enrolments, because a bursar is the person who reads a fee clearance; staff records and the payroll detail on them; configurations, for the payout numbers; and verification of logbook entries.

Teachers and lecturers

The teaching screens and almost nothing else. Their own courses, grade entry, the assignments they set and the submissions they grade, their own timetable, their own execution logbook, and the report slips their learners receive. Neither role sees fees, staff contracts, enrolments or messaging — which is why a school with a part-time teacher can employ one without that teacher ever meeting the payroll.

Four screens belong to the super administrator alone

Institutions, Applications, Roles and Permissions are the platform’s own screens, and no school role reaches any of them. The same is true of subscriptions for the schools you do not own, the platform dashboard, and the field and tag vocabularies.

A role is a named bundle of permissions

A permission is one single ability — view fees, edit courses, confirm a logbook entry. A role is a name attached to a set of them. The Permissions screen lists the abilities themselves, each with a name, a description and the number of roles holding it; the Roles screen lists the bundles. The bridge is the Permissions column on a role.

Reach for a role, not a permission

In a school, almost every access decision is a role decision: this person is the bursar, this person is the secretary. Reach for permissions only when you are describing a role that does not exist yet — and then describe the job, not the capability. “Can see fees but cannot mark payments” is a role; a single permission on somebody’s account is a decision nobody will remember in six months.

Both screens are system administration

Roles and Permissions belong to the platform rather than to any school. A school’s institution administrator cannot open either, which means the school cannot accidentally grant itself the keys to the platform. When a school genuinely needs a different set of access — a school where the head of school also takes the fees, for instance — the honest route is a new role defined centrally, not a workaround at the school.

Removing a role takes effect straight away

Change somebody’s roles and the next page they open reflects it. Their open screen may need reloading before the menus change, but there is no cached state to clear, and no session to end. Revoking the bursar role from a leaver on their last day is therefore a complete answer.