Managing External Users Within the LMS
The use of the LMS system as a standalone instance looks like it’s coming to an end. Almost every implementation of the LMS today includes using BizX – maybe not as the source system of employee data, but at least holding enough to support the learning module. Clients so far have been welcome to this, as having BizX unlocks the potential of using other modules down the road. However, this brings up an interesting question – what do we do about external employees and contractors who need access to the LMS?
Do we begin storing external data in BizX? While this cause issues if we are using EC? What about SSO? Can we utilize the “sites” feature in LMS for them? These are just some of the questions clients face when exploring giving LMS access to externals.
In this blog we are going to explore three ways in which clients can bring external users into their LMS.
Using LMS Sites with User Self-Registration
LMS Sites are a standard feature by which users external from the company and not in BizX can directly access the LMS. Users are given a url to access with their username and password. Once logged in, their experience is very similar to that of an internal employee – they have a learning homepage from which they can see their To-do list, explore the catalog, see their learning history, ect (all dependent on the permissions in the user role you assign them).
External user domain, catalogs, and roles can be set up to manage the users. Using separate catalogs would be important in this case – you can set the prices for your courses in the external catalog different from what you would price it for internal employees. Also – it is important to note that approval processes do no work with sites – if you have a course with an approval process on it, external users using sites would be able to bypass it. If you want control over external users taking courses, you may want to limit their ability to register for courses on their user role and have admins manage their learning.
The most common method of external site account creation is via user-made account. Externals would go to the external site link and add basic information about themselves and create (or be assigned) a username and password. Account creation restrictions (approval process, registration code) available to restrict access to site. You do not need a user feed to create or maintain data.
One important drawback of using sites with self-made accounts is that the user does not enter manager data. Even though they are external users, their record could still maintain a manager and that manager can assign them learning, register them for courses, run reports, ect. However, in this case, the manager filed would need to be maintained by an admin if you want to unlock these features (or else you would need to use the user feed – see next section).
All set up for sites is managed under system admin>application admin>sites.
The admin setting up the site would define what fields a user needs to enter.
Admins can maintain registration codes to give to contractors to be able to self-create an account. Alternatively, new accounts can be directed to an admin for approval.
The admins would send out the link to the site. The new users would then hit the registration link and fill in their basic information.
Once complete, the new user would be added to the domain/role/org identified in the site’s settings.
Using LMS Sites with a User Feed
Clients often have a different source system for external user data than for their internal employees. If this is the case, clients can consider having a user feed create external user data in the LMS while using sites.
Clients would set up a standard user feed into the LMS using the User Connector (not the SF user connector). To indicate that this is an external user who will be using sites, the “Shopping Cart Account Type” needs to be set to EXTERNAL. This way the system knows that the user should be coming in through sites.
This has a major benefit of having both standardized and more complete data coming into the system, rather than self-entered. Manager information could come through the feed so that clients can unlock those manager capabilities for managing externals. However, note that approval processes are still not able to be used with external sites, even if externals have a manager on their record.
Externals would be notified via e-mail of their account password – however there is no syntax available for username. Clients would either need SF’s support to add the syntax or standardize contractor username to communicate in the notification(such as first initial &last name).The users would access the login link with username and password, reset their password, and add account recovery questions.
From there, the new users would be taken to their learning homepage.
Maintain Contractor Data in BizX
A third option is to begin storing your contractor user data within BizX. BizX would not necessarily be the source system for your external data, but would contain records that would be passed onto the LMS. Sites would not be used in this case – the externals would access similarly to employees – by first logging into BixZ and then accessing the LMS module. If the client is using EC, you can create shell records that would not have an impact on employee records.
External user data would be initially imported via a user import into BizX. External users would receive the welcome email and set up their initial login. Roles and permissions could be used to limit their access to only learning. If you are using SSO, you can indicate in the user feed that these users would bypass SSO with a direct login.You can still use domains, roles, and catalogs to restrict the external users in the system. Also, this is the way you can unlock using manager approval for courses, since we would no longer be using sites.