Training

Training is an optional feature in Novantra. When enabled, your organization can assign published training courses to parties (employees, contractors, vendors, beneficiaries, anyone you represent as a party) and track completion.

This page describes the feature from a customer perspective: what it covers, how the catalogue works, and the day-to-day mechanics.

A worked scenario: an offshore drilling contractor

An offshore drilling contractor maintains a population of about 2,000 parties (full-time crew, rotational crew, third-party inspectors, port agents). Their HSE function publishes a baseline set of safety courses (“Hydrogen-sulfide response,” “Working at height,” “Confined-space entry”) and assigns the appropriate set to each party based on their role.

The day-to-day looks like this:

The HSE team publishes a new version of “Hydrogen-sulfide response v3.2” in the training catalogue.
The training-assignments coordinator opens the catalogue, picks the course, picks the recipients (a folder of “Drill-floor crew” parties), provides a reason (“HSE program annual refresh, Q2 2026”), and submits.
Each assigned party receives a notification (and, where appropriate, a public session task delivered via a session link) directing them to complete the course.
As each party completes the course, completion is recorded against the assignment with the actor (the member who marked it complete on the party’s behalf, or the party themselves through a public session if that’s how the workflow is set up).
At any time, the HSE team can pull a list of assignments filtered by course, by folder, by completion status, by due date.

What Training owns

Training as a feature owns:

the training catalogue (the published course definitions and their versions)
training assignment records (a course assigned to a party, with the actor, the reason, and the completion state)
training-specific permissions and the training nav entry

Training does not own:

the party records themselves; those come from the Party module
member identity; that’s Workspace administration
document storage; uploaded course materials live in the DMS where applicable
inbox notifications; those flow through the workspace notification surface
session-link delivery for external completion; those are owned by Public Sessions

This separation matters: training assignments target parties, not members, so that an assignment survives a person changing jobs, a contractor returning after a gap, or a member account being deactivated.

Training assignment recipients are always parties. Even when a member completes their own training, the assignment is recorded against the party that member represents, not against the member account directly. This is what lets historical training records remain meaningful over years.

The training catalogue is yours

In both Cloud and Sovereign, the training catalogue is owned by your organization. You create your own courses, version them, and publish them for use inside your workspace. Novantra does not curate or supply training content; the catalogue is yours to build and maintain.

In practice this means:

You decide what courses exist. Safety training, regulatory compliance training, role-specific onboarding, internal policy training, whatever your organization actually delivers, you define here.
You publish your own versions. When the content of a course changes (a new revision of a procedure, an updated regulatory citation), you publish a new version of the course in your own catalogue.
There is no Novantra-managed roster. What’s in your catalogue is what you put there.

In a multi-organization Sovereign install, each organization owns its own catalogue independently.

How an assignment is made

An assignment carries:

the course id (a published course in the active catalogue)
one or more recipients, each a party reference (entityType: "party", entityId: a party id in the same organization)
a reason for the assignment (operational context, training plan id, regulatory cycle, internal program)

Once recorded, the assignment is owned by the organization and tracked independently of any one member’s involvement. If the member who created the assignment leaves the organization, the assignment remains valid and its history is preserved.

How completion works

There are two common shapes:

A member marks completion on behalf of a party

A member with the complete training permission marks the assignment complete on the party’s behalf. Useful for in-person delivery, observed practical sessions, supervisor sign-off after a drill.

The party completes through a public session

For parties without a member account (external contractors, third-party assessors, applicants going through onboarding), training can be delivered through a public session. The session task represents the training step; the party completes it through a session link; completion is recorded against the assignment automatically.

See Public sessions for how session-driven workflows are constructed.

Versions

Training courses are versioned. An assignment is bound to the version of the course that was active at the time of assignment. Publishing a new version of the course does not silently rewrite old assignments; you assign the new version explicitly.

This matters because historical records need to remain meaningful: a 2024 completion of “Working at height v2.1” should not pretend to be a completion of v3.0 just because v3.0 is now the active version.

Permissions

Permission	What it lets you do
`training.view`	See the training catalogue and assignments visible to you.
`training.assign`	Create new assignments for parties.
`training.complete`	Mark training complete on behalf of a party (within your scope of access).
`training.manage_assignments`	Edit, reassign, or close out assignments for the organization.

Training permissions are managed through the same roles surface as the rest of the workspace; see Roles & Permissions.

A worked scenario: an annual refresh

A specialty veterinary referral hospital runs an annual rabies-handling refresh across its 230 parties (veterinarians, vet techs, kennel staff, transport drivers, locum partners).

The clinical operations team publishes “Rabies handling refresh v4.0” in the hospital’s training catalogue on 2026-04-15.
The clinical operations lead creates an assignment with all 230 parties as recipients, reason “Annual rabies handling program 2026.”
195 parties have member accounts and complete the course through the in-product experience.
35 parties (mostly locum partners) don’t have member accounts; their completion is gathered through a public session whose task type is training_complete referencing the assignment.
By 2026-06-15 the operations lead pulls a report of incomplete assignments and follows up directly with the remaining parties.

The training feature handles the lifecycle from publication to completion; the party model handles the population; the public-sessions model handles the session-link delivery; the roles model handles who can do what.

Enabling and disabling Training

Training is gated at two levels:

deployment selection: Training routes and migrations only ship into a deployment when the deployment profile includes the Training feature.
runtime availability: even when Training is in the build, an admin can disable it for an organization, and entitlement rules can withhold it.

When Training is not available, the nav entry does not appear and the routes return a feature-not-available response. Disabling Training does not delete historical assignments; they remain in the database and reappear if Training is re-enabled.

Party Governance, since training recipients are always parties.
Public Sessions, for session-link completion by external parties.
Roles & Permissions, for the training-specific permissions.
Audit log, for the time-ordered record of who assigned and completed what.