Platform Modules
Learn about the modules that make up your platform
Search the Knowledge Base
Related Help Guide Pages
Learn about the modules available in your platform, and what you can use them for.
Your platform is built from a wide selection of modules! Each module is designed for a specific type of information, whether that’s Course information, Delegate information, Invoice information, or customer Account information!
There are many points in your platform where you need to select a module, including when you are creating Workflows, creating gadgets on your Dashboard, and when building Report Engine reports. Choosing the right module is important because it ensures that you’re viewing and working with the correct data, and therefore reporting accurately.
This page will help you:
Understand what modules are and how they’re used
Learn what the most commonly used modules are
Learn what information these modules contains, and how they’re typically used in Workflows, Filters, Reports, and the v2 API
What are platform modules?
This section explains what modules actually are, and where you will find them
A module is a structured collection of items in your platform. For example, 'Users' is a module and it is a collection of the people that interact with your platform.
Each module has:
A model name (used internally and in technical tasks)
An alias (the friendly name you’ll usually see in your platform)
A set of fields that describe the data stored in it
For example, the UserCourseDate model (known as Delegates) stores information about people registered onto Courses (Users on Course Dates!), this including their booking status, whether they’re on a waiting list, the date they were registered, and if they’re attending as part of a sessions plan.
Each module in your platform has it’s own DataGrid. As an example, we can access the UserCourseDateClass (known as Class Delegates) module information via the Class Delegates DataGrid.
From this DataGrid, we can view the items that this module includes (Delegates registered onto Class Courses), and we can see what information is available (such as Date Registered, Delegate Name, their Account Name, the Course details, and the Course’s Venue).
For another example, the ‘Invoices’ module stores information about each Invoice that has been generated. We can access the information in this module by opening the Invoices DataGrid from the main menu
From this DataGrid, we can view the items that this module includes (Invoices), and we can see what information is available (such as the ID, Reference, Target, the Date Due, and the Invoice’s Status).
Shared fields between modules
Some fields you see in a module don’t actually belong to that module, they are shared fields pulled in from another module.
For example:
In the Delegates module (UserCourseDate) you can see the Course’s Start Date, that field doesn’t belong to the Delegate, it comes from the Courses module (CourseDate)!
This means if you edit the Start Date on the Course, it will update automatically for all Delegates linked to that Course. You cannot edit that field per Delegate, because it’s not stored at Delegate level.
Shared fields are there to give you context and save time, so you don’t need to jump between modules/DataGrids to view related information. But it’s important to know where the data originates from, if you need to change a shared field, you must update it in the module it belongs to.
The same principle also applies when you create Custom Fields. Some modules allow you to share a Custom Field with other modules, so the information can be viewed in more than one place.
For example:
If you create a Custom Field called “Dietary Requirements” on the User module, it will store alongside that User’s core details (such as their name, email address, and contact information).
You’ll then have the option to share this Custom Field with the Delegates module.
If you do, the “Dietary Requirements” field becomes available as a shared field wherever the Delegates module is used, including reports, the Delegates DataGrid, or Delegate-based Workflows.
As with standard shared fields, because the field belongs to the User, you cannot edit it per Delegate. However, you can still view and filter on it when working with Delegates, which can be very useful for your reports and communications!
What are the most commonly used modules?
Here is an overview of the most commonly used modules
Delegate
Model name: UserCourseDateModel
Items: Delegates & Trainers registered onto all Courses, if a User is registered onto 4 Courses then they will be linked to 4 Delegates (one for each Course)
Class Delegate
Model name: UserCourseDateClassModel
Items: Delegates & Trainers registered onto Class-based Courses only
Please note: Trainers are hidden when viewing the Class Delegates DataGrid via the main menu
Web Delegate
Model name: UserCourseDateWebModel
Items: Delegates & Trainers registered onto Web-based Courses only
Please note: Trainers are hidden when viewing the Web Delegates DataGrid via the main menu
eLearning Delegate
Model name: UserCourseDateELearningModel
Items: Delegates registered onto eLearning-based Courses only
Knowledge Document Delegate
Model name: UserCourseDateDocumentsModel
Items: Delegates registered onto Document-based Courses only
Course
Model name: CourseDateModel
Items: All scheduled Courses, including scheduled Class & Web Courses, and dummy Courses created for eLearning & Knowledge Document Delegates
Class Course
Model name: ClassCourseDateModel
Items: Class-based scheduled Courses only
Web Course
Model name: WebCourseDateModel
Items: Web-based scheduled Courses only
Booking
Model name: CourseDateBookingModel
Items: Bookings processed through the Checkout or Shopping Baskets
Please note: Delegates, Purchases, and Vouchers created outside of the baskets will not have a ‘Booking’ record
User Award
Model name: UserAwardModel
Items: All completed, targeted, and expired Awards for each User
Please note: When a Delegate is give the status ‘Completed’ on a Course that has as associated Awarded Award, a User Award will automatically be created for them or (if they were already targeted for this Award) their target User Award will be changed to completed
Invoice
Model name: InvoiceModel
Items: All generated Invoices, including temporary (not yet committed) and cancelled
User
Model name: UserModel
Items: All Users stored in the platform, including those who will be registered as Delegates on Courses, the people who make bookings (such as managers), and administrator Users
Account
Model name: CompanyModel
Items: All customer Accounts and Training Provider Accounts
Course Template
Model name: CourseTemplateModel
Items: The course catalogue, the Course Templates are used as templates when scheduling Courses
Resource
Model name: ResourceModel
Items: Trainers, Venues, and any other Resources required for Courses to run - for example catering or equipment
Products & Service
Model name: ProductModel
Items: The additional items to sell either alongside or independently to Courses - for example equipment, tools, consultations, and extra services
Purchase
Model name: PurchaseModel
Items: A record of each time a Product & Service is sold
Transaction
Model name: TransactionModel
Items: Every payment and refund made on Invoices
Placeholder
Model name: PlaceholderModel
Items: Placeholders registered onto Class & Web Courses to pay for / hold places
User Role
Model name: UserRoleModel
Items: The platform roles assigned to each User, every User will have a 'main role' which can be viewed in the Users DataGrid. Not uncommonly Users will have multiple roles, this model keeps a record of each role each User has.
Opportunity
Model name: OpportunityModel
Items: CRM Opportunities/enquiries logged in the platform
Checkout Baskets
Model name: BasketModel
Items: All in progress and closed baskets for customers and admins using Checkout to book their Courses or purchase Products & Services
Top tips for choosing the right module
Whether you’re building a Workflow, creating a Dashboard gadget, or writing an Email Template, it’s important to select the right module!
Figure out where your data is coming from
The first step is to think about where your data is coming from.
If you’re creating a Dashboard Gadget – where in the platform are we sourcing information for this gadget, are we reporting on Invoices, or eLearning Delegates, or Courses!
If we’re creating Workflows – what area of the platform is going to have something created or updated that will trigger this email to send, is it a Course being created, or a Delegate having their status changed, what is the area?
If we’re creating Email Templates – what area of the platform do we want to be able to send this email from, if we want to send it from the Invoices DataGrid – we will want the Invoices module!
If there are multiple possible Modules, choose the one with lowest level of data
If there are multiple possible Modules, always choose the one at the lowest level of data, the one that represents individual records rather than broader categories.
For example, if your email is going to contain information about a Course and a Delegate, you would use ‘Delegate’. This is because a Course can have many Delegates, but each Delegate only belongs to one Course. So, if you're sending an email that needs both Course and Delegate details, you'd choose the Class Delegates Module, because it contains records for each individual Delegate, along with their Course information.
Check the fields available in the Module
Once you have selected the module you think you need, check the fields that are available to you to be sure.
If you’re building a Dashboard Gadget, check that the fields available make sense after you have made your module selection.
If you’re building an Email Template, check that the merge fields make sense after you have made your module selection.
Test your choice before finalising
Unless you’re confident its then always worth sense checking your results, send a test email, cross-reference your results
The accessplanit modules
Here is the detail and uses for the key modules in your accessplanit platform
Delegates
Model name & alias:
UserCourseDate (Delegates)
Description:
The Delegates module stores all records of users registered onto courses. It covers Delegates of every status (including booked, cancelled, completed, transferred, and waiting list). Trainers are also recorded in this module when they’re linked to Courses, although they do not have a status.
Key fields & their descriptions:
Date Registered – The date the Delegate was registered onto the Course
User Fullname – The full name of the user (first name and surname), this is pulled from the User module and is shared with the Delegates module
Account Name – The organisation (Company) linked to the Delegate’s booking, this is typically their Main Account/Employer, this is used for billing and reporting purposes
Course Template or Alias Name – The name of the Course the Delegate is registered on, if the Course has an alias this will be used instead of the Course Template’s name
Start Date – The date the Course will start, this field is shared from the Course module and is very useful for filtering Delegates by Course timings
Invoice Reference – The generated reference number of the Invoice the Delegate is included on, if this is empty then the Delegate is not yet included on an Invoice, if this says ‘No Reference Set’ then only a temporary Invoice exists for this Delegate. If a Delegate has had multiple Invoices, for example when they are rebooked onto a Course, this will always show the most recent Invoice Reference
Invoice Status – The current state of the Invoice (e.g. Temporary, Part Completed, Outstanding, Completed, or Cancelled”), this is helpful for filtering Delegates to see only those that are yet to pay, or have already fully paid
Is Session Delegate – Boolean (yes/no) that indicates if the Delegate is registered onto the Course as part of a sessions plan, if this is a ‘yes’ the Delegate is registered onto a Session (e.g. First Aid Day 2), if this is a no the Delegate is either registered onto a standalone Course (e.g. a 1 day Course) or a Sessional Course.
Status – Current status of the Delegate (e.g. Booked, Cancelled, Completed) on this Course
Waiting List – Boolean (yes/no) to indicate whether the Delegate is waiting for a space on the Course
May also be known as:
"Learner", "Delegate", "Participant", "Candidate", "Attendee", "Registrant", "Student", "Pupil"
Common Workflows:
Confirmation of Course registration – triggered when a Delegate is first booked, containing an overview of the Course and an explanation of what other information they will receive and when
Confirmation of Cancellation – triggered when a Delegate is cancelled
Transfer Confirmation – triggered when a Delegate is moved to another Course
Trainer Confirmation - triggered when a Trainer is first assigned to a Course
Common Filters:
Course Start Date - Period - Future
To include only Delegates registered for upcoming courses
Course Start Date - Period - Past
To include only Delegates registered on past courses
Status - Is In - Booked
To include only Delegates that are ‘Booked’ on the Course
Status - Is In - Waiting List
To include only Delegates that are ‘Waiting List’ on the Course
Account Name - Is In - [name]
To include only Delegates from a specific organisation
Is Session Delegate - Equal to - No
To exclude Delegates registered onto Sessions
Date Registered - Period - Today
To see Delegates booked/registered today
Invoice Status - Is In - Outstanding + Part Completed
To see Delegates that haven’t paid
Invoice Status - Is In - Completed
To see Delegates that have a completed Invoice
Invoice Reference Number - Is Empty
To see Delegates that haven’t been Invoiced
API feed usage:
Commonly used in integrations that push Delegate and attendance information:
Finance systems (to link Delegates to Invoices)
Learning Management Systems (LMS) (to sync Course attendance)
HR systems (to track training and compliance records for Users)