LMS Governance Policies For Data And Integration

LMS governance policies for data and integration

The master data within a learning management system primarily comprises user, organization, location, role, course, and transcript data. These components are the foundation of the system, and it is of utmost importance to manage them effectively and efficiently.

Integration for an LMS consists of inbound and outbound integration. Inbound integration comes from the organization's human resources data, where we receive the basic fundamentals of the organization (i.e. user data, location, role, and organization). Outgoing integration is primarily about sending user transcription data along with certain course elements to different systems within an organization. There could be system integrations in which we would be receiving and sending data (that is, two-way communication).

The typical challenges facing master data and integration are listed below.

  • Batch jobs leading to delays in receiving information; displays different states of data on different systems. In addition, most of the time, the interested party of the company is asked to wait a day or two for the information to be updated.
  • Legacy systems generally update their certification or course status as part of a monthly cycle, leading users to wait to see their updated transcription status.
  • A delay in obtaining the correct data leads to incorrect or inconsistent reporting, which subsequently delays business decisions.
  • Multiple, non-unique, and convoluted data sources increase the burden of managing systems effectively; Traditionally, a lot of coding is done with respect to business rules within system integrations.

The cost of maintaining an LMS has typically been high due to all of the above reasons and more. The benefits of having an effective governance policy for managing and integrating master data begins with clean data. It provides guidance and structure and limits to operate, communicate and make decisions. It helps create a structured, streamlined, and standardized process for faster responses and reduced delivery times with better quality assurance and better decision making. Create a story of why things were done a certain way and how it should be done for an intuitive and easy-to-use learning management system.

Before delving into governance policies, let's understand the different sub-elements within core data and fundamental integrations.

Foundational / Integration Data ElementDetails
User dataUser data consists of different information:

  • Profile info of the user: name, surname, unique identification of the organization, email, contact number, manager or not
  • Organization information User ID: Organization ID, Organization Name, Business Unit, Business Line, Least Cost Center ID
  • Role information Username: role title, role code, role family, management level, role category, work shift, and role classification (if applicable)
  • Manager information: immediate manager, post-level managers
  • Location information Username: geographic code, geographic state, geographic postal code, geographic time zone, and country
  • Information experience: date of joining the job, date of joining the role, experience in different categories (i.e. organization, role, business unit, line of business)
Organization dataThe organization data within the LMS consists of details of the top-level organization and then delves into different levels of "organizational structure", consisting of the brands of companies, business units, lines of business, brands, departments and cost centers. Each level could have its individual details in terms of its ID and names and the subsequent parents in the hierarchical chain.
Role dataThe role data consists of the role information within the organization and consists of different master role data information (i.e. role title, role code, role family, management level, role category, shift work and role classification). This could be classified according to the organizational structure and its levels.
Location dataLocation data consists of location information where an organization provides its products / services and executes its business operations. It consists of the different master location data information (i.e. geographic code, geographic state, geographic postal code, geographic time zone, and country).
  • LMS integration serves different business purposes, as data is sent to different systems within the organization and each system uses it for different needs, such as performance evaluation, compliance, learning performance dashboard, learning cycle role life and route definition, gamification, incentives, access management and reports.
  • Integration for an LMS could vary, starting from inbound versus outbound integration; unidirectional communication versus bidirectional communication for data elements; integration modes (i.e. file-based [batch jobs], message queues, real-time API, web service; and application integrations (i.e. external, internal, cloud-based).

The following section discusses key governance policies for master data and integration within an LMS in 3 key areas: data dictionary management / integration manual, data access and integration, data audit and integration.

1. Data dictionary / Management of the integration manual

As with any software application, it is essential to manage the data dictionary or the integration manual similar to the requirements specification document. The data dictionary and integration manual should be viewed as the holy book of an LMS, and should be maintained and updated.

The data dictionary must have all the information about the data elements present or used in the LMS; You must also cover the fields in the background system. There must be a business section that defines the purpose of the data item; each informational data item should capture the lowest possible level of detail (for example, name, business purpose, business rule, data type, screen details [where this data element is visible], data length) to name a few.

The integration manual should capture the integration mode of the integrator system; type of integration; commercial justification to receive the data and its corresponding use in the integrating system; business contacts for the integrator system; type of application hosting; the frequency with which data is received or delivered from an LMS; and, calendar of data sent or received.

Whenever there is a change to a data item or an integration, it has to go through the data / integration governance board so that the impact can be analyzed and the details can then be documented / updated accordingly, after the signature of the interested parties; similarly, a general rule must be followed for any new data / integration components so that the corresponding dictionary / manual can be updated.

2. Data access and integration

It is highly significant that the system access controller knows to whom access should be provided and what access should be granted.

Access to data / integrations ensures that users with the correct privileges have the correct permissions that will allow them to create / edit / archive information successfully. These governance policies can be divided into two heads: (1) request access and (2) grant access.

The access request must have a help desk ticket submitted with the reason for the access request along with manager approval. The grant of access must be reviewed and the requesting member must assign / complete the appropriate training before obtaining privileges. The LMS administration team should validate the request by adding user privileges and restrictions when appropriate.

The highest level of access should be limited to a few. (For example, an LMS data manager who understands the system's complexities and complexities, from managing the Data Upload Wizard to integration settings; any changes to a data item or integration should not work without the eyes watchers of a data manager.)

3. Data audit and integration

Last but not least, for any system, the audit process provides assurance that operations are executed effectively and are efficient. Within an LMS, it is essential that we do a periodic audit process for all critical fundamental data. Starting with users, we need, at a minimum, to run an audit process on a quarterly basis so that only valid users are active on the system and ensure that licenses are up to date. The same is true for organization / role / location data, so only active data is present as there is always the possibility that an organization Line of business to update your name, paper be decentralized, and geographic location to be added.

It is always a good practice to have regular checkpoints with integration partners to verify if they still need the LMS data or if there are any additional requirements (i.e. change the power settings or cancel the power itself). These regular audit processes will ensure that integrations are optimized and updated.

Another audit process that companies should be aware of is checking user requests / tickets to understand which data areas or integrations are constantly having issues or challenges and identify improvement opportunities within the LMS, and then address them.


"The data will speak to you if you have the correct data." The aforementioned policies capture and maintain the "who, what, why and how" part of a data and integration related LMS. It will ensure that current and future statements are safe for stakeholders and business users.


Please enter your comment!
Please enter your name here