Courses, Course Templates, and Events: Structure and Inheritance – Support Portal

Administrate separates course templates from events so you can design training once, then deliver it many times without losing operational control.

The core idea is simple:

Course Template = the reusable training design
Event = a specific delivery instance of that training

This separation is one of the most important structural concepts in Administrate. It protects consistency, improves reporting, and prevents operational changes from damaging the reusable training blueprint.

The core model: template vs delivery

A course template defines what the training is meant to be. An event defines how that training is actually delivered in a real operational context.

In practical terms:

Course Template stores reusable structure and defaults.
Event stores dates, delivery details, people, learners, and execution.

This means Administrate is not designed around “one course = one delivery.” Instead, one course template can support many events over time.

What a course template is

A course template is the reusable blueprint for a training product. It defines the structure that future events are based on.

Depending on configuration, a course template may define things such as:

title and description
delivery mode defaults
pricing defaults
communications defaults
capacity planning defaults
achievement and completion settings
content and resources
reporting and classification values such as category or level

The course template should remain focused on reusable design, not the day-to-day operational realities of a specific delivery.

What an event is

An event is the real delivery instance created from a course template. It is where the training becomes operational.

An event may define or contain:

schedule and session dates
delivery location or virtual classroom setup
instructors and personnel
learner bookings and participation
attendance and progress
communications
finances and transactional records
event-specific overrides

This is the level where training is actually delivered, managed, and measured.

Why the separation matters

Keeping templates and events separate protects both consistency and flexibility.

Consistency: reusable defaults reduce repeated setup work.
Flexibility: individual events can adapt to real delivery needs.
Cleaner reporting: template structure and delivery outcomes are not collapsed into a single record.
Better governance: operational changes do not automatically corrupt the reusable course design.

Without this model, organizations tend to create documentation and reporting confusion because structural settings and event-by-event changes become mixed.

How inheritance works

When you create an event from a course template, the event typically inherits structure and default values from the template.

The basic pattern is:

Course Template → Event inherits defaults → Event may override where allowed

This is what allows Administrate to be both reusable and operational.

Inheritance is helpful because it means administrators do not need to rebuild every delivery from scratch. Instead, they begin with a known baseline.

What usually inherits from the template

Depending on your configuration, the following kinds of settings are commonly inherited from the course template into the event:

descriptive and classification information
planning defaults
financial defaults
communication defaults
achievement and completion rules
content or resource defaults

The important principle is that the template defines the intended baseline, and the event uses that baseline as a starting point.

What can be overridden at the event level

Events often need to adapt to real delivery requirements. For that reason, some inherited values may be changed or overridden at the event level.

Typical event-level overrides may include:

dates and schedule
location or virtual classroom settings
instructors and personnel
capacity or fill assumptions
financial settings where event-specific pricing or commercial arrangements apply
communications or delivery-specific setup

This is why event records should be understood as operational instances, not just copies of the template.

Choose the right level for changes

One of the most common administrative mistakes is changing the wrong layer.

Use the course template when the change should affect the reusable design of the training product.

Use the event when the change is specific to a single delivery.

A useful rule of thumb:

If the change should apply to future deliveries by default, update the course template.
If the change only applies to one scheduled delivery, update the event.

This distinction prevents structural drift and reduces confusion when comparing planned training design against actual delivery.

Examples of the model in practice

Example 1: reusable public training

You run the same classroom course every month.

The course template defines the standard title, description, pricing logic, and achievement rules.
Each monthly event defines its own dates, instructors, learners, attendance, and finances.

Example 2: one-off private delivery

A private client needs a custom delivery of an existing course.

The course template still provides the training blueprint.
The event can override scheduling, personnel, and commercial details to match the private engagement.

Example 3: changing a template after events already exist

You update a course template description or default planning value.

Future events may use the new default.
Existing events may retain their own values depending on the field and when the event was created.

This is why inheritance should be understood as a baseline model, not as a guarantee that all existing events stay permanently synchronized with the template.

Where learners and bookings fit

Course templates define the training structure, but learners do not participate at the template level. Participation happens at the event level.

That means:

learners are booked onto events, not onto the reusable template itself
attendance is recorded at the event level
achievements are typically tied to event participation and resulting outcomes

This is why the template/event distinction is so important. Training design lives at one level, while real participation and outcomes live at another.

Where learning paths fit

Learning Paths sit above individual events and achievements. They coordinate broader progression, but they do not replace the event as the operational unit of delivery.

In other words:

Course Template defines reusable training design
Event delivers that training
Learning Path aggregates multiple training requirements or outcomes across deliveries

Common mistakes to avoid

Treating the course template as the delivery record. It is the blueprint, not the execution history.
Making structural changes at the event level when they should be template defaults.
Assuming all template updates automatically rewrite existing events.
Confusing learner participation with course design. Learners belong to event participation, not template structure.

How this connects to the training lifecycle

In the wider training lifecycle, the relationship looks like this:

A course template defines the reusable training product.
An event is created to deliver it.
Learners are booked onto the event.
Attendance and progress are recorded at the event level.
Achievements may be awarded based on those outcomes.
Learning Paths may roll those outcomes into broader progression.