Purpose: Use this article to understand how Administrate separates identity from participation across Accounts, Contacts, Learners, bookings, and training activity.
This article explains the relationship between organizational context, person records, learner participation, and event-level activity.
This article explains:
- Accounts
- Contacts
- Learners
- Bookings and participation
- Identity vs participation
- Operational role context
- Training lifecycle relationships
Table of contents
- The core model: identity vs participation
- Accounts: organizations and ownership context
- Contacts: people over time
- Learners: training-capable participation records
- Participation happens through bookings
- Common roles a contact can play
- Why this model matters operationally
- Where this connects to the training lifecycle
- Common misunderstandings to avoid
- Related concept guides
Administrate separates identity from participation. This is one of the most important concepts in the platform. It allows the system to preserve a person’s long-term identity while also accurately tracking what they did in a specific training context.
In practical terms, this means Administrate does not treat “a person” and “that person’s participation in a specific event” as the same thing.
The core model: identity vs participation
The simplest way to understand the model is:
- Account = the organization or customer context
- Contact = the person over time
- Learner = that person in a training-capable context
- Booking / registration = that learner participating in a specific event or learning experience
This distinction matters because a single person may:
- belong to one or more organizational contexts
- participate in many different training events over time
- have different outcomes, attendance records, financial relationships, or achievements in each case
Administrate keeps those layers separate so reporting remains accurate and operational workflows remain flexible.
Accounts: organizations and ownership context
An Account represents the organizational context around a person or a training relationship. Depending on your operating model, an Account may represent:
- a customer organization
- an employer
- a client buying private training
- a business unit or partner relationship
Accounts matter because they influence commercial, operational, and reporting relationships. Pricing, invoicing, private training arrangements, and account-level visibility often depend on this layer.
An Account is not a learner record, and it is not attendance. It is the organizational context in which people and training relationships exist.
Contacts: people over time
A Contact is the durable record of a person. It represents who they are over time, independent of any one event or booking.
A Contact may include information such as:
- name and contact details
- employer or account association
- communication preferences
- longitudinal history
The important principle is this: a Contact remains the same person even as their training history, bookings, achievements, or account associations evolve.
This is why identity should not be modeled at the event level. Events change. Participation changes. The person record should remain stable.
Learners: training-capable participation records
A Learner represents a person in a training context. This is the layer that connects identity to delivery and outcomes.
Learners are used so Administrate can attach training-specific records to the right person without collapsing all training history into the Contact record alone.
In practical terms, learner-related records are where the system can connect:
- event participation
- attendance
- progress
- achievements
- certifications
A Contact can exist without active participation in training. Participation happens later, through booking or registration onto an event or path.
Participation happens through bookings
The most important operational idea in this model is:
Identity does not equal participation.
A person becomes an active participant in a training delivery when they are booked or registered onto a specific event, learning path, or other learning activity.
That means Administrate can accurately answer different questions, such as:
- Who is this person? → Contact
- Which organization are they associated with? → Account
- Are they participating in training? → Learner / booking context
- What happened in this specific delivery? → Event participation records
Common roles a contact can play
The same Contact may appear in different operational roles across the platform.
- Learner — participates in training
- Instructor — delivers training
- Event personnel — supports delivery or administration
- Commercial contact — purchases, approves, or manages training
- System user — interacts with Administrate operationally
These roles should not be confused with one another. A person may be one of these, several of these, or move between them over time.
Administrate’s model supports this flexibility by keeping identity stable and allowing role and participation context to vary.
Why this model matters operationally
This structure is not just theoretical. It affects how the system behaves in everyday work.
- Reporting stays accurate because outcomes can be tied to actual participation rather than only to a person record.
- Historical records stay trustworthy because a person’s identity remains stable even as their bookings and achievements change.
- Event-level operations stay clean because attendance, progress, and achievement logic are attached to the delivery context where they occurred.
- Commercial workflows stay flexible because Accounts, Contacts, and bookings can be related without becoming the same record.
Where this connects to the training lifecycle
In the training lifecycle, identity comes first and participation follows.
- A person exists in the system as a Contact.
- They may be associated with an Account.
- They become a participant when they are booked or registered onto an Event or related learning activity.
- Attendance, progress, and outcomes are then recorded in that participation context.
- Achievements and certifications can then be issued based on what actually happened.
This is why identity articles, event articles, participation articles, and achievement articles must all agree with one another.
Common misunderstandings to avoid
- A Contact is not the same as a booking. A person can exist in the system without being on any event.
- A learner outcome is not the same as identity. Pass, fail, attendance, and certification belong to the participation context.
- An Account is not the same as a person. It is the organizational layer around the relationship.
- A role is not always permanent. A person may be a learner in one context and an instructor or contact owner in another.
Related concept guides
- Courses, Course Templates, and Events: Structure and Inheritance
- Events: Lifecycle, Inheritance, Conflicts, and Operational Reality
- Learning Paths: Multi-Event Delivery Without Losing Event Truth
- Enrollment, Bookings, Attendance & Progress: What “Participation” Means
- Training Lifecycle in Administrate