Skip to content

Training for Portal Users

Ed Mozley edited this page Sep 9, 2026 · 1 revision

Training for Portal Users

Pushing LMS courses to the people who use your service desk, not just the people who run it.

Until this, the LMS could only ever assign a course to a group of analysts. A course can now go to a group of people, to one named person, or to everyone on the self-service portal β€” and portal users take it in the portal, with the same player, the same knowledge checks and the same marking.


Assigning: the four targets

LMS β†’ Assignments β†’ Assign, then Who for. One list holds all four, because you know you want "Finance" β€” not which table Finance is stored in.

Target Reaches Use it for
Learning group analysts only Staff training, by team or role. The original, and still the default.
People group analysts and portal users Training for a set of people across the organisation. See People Groups.
Everyone on the portal every active portal account, including people added later Mandatory training for the whole company.
One person… one named analyst or portal user A single starter, a contractor, somebody who missed the group session.

The number beside each group is how many people it will reach. For a people group it excludes lapsed memberships, because those are not people the course will reach.

"One person" opens a search rather than a dropdown. A list of every portal user is unusable the moment an installation has more than a screenful, and a real one has thousands.

Editing an assignment

Use the pencil on any row to change the course, who it is for, or the deadline. Previously this meant deleting the row and starting again, which threw away the deadline you had already typed and left a gap where the course reached nobody.

No one's progress is affected by an edit. Training records are held against the person and the course, never against the assignment β€” so moving a course from one group to another does not erase what anybody has already done. Somebody who is no longer reached keeps their record too; it just stops being expected of them.


What a portal user sees

A Training tab in the portal's navigation, listing each course with its state, how far through it they are and when it is due.

It appears only for somebody who actually has training. On an installation that has never pushed a course to the portal β€” which is most of them β€” a permanent tab leading to an empty page is a worse answer than no tab.

On their dashboard, above their ticket counts, anything still to do appears as cards: soonest first, anything overdue in front of that and marked. Only outstanding courses are listed; a panel that also showed finished ones would become permanent furniture that stops meaning anything. It is absent entirely for anybody with nothing to do.

Taking the course works exactly as it does for an analyst. Both kinds of course play β€” ones you have written and SCORM packages you have uploaded β€” progress is saved as you go, and the result appears beside everybody else's on the Progress tab.

A portal user can only ever open a course assigned to them. A course that is not theirs and a course that does not exist give the same answer, so the URL cannot be used to discover what exists.


Deadlines

A deadline is a day, not a moment. Somebody given until Friday has the whole of Friday, and becomes overdue once Friday has finished.

That sounds obvious and was not always true: the check used to ask whether the stored instant had passed, and since a picked date is stored as midnight, a course due on the 9th turned red at one second past midnight on the 9th. Anybody told they had until Friday opened it on Friday to find they were already late.


Reminder emails

LMS β†’ Settings β†’ Reminders.

An analyst sees their courses whenever they use FreeITSM. Somebody who only uses the portal has no reason to sign in unless you tell them β€” so a course pushed to 400 staff with no email attached is a course 400 people never find out about. Reminders are what make the portal push a real feature rather than a page nobody visits.

Settings

  • Send training reminders β€” off until you switch it on.
  • Remind this many days before the deadline β€” a list, e.g. 7, 1. Use 0 for the day it is due.
  • Keep reminding after the deadline, and how often.
  • Send even without a scheduled task β€” see below.

It is off by default, and that is deliberate

Every other default here is chosen to be safe; this one is chosen to be inert. Upgrading FreeITSM must never, on its own, email several hundred people about training they were assigned months ago β€” which is exactly what a helpful "default on" would do on the first run after an upgrade.

You are told the size before you turn it on

The screen shows how many reminders would be sent right now, and how many people have no usable email address. Nobody should have to switch on a mail merge to find out how big it is.

That count is produced by the same code that does the sending, so the number you are shown is the number that will go.

Nobody is reminded twice

Reminders are found by asking "whose deadline is N days away", which stays true all day. The send is recorded once, so re-running sends nothing.

Moving a deadline is genuinely new information, and does prompt a fresh reminder. Finishing a course stops all of them immediately β€” nobody is chased for training they have passed.

Do you need a scheduled task?

Not to get started. With Send even without a scheduled task left on, FreeITSM sends anything due whenever somebody opens the LMS, at most once an hour. Reminders work out of the box.

But that is a fallback, not a schedule. If nobody opens the LMS for a week, nothing is sent for a week.

For reliable daily sending, run cron/lms_reminders.php once a day:

# Linux
0 8 * * *  /usr/bin/php /path/to/freeitsm/cron/lms_reminders.php

# Windows: Task Scheduler, daily, running php.exe with the full script path

Over HTTP it needs a shared secret in lms_reminder_cron_token; from the command line it needs nothing. If no token is configured the HTTP door is shut, not open.

Reminders also need a mailbox that can send. The settings screen says so plainly if there is not one, rather than letting you switch reminders on and wait for email that cannot leave the building.

Every reminder is recorded in the outbound email log under its own route, Training reminder, so "did the chase go out, and to whom" is answerable.


Who has no email address

Some people deliberately have no mailbox β€” warehouse and shop-floor staff often do not. They still see their training when they sign in to the portal, but no reminder can reach them.

The Reminders screen counts them separately and says so. A failure count that is really "these people have no email" tells an administrator nothing.


See also

FreeITSM

Getting Started

Modules

Multi-tenancy (planned)

Blue sky thinking

Bugs resolved

Links

Clone this wiki locally