The Manager Module

Most training platforms show a learner their own progress and nobody else's. That leaves the person who paid for the training with no way to know whether it is happening. The Manager module is that missing view: who was assigned what, how far each person got, what has slipped past its due date, and which credentials your people now hold.

It is a reporting and assignment surface. It reads — it never reaches into anyone's account, submits work on their behalf, or shows you their answers.

Availability: the Manager module is part of the Business plan, alongside SSO/OIDC and LMS interoperability. It is the plan on which a workspace holds more than one person, and following other people's training is meaningless where there is only ever yourself.

Who can open it

The module lives at Manage → Learning. Configuring the LRS integration is an administrator's job; a manager sees whether it is switched on but never the credential.

The summary row

Seven figures across the top, all scoped to your workspace:

Assigning a path

Enrolment used to exist only as something a learner did to themselves. An organisation that buys training does not ask its people to volunteer for it, so a manager can assign directly:

1. Pick a published learning path.
2. Select the members it is for.
3. Optionally set a due date (YYYY-MM-DD). Assignments past that date show as overdue in the table and in the summary.

Two behaviours worth knowing:

• Only members of your own workspace can be assigned anything. The list of addresses arrives from a form, so it is checked against the workspace's real membership before anything is written. An address that is not a member is silently dropped rather than invited.
• Someone already working on the path is skipped, not reset. The result says how many were assigned and how many already had it. Re-assigning would have rewritten who assigned it and when it was due, without changing a single thing the learner had done.

Unassigning removes the assignment. It does not delete the learner's progress or revoke a credential they have already earned.

The competency export

Manage → Learning → Export CSV produces competency_record.csv: one row per learner per card, with the framework alignment attached.

learner, path, nice_work_role, nice_category,
card, competency_cluster, card_category, requirement,
status, attempts, best_score, card_completed_at,
path_completed_at, path_score_pct,
assigned_by, due_at, credential_issued_at

The platform could already export a competition — scoreboard, participants, solves. This exports what was measured against a framework, which is the part a security organisation is actually asked to evidence in an audit. Each export is recorded in the workspace audit log.

Sending completions to your own LRS

If your organisation runs a Learning Record Store, CTFFactory can post xAPI statements to it as your people complete cards and paths, so the training shows up in the system your compliance reporting already reads.

Configured by an administrator under the same page:

• Endpoint — must be https. These statements carry names, email addresses and results, so plain HTTP is refused rather than warned about.
• Authorization header — stored encrypted and never sent back to a browser, including to the administrator who set it. Replace it by entering a new one.
• Enabled — a switch, separate from the endpoint, so you can stop sending without losing the configuration.

Note: the endpoint is validated against the platform's outbound URL rules, which refuse internal and loopback addresses. An LRS reachable only from inside your own network cannot be a target.

What the module deliberately does not do

• It does not let a manager open a learner's session, submit a flag, or read their attempts in detail.
• It does not create accounts. People are added to the workspace by named invitation or by SSO; assignment works on members who already exist.
• It does not follow anyone outside your workspace, including collaborators granted access to a single event.