External training & xAPI sources

In one sentence

External training is QFormance's way of tracking required courses that don't live inside QFormance — your corporate LMS, a regulator's portal, a supplier-provided certification — with completions flowing in via xAPI statements that the external system pushes to QFormance.

Three things to remember

Two admin pages, one workflow. The Training Catalog defines which courses exist and who needs them. The xAPI Sources page issues the API keys those external systems use to push completion statements. You need both for end-to-end automation.
Activity IDs are the contract. Each external course has an activity ID (a stable URL or IRI). The external system pushes xAPI statements naming that activity ID; QFormance matches the statement against the catalog and credits the user automatically.
Distribution is by user or by role. Assign a course to specific users and / or to whole roles. Adding the role to someone new picks up the course requirement immediately.

Why external training exists

Internal courses (managed at Internal Courses) cover training authored and delivered inside QFormance — content, quiz, completion tracking, all in-app.

External training covers the other half — courses delivered elsewhere where QFormance needs to track who has completed what without owning the content:

Corporate LMS like Cornerstone, SuccessFactors, Workday Learning.
Regulator-mandated training on a third-party portal (OSHA, FAA, GMP refreshers).
Supplier or customer certifications delivered through their portal.
Conference / industry training where the issuing body provides an xAPI completion stream.

Once a course is in the catalog and an xAPI source is configured, completions land in QFormance automatically — feeding role-level training gates, audit trails, and renewal tracking with no manual data entry.

Training Catalog — defining the courses

Admin → Training → Training Catalog.

Each course in the catalog has:

Title — what users see.
Description — optional context.
Category — free-text classification (Quality, Safety, Compliance, etc.) for filtering.
Activity ID — the xAPI activity URL/IRI that incoming statements name. This is the technical contract. Examples: https://corp.acme.com/lms/courses/iso9001-overview, https://regulator.example/training/gmp-refresher. Whatever the source system uses to identify the course.
External URL — optional link out to where the course lives. Users assigned the course can click through to take it.
Retrain interval (months) — optional. When set, completions expire after this many months and a renewal is required.
Reminder cadence — picks the email schedule that fires when users are assigned the course. Six presets (default Weekly for 4 weeks). See Acknowledgement & training reminders for the full list.

Distributing a course

For each course, pick who's required to complete it. Two ways:

By user — pick specific people. The course requirement appears on their training dashboard immediately.
By role — pick a role. Everyone with that role (now and future) inherits the requirement automatically. New people granted the role pick it up next sign-in.

Distribution can mix both — "this course is required for everyone with the Lead Auditor role, plus these three specific contractors".

Read & Acknowledge users are first-class consumers of external training. xAPI completions pushed from your LMS land on their training records the same way they land on full users' records — same matching logic, same audit trail, same visibility in the user's Training Hub history. So the workforce doing the work via your corporate LMS shows up on QFormance with their certifications intact, at $3/seat.

When a user (full or R&A) is assigned an external course — either directly or because they were added to a role or group that's on the distribution list — they get an email immediately, and follow-up reminders fire on the cadence set on the course. See Acknowledgement & training reminders.

Activating and retiring courses

A course row carries an Active toggle. Deactivating:

Removes the requirement from users who haven't yet completed it.
Keeps existing completion records intact for audit purposes.
Stops accepting fresh xAPI statements for that course.

Re-activate later if the course returns; the catalog row stays in place.

xAPI Sources — issuing API keys

Admin → Training → xAPI Sources.

This page is where you provision the API keys external systems use to push completion statements to QFormance.

Each source has:

Name — descriptive, what system this key represents (Cornerstone Production, OSHA Portal).
API key — generated when you create the source. Shown once at creation time.
Allowed activity IDs — the activity IDs this key may report on. Required at creation: a key reports only on the activities listed here.
Created at / Last used at — when the key was issued and when the source last successfully pushed a statement.
Active toggle — flip off to suspend the key without deleting it.

Creating a source

Click New source.
Enter a name and list the activity IDs this system is allowed to report on — at least one is required. See Scoping a key below.
Click Create. The dialog shows the issued API key once. Copy it and configure it in your external system's xAPI / LRS endpoint.
Close the dialog. The key is gone — there's no way to retrieve it later. If you lose it, delete the source and create a new one.

The xAPI endpoint your source posts to is https://www.qformance.io/api/xapi/statements with HTTP Basic Auth using the issued key. The exact format follows the xAPI / Tin Can specification.

Scoping a key to specific activities

Every key is scoped: it may only report completions for the activity IDs on its Allowed activity IDs list, and completions for anything else are rejected. Anyone who obtains a key — from a saved LMS config, a support ticket, a screenshot — is therefore limited to the courses that key was issued for, instead of being able to write a training record for anything in your catalog.

Set the list when you create the source, and edit it later from the scope button on the source row — one activity ID per line.

One or more activity IDs — every activity ID the statement names must be on the list. Anything else is stored in the inbox as rejected and records no training.
Empty list — the key records no completions. It still authenticates, and every completion statement it sends is rejected. Clearing a key's list stops it recording training without deleting it, and its existing records stay in place — but it is not a full off switch: the key can still read and write xAPI state data (the bookmark / resume data courses store) for your organization. To shut a key off entirely, switch the source Inactive or delete it.

"Every activity ID the statement names" means the ones the inbox reads: the statement's object.id, plus the first contextActivities.grouping entry and the first contextActivities.parent entry when they're present. Naming an allowed course in the context of a statement about a different activity doesn't get it through.

Scope each key to the activity IDs that system actually delivers. A listed activity ID that matches no catalog course still records the completion — it lands in the learner's history as uncategorized — unless your organization has strict catalog matching enabled, in which case the statement is stored but records no completion.

Watch out for: scoping limits what, not who

The allowed-activity list restricts which courses a key may report on. It does not restrict whose completions it may report — a key can still record a completion of a listed course for any member of your organization. That's a deliberate limit, not an oversight: an LMS legitimately reports completions for every learner it trains, so there's no learner list to check a statement against. Restricting that would need per-learner credentials or cryptographically signed statements, which the xAPI integrations customers run don't support today.

The practical consequence: a leaked key can still lie about the courses it was issued for. That's why each key should list only the activities that one system actually delivers, and why source keys are privileged credentials — if one may have leaked, delete the source and issue a new key.

How completions get credited

When an external system pushes an xAPI statement:

The statement's actor carries a user identifier — typically an email address — that QFormance matches to a profiles row in your org.
The statement's object.id is the activity ID you configured on the catalog course.
The statement's verb is one of the completion verbs (http://adlnet.gov/expapi/verbs/completed, http://adlnet.gov/expapi/verbs/passed).
If the actor maps to a user in your org and the activity ID matches an active catalog course, QFormance writes a completion record and (if result.score is present) records the score.

If any of those fail, the statement is rejected and the source's Last used at doesn't update. Check the activity ID exactly matches and that the user's email matches their QFormance profile.

Watch out for: activity-ID drift

A new edition of a course in your LMS often gets a new activity ID. Statements with the new ID won't match a catalog entry keyed to the old ID. Update the catalog activity ID when your LMS bumps its version, or add a new catalog row for the new course and retire the old one.

Permissions

Both pages are gated on the Access audit admin permission. The default Admin role has it; Standard User doesn't. Grant it on a custom role if you've delegated training administration.

What this doesn't do

It doesn't author courses. External training is purely a tracking layer. Content lives in your LMS or external portal; QFormance only records that the user completed it.
It doesn't render quizzes. Quizzes are for internal courses — see Internal Courses. External completions arrive pre-graded from the source.
It doesn't push to external systems. xAPI here is a one-way pull — the external system pushes completions to QFormance, not the other way around. If you need to push training requirements to an external LMS, that's a separate integration.

Training hub — the user-facing training surface
Internal courses — for courses authored inside QFormance
Training reporting — pulling reports including external completions
Roles & permissions