1. Mostly with course code and naming conventions. Course codes have some functions that you can leverage in catalogs, but you can tack on a few things like year or version to it.

Naming conventions help to differentiate (typically by adding a year or date to it) the date that it was released that it was relevant for. For example a compliance course for this year may be Annual Compliance Training 2022.

2. You can be more discrete with additional fields on courses to add a version field.
3. Lastly, as you retire your courses you can adjust the code accordingly.

Lessons learned btw? You may want to develop a policy surrounding a publishing or curation cycle for courses. Stale content is a serious distractor to learners and reinforces tired LMS syndrome…so you express to your teams:

• Route to publication and the deployment cycle
• publication date
• Content review date (put it out for a year for example from first published
• Deprecation Date

@Tracy OWe use a very specific course code schema that helps us support 6 audiences, 5 countries(so far), and 5 languages (so far). It also support “generations” of both courses and learning plans

EX: ACT1_xxxx_LN

A = Audience

CT = Country code, two letter, international standards

1 = Generation, which we define as “significant, more than version, changes”

_ = Segment break

xxxx = Course number. Certain groups like “New Hire” begin with 1; other groups use different numbers. Course number actually remains the same thru different countries or languages if the content is largely the same, and thru generational changes too. This helps with sorting.

_ = Segment break

LN = Language, one or two characters, and try to use international standards.

We use the same schema for our catalogs and learning plans, with some minor modifications

The one drawback I’ve found with using codes is that they generally aren’t searchable by the learner. The only way I found for a learner to use a course number is to add it into the Title of the course. Unfortunately, this made the course tiles look very messy, so we’ve had to made course codes an “admin only” thing, which really really limits their usefulness. 

I like the approaches from everyone.  We follow a similar unique course code that is filtered mainly by admins and not our external users.   Because of our current practices we are beginning to grow our courses at an alarming rate.  I am curious how people are dealing with versioning of materials and test instead of creating a whole new course to be the versioning.   As a company we are moving to a more aggressive delivery of product which will require us to offer updated training more regularly than we can sustain by duplicating courses with new codes to work as our versioning.  Any ideas?

We use a similar course code classification structure for defining the category, course sequence, audience, and language. However, we don't number the version of each course. Versions of a course are limited to the audience or the language. If we are versioning the course content, we push the training material that is changing to the Central Repository and use the versioning there to track the update. This method keeps all the courses in our library evergreen and insures the learner always has the latest version.

I also described our process for pruning old courses in an earlier discussion: https://community.docebo.com/let-s-talk-shop-42/how-do-you-decide-what-to-prune-4169?postid=17966#post17966 

Briefly, we divide training into "reference" courses that we always keep up to date and "current awareness" courses that cover what is new. The current awareness courses are never updated (unless there was an error in the original material) and are unpublished after about one year.

In addition, we created two course additional fields, Released and Updated, to keep track of when the course was first published and when it was last updated.

There are two ways that I can understand your question

1. Simply updating the training material using the Central Repository
   1. I don’t use a new course for a new version. When I create a new course shell (in Course Management), and add the first version of the Scorm file as a training material, I push the training material into the Central Repository. This sets the version of the training material at “v1”.
   2. When I have a new version of the Scorm file to upload (which I’ve named with the schema I described above, including a version number), then I go to the Central Repository and edit the training material by uploading the new version there. The Central Repository marks that new version as “v2”. Then I can push the new v2 version into the course shells.
   3. You can check the version of the training material in the course shell by hovering over the hard drive icon in Training Materials.
2. It sounds like your team may need to spend some time deciding on your course TYPES: onboarding, uptraining, certifications, etc. And then DEFINE what you mean by those terms. What constitutes each course type? What are the situations that dictate the course type? When is each type of course used in the LMS?
   1. In our team, we have updates to onboarding, but we also have to uptrain those who already have taken the onboarding course. So in these situations we upload the same Scorm file to the onboarding course, and then create a new uptraining course. We keep the onboarding courses separate (in a LP) from the uptraining courses by how we number the uptraining course.

Here is some thing I DON’T do:

• I don’t display the course number or version number in the course shell title, or anywhere that the learner can see. Too confusing for the learner, and it is information that is really just necessary for the administrator.

Some great ideas. When updating a course version, my understanding it that a user who is in-progress for that course will have to start over. Does anyone have experience with this? It seems like users would get upset at having to start a course over.

Docebo support helped me find how tracking works with versioning when using the CLOR.  

Click Save Changes to complete the creation of the new version.