Moodle competencies and learning plans

Before anyone opens the import tool, the team has to decide what a competency framework is for their organization and how its parts relate. In Moodle, the learning plans tool (tool_lp) holds the framework, its competencies and any hierarchy, the rating scale used to judge each competency, and the links that attach competencies to courses and activities. Each of these is a separate design decision, and the CSV import file can only express the model it is given. Treat the model as the deliverable and the file as its serialization.

Start with the framework itself. A framework is the top-level container, usually matching a role, program or accreditation standard. Decide whether one framework per job family, qualification or regulatory standard is clearer than a single large framework, because the framework boundary determines who can see and manage the competencies inside it. Then map the hierarchy: competencies can be nested under parent competencies, and the depth and naming of that tree will be hard to change later. Write the tree down in a spreadsheet with a stable identifier for each competency before any file is drafted, and agree who owns each branch.

The rating scale deserves the same care. Moodle lets a framework define a scale of levels that learners and assessors select when a competency is rated. Confirm the number of levels, their labels, and which level counts as competent, since those choices drive how evidence is reported and how a learning plan decides that a competency is complete. Also decide where the scale is set: a scale shared across frameworks is easier to report on, but a scale per framework allows different wording for different standards. Check how your release's import file expresses scale definitions.

Next, define how competencies attach to courses and activities. A competency can be linked to a course, to an individual activity within it, or both, and the choice controls where ratings can be recorded and which evidence appears in a learner's plan. Map each competency to the activities that will produce evidence for it, and note which ones will be graded automatically and which need a rating by a person. Linking is a separate step from importing, so the model should name the courses and activities involved before the import file is finalized.

Changing the structure after users have ratings is the expensive mistake. Renaming a label is manageable, but moving competencies between parents, altering the scale, or deleting a competency can leave ratings and evidence attached to structures that no longer match the framework, and regulated organizations may then need to explain the gap to an auditor. Before the first import, get sign-off from the curriculum owner and the assessment lead, and test the full model on a non-production site. Confirm the exact column layout, identifiers and scale syntax in the tool_lpimportcsv documentation for your Moodle release, because the file format is the part most likely to change between versions.

A regulator, accreditor or internal quality team will rarely accept a competency marked "achieved" on its own. They will ask who rated the competency, against which scale and framework version, when the rating was made, and what activity or assessment supported it. Moodle's learning plans tool (tool_lp) records competency ratings against a framework, so the design work is deciding which of those records the organization treats as evidence, and making sure the record carries the detail an auditor will ask for. Confirm with your quality lead which questions the assessor will ask before the framework is loaded, because the answers shape the data model.

Decide early which ratings count as evidence. A rating given by a qualified assessor, linked to a graded assignment, quiz or observed task, is usually stronger than a self-rating or a rating made from course completion alone. Define the rating scale and the roles allowed to rate in writing, and configure Moodle's competency rating permissions to match. Settle how ratings made during a learning plan are treated compared with ratings made directly in a course, and whether a rating can be overwritten. Each decision should be recorded in your training policy so that the platform behaves the same way every time.

Frameworks change. A scale may be renamed, a competency reworded, or a competency retired after a regulatory update. Moodle does not replace the history of a rating when a framework changes, so the team needs a change log that records the framework version, the date of the change, who approved it and which learners or cohorts were affected. Treat each CSV import from tool_lpimportcsv as a versioned release, keep the source file under change control, and test framework migrations with tool_lpmigrate on a copy before running them in production. Confirm the exact behavior of your Moodle version with its release notes before relying on it.

Retention is set by your organization's rules and the regulations that apply to it, not by Moodle defaults. Decide how long competency records, linked assessments and framework versions must be kept, who may request an export, and how records are removed when a retention period ends. Test the export before an assessment, because the auditor will expect records they can read outside the platform. Keep backups of the database and the file store that hold the evidence, and check that restoring them brings back ratings and their history together.

DeployOpen prepares systems, controls and evidence for assessments, including the configuration, the documented rating rules, the change records and the retention procedures described above. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, and the organization should confirm with them in advance which evidence they require and in what format.

The handover package is the set of artifacts your team needs to run competency frameworks and learning plans without the implementation team in the room. The framework model should be delivered as source files: the CSV files used to build each framework, with a written record of hierarchy, scale definitions, rule settings and the Moodle version each was tested on. Alongside it, the import file specification documents column order, identifiers, parent references and scale values for the CSV import tool (tool_lpimportcsv), and the import logs from tested runs show which files loaded cleanly and which needed correction. Ask for these logs from a non-production copy, since they are the evidence your team will reuse when a framework changes.

The linking map records which competencies attach to which courses and activities, and whether each link is set by hand, by course module or through a template. Without it, your administrators cannot tell why a learner's evidence appears against one activity and not another. The permission and role design sits next to the map. It should state who can create and edit frameworks, who can rate evidence, who can view a learner's plan, and whether line managers see plans at all. Each permission should trace to a Moodle capability assigned at a defined context level. Confirm these decisions with your HR and data protection owners before handover, because changing them later affects who has already seen data.

The learning plan template library contains the reusable plans your organization will assign, with their competency lists, review points and completion rules. Pair it with the test and pilot evidence: the test scripts, the results of each run, the defect list with its resolution, and the pilot records showing a defined group of learners moving through real plans. Ask for named sign-off from the user acceptance testers, identifying which staff tested which workflows. A pilot that covers only administrators proves little, so confirm with your owners that the pilot group includes ordinary learners and the managers who rate them.

The runbook for upgrades and framework changes is the document your team will use most often after go-live. It should cover how to test a Moodle minor release against your frameworks before it reaches production, the steps to repeat the CSV import tests after an upgrade, and the rules for changing a framework. Decide in advance whether a change creates a new framework version or edits the existing one, and what happens to ratings already recorded. The administrator training notes complete the package. They should walk through routine tasks such as importing a revised file, reassigning a template and pulling a completion report, and name the situations that require escalation.

Your organization must supply the framework owners who approve competency wording and structure, the decision-makers who set rating scales, the source data for existing frameworks and learner groups, and staff who will carry out user acceptance testing with time set aside for it. Missing any of these usually moves dates, so name them in the scope before work begins. Moodle core is licensed under GPL-3.0, so your right to use the core platform does not depend on the engagement. Ownership and licensing of any custom code, plugin or documentation follow the written scope, so confirm in writing which items transfer to you, which are licensed and which remain with the implementation team.