Roles and permissions in an LMS: what to check beyond the ‘administrator’ and ‘student’ roles
In a small learning portal, two groups may suffice at the outset: a few administrators and everyone else. However, once the LMS is used by multiple departments, tutors or external partners, such a division tends to be too broad. A manager needs their team’s results, a specialist needs to edit a single course, and a support staff member needs help with an account. Everyone requires different levels of authorisation.
The list of role names in the menu therefore tells only part of the story. It is important to ascertain which activities a role permits, what data it has access to, and whether its scope can be restricted. It is precisely in these details that learning management systems can differ significantly.
A role is a set of permissions within a specific scope
Under the title ‘tutor’, one platform may offer only the marking of assignments, whilst another may also allow content editing and access to all participants’ results. Similarly, ‘manager’ may refer to the head of a specific team or the administrator of a large section of the portal. You should therefore always translate these titles into specific operations.
In addition to the activity itself, its scope is important. The Moodle documentation, for example, describes the combination of role and context. The same question is useful when assessing any LMS: is this person permitted to manage the entire system, a single organisational unit, a specific course, or only a selected activity?
An overview of results does not necessarily imply the right to change them
Let us imagine a branch manager who needs to check whether staff have completed a training course. Simply reading the report may be sufficient for them. However, if a predefined role also allows them to change marks or manually confirm completion, they gain broader powers than the organisation intended.
When viewing the demonstration, pay attention to the sections on reading, creating, editing, deleting and exporting. Exporting, in particular, is often overlooked. A limited view on the screen does not guarantee that the same user will not download a broader set of data in a file or via a linked tool. The scope of permissions should be consistent across all methods of access.
Delegated administration is designed to ease the burden on head office
In larger organisations, it is often practical to delegate part of the administration to local administrators. The question is whether the LMS allows such a role to be set up without granting global access. A local administrator may need to create an account and assign a course, but should not be able to change company-wide settings or accounts at other branches.
Also check bulk operations. Sometimes the standard interface is well-restricted, whilst user imports or bulk assignments operate on a broader scale. Ask whether permissions can be managed via groups and how changes to these affect existing accounts.
Inheritance can grant unexpected permissions
A user may simultaneously act as a student, a tutor for a single course and a team leader. The LMS must evaluate the combination of these roles in some way. The interface should clearly show how permissions are aggregated, whether any restrictions apply and how the system resolves any potential conflicts.
Ask to see an overview of the permissions actually granted to a specific individual. If an administrator can only see a few ticked roles and has to guess the resulting access rights, it will be more difficult to identify errors. It is also useful to be able to determine the source of a specific permission: whether it stems from a job role, group membership or individual settings.
A change of role is a good test of the system
A model employee leads one team and subsequently moves to a different role. When the LMS is demonstrated, check whether they lose access to their original team, are granted the correct new scope of responsibilities, and retain their own learning history. Temporary cover should also have a clear start and end date.
It is important to ensure consistency with the source of organisational data. If membership is sourced from an HR system, enquire about any synchronisation delays and how exceptions are handled. Otherwise, manually granted permissions may remain active even after a change that has automatically removed membership of the group.
Also check the administrator’s access to sensitive operations
An administrator should not automatically be able to change everything without a record. Check who is authorised to modify historical results, issue certificates manually, delete attempts or take over another user’s session. Traceability is crucial for these operations.
Ask whether the log includes the person, time and nature of the change, and whether a standard administrator can delete this record. At the same time, ask to be shown who can assign new roles. Otherwise, the restrictions may be well-designed, but a local administrator could grant themselves broader rights.
How to verify permissions before making a selection
Prepare a few common roles from your organisation and, for each one, a short list of permitted and prohibited actions. It is not enough simply to check whether a manager can find their report. Also try opening another team’s data or exporting other data.
- Can a local administrator only work within their own organisational section?
- Is it possible to separate the display of results from changes to them?
- Can the origin and actual scope of permissions be seen?
- Are temporary permissions revoked once a substitution period ends?
The aim is not to create as many roles as possible. It is important that the platform is able to clearly express actual responsibilities. In the LMS Catalogue, role management is a suitable starting point; however, you should always verify the specific access model using your own examples.
