Viewpoint On LMS Master Data And Integration And Related Governance Policies

LMS Governance Policies For Data And Integration
Summary: This article provides a perspective on master data and integration within a Learning Management System. It also covers the different governance policies that are key from a data/integration perspective when implementing or maintaining an LMS.

LMS Governance Policies For Data And Integration

Master data within a Learning Management System mainly comprises user, organization, location, role, course, and transcript data. These components are the foundation of the system, and it is of the utmost importance to manage them effectively and efficiently.

Integration for an LMS consists of inbound and outbound integration. Inbound integration comes from the HR data of the organization, wherein we receive the core fundamentals for the organization (i.e., user, location, role, and organization data). The outbound integration consists mainly of sending the user transcript data along with certain course elements to the different systems within an organization. There could be system integrations wherein we would be both receiving and sending data (i.e., two-way communication).

The typical challenges faced with master data and integration are listed below.

  • Batch jobs which lead to delays in receiving the information; it shows different data states in different systems. Also, the majority of the time, the business stakeholder is requested to wait for a day or two in order for the information to be up to date.
  • Legacy systems typically update their certification or course status as part of a monthly cycle, which leads to users waiting to see their transcript status updated.
  • A delay in having the right data leads to incorrect or inconsistent reporting, which subsequently delays business decisions.
  • Multiple, non-unique and convoluted data sources add to the burden of managing systems effectively; traditionally, a lot of hardcoding is done with respect to the business rules within the system integrations.

The maintenance cost of an LMS has been typically high due to all of the above reasons and more. The benefits of having an effective governance policy for master data management and integration starts with clean data. It provides guidance and structure and boundaries to operate, communicate, and make decisions. It helps create a structured, streamlined, and standardized process for faster responses and reduced lead times with better quality assurance and improved decision-making. It creates a history of why things were done in a certain way and how it needs to be done for a user-friendly and intuitive Learning Management System.

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


Foundational Data Element/Integration Details
User Data The user data consists of different information:
  • Profile information of the user: first name, last name, unique organization ID, email, contact number, manager or not
  • Organization information of user: organization ID, organization name, business unit, business line, lowest cost center ID
  • Role information of user: role title, role code, role family, management level, role category, work shift, and role classification (if any)
  • Manager information: immediate manager, subsequent level managers
  • Location information of user: geographical code, geographical state, geographical zip code, geographical timezone, and country
  • Experience information: employment joining  date, role joining date, length of experience in different categories (i.e., organization, role, business unit,  business line)
 Organization Data The organization data within the LMS consists of top-level organization details and delves subsequently into different "organizational structure" levels, consisting of the companies brands, business units, business line, brands, departments, and cost centers. Each level could have their individual details in terms of their ID and names and subsequent parents in the hierarchy chain.
 Role Data The 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, work shift, and role classification). This could be further classified based on the organizational structure and its levels.
Location Data The location data consists of the location information where an organization provides its product/services and runs its business operations. It consists of the different master location data information (i.e., geographical code, geographical state, geographical zip code, geographical time zone, and country).
  • The LMS integration serves different business purposes, as the data is sent to different systems within the organization and each of the systems uses it for different needs, like performance evaluation, compliance, learning performance dashboard, role lifecycle and path definition, gamification, incentives, access management, and reporting.
  • The integration for an LMS could be varied, starting from inbound vs. outbound integration; one-way communication vs. two-way communication for the data elements; integration modes (i.e., file-based [batch jobs], message queues, real-time APIs, web service; and, application integrations (i.e., external, internal, cloud-based).

The below section talks about the key governance policies for master data and integration within an LMS under 3 key areas: data dictionary/integration handbook management, data and integration access, data and integration audit.

1. Data Dictionary/Integration Handbook Management

As with any software application, it is paramount to manage the data dictionary or integration handbook similar to the requirements specification document. The data dictionary and integration handbook should be considered as the holy book of an LMS, and it needs to be maintained and up to date.

The data dictionary should have all the information about the data elements present or utilized in the LMS; it should also cover the system backend fields. There should be a business section defining the purpose of the data element; each informational data element should capture the lowest detail level possible (e.g., name, business purpose, business rule, data type, screen details [where this data element is visible], data length) to name a few.

The integration handbook should capture the integrating system integration mode; integration type; business justification for receiving the data and its corresponding usage in the integrating system; business contacts for the integrating system; application hosting type; the frequency at which data is received from or delivered to an LMS; and, schedule of data sent or received.

Every time there is any change to a data element or an integration, it has to go through the data/integration governance board so that the impact can be analyzed and, subsequently, the details can be documented/updated accordingly post business stakeholder sign off; similarly, a rule of thumb needs to be followed for any new data/integration component so that the corresponding dictionary/handbook can be updated.

2. Data And Integration Access

It is very significant that the gatekeeper of the system knows who the access needs to be provided to and what access needs to be granted.

Data/Integrations access ensures that users with the right privileges have the right permissions that will allow them to create/edit/archive information successfully. These governance policies can be divided into two heads: (1) requesting access and (2) granting access.

Requesting access should have a help desk ticket submitted with the reason for the access request along with the manager's approval. Granting access should be reviewed and appropriate training should be assigned/completed by the requesting member prior to them getting privileges. The LMS admin team should validate the request by adding privilege to the users and constraints wherever applicable.

The highest level of access should be limited to a few. (For example, an LMS data steward who understands the integrities and complexities of the system, from managing the Data Load Wizard to the integration configurations; any change to either a data element or to an integration, should not go live without the watchful eyes of a data steward.)

3. Data And Integration Audit

Last, but definitely not least, for any system, the audit process provides the assurance that the operations are running effectively and are efficient. Within an LMS, it is essential that we do a periodic audit process for all the core fundamental data. Starting with users, we need to, at minimum, run an audit process quarterly so that only valid users are active in the system and make sure the licenses are up to date. The same holds true for organization/role/location data so that only the active data is present, as there is always the possibility for an organization's business line to update its name, role to be decentralized, and geographical location to be added.

It is always a best practice to have periodic checkpoints with the integration partners to check if they still need the data from the LMS or if there are any additional requirements (i.e., changing feed configuration or sunsetting the feed itself). These regular audit processes will ensure that the integrations are streamlined and up to date.

Another audit process that businesses need to take into consideration is checking the user request/tickets to understand which data areas or integrations are constantly having issues or challenges and identifying improvement opportunities within the LMS, and subsequently addressing them.


"Data will talk to you if you have the right data." The above-mentioned policies capture and maintain the "who, what, why, and how" part within an LMS related to data and integration. It will ensure that the current and future states are secured for business stakeholders and users.