Managing Inactive LMS Accounts in Omani Organizations

Picture the renewal meeting at a services company in Muscat. The provider’s proposal for the LMS software is based on 1,400 user accounts. HR counts 900 current employees. The other 500 accounts belong to people who resigned, seasonal staff from last summer, contractors from a finished project, and a few duplicates created when employees moved between branches. Someone suggests deleting them all before signing. Someone else asks what would happen to those people’s safety training records if their LMS software accounts disappeared.

Both instincts are reasonable, and both can go wrong. Keeping every account in the LMS software inflates license counts, clutters reports, and leaves old access open. Deleting accounts can destroy training records the organization may still need for an audit, a dispute or a rehire. The way through is a policy: a clear definition of ‘active’, an understanding of how the LMS software license counts users and an agreed route from active to archived that keeps the required record.

This article sets out that policy for HR, IT and procurement teams in Omani organizations that run LMS software, together with the tests to run before applying it. Turnover is a particular issue for companies with many small branches, as discussed in our guide to choosing an Arabic LMS for Omani companies with small branches.

Define ‘Active’ Before You Count Anything in the LMS Software

‘Inactive’ is meaningless until ‘active’ is defined. Organizations running LMS software use at least four different meanings, often without noticing: currently employed according to HR, holding at least one open assignment, signed in within a set period, or having completed something within a set period. A field technician in Duqm who signs in twice a year is inactive by the third definition and fully active by the first.

Base the definition of active on HR status first and on activity second. A practical set of statuses for LMS software is:

• Active: a current employee, or an approved external user with a valid end date.

• Dormant: a current employee with no sign-in or assignment for an agreed period, such as six months, to be reviewed rather than removed.

• Leaver: employment has ended; the account is deactivated, and the record is kept.

• Expired external: a contractor, trainee or partner whose agreed end date has passed.

• Archived: a deactivated account moved to read-only storage after an agreed period, with its training record intact.

Before counting, remove the noise. Duplicates appear when an employee moves branch, when a name is spelled differently in Arabic and English, or when one person has both a personal and a work email. Match accounts to the employee number in the HR file and merge duplicates in the LMS software before deciding that anyone is inactive.

Write the statuses down, configure them in the LMS software where it allows, and agree them with HR, IT, and the training team. Every later decision, from the license count to the monthly clean-up, depends on them.

How the LMS Software License Counts Users

Licensing models for LMS software differ, and the cost of inactive accounts depends entirely on how yours counts users. Before negotiating, ask the provider to answer in writing:

• Does the license count named accounts, accounts that signed in during a period, or every account that exists?

• Does a deactivated account still count? Does an archived one?

• If a leaver is reactivated after a rehire, does the history return with the account, and does it count again?

• Do external users, such as contractors or franchise staff, count in the same way as employees?

• Can the organization export full records for archived accounts at any time, including after the contract ends?

Put the answers into the contract as definitions, not as sales notes. If deactivated accounts do not count, a clean deactivation process pays for itself. If every existing account counts, archiving may need to happen outside the LMS software, in which case the export you keep must be complete and readable.

A Policy for Inactive LMS Software Accounts

Security guidance treats inactive accounts as a risk in their own right. NIST’s SP 800-53 control catalog includes a control (AC-2(3)) to disable accounts within an organization-defined period when they have expired, are no longer associated with a user, violate policy, or have been inactive for an organization-defined period, and notes that this supports least privilege. The same control family calls for aligning account management with personnel termination and transfer processes. Applied to LMS software, that gives five steps:

• Leavers: deactivate the LMS software account on the last working day, triggered by the HR exit process rather than by someone noticing later.

• Dormant employees: review each case with the line manager before acting; long leave or rare sign-ins are not reasons to remove an account.

• External users: set an end date when the account is created, and let it expire unless someone extends it.

• Archive: after an agreed period, move deactivated accounts to an archived, read-only status with the training record intact.

• Delete or anonymize: only when the retention period in your records policy has ended, and with the approval of its owner.

How long to keep training records is a records management decision, not an LMS software setting. In Oman, the National Records and Archives Authority’s records management and retention guide states that, under the Documents and Archives Law (Royal Decree 60/2007), government units and other entities subject to that law prepare a classification of their records and schedules of retention periods, in coordination with the Authority. If your organization is subject to it, training records belong in that schedule. If not, use your own records and data protection policy, and confirm the periods with your legal team. This is general information, not legal advice.

Test the Policy in the LMS Software Before Applying It

A deactivation run in LMS software that goes wrong can remove hundreds of records in minutes. Test every step with a handful of test accounts first:

• Deactivate a test leaver: they cannot sign in, and their completed courses still appear in historical reports, marked as a leaver.

• Check current reports: leavers no longer appear in managers’ team views or in current completion rates.

• Rehire the test leaver: the account is reactivated with its history, without creating a duplicate.

• Archive an account: the record stays readable and exportable, and the license count changes as the contract says.

• Let a test contractor’s end date pass: the account expires on time, and the manager is informed.

• Run a bulk deactivation from an HR file of ten accounts and compare the result with the file line by line.

Check the exports from the LMS software too: archived and leaver records should keep the same identifiers as the HR system, so they can be matched years later. Our guide to essential fields in LMS report exports for Oman HR teams lists the fields that make that possible.

A Hypothetical Example: A Facilities Services Company

The following example is hypothetical and is included only to show how the policy works.

A facilities services company with its head office in Muscat and teams in Sohar, Nizwa and Salalah uses LMS software for safety inductions and technical refreshers. Before renewal, HR compares the account list with the payroll file and finds about 400 accounts that do not match a current employee.

The team does not delete them. It agrees on the five statuses, asks the provider in writing how deactivated and archived LMS software accounts count, and learns that archived accounts do not count toward the license. It then tests deactivation, rehire, and archiving with ten test accounts, finds that rehiring created a duplicate, and has the provider fix the matching rule. Only then are the 400 accounts processed: leavers deactivated and archived, contractors expired, and 23 dormant employees reviewed with their managers, most of whom turn out to be field staff on rotation.

The renewal is based on the real number of active users, and the safety records of former employees remain available for the next audit.

Running the Policy Every Month

Make inactive accounts a routine, not an annual clean-up. Each month, compare the LMS software user list with the HR file and process leavers, expired external users, and new dormant cases. Each quarter, review dormant accounts with managers and confirm the license count with the provider. HR owns the statuses, IT runs the changes, the training team checks that records survive, and procurement watches the license.

Keep a short log of each monthly run in the LMS software or alongside it: how many accounts were deactivated, archived, expired, or reactivated, and why. When an auditor or a provider questions a number, the log answers in minutes.

Inactive accounts also affect access. A dormant LMS software account with an old manager role can still open a team’s records, so include role checks in the monthly run; our guide to managing LMS permissions across company branches covers that side.

Summary

Inactive accounts in LMS software are a licensing problem, a security risk, and a records question at the same time. Defining ‘active’, knowing how the license counts users and agreeing a route from active to archived solves all three without deleting records the organization may need.

Write the statuses down, get the LMS software licensing answers into the contract, test deactivation, rehire and archiving with test accounts, and run the policy every month. Omani organizations that do this pay for the users they actually have and can still show the training records an auditor asks for.

Click here. If you want Skillup MENA to help you.