Administrate reporting is relationship-driven. The most important decision you make is selecting the correct entity (table) for the question you are trying to answer.
Contents
- Start with the question (business intent)
- Entity selection: rows define meaning
- Relationships and accessible fields
- Relationship direction and duplication
- Rollups: Contacts vs Learners vs Events
- Common reporting mistakes
- Related references
- Where to go next
Start with the question (business intent)
Reporting begins with intent. For example:
- Which clients purchased training last quarter?
- Who attended, and did they complete?
- What revenue was received by Region?
The correct entity follows directly from the question you are trying to answer.
Entity selection: rows define meaning
Entity selection determines what each row in your report represents:
- Accounts → one row per organization
- Contacts → one row per person (identity)
- Events → one row per delivery instance
- Learners / Delegates → one row per participation record
If totals look incorrect or inflated, the entity is often misaligned with the reporting intent.
Relationships and accessible fields
Once an entity is selected, available relationships determine which fields can be included in the report.
For example:
- A Delegate can access Event and Contact data
- An Event can access Course and Venue data
- An Invoice can access Account and Booking data
These relationships allow reports to combine data across different parts of the system, but they also introduce complexity when multiple related records exist.
Relationship direction and duplication
Relationships are not always one-to-one. Many are one-to-many, which can affect how results are returned.
- One Event can have many Delegates
- One Account can have many Contacts
- One Contact can have many Bookings
When you include fields from a related entity, records may repeat (duplicate rows) because each related record is returned.
For example:
- An Event-based report that includes Delegate data may show multiple rows per Event (one per Delegate).
This is expected behavior and reflects the underlying data relationships.
When a related field returns several values in one row, check the direction of the relationship you followed. A path such as Contact → Event Registrations can return several related records (one Contact has many registrations), while Delegate → Contact returns one.
Filtering with a supporting report
When only one of several related records should qualify — for example, one relation stores the value you need (such as line manager) while another stores the qualifier (such as primary job role) — build a small supporting report that isolates the qualifying records, save it, and use it as a filter in the main report:
- In the main report's conditions, choose Add Saved Filter.
- Select the supporting report.
- Choose In saved filter (or Not in saved filter) as the condition.
The main report then only includes records that match the supporting report's results.
Rollups: Contacts vs Learners vs Events
- Learners preserve event-level truth and are best for participation and completion questions.
- Contacts provide longitudinal history across many Events and courses.
- Events support operational rollups such as delivery performance and scheduling analysis.
Choosing between these determines whether you are analyzing participation, people, or delivery.
Common reporting mistakes
- Choosing the wrong entity: leads to incorrect totals or missing fields.
- Misinterpreting duplicate rows: repeated rows often reflect valid one-to-many relationships, not data errors.
- Mixing identity and participation: Contacts represent people, while Learners represent event participation.
- Using the wrong level of aggregation: Event-level vs learner-level reporting can produce very different results.
Related references
Where to go next
- How Administrate Works: Core Concepts & Relationships
- Imports & Data Logic: Matching, Updates, and Safe Operation