Manage Your Users

This article focuses on the the basics of creating users, role assignments, enrolments, and user information & status management.


Creating a User

Lambda Learn offers several options to add users. When user accounts are created on a site, the process is called authentication and when users join a course, the process is called enrolment.

Typically only the administrator is allowed to add (authenticate) users to a site. Course creators or teachers are then able to add students, by way of enrolment, to their course. They do not have permission to add users to the site, unless they are given that capability by the administrator. 

add-user Adding a New User: Manual Authentication

 As an administrator,  you can add users one at a time in the Add a new user page: Site administration > Users > Accounts > Add a new user

The required user profile fields are: Username, First name, Surname and Email address.  The user password may be manually entered, or you can let the system "Generate password and notify user" via email.

There is also a "Force password change" setting that prompts the user the user to change their password upon login. Of course, the user's password. It is subject to the password policy you have set in Settings > Site administration > Security > Site policies.

Administrators can create new user profile categories and fields in Administration > Site administration > Users > Accounts > User profile fieldsProfile fields may be a menu of choices, text area, text input or a checkbox and may be required or not.

The process of adding one user manually is called Manual authentication. This setting is enabled by default. You can lock certain fields, set password expiry dates and other configure other settings from Site administration > Plugins > Authentication > Manual accounts.

Back to TOPICS

batch user upload  Bulk User Management via CSV

If you need to deal with many users at a time, the Upload users feature will allow for quicker management: Site administration > Users > Accounts > Add a new user.

The upload users file is typically referred to as a CSV (comma separated values) text file. It has fields separated by a comma (or other delimiter) ONLY - no spaces.

    • You can use a spread sheet program, such as MS Excel or Google Sheets, to create the file with the required columns and fields. Then save the file as "CSV". These files can then be opened with a simple text editor (eg, Notepad++) for verification.
    • The first line of the *.csv file must contain at least the required field names: username,firstname,lastname,email
    • The subsequent lines (user records) contain information about each user. For example: slumbergh,Sam,Lumbergh,
simple CSV


The batch user upload method also allows you to accomplish other bulk user related actions such as:

Bulk user actions enabled using CSV moodle totara icon
Course enrolment and un-enrolment. orange check mark green check mark
User role assignments. orange check mark green check mark
Update the information of existing users. orange check mark green check mark
Suspend or delete users. orange check mark green check mark

Dynamically provide learners access to targeted learning content, based on the latest HR information.

For more information on automating user enrolment based on organization and job position, see articles on HR Import and Job Assignments Using Hierarchies.

green check mark


  1. The "password" field is optional if the 'New user password' setting on the upload screen is set to "Create password if needed and send via email". However, if you selected the "Field required in file" setting,  then you must provide the required password that meets the requirements your site's Password policy.
  2. To force password change for a particular user, set the password field to changeme. If omitted, a password will be generated for each user (during the next Cron job) and welcome e-mails sent out. The text for the welcome e-mail is in the language settings in Site administration > Language > Language customisation with a String identifier of 'newusernewpasswordtext'.
  3. It is usually not necessary to upload users in bulk with Upload users. To keep maintenance work down you should first explore forms of authentication that do not require manual maintenance.  See ADDING USERS FROM OTHER SYSTEMS via SSO below, or other  authentication  methods  available  in Lambda  Learn  in

    How Users Log In: Site Access and Authentication.


For detailed steps, see Uploading Users With a CSV Text File under User Management.

Back to TOPICS

self-registration  Email Based Self-Registration 

In the event where you want your users to create their own, the Email-based self-registration provides that workflow. The default required registration fields are Username, Password, First nameSurname, and Email

Screen Shot 2020-07-10 at 3.59.12 PM



By default, the Self-Registration by email feature is disabled because of the possibility of spammers accessing your site.

Back to TOPICS

users from network  Adding Users From Other Systems via Single Sign-On (SSO)

It is possible for users to connect to Lambda Learn  via single sign on (SSO) from other systems. The settings for these may be found in Site administration > Plugins >Authentication > Manage authentication and include:

    • CAS server (SSO) - account details are located on an external CAS server.
    • External database - account details are located on an external database.
    • LDAP server - account details are located on an external LDAP server.
    • Shibboleth - account details are located on an external Shibboleth server.
    • Web services authentication.

Back to TOPICS

Assigning Roles and Permissions

To fully understand what users can do in Lambda Learn, we need to define 4 key terms related users and abilities in the system:

  • Capability: A configurable aspect of program behaviour. LAMBDA LEARN (Moodle) has 100s of capabilities. Each capability has a computer friendly name like mod/forum:rate and a human-friendly name like "Rate posts."
  • Permission: Permissions are paired with each capability. There are four possible permission values: AllowPreventProhibit and Not set/Inherit. (It is called Not-set when defining roles, and Inherit when overriding permissions.)
  • Role: A named set of permissions that are associated with each capability. For example. the "Teacher" and "Student" roles come with the standard LAMBDA LEARN (Moodle) install.
  • Context: A functional area or space in LAMBDA LEARN (Moodle) where roles can be assigned. Contexts have a hierarchy. There is a hierarchy of contexts which helps locate and define a specific space. Generally speaking, this hierarchy allows a lower context to receive information from a higher context. For example, an LMS site is one context and that contains a number of other contexts within it. A category is a context, within a site context, that contains courses and sub-categories that have a context of their own.  Courses have activities or resource.

The combination of roles and context define a specific user's ability to do something on any page.  A context might contain other contexts and Roles can be assigned to each context. Apart from the manager and course creator, users do not normally have a site-wide (or system) role. 

Because of the way LAMBDA LEARN works, assigning roles is done for a particular context. Site and course are examples of two different contexts.

role Roles and Contexts

A context is combined with role permissions to define a User's capabilities on any page in LAMBDA LEARN. Typically contexts have their own organization structure which allow a User's role to be passed along to the context "below" but not to the one above it. 

The image below shows a few contexts and their relationships. The "System" or LAMBDA LEARN site is the overall context. The User is defined initially in this context. The System context has 2 contexts under it, with other context under them in which roles can be assigned: 

  • The Front page context has an activity module context and a block context within it.
  • The course Category context has a Course context within it. The course context has an activity module context and a block context within it.

Context within context (1)

It is possible to assign a user different permissions based upon a specific context. For example, a user might be given the role of student for a course but be given a teacher's role in the context of one specific forum. Or a user can be a teacher of one course and a student in another course.

Many LAMBDA LEARN contexts have a place to grant exceptions to specific roles within that context. Those exceptions are non-transferable from that context. That is, an exception can be applied to the next context downward, but cannot applied sideways nor upward from that context. 

Types of Site Contexts


To assign a role in the system context, go to Site administration > Users > Permissions > 'Assign system roles'.

Any roles assigned here apply across the whole site. It makes sense therefore that only roles that need this functionality can be assigned here. The Manager role and Course creator role are examples of two such roles. Assigning a teacher or student here would result in their being able to teach/study in every single course on the site, which is not usually desirable.

Category (Course)

Users may be enrolled in a course category to save enrolling them in each individual course in that category.


A course can have many contexts in its space. These might include lesson, assignment, forum and quiz modules and blocks.


An example of this is assigning a student the teacher role locally in an individual activity like a forum so they can moderate their classmates' posts while still retaining the student role in the rest of the course.


You may wish to assign roles to a block if, for instance you want specific people to see the block but for it to be hidden from others.


The user context is used for roles such as mentor, team leader or the Parent role. The role to be assigned must have 'User' ticked as the context type where it is to be assigned.

To assign a user the role of mentor in the context of their mentee, click the mentee's profile, then Preferences then 'Assign roles relative to this user'.

If a mentor has lots of mentees, the role of mentor can be assigned to them all in one go as follows:

  1. Put all mentees in a cohort
  2. Go to Site administration > Users > Permissions > Assign user roles to cohort.

Standard Roles

By assigning a role to a user in a certain context, you grant them the permissions contained in that role for the current context and all lower contexts. So when you create a new role or tweak a pre-existing role via Administration > Site Administration > Users > Permissions > Define roles you are asked in which context(s) you want the role to be assigned.

    • Site administrator. Site administrators have permissions to do anything. It is recommended that you don't have lots of admins on your site. Good practice is to only have one or two, then give everybody else roles such as Manager, with only the permissions that they require.
    • Manager. The default Manager role enables users assigned the role to access courses and modify them, as well as perform certain administrative level tasks related to courses, users, grade settings, etc. - a lesser administrator role
    • Course creator. A user assigned the role of course creator can (as the name suggests!) create a course. If the setting "Creators' role in new courses" (creatornewroleid) in Site administration / Users / Permissions / User policies is left as default (teacher), then the course creator is enrolled as a teacher in the course they have just created and can then edit the course settings and enrol other users. A course creator can also view hidden courses.
    • Teacher. Teachers can do almost anything within a course, including adding or changing the activities and grading students. By default, teachers can also assign a Non-editing teacher role and a Student role to other users. 
    • Non-editing teacher.  A non-editing teacher is able within a course to view and grade students' work, but may not alter or delete any of the activities or resources. This role might typically be given to a classroom assistant for example. In courses where groups are used, the non-editing teacher may well be responsible for one particular group and will not need access to other groups.
    • Student. A user with the Student role in can participate in course activities and view resources but not alter them or see the class gradebook. They can see their own grades if the teacher has allowed this.  Once learners have enrolled or been enrolled into at least one course they then only see their own courses in the My Courses section of the navigation block or via their dashboard. 
    • Guest. Lambda Learn has a built-in "Guest account". Visitors can log in as guests using the "Login as a guest" button on the login screen and enter any courses which allow guest access. In addition, logged-in users can enter any courses which allow guest access without being required to enrol. Guests ALWAYS have "read-only" access - meaning they can't leave any posts or otherwise mess up the course for real students.
    • Authenticated user. When a user logs in, they are automatically assigned the role of authenticated user. A user will have additional roles as well as the authenticated user role according to where they are in Lambda Learn , such as student in a course. By default, authenticated users have permission to edit their own profile, send messages, blog and do other things outside of courses.
    • Authenticated user on the front page role - a logged in user role for the front page only

Roles can be inherited. For example if a user is assigned a Teacher role in a specific course category, then the user will have this role in ALL courses within the category. 


When assigning a user another role in a context, use the Override feature in a specific context for exceptions.

Roles will only work if the role assignment is made in the correct context. Some examples: a Teacher role should be assigned to a user in the course or course category context, a Forum moderator for a particular forum should be assigned in that specific forum.

Back to TOPICS

administrator  Assigning System Roles

 Lambda Learn allows for the assignment of additional site administrator. But as site administrators have permissions to do anything, It is recommended that you don't have lots of admins on your site. Good practice is to only have one or two, then give everybody else roles such as Manager, with only the permissions that they require.

Users may be assigned the role of site administrator by another site administrator in Site administration > Users > Permissions > Site administrators, but the role itself cannot be edited (or deleted!).

Site administrators are assigned via a special page: Administration > Site Administration > Users > Permissions > Site Administrators.  Select the name from the right and move it over to the left. 

Screen Shot 2020-07-13 at 4.04.57 PM



The primary administrator (created when the site was created) cannot be removed from the site administrator role.

Back to TOPICS


Assigning  System Roles by CSV

Where certain custom roles are applied in the system context, it is possible to upload users to that role in bulk by adding the field sysrole1 (etc) to a CSV file.

When previewed, there is a column indicating their system role:

Once uploaded, the users are present on the 'Assign system roles' screen:

Back to TOPICS



How Do I Delete a User?

When managing users in a system, it is important to know the types of user status available in the system and how they differ.


Suspending a user means that their account still exists, along with all the data they've generated (grades, posts, ratings, messages, etc.).

When a user is suspended, they can no longer log in, but an administrator can un-suspend a user in the event that a user requires access again.


Deleting a user removes the user's account and any data associated with the account (grades, posts, ratings, messages, etc.).

This is typically not recommended, in the event the user requests their information at a later date - instead, a suspension is the better choice.


An active user in the system is when a user has logged in at least once. You may have seen the term "Active" in the course context, but this pertains to them not being suspended, rather than having actually accessed the course.
Back to TOPICS

minus  Deleting a User Account

Deleting a user account is a straight forward and easy process, but before you do so, you need to consider your organization's policy on retaining user data and their record of learning, such as: courses taken, completion and grade records, etc. 

Deleting a user account deletes ALL their information from the system.

An account can be deleted by clicking the delete icon opposite the user's name.

When an account is deleted, the email address + timestamp for when the account was deleted is stored as the username.

If an account is deleted by mistake, it can be partially restored by resetting the deleted flag to zero in the database and resetting the username and email address.  Grades may be recovered by re-enrolling the user into their courses and ticking the 'Recover user's old grades if possible' checkbox in the enrolment options. 

Back to TOPICS

suspend Suspending a User Account

Suspending a user account does not delete any of their data. Users are just prevented from logging into and blocks any massaging from the system.  The process of suspending a user is as follows:

    1. Click the edit icon opposite the user's name.
    2. On the user profile edit page tick the 'Suspended account' checkbox.
    3. Scroll to the bottom of the page and click the 'Update profile' button.

Delete  vs. Suspend  

  • Deleting a user account results in their data being permanently deleted and cannot be recovered. Deleted users loose their profile details: user references, enrolments, email, username, all preferences, enrolments, group and cohort membership,  and grades. The only exception is data related to other users in forum posts or wiki entries, these are not deleted because of dependencies related to other users.
  • Suspending a user is a temporary prevention  of login. All data related to that user remains unchanged.  Suspended users are no longer able to access any of their courses on Lambda Learn but their data is preserved, so it is possible for them to return to their course at a later time.

To retain any user data, you should suspend , rather than delete, the user's account.


disable account Disabling a User Account: "No login"

In the event you want to temporarily block a particular user from accessing your LMS, an administrator may "turn off" or disable a user's account by selecting "No Login" in the "Choose an authentication method setting" in that user's profile. This means the user will not be able to log into the site, but their account is otherwise unchanged.

When this setting is used, the email associated with this account may not be used to create another account.

no login

Note: Users will not receive any error or other message when they try to log in but it simply will not allow them in. So it will appear as though their password was incorrect and they may attempt to reset it. Consider this issue when using No login, in order to reduce support issues.

The No login setting is in effect for the duration that the account is assigned to this authentication type.

Back to TOPICS


Messaging a User

Unless disabled by the administrator (in Site administration > Messaging > Messaging settings), teachers, students and other users may send and receive private messages via Lambda Learn (Moodle). This is in addition to receiving notifications about assignments, forum discussions etc.


message option Enabling / Disabling Site-Wide Messaging

The personal messaging system in Moodle is enabled by default. It may be disabled by a site administrator from Site administration > Messaging > Messaging settings.

From 'Messaging settings', the administrator can "Allow site-wide messaging" (disabled by default). If this setting is enabled, users on the site can view all other users when selecting someone to message and can choose to accept messages from anyone on the site.


user message options  Messaging Settings for All Users

  • Users can decide how they want to be notified of new messages and event notifications by editing their messaging preferences page, which they can access either from the Preferences link in the user menu or from the gear icon in the messaging/notifications menus. 
  • Which options users see depend on what has been enabled by the administrator.  Because users might have many different messaging options, they are ordered into different components - for example, activities, system, enrolments etc. Example notifications preferences screen - student view
    Back to TOPICS


    notifications  Notifications

    Notifications alert teachers, students and other users about events in the LMS such as new forum posts, assignments needing grading or badges awarded.

    • Along with a visible alert to new events in the notifications menu, users can configure how they are notified of new events from their notification preferences page accessed from the user menu or from the gear icon in the notifications menu.
    • Notifications may be sent via the web (when logged in the LMS), email and mobile (for Mobile-enabled sites).
    • Web offline options are for setting whether a user is notified when they next log in to the LMS.


    More Resources


    Our eLearning industry experts have put together other resources to offer you more advice, best-practices, and how-to guides: