Administrate is designed around a small number of core concepts that interact in intentional, predictable ways. Understanding these relationships is essential for configuring the system correctly, interpreting reports accurately, and avoiding downstream issues as your data grows.
This article explains the system mental model of Administrate: what the primary entities are, how they relate, and the rules that govern their behavior.
This is not a step-by-step guide.
It defines the conceptual foundation that other documentation assumes.
Contents
- Administrate is event-centric
- Templates define intent; instances execute it
- Relationships are directional
- Identity is layered
- Geography and organization drive behavior
- Delivery and access layers
- State matters more than screens
- History over convenience
- How to use this knowledge
- Where to go next
Administrate is event-centric
Administrate exists to support training delivery. Everything in the system enables, manages, records, sells, presents, or reports on training activity.
Training activity is executed through Events.
- Courses define what you teach.
- Events define when, where, and how training happens.
- Learners represent participation in a specific Event.
- Financials, achievements, communications, access, and reporting attach to Events directly or indirectly.
If you are ever unsure where something “lives” in Administrate, ask:
Is this describing intent, presentation/access, or execution?
- Intent lives upstream (templates, defaults, configuration).
- Presentation & access sit on top (Portals, LMS, WebLink).
- Execution lives downstream (Events, Learners, outcomes, transactions).
Templates define intent; instances execute it
A central design principle in Administrate is the separation between templates and instances. Templates define what should happen; instances record what actually happened.
Templates
Templates define how training should be delivered. They capture defaults, rules, and expectations.
Examples include:
- Course templates
- Pricing structures
- Achievement rules
- Communication templates
Templates are not historical records. They describe intent, not completed work.
Instances
Instances represent actual activity in the system.
Examples include:
- Events
- Learners
- Bookings
- Tasks
- Financial transactions
Instances are historical records and are preserved intentionally.
One-time inheritance is the rule
- When an instance is created, it pulls settings from its template.
- After creation, the instance becomes independent.
- Changes to the template do not retroactively alter existing instances (unless a feature explicitly states otherwise).
This design protects historical accuracy and reporting integrity, even when it limits convenience.
Relationships are directional
Many Administrate relationships appear bidirectional in the UI but are directional in the data model. Directionality explains why some changes propagate and others do not.
- Course templates → Events
- Events → Learners
- Regions → financial logic
- Locations → time zones and availability
Directionality commonly explains:
- Why some changes don’t propagate
- Why certain edits are blocked
- Why reporting behaves the way it does
Identity is layered
Administrate separates who a person is from what role they play at a given moment. This keeps identity stable while participation remains event-scoped.
Contacts
Contacts represent people over time.
A Contact can be (at different times):
- a Learner
- an Instructor
- a Booking Manager or Client Contact
- an internal coordinator or administrator
- a system User
Roles are contextual, not exclusive.
Learners
Learners represent participation, not identity.
- Created when a Contact is enrolled in an Event
- Event-scoped and transactional
- Outcomes are issued at the Learner level
Learners preserve event-specific truth.
Contacts accumulate training history over time.
Geography and organization drive behavior
Organizational structure, geography, and finance are intentionally separated so that operational and financial context can vary without breaking identity or training records.
- Companies define organizational boundaries
- Regions define financial and operational context
- Locations define where Events occur
- Venues optionally add physical detail
Delivery and access layers
Administrate supports multiple ways for learners and clients to discover, register for, and access training. These layers affect visibility and access, not the core execution model.
- Branded Portals
- LMS experiences
- Public or private WebLinks
- Client-specific storefront experiences
State matters more than screens
Many behaviors in Administrate are driven by state (what something is right now), not where you happen to be clicking in the UI.
- Event lifecycle states
- Booking status changes
- Completion and achievement states
When something behaves unexpectedly, the fastest diagnostic question is often: what state is this entity in?
History over convenience
Administrate prioritizes auditability and reporting integrity over retroactive edits. As a result:
- Instances (Events, Learners, financial records) are preserved as the record of what happened.
- Many “defaults” are applied at creation time rather than kept live-linked forever.
- Some edits are intentionally restricted because they would rewrite history and invalidate reporting.
How to use this knowledge
Use this model to decide (1) where configuration should happen, (2) where truth should be recorded, and (3) where reporting should roll up. If you keep “templates vs instances” and “identity vs participation” straight, most Administrate behavior becomes predictable.
Where to go next
- Courses & Course Templates: Defaults, Inheritance, and Change
- Events: Lifecycle, Inheritance, Conflicts, and Operational Reality
- Accounts, Contacts, Learners & Roles: Identity and Participation
- Portals, LMS, and WebLink: How Training Is Presented and Accessed
- Reporting in Administrate (then) Using the Reporting Engine
Final note: Administrate is powerful because it is structured. Once the structure is understood, system behavior becomes predictable.