@dklinger Hiya … so we’ve got 3 approaches that we use, and we’re never consistent with which we use for what , but overall they seem to work most of the time.

1. An empty course shell. We’ve set up shells that have titles like “Equivalent to xyz” … this lets us put an ‘event’ on their user record with a completed status and a date. The titles can be anything really, and if the user can see their full profile or their completed courses, then they can see what we did. We’ve taken this into the API realm and have configured an environment in Insomnia (similar to Postman), that lists courses IDs, LP IDs, etc. so we can do some of these type of activities a bit easier.
2. A drop-down additional field. We use these fields as part of our usual post-training operations, with standardized events. Sometimes we add a specific event.
3. A wiki journal. Outside of the LMS and accessible only to SuperAdmins we created a timeline of when significant events happen...like today I’m retiring about 4K+ accounts that haven’t been accessed in over a year. I’ll make a journal entry, and even probably upload my .csv used to retire the accounts. Just gives us a contextual “paper trail” for troubleshooting accounts in the future.

@KMallette - thank you for the advice.

I get it. So hear me talk it through. Just writing this out will help. You are going to get the “best answer” by the way.

The initial challenge is a “seldomly used mandate”.

Part of the challenge is that this is more of a mandate on us to ensure an increased level of transparency to the event and as we move forward. And I do want the detail to be available - which it is - via the audit trail - but that is way out of context for the layman. But we do not control all reporting - which inherently creates a type of fail as well (if a Compliance team rolls in for a report that they configure and run and they miss the field, then well we miss a transparency driver).

I have always been super weary of loading “an event” as part of a person’s user profile. As events in time equate really well to something like a course (because of a time/date stamp). That is part of why the hesitance was there and the ask for best practices. It makes me lean want to into your scenario 1. Where we can essentially lock a course (so the user cannot open it) - it will be marked as completed and left under maintenance so we have a breadcrumb to the event in a space other than audit/reporting.

So maybe it is a blend of the three:

• Use an additional field on a person’s user profile that will report out to the event name. That user profile points to a course code.
  • that tells us that the course that is meant for an audit event.
• The course has a title that will be somewhat ambiguous - with admin only in it. It will be locked. The course code aligns with the first bullet as the connector.
• The course has a url that points at the wiki journal. The wiki journal describes the event, people impacted, and how to get back to course, the audit log / reports that represent the event.

In reality - if I add it to our documentation space, then it is probably covered well enough. We really arent going to be using this so much that it needs to be a feature. 

I think in closing - it needs to be a solution that gets our business units blessing (those pesky requirements) and something we can maintain as we move forward.

You have a couple of points (like leaving the course shell under maintenance) that make sense for us as well. Thanks for talking it out.