People and roles
Manage Users has two tabs: Users and Roles.
The four roles
Every organisation starts with these:
| Role | What it opens |
|---|---|
| Student | The learning console. Every account holds this |
| Instructor | The instructor console: authoring, grading, classes |
| Manager | The admin console, minus Org Management |
| Admin | Everything, including Org Management and people |
Roles are per organisation. Somebody's role here says nothing about their standing anywhere else on the platform.
A person can hold more than one. An instructor who also administers holds both, and gets both consoles in their mode switcher.
You can create additional roles on the Roles tab. Be aware that the four above are the ones the product's own permission checks recognise — a role you invent called "Teaching Assistant" is a label you can filter and report on, not a new set of permissions.
Inviting one person
Invite users takes a full name, an optional username, an email address, and the roles to grant.
They receive an email with a link to set a password. Until they use it, their account is in an Initial state: it exists, it can be given roles and enrolments, and it cannot yet sign in.
A manager cannot invite an admin or another manager. They can invite students and instructors. That ceiling is enforced by the platform, not just hidden in the console, so there is no way around it by another route.
Inviting many people
The same dialog has a CSV tab.
| Column | Required |
|---|---|
name | Yes |
email | Yes |
username | No |
Column headings are matched loosely, so "Email Address" exported from a spreadsheet works without renaming. Up to 200 rows at a time; the file must be CSV and under 5 MB.
Choose the roles once and they apply to everyone in the file.
After the import you get three lists: invited, failed, and skipped. Rows whose email is already in use are skipped, not duplicated, so re-uploading a file with ten new names added to it does the right thing.
If a lot of rows report "not an email address", the usual cause is a header row being read as data. The dialog names the offending values rather than just counting them, for exactly that reason.
Account states
The four actions in this section — resend, unlock, suspend and reactivate — and removing somebody are administrator actions. A manager can see the controls on the Users tab and will be refused if they use one.
| State | Meaning | What to do |
|---|---|---|
| Initial | Invited, has not set a password | Resend activation if it never arrived |
| Active | Normal | — |
| Locked | Too many failed sign-ins | Unlock |
| Suspended | Membership of this organisation is suspended | Reactivate |
Resend activation
Sends a fresh set-password link and invalidates the old one. Use the newest email if several have gone out.
If the platform cannot send the mail it tells you so rather than reporting success — which matters, because the alternative is an administrator waiting for a delivery that is never coming. In that case, have the person use Forgot password on the sign-in page instead; by that point it will work.
Unlock
Clears a lockout from failed sign-ins. Their password is unchanged and no mail is sent. If they still cannot get in afterwards, the password is the problem, not the lock — send a fresh set-password link.
Suspend
Blocks somebody from signing in to this organisation. It is scoped here and nowhere else: their account survives, and any other organisation they belong to is unaffected.
Their membership, roles, enrolments and progress are all kept. This is reversible at any time and is not a deletion.
The sign-in page tells them their access was suspended and names your organisation's support email if one is set. Without that address the message is a dead end, which is one good reason to set it.
Anything assigned to them stays assigned. Suspension does not ask you to hand their work over first — it assumes they are coming back.
Reactivate
Restores access, with the password they already had and everything exactly as they left it. No email is sent and nothing about their credentials was touched while they were out.
Removing somebody
Removing a person from the organisation removes their membership. Nothing is deleted — no class disappears, no submission is lost.
The quiet failure that this avoids is different: work stays assigned to somebody who is no longer a member, and no screen says so. Six months later nobody knows who is meant to be grading that queue.
So the platform blocks the removal while anything is still assigned to them, and offers a hand over work step first. Each category of responsibility gets one picker, so "everything Sam was doing now belongs to Ada" is one choice rather than eleven. Individual rows can be overridden underneath.
Suspend is usually the right tool, not remove. Remove is for somebody who is genuinely gone; suspend is for anything you might undo.
Managing roles
The Roles tab lists every role in the organisation and what it is for. You can create, edit and delete them, and assign them in bulk from the Users tab.
Bulk role editing is the fastest way to promote a group — the ten people running the new intake, say — without opening ten dialogs.
Who can do what
The short version:
| Action | Admin | Manager | Instructor |
|---|---|---|---|
| Invite students and instructors | Yes | Yes | No |
| Invite admins and managers | Yes | No | No |
| Suspend, unlock, reactivate, remove | Yes | No | No |
| Create and edit roles | Yes | Yes | No |
| Organisation settings and branding | Yes | No | No |
| Cohorts, enrolment, pathways | Yes | Yes | No |
| Grading scales | Yes | Yes, read and set | No |
| Author courses | Yes | Yes | Yes |
| Grade submissions | Yes | Yes | Yes |
The longer version, with the reasoning, is in Roles and permissions.