Appearance
Structuring a Course
A course is one registration. Inside it, modules let each session, week or topic carry its own content, dates and credit. This guide covers when to use modules, when to split into separate courses, and how to shape either so credit, completion, and reporting fall into place.
"Lecture" and "course" mean the same thing
LecturePanda uses both words for the same container: one sign-up, one price, one registrant list.
Modules need the course builder
Modules are built in the new course builder. It is self-serve and per person: use Try the new version at the bottom of any course's menu or in your user menu, and switch back any time with Use the classic pages. The classic pages treat a course as a single unit and edit only its first module. See The Course Builder and Course Modules.
What a course holds, and what a module holds
A course is the container for registration. A module is a section of the course with content and rules of its own. Every course has at least one module — a new course starts with one named Module 1, and a course from before modules has one named Default; both are just names you can change — and a course with a single module behaves exactly as courses always have.
| What | Belongs to | Covers |
|---|---|---|
| Registration | The course | One sign-up for everything in it, with its registration types, form questions, pricing rules, and registration security |
| Speakers | The course | Your presenters and their access to the audience response portal |
| Completion order | The course | Whether learners take the modules in any order, or Completed in order |
| Learning materials | Each module | Videos, downloadable files, on-screen text sections, and xAPI packages (Storyline, Rise and the like — learners see these under "Learning Modules", which is an older, unrelated use of the word) |
| Quizzes and evaluations | Each module | Knowledge checks, graded post-tests, and surveys, each aimed at everyone or at particular credits and registration types |
| Credits | Each module | What can be earned, which registration types earn it, the hours it carries, and the certificate it produces |
| Dates, place and webinar | Each module | Starts and Ends, and for a Live or Mixed module its location, webinar and conference line |
| Check-in | Each module | Whether attendance is taken at that session |
| Opening and closing dates | Each module | Module Opens On and Module Closes On, under Module Time Limits |
Learners see modules as parts. A course with several opens on a Parts list; the learner presses Start This Part, works through that part's materials, credits and evaluations, submits, and gets that part's certificates — without waiting for the rest of the course.
Modules are all optional. There is no "required" flag. A course is complete when every part the learner started is complete. If learners must take the modules in sequence, turn on Completed in order on the Course Outline card (Course Details page): a learner can then only start a module once the ones before it are complete.
Scoping one file to one lesson
Put the file in that lesson's module. If the lesson is a Storyline package, Storyline can also carry downloadable files inside the package itself, through its Resources panel.
Where each of these is configured
Course builder: the course menu runs top to bottom — Summary, Course Details (title, description, time zone, speakers, the Course Outline), Registration (Security, Form, Pricing, Experience), then Course Content, where each module has its own settings page and its own Materials, Credits and Quizzes pages — see Course Modules.
Classic pages: each is a tab on the course — Details, Payments, Materials, Speakers, Credits, Quizzes and Registration Security.
Modules, separate courses, or a catalog?
Three tools, three jobs:
- Modules in one course — one registration covers several sessions or sections.
- Separate courses — each has its own registration, price and registrant list. Chain them with prerequisites when order matters.
- A catalog — a public, browsable list of separate courses. It groups them for discovery; it doesn't change how any of them work. See Publishing & Sharing.
| If… | Use |
|---|---|
| People sign up once for the whole program | Modules |
| Each session has its own date, place, webinar or check-in | Modules |
| Learners should collect a certificate per session as they go | Modules (each module certifies by itself) |
| A week should open on a set date | Modules, with Module Opens On |
| Sessions must be taken in sequence, inside one program | Modules, with Completed in order |
| Each session is sold separately, or priced differently | Separate courses — pricing rules belong to the course; a module has no price |
| People pick and pay for only the sessions they want | Separate courses, gathered in a catalog |
| Sessions have different audiences, registration forms or security rules | Separate courses |
| Finishing one offering should unlock another | Separate courses, chained with prerequisites |
| You want one registrant list and one report per session | Separate courses |
| The same event repeats on several dates | Separate courses, one per date — see Running a Live Event |
What it costs is about the same either way. A registration uses one participant from your bank. In a course with several modules, the learner's first Start is included, and each further module they start uses one more. Five separate courses cost five participants for a learner who takes all five; one course with five modules costs the same learner five. The difference is a learner who only starts two of the five: two participants, not five. Details and a worked example are in How Billing Works.
Long-running programs
When content rolls out over weeks or months, make each session a module — one registration for the program, one module per session.
This used to be the case for splitting into separate courses, because a single flat course produced no completion records until the learner finished everything. Modules remove that problem:
- Each module completes, certificates and reports on its own schedule. A learner who finishes January's session in January has January's certificate in January.
- Each live module sends its own day-before and starting-soon emails, and its own reminders start when that session ends — not when the last one does.
- A module that opens later announces itself with a "now open" email.
Separate courses are still right when:
- Learners pay per session, or different learners buy different subsets
- Sessions are open to different audiences
- You need a registrant list per session — for sign-in sheets, or to cap seats per session (seat limits are per course)
If you report to an accreditor
Submission deadlines still run per credit. ACPE's window, for example, is timed from that credit's own activity date rather than from when the learner finishes the program. A module per session keeps each credit tied to its own session's dates, but a learner who leaves January's part unfinished until June is still outside the window. Check your accreditor's timing before building a long program; see ACPE Credits if that's the one you report to.
Multi-week pathways
For a guided program — a welcome video, a reading, a podcast, a checklist, and a knowledge check each week, over several weeks — build one course with a module per week.
- Give each week a Module Opens On date (turn on Module Time Limits on the module's settings page) so it is listed but locked until its week arrives.
- Turn on Completed in order if week two should also wait for week one to be finished.
That gives you per-week learning materials, per-week completion tracking, and gating between weeks, under one registration. A typical week maps onto LecturePanda like this:
| The step you have in mind | How it's built |
|---|---|
| Watch | An embedded video (Vimeo or YouTube hosted) |
| Read | On-screen lesson content rather than a PDF |
| Listen | Embedded audio |
| Download | A file in that week's learning materials |
| Knowledge check | A quiz with a passing grade and attempt limit |
| Reflect | A short response step, or built into an xAPI package |
Two things to plan around:
- When a week has to run in a strict sequence internally, author it as a single xAPI package in Articulate Rise, Storyline, Captivate, or iSpring and upload that. You get exact control over the order and flow within the week, and Rise in particular suits the guided-pathway feel. For weeks where order doesn't matter, the standard materials layout is quicker to build.
- Reminders follow each module. Learners who haven't finished are nudged weekly. Each module's 60-day reminder clock starts when that module opens (or when its live event ends), so week eight gets its own reminders even though registration was two months earlier. The nudges stop as soon as the learner completes. See Emails LecturePanda Sends.
Reminders respond to progress
Built-in reminders follow each learner's own progress, so someone who's already finished never gets chased, and a "now open" email goes out when each week unlocks. When you want something more — a personal welcome, a message from the instructor — Zapier's completion and registration triggers give you that, and the two work well together.
If you're on the classic pages, the older pattern still works: one course per week, chained with prerequisites so week two opens when week one is complete.
Live and on-demand: one course each
After a live conference, the fastest way to publish the recordings is to duplicate the course and run the on-demand version as its own. You keep the live course as a clean record of who attended, and the copy is ready for on-demand learners in a couple of clicks.
A live course is built around a live event, and each of its settings is tuned for that:
- Access codes verify live attendance, which is exactly what you want for the live session — and the on-demand version verifies a different way.
- Video tracking is typically off for live courses and on for on-demand, where watching the recording is the thing being verified.
- Day-before and starting-soon emails are timed to the live module's dates, which is right for attendees and irrelevant to on-demand learners.
- Reporting stays clean when each course serves one cohort with one set of requirements.
The clean pattern: leave the live course intact as the record for live attendees, duplicate it for on-demand, swap the code requirement on the duplicate's credits for the video tracking requirement, and let each course do its job.
A learner who takes both uses two registrations, and so two participants from your bank — worth knowing when you size it, and a small price for two sets of records that stay straightforward to report on.
Could the recording be a module on the live course instead?
It can, when the recording is for the same registrants — attendees who want to rewatch, or a home-study follow-up to the session. A Home module sends no event emails, so it won't confuse anyone. For a second cohort of on-demand learners, the duplicate is still cleaner: the live course's registrant list stays a record of who attended, registration for it can close, and each version keeps its own price and its own way of verifying participation. The bank cost is the same either way — a second module started and a second registration each use one participant.
Two audiences with different exams
When two groups share a course but sit different final exams — supervisors and staff, nurses and aides, pharmacists and technicians — give each group its own credit. Duplicate the credit, attach only the first group's exam to their credit and only the second group's exam to theirs, then set the registration types on each. Each learner sees exactly the exam that applies to them, and each group can carry its own credit hours and its own certificate.
Since a credit requires every quiz attached to it, keeping the two exams on separate credits is what makes that clean separation work. See Claiming Credit if a course already has both on one credit.
When both groups answer identical questions, a single shared quiz is the simpler build — filter the results by registration type afterwards.