Skip to main content
All manual pages

People and access

Roles, staff access and personas

Create a role, grant permissions per resource and action, add staff users and assign their roles, and understand how personas switch what a user can do.

Last updated August 15, 2026

What you'll do

Decide who at your centre can do what. Build roles out of per-resource, per-action permissions, create staff accounts, assign roles to them, and understand the persona switcher that appears for anyone holding more than one role.

Before you start

  • A list of your staff and, for each, the shortest description of their job: takes money at the front desk, enters marks, runs the centre.
  • The Roles and Users permissions. Manage Permissions additionally needs the Roles manage permission.
  • Ten minutes of thinking before you start clicking. It is much easier to build a role once from the job description than to discover six months later that the desk clerk can delete students.

Everything on this page lives under Access Control in the sidebar — Users and Roles. (The Configurations group next to it is unrelated: it holds School/College, Class Levels, the grading scale and Schedules.)

How permissions work

CampusQ does not have fixed job titles with fixed powers. Access is permission-based: a permission is one resource plus one action — for example Payments + Create, or Students + Export. A role is a bundle of those permissions, and a user holds one or more roles.

The actions you will actually meet, and their labels on screen:

LabelMeaning
ViewRead the list and the records.
CreateAdd a new record.
EditChange an existing record.
DeleteRemove a record.
ExportGet data out.
ImportBulk upload. Students only.
ApproveApprove a pending item. Payments and Results only.
PublishMake content live. Exams and Course Content only.
ManageFull control of the resource.

Actions are not uniform across resources, and this trips people up. Some resources offer seven actions; Enrollments and Schedules offer only Manage, with no separate View; Class Levels and Question Bank offer View/Create/Edit/Delete but no Manage; Subscriptions offers only View and Create. Do not plan a role on the assumption that every resource has a View toggle — look at what is actually there.

Start from the roles you already have

Before you build anything, look at what is already there. Six roles ship with the system, and two of them are the front-office roles most centres would otherwise build by hand:

RoleWhat it is for
AccountantHandles money: records payments and expenses, works fee invoices, and reads the finance reports. Cannot delete financial records.
CoordinatorRuns the academic desk: students, enrolments, attendance, exams and schedules. Deliberately has no access to money.
Super AdminEverything inside your centre.
Teacher, StudentThe two portal personas.
Platform AdminNot a role for your centre — it belongs to the people who run the platform.

The two new ones are a deliberate separation of duties, which is the thing an ISO 27001 auditor will ask about:

  • Accountant can read, create and update Payments, Expenses, Finances and Fee Invoices, and read Reports. It cannot delete anything at all — not one Delete switch on any resource. That is not an oversight. Financial corrections in CampusQ are reversals and voids, which leave a trail; a delete would not. Fee Invoices has no delete anywhere in the product, for the same reason.
  • Coordinator can read, create and update Students, Attendance, Exams, Enrollments, Schedules and Teacher Attendance; read and update Batches; read and create Announcements. It has no money access whatsoever — no Payments, no Finances, no Expenses, no Fee Invoices, no Reports. It also cannot create a batch, only edit one, because creating a batch sets a fee and a billing cycle, which is a money decision.

The principle underneath both: whoever enrols a student should not also be the person who records the money for that enrolment. If you assign these two roles as they ship, you get that separation for free.

Note one consequence that looks like a bug and is not: collecting against a fee invoice needs Payments create, not Fee Invoices update. So a Coordinator can see a student and still not take their money, exactly as intended.

Seeded roles cannot be edited in the app — see the Type column below. If your centre needs something different, copy the shape into a custom role. That leaves the deviation visible and auditable rather than hidden inside a modified system role.

Create a role

Go to Roles (Manage roles and their permissions) and press Create Role.

Give it a Role Name and a Description, then press Create. Write the description as the job, not the permission list — Front desk: takes payments and marks attendance, cannot change fees — because that is what tells the next person whether the permissions are still right.

The Type column separates System roles from Custom roles. System roles are provided and cannot be edited; Edit and Manage Permissions are hidden on them. View Details always works, and reading a system role is the fastest way to see how a sensible bundle is put together before you build your own.

Grant permissions

From the role's row menu choose Manage Permissions. The screen is headed Manage PermissionsConfigure permissions for this role — with the role's name beside Role:.

The layout is one card per resource, each holding a row of switches, one per action available for that resource. Each card shows a granted/total count, and the header shows the overall number granted.

To work through it:

  1. Use the search box (Search resources or permissions...) to jump to a resource rather than scrolling. There are enough cards that scrolling is a waste of time, and the list grows as the product does.
  2. Turn on the individual actions you want. Cards are listed alphabetically by resource name.
  3. Grant All and Revoke All on a card set every action for that resource at once. Grant All is a blunt instrument — it includes Delete — so prefer the individual switches for anything involving students, payments or enrollments.
  4. Reset at the bottom discards your unsaved changes.
  5. Press Save Permissions.

Guidance worth following

  • Start from nothing and add. Do not start from Grant All and remove; you will miss something.
  • View before Edit, Edit before Delete. Almost nobody needs Delete. Deleting a student, an enrollment or a payment in CampusQ is permanent, and a deleted enrollment's roll number is never re-issued.
  • Never grant Course Content to a teacher role. Teachers reach course content through their own scoped portal screen. The tenant-wide Course Content permissions would let them author or change any course in your centre.
  • Withhold Enrollments: Manage from front-desk staff unless they genuinely need to change fees. It is the permission behind fee adjustment.
  • Roles: Manage is the keys to the building. Anyone who holds it can grant themselves anything. Keep it with the account owner.
  • Money is three separate resources, and the split is useful. Finances governs the money accounts and categories — the configuration. Expenses governs the cash-book entries themselves. Payments governs receipts, teacher payouts, salary structures and payroll. Somebody who records daily expenses does not need Finances; somebody who takes fees does not need either.
  • Fee Invoices has no Delete anywhere, so there is no delete switch to withhold. Corrections are cancel, waive and adjust, all reasoned and all recorded.
  • Reports is one permission covering every report. Grant it and you have granted the finance and payroll reports too. There is no way to give somebody the attendance reports alone.
  • Some resources never appear even though you may have heard of them — Assignments, Materials and several others have no grantable permissions today. If a resource is not in the editor, it cannot be delegated, and only a super-user reaches it.

An audit-trail limitation to plan around

Saving replaces a role's whole permission set at once, and CampusQ keeps no visible history of the change. There is no diff before you save, no reason field, no confirmation step, and no change log on the role afterwards. If your centre needs access-review evidence — an ISO 27001 audit will ask for it — keep your own record: export or screenshot the permission set after each change, with the date and who approved it. Doing that at the moment of the change costs a minute; reconstructing it later is impossible.

Add a staff user

Go to Users (Manage system users and their access) and press Create User.

FieldNotes
Full NameRequired.
UsernameRequired. What they type to sign in.
PasswordRequired, create only. Masked, with a strength indicator.
EmailOptional and unused for delivery.
Phone NumberRequired. Their login SMS goes here.
RolesMulti-select, create only. Assign it now if you can.
StatusEdit only. How you deactivate somebody.

Press Create. If Credential SMS is on, the login URL, username and the password you typed are texted to them straight away, and you are given no confirmation either way. See SMS and notifications.

Assigning roles afterwards

The Roles multi-select disappears in edit mode. To change somebody's roles later, use Assign Roles on their row menu, pick the roles and press Assign.

This replaces their whole role set, with no confirmation prompt and no preview of the resulting permissions. Note what they hold before you change it.

Resetting a password

Reset Password on the row menu: New Password and Confirm Password, then Update.

A reset does not send an SMS. The credential SMS fires only when an account is created. After a reset you must get the new password to the person yourself — in person, or by a channel you are comfortable with. Nothing in the interface says so, which is exactly why it catches people out.

Deactivating somebody who leaves

There is no delete action on Users. Edit the user and set Status to inactive. Do this the day somebody leaves — an active account with a known password is the most common way a former employee keeps access.

The User Details page also shows Last Login, Failed Logins, Account Lock and Locked Until, which is where you look if somebody reports being locked out or you are checking for suspicious sign-in attempts.

Personas

A persona is the hat a user is wearing: Administrator, Teacher, Student or Guest. A person can hold more than one — a teacher who is also your academic coordinator, or an administrator whose child studies at the centre.

The switcher is in the top bar, on the right, immediately left of the language switcher. It shows the current persona's icon and name; the dropdown is headed Switch Persona, with a tick beside the active one. On a phone only the icon shows.

It only appears if the user holds more than one persona. A single-persona user never sees it, which is normal.

Switching does four things: updates your persona on the server, re-issues your sign-in with the new persona's permissions, rebuilds the whole menu, and redirects you to that persona's home — Administrator to the dashboard, Teacher to the teacher portal, Student to the student portal.

Two important points:

  • You are not in two personas at once. Switching replaces your permissions. An administrator who switches to Teacher loses their admin menu and admin permissions until they switch back, and there is no banner reminding them which persona they are in beyond the switcher itself. If an admin says a screen has vanished, this is the first thing to check.
  • The choice is remembered on the server, not in the browser. Sign out, change device, sign in on somebody else's laptop — you come back in the persona you last chose.

Notes

  • Roles are bundles, users hold roles. Change the role and everybody holding it changes with it. That is usually what you want; occasionally it is a nasty surprise, so check the Users list's Roles column before editing a role.
  • Personas are not roles. A persona decides which portal and menu you get; a role decides what you may do within it.
  • The essentials-only menu is not access control. Hiding a menu item hides nothing from anyone who knows the URL. Restricting access means removing the permission. See Getting started.
  • English-only strings. The Users and Roles page headings; the create/edit dialog titles (Create Users, Update Roles) and their Create / Update buttons; the Type column's System / Custom; every resource name and every action name in the permission editor; and every persona name in the switcher. So in Bengali the panel heading reads অনুমতিসমূহ while the cards beneath it read Students, Payments, View, Edit. Say so when you train Bengali-speaking staff.
  • The same administrator is labelled two waysAdministrator in the switcher, Admin on the profile badge. Same thing.

Troubleshooting

A staff member gets "You do not have permission to view this data." Their role lacks the View permission for that resource — or, for Enrollments and Schedules, the Manage permission, since those two have no separate View.

I granted a permission and it has not taken effect. Permissions are carried in the user's signed-in session. Have them sign out and back in, or switch persona, which re-issues it.

Edit and Manage Permissions are missing on a role. It is a System role. Create a custom role instead — open the system role's View Details first to copy its shape.

A resource I need is not in the permission editor. It has no grantable permissions in the product today, so it cannot be delegated.

Somebody can see fees and I do not want them to. Look at their Payments, Enrollments, Finances and Reports permissions. Remember roles are shared: check who else holds the same role.

An administrator says half their menu has disappeared. Check the persona switcher in the top bar. They are probably in the Teacher or Student persona. Switch back to Administrator.

A user is locked out. Open View Details for Account Lock, Locked Until and Failed Logins, then reset their password if needed — and remember to tell them the new one, because no SMS goes out on a reset.