# Attendance
Source: https://docs.firstrespondershub.com/cohort-management/attendance
Taking attendance for a session: Present, Late, Absent, Excused, and notes.
You can record attendance for each session so you know who was there and who was late, absent, or excused.
## Where to take attendance
1. Go to [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts) and open the cohort.
2. Open the **Schedule** tab.
3. Click the session you want (or use the action for that session), then choose **Take attendance** (or the equivalent).
A panel or page opens listing enrolled students. For each student you select a status and can add optional notes.
## Attendance statuses
* **Present** — The student attended.
* **Late** — The student attended but arrived late.
* **Absent** — The student did not attend and was not excused.
* **Excused** — The student did not attend but was excused (e.g. illness, emergency).
You can add **notes** per student (e.g. "Left at 2 PM" or "Doctor’s note on file"). Notes are for your records and are typically not shown to students.
## Saving attendance
After you set each student’s status (and optional notes), save. The attendance is stored for that session. You can reopen **Take attendance** for the same session later to change or add statuses if needed.
## Who sees attendance
Attendance is used by your organization for records and reporting. Whether students can see their own attendance (e.g. on their dashboard or in a transcript) depends on your setup; the app may show it in the student’s schedule or profile where applicable.
## See also
* [Schedule and sessions](/cohort-management/schedule-and-sessions) — How to open a session and choose Take attendance.
* [Students and invites](/cohort-management/students-and-invites) — Who is enrolled and thus listed for attendance.
# Creating a cohort
Source: https://docs.firstrespondershub.com/cohort-management/creating-a-cohort
Step-by-step: name, program offering, dates, capacity, recurring patterns, and instructors.
When you create a new cohort, you choose the program offering, set dates and capacity, define the recurring schedule (patterns), and optionally assign instructors.
## Where to start
Go to [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts) and click **Create New Cohort**, or open [**Create New Cohort**](https://www.firstrespondershub.com/program-dashboard/cohorts/create) directly.
## What you’ll set
### Basic information
* **Cohort name** — e.g. "EMT Basic Fall 2024." This is what you and students see.
* **Program offering** — The offering (program and pricing) this cohort is for. Only active offerings appear.
* **Start date** and **End date** — When the cohort runs.
* **Enrollment deadline** — Optional. The last day students can sign up. Leave it empty and sign-ups run until the class starts or fills. You can add a closing time later in Settings. See [Enrollment deadlines](/cohort-management/enrollment-deadlines).
* **Enrollment capacity** — Maximum number of students (optional).
### Schedule (recurring patterns)
You define one or more **recurring patterns** that describe when class meets—for example "Every Monday 9:00 AM–5:00 PM at Main Campus – Lecture." Each pattern has:
* **Day of week** — Monday through Sunday.
* **Name** — Short label (e.g. "Lecture Day").
* **Start time** and **End time**.
* **Location** — A location from your organization, or virtual.
* **Session types** — e.g. Lecture, Skills Lab, Clinical (one or more per pattern).
A pattern does not create class dates on its own. After you save the class, open it and go to **Settings → Schedule → Step 3 · Build the class dates**. See [Recurring patterns](/cohort-management/recurring-patterns) and [Schedule and sessions](/cohort-management/schedule-and-sessions).
### Instructors
You can assign instructors to the cohort when creating it. They’ll be available when you assign teaching to sessions later.
## After you create the class
You land on the class page. New classes start as **Getting ready**, which means nobody can sign up and the class stays off your website. That is on purpose — finish setting it up first.
Here is the order that works:
1. **Settings → Schedule → Step 3** — build the class dates from your pattern.
2. **Settings → Document fields** — fill in anything that changes per class, like a course ID.
3. **Settings → Signing up** — check the seat count and the last day to sign up.
4. **Settings → Signing up → Status** — set it to **Open**.
5. Invite students with **Invite** or **Invite a list** on the **Students** tab, or let them sign up on their own. See [Students and invites](/cohort-management/students-and-invites).
You cannot set a class to Open until it has at least one class date. If the Open option is greyed out, go back to Step 1.
## See also
* [Recurring patterns](/cohort-management/recurring-patterns) — How to define and edit patterns.
* [Class settings](/cohort-management/settings-overview) — Change anything after you create it.
* [Status and who can find it](/cohort-management/status-and-visibility) — Open the class for sign-ups.
* [Schedule and sessions](/cohort-management/schedule-and-sessions) — Build and manage the calendar.
# Cancel, archive, or delete
Source: https://docs.firstrespondershub.com/cohort-management/deleting-a-cohort
Three ways to take a class down, what each one does to students and codes, and which one you want.
Sometimes a class is not going to run. **Settings → Cancel, archive or delete** gives you three choices, listed from least to most drastic.
## Which one do I want?
| Choice | Use it when | Can you undo it? |
| ----------- | ----------------------------------------------------------------------------------- | ---------------- |
| **Cancel** | The class is not running. Low enrollment, no instructor, a change of plan. | Yes |
| **Archive** | The class is over, or you set it up and never ran it. You want it out of your list. | Yes |
| **Delete** | You made it by mistake and nobody signed up. | **No** |
Most of the time you want **Cancel** or **Archive**. Delete only works for a class with zero sign-ups, and it erases the record for good.
## Cancel the class
Cancelling calls the class off without erasing anything.
### What you see before you click
The cancel card shows three numbers so you know exactly what you are affecting:
* **Students enrolled** — and how much money they have paid.
* **Codes not sent** — access codes that are queued to be emailed, and when they would have gone out.
* **Already sent** — codes students already have. These are not affected.
### What cancelling does
* Closes enrollment and the waitlist.
* Hides the class from your organization page and from search.
* **Stops queued access codes from going out.** Those codes go back into your stock for other classes.
* Leaves every student on the roster, with their payments and paperwork, so you can transfer or refund them.
* Locks the schedule until you reopen the class.
### What cancelling does not do
* It does **not** email your students. Tell them yourself.
* It does **not** refund anyone. Refunds are separate. See [Refunds](/payment-settings/refunds).
* It does **not** take back codes students already received.
You can add a reason. It is optional and it is saved to the class history, not sent to anyone.
While a class is cancelled, its status and schedule are frozen. That is on purpose: moving dates while codes are on hold could email students a code for a class that has not started. Reopen the class first.
### Reopening
Open the same section and click to reopen. The class comes back as **Getting ready**, and its queued access codes go back in the send queue. Set the status to **Open** under **Signing up** when you are ready for students.
### Example
Your September EMT class has three students and you need eight to run it.
1. Open the class → **Settings** → **Cancel, archive or delete**.
2. Read the numbers. Three students, \$1,200 paid, four codes queued for next Tuesday.
3. Type a reason: `Low enrollment — students offered a transfer to the October class.`
4. Click **Cancel this class**.
5. Email the three students yourself and offer them the October class.
6. Transfer or refund them from the **Students** tab.
## Archive the class
Archiving files the class away. It disappears from your class list and from your website, and nobody new can sign up. Students, payments, attendance, and paperwork all stay exactly where they are.
This is the right choice for a class that is finished, or one you set up and never ran.
To undo it, click **Bring this class back**. It returns as **Getting ready**, so nobody can sign up right away.
You cannot archive a class that is cancelled — it is already hidden and already closed. If you want it filed away for good, reopen it first, then archive it.
## Delete the class
Deleting erases the class for good. There is no undo.
You can only delete a class **nobody has signed up for**. If even one person is enrolled, the delete button is replaced by two options:
* **Archive it instead.** This keeps everyone's records. It is what most people want.
* **Move every student to another class** from the Students tab, then come back and delete.
See [Students and invites](/cohort-management/students-and-invites) for how to transfer a student.
## See also
* [Status and who can find it](/cohort-management/status-and-visibility) — Statuses you pick versus statuses we set.
* [Refunds](/payment-settings/refunds) — Give money back after you cancel.
* [Refunds and unused codes](/student-access/refunds-and-unused-codes) — What happens to access codes.
# Document fields
Source: https://docs.firstrespondershub.com/cohort-management/document-fields
Values that change from one class to the next, like a course ID on a PDF or an access code detail.
Some values are the same for every class in a program. Some change every time you run it — a state approval number, a session number, a vendor course ID.
**Document fields** are how you store the ones that change. You define the field once on the program. Then each class fills in its own value.
Find them at **Settings → Document fields** on any class.
## Where the values get used
A document field can feed two things:
1. **Application PDFs.** The value is stamped onto the PDF a student fills in or signs.
2. **Access codes (credentials).** The value goes into the email and dashboard details a student receives for a course.
Under each field the page tells you what uses it, so you know what you are changing.
## Example
Your program is a state-approved EMT course. Every run gets its own course approval number from the state.
| Class | Approval number |
| ----------- | --------------- |
| Spring 2026 | `EMT-2026-0114` |
| Fall 2026 | `EMT-2026-0388` |
You add one field to the program called **State approval number**. Then on each class you type that class's number. The right number lands on every student's paperwork with no copy and paste.
## Changing a value after students have started
This is the part to read slowly. Changing a value can affect paperwork that already exists.
When you save a change, the page tells you what is affected and asks you to confirm.
| What already exists | What happens |
| -------------------------------- | ------------------------------------------------------------------------- |
| **PDFs nobody has signed** | Can be redone with the new value. Old versions are kept. |
| **PDFs students already signed** | Have to be voided. Those students get an email asking them to sign again. |
| **Access codes not sent yet** | Will use the new value when they go out. |
| **Access codes already sent** | Do not change. Students keep what they got. |
Voiding a signed PDF means the student has to sign it again. Only change a value on a signed document when you have to.
If a class's PDFs fall out of date, a yellow banner appears on this section with a **Review & update** button.
## Leaving a field empty
An empty field **holds** every document and credential that uses it. Nothing goes out half-finished.
That is deliberate. It is better for a code to wait than for a student to get a blank course ID and land in the wrong place.
## Credential details for this cohort
Under the document fields you may see a second card: **Credential details for this cohort**.
These are the access-code details for courses in this program — a course ID, a course web address, and so on. The course has a default. What you type here wins for students in this class.
* Leave it blank and students get the course default.
* If the course has no default, you have to set it here, or student access waits.
The hint under each box tells you exactly what students will get.
This card only appears when a course in the program actually has details that can change per class. If you do not see it, there is nothing to set.
## See also
* [Different values per class](/student-access/different-values-per-class) — The full story on per-class access details.
* [Applications](/enrollment/applications) — Where PDF documents come from.
* [Class settings](/cohort-management/settings-overview) — The rest of the Settings tab.
# Editing and cancelling sessions
Source: https://docs.firstrespondershub.com/cohort-management/editing-and-cancelling-sessions
Change session details (date, time, location, type) and mark a session as cancelled.
You can edit any session’s details or cancel it so students and the schedule reflect the change. Editing and cancelling are done from **Manage Session** on the cohort’s Schedule tab.
## Opening session details
1. Go to [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts) and open the cohort.
2. Open the **Schedule** tab and click the session you want.
3. Click **Manage Session** (or the equivalent), then open the **Details** tab (or the edit view that shows title, date, time, location, and cancellation).
## What you can edit
* **Title** — Name of the session (e.g. "Week 1 – Monday").
* **Description** — Optional description for students.
* **Date and time** — Start and end date and time. If the session spans more than one day, you can turn on a multi-day option and set end date/time.
* **Session type** — e.g. Lecture, Skills Lab, Clinical, Examination.
* **Location** — Physical location or virtual. If virtual, you can enter a virtual meeting link.
* **Notes** — Internal notes (typically not shown to students).
Save your changes when you’re done. The calendar and student schedule will update.
## Cancelling a session
In the same **Manage Session → Details** (or edit) view:
1. Turn on the option to **cancel** the session (e.g. "Session is cancelled" or similar).
2. Optionally enter a **cancellation reason** (e.g. "Instructor illness" or "Weather"). The reason can be shown to students so they know why the session was cancelled.
3. Save.
Cancelled sessions usually still appear on the calendar or schedule but are clearly marked as cancelled. Students see the cancelled state and the reason if you entered one. Cancelled sessions are often excluded from attendance or teaching reports, depending on the app.
## Deleting a session
If the app supports deleting a session (e.g. a "Delete session" button in Manage Session or Details), that removes the session from the schedule entirely. Use this only when the session was created by mistake or should no longer exist. Deleting is different from cancelling: cancelled sessions remain on the schedule as cancelled; deleted ones are gone.
## See also
* [Schedule and sessions](/cohort-management/schedule-and-sessions) — How to open Manage Session from the Schedule tab.
* [Session topics and segments](/cohort-management/session-topics-and-segments) — Record what was taught (Teaching tab in Manage Session).
* [Sessions and lessons](/courses/sessions-and-lessons) — Assigning lessons to a session.
# Enrollment deadlines
Source: https://docs.firstrespondershub.com/cohort-management/enrollment-deadlines
Set the last day and time students can sign up, and see exactly what closes when it passes.
Every class can have a **last day to sign up**. After it passes, no new students can join.
Set it at **Settings → Signing up → Last day to sign up**.
## Quick picks
Open the row and you get buttons for the most common answers:
| Button | What it sets |
| --------------------------- | --------------------------------------------------------- |
| **No deadline** | Sign-ups run right up to the moment class starts. |
| **1 hour before it starts** | The exact date and time, one hour before the first class. |
| **2 hours before** | Same idea, two hours. |
| **The day before** | End of the day before the start date. |
| **1 week before** | End of that day. |
| **2 weeks before** | End of that day. |
Or pick your own date, and optionally a **closing time**.
## Date, time, and timezone
* **Date with no time** — sign-ups stay open through the whole day. A May 1 deadline closes at the end of May 1.
* **Date with a time** — sign-ups close at that exact moment. May 1 at 5:00 PM closes at 5:00 PM.
* **No deadline at all** — sign-ups close when the first class meets. If the class has no dates on the calendar yet, they close at the end of the night before the start date.
Times use the **class's local timezone** — the timezone of its location. A New York class closing "May 1 at 5:00 PM" closes at 5:00 PM Eastern. A Los Angeles class closes at 5:00 PM Pacific, three hours later in real time.
If a class has no location timezone set, Eastern Time is used.
The row and the preview both show the deadline in plain words, so you can read back exactly what you set before you save.
## What closes when the deadline passes
* Paid checkout
* Free enrollment
* Application form submissions — and the form page itself shows an "applications closed" screen
The apply button disappears from the class's public page.
## What keeps working
Everyone already enrolled keeps everything: the class, the materials, the schedule, and their dashboard. Payments, payment plans, applications already submitted, and invite links all keep working.
**Only new sign-ups stop.**
## The deadline can turn a class Full
When the deadline passes, the class status changes to **Full** on its own — even if seats are still open.
That surprises people. If a class shows Full and you know it is not, check the deadline first. See [Status and who can find it](/cohort-management/status-and-visibility).
To reopen it: set the status back to **Getting ready**, change or clear the deadline, then set it to **Open**.
## Example
Your BLS class starts Saturday at 8:00 AM. You need the roster locked Friday afternoon so you can print rosters and count books.
1. Open the class → **Settings** → **Signing up**.
2. Open **Last day to sign up**.
3. Pick the date **Friday**, and set the closing time to **3:00 PM**.
4. Save.
The preview reads: *Sign-ups close Friday at 3:00 PM, the class's local time.* At 3:01 PM the apply button is gone and the class shows Full.
## Early sign-up price is a different thing
A class can also have an **early sign-up price** — a discount for people who sign up before a date. That is a price, not a cutoff. Sign-ups keep going after it passes; they just cost more.
The early deadline has to be at least one day before the last day to sign up. See [Class settings](/cohort-management/settings-overview).
## See also
* [Status and who can find it](/cohort-management/status-and-visibility) — Why a class turns Full.
* [Seats and stopping sign-ups](/cohort-management/seats-and-capacity) — Close a class early on purpose.
* [Program offering enrollment settings](/enrollment/program-offerings-settings) — Settings that shape the whole enrollment flow.
# Feedback
Source: https://docs.firstrespondershub.com/cohort-management/feedback
NPS, session surveys, category ratings, student reviews, and session survey history on the Feedback tab.
The **Feedback** tab brings together student feedback for the cohort: NPS (Net Promoter Score), session surveys, category ratings, written reviews, and session survey history. Use it to see how the cohort is going and what students thought of specific sessions or the program as a whole.
## Where to find feedback
1. Go to [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts) and open the cohort.
2. Click the **Feedback** tab.
The first time you open it, the app may load detailed feedback (ratings, reviews, surveys). You’ll then see summary cards and sections described below.
## What the Feedback tab shows
### NPS (Net Promoter Score)
If your organization collects NPS, you’ll see a summary such as promoters vs detractors and the NPS score for the cohort or offering. This reflects how likely students are to recommend the program.
### Session surveys
After sessions, students may be asked to rate the session (e.g. 1–5) and optionally leave a comment. The Feedback tab can show:
* Total number of session survey responses.
* Average session rating.
* **Recent session surveys** — A list of sessions with response count and average rating. Expanding a session may show individual responses and comments.
Use this to see which sessions were rated highly and where students left comments.
### Category ratings
If feedback is collected by category (e.g. content, instructor, materials), you may see a breakdown: each category with average rating and number of ratings. This helps you see strengths and areas to improve.
### Student reviews
When students complete the program (or at a set time), they may submit a **review** with an overall rating and optional public and private feedback. The Feedback tab can list these reviews with:
* Student name (or anonymous, depending on setup)
* Date submitted
* Status (e.g. submitted, published)
* Overall rating (e.g. stars)
* Public review text (if any)
* Private feedback (for your eyes only)
* Cohort improvement suggestion (if the student left one)
Reviews help you understand the full experience and can be published to your public profile if you use that feature.
### Session survey history
A section may list recent sessions with survey response counts and average ratings, and let you expand to read comments. This is the same session-level data as above, in a history or list form.
## Using feedback
* **During the cohort** — Check session surveys and comments to adjust pacing, content, or logistics.
* **After the cohort** — Use NPS, category ratings, and reviews for program improvement and for marketing (e.g. published reviews).
* **Private vs public** — Private feedback and cohort suggestions are for internal use; public review text can be shown on your organization’s page if you enable it.
## See also
* [The cohort page](/cohort-management/overview-and-editing) — A "How it's going" card shows the average rating once students have rated the class.
* [Schedule and sessions](/cohort-management/schedule-and-sessions) — Sessions are what students rate in session surveys.
# Cohort Management
Source: https://docs.firstrespondershub.com/cohort-management/index
Set up a class, fill the seats, run the schedule, and close it out.
A **cohort** is one run of a program. "EMT Basic — Fall 2026" is a cohort. So is "Spring Weekend Intensive." In the dashboard you may also see a cohort called a **class**. Same thing.
From a cohort you manage the people, the schedule, the settings, and the results.
## Where to find cohorts
Go to [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts). Click any class to open it.
## The five tabs
| Tab | What it's for |
| ------------ | ----------------------------------------------------------------------------------------------------- |
| **Students** | Everyone connected to the class: enrolled, invited, waitlist, people who asked about it, and results. |
| **Settings** | The class record itself — name, dates, seats, status, price, and cancelling. Program owners only. |
| **Posts** | Announcements for this class. |
| **Schedule** | The real class dates. Take attendance, move one date, or cancel one date. |
| **Feedback** | Ratings and reviews from students. |
Instructors see Students, Posts, Schedule, and Feedback. They do not see Settings, and they never see money.
## A quick tour
Say you are opening a new EMT class in September.
1. **Create the class** and pick the program it belongs to.
2. Open **Settings → Schedule** and set the first day, the last day, and which days it meets. Then build the class dates.
3. Open **Settings → Signing up**, set the seat count, and change the status to **Open**.
4. Students sign up. Watch them arrive on the **Students** tab.
5. Class runs. Instructors take attendance on the **Schedule** tab.
6. When it ends, record who passed from the **Students** tab.
## What you can do
| Topic | What it covers |
| ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| [The cohort page](/cohort-management/overview-and-editing) | The five tabs, the Students tab, seats, revenue, and recent activity. |
| [Creating a cohort](/cohort-management/creating-a-cohort) | Name, program, dates, seats, weekly pattern, and instructors. |
| [Class settings](/cohort-management/settings-overview) | The Settings tab: what each section holds and how the rows save. |
| [Status and who can find it](/cohort-management/status-and-visibility) | The three statuses you pick, the three we set for you, and public vs unlisted vs private. |
| [Seats and stopping sign-ups](/cohort-management/seats-and-capacity) | Seat counts, no-limit classes, and the one-click way to stop new sign-ups. |
| [Enrollment deadlines](/cohort-management/enrollment-deadlines) | The last day (and time) students can sign up, and what closes after it. |
| [Recurring patterns](/cohort-management/recurring-patterns) | "Every Monday, 9–5, Main Campus" — the pattern your class dates come from. |
| [Schedule and sessions](/cohort-management/schedule-and-sessions) | Building the class dates and working with them day to day. |
| [Editing and cancelling sessions](/cohort-management/editing-and-cancelling-sessions) | Move one class date, change its room, or call it off. |
| [Session topics and segments](/cohort-management/session-topics-and-segments) | Record what was taught, for how long, by whom. |
| [Attendance](/cohort-management/attendance) | Present, Late, Absent, Excused. |
| [Waitlists](/cohort-management/waitlists) | Two kinds of waitlist and how people get on them. |
| [Students and invites](/cohort-management/students-and-invites) | The roster, inviting one student or a whole list, the three tuition choices, seat holds, and transfers. |
| [Document fields](/cohort-management/document-fields) | Values that change from class to class, like a course ID on a PDF or an access code. |
| [Outcomes](/outcomes) | Recording who passed, who failed, and who earned a certification. |
| [Feedback](/cohort-management/feedback) | Ratings, session surveys, and student reviews. |
| [Cancel, archive, or delete](/cohort-management/deleting-a-cohort) | Three ways to take a class down, and which one you want. |
New here? Start with [The cohort page](/cohort-management/overview-and-editing).
# Outcomes (from a cohort)
Source: https://docs.firstrespondershub.com/cohort-management/outcomes
Record who passed, who failed, and who earned a certification — from the Results chip on the Students tab.
When a class finishes, you record what happened to each student: passed, failed, completed, withdrew, or earned a certification.
You do this from the class itself.
## Where to find it
1. Open the class from [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts).
2. Stay on the **Students** tab.
3. Click the **Results** chip.
There used to be a separate **Outcomes** tab. It now lives on the Students tab as the **Results** chip, next to Enrolled, Invited, and Waitlist.
The Results view lists every enrolled student with their result and the date it was recorded. Students with nothing recorded show **Not recorded yet**, so you can see at a glance who is left.
## Record results for the whole class
This is the fast way, and it is what most people want after an exam.
1. Click **Record results** in the seat strip at the top of the Students tab.
2. Pick the outcome type, the subtype, and the date.
3. Set each student's result and score.
4. Save.
See [Recording outcomes in bulk](/outcomes/recording-in-bulk) for the full walkthrough.
## Record one result
Use **Record outcome** and choose the student, type, subtype, date, result, and an optional score and note.
## Editing and history
Each row has **Edit**, **View history** (who changed what and when), and **Delete** for program owners.
## Withdrawing a student
To take a student out of the class, use **Unenroll** on their row. You give a reason and a date. The platform records a withdrawal outcome and frees their seat.
See [Unenrolling a student from a cohort](/outcomes/unenrolling-from-cohort) for what else changes — access, invoices, and access codes.
## A nudge near the end
As a class gets close to its end date, the Students tab shows a prompt reminding you to record results, with a button that opens the bulk sheet. It goes away once you have recorded them.
## See also
* [Outcomes](/outcomes) — The full guide, including the Results & Certifications page.
* [Outcome types](/outcomes/outcome-types) — Set up the results your programs use.
* [Recording in bulk](/outcomes/recording-in-bulk) — Step by step.
* [Unenrolling from a cohort](/outcomes/unenrolling-from-cohort) — Withdrawals.
# The cohort page
Source: https://docs.firstrespondershub.com/cohort-management/overview-and-editing
The five tabs, the Students tab, seats, revenue, and recent activity.
Open any class from [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts). The class page is where you spend most of your time.
## The header
At the top you see the program name, the class name, a **status pill**, and the dates. Two buttons sit on the right:
* **Public page** — opens the page students see.
* **Copy link** — copies that same web address so you can paste it into an email or a Facebook post.
## The tabs
| Tab | What it's for |
| ------------ | ------------------------------------------------------------------------------------------------------- |
| **Students** | Everyone connected to this class. This is the default tab. |
| **Settings** | Edit the class itself. See [Class settings](/cohort-management/settings-overview). Program owners only. |
| **Posts** | Announcements for this class. See [Posts](/posts). |
| **Schedule** | The real class dates. See [Schedule and sessions](/cohort-management/schedule-and-sessions). |
| **Feedback** | Ratings and reviews. See [Feedback](/cohort-management/feedback). |
## The Students tab
This one tab holds every kind of person attached to the class. A row of **chips** switches between them.
| Chip | Who is in it |
| ------------------ | ----------------------------------------------------------------------- |
| **Enrolled** | Students who signed up and hold a seat. |
| **Invited** | People you invited who have not accepted yet. Their seat is being held. |
| **Waitlist** | People waiting for a seat. |
| **Asked about it** | People who sent an information request about this class. |
| **Results** | Students with a recorded outcome, like passed or failed. |
Once a class starts, the **Invited**, **Waitlist**, and **Asked about it** chips disappear if they are empty. Selling is over, so the page stops showing empty lists. If any of them still has people in it, the chip stays.
Above the chips is a search box. Type a name, an email, or a phone number to filter the list you are looking at.
### The seat strip
Right under the card title is one line of numbers that tells you how the class is doing:
* **Seats** — how many are filled, how many are held by invites, and how many are open.
* **Attendance** — how many class dates have had attendance taken, once the class starts.
* **Results** — how many students have an outcome recorded.
Click **Change seats** to jump straight to Settings. Click **Record results** to open the bulk outcome sheet.
### Export
The **Export** menu gives you three files:
| Export | What's in it |
| ---------------- | -------------------------------------- |
| **Roster** | Everyone signed up. |
| **Money report** | Agreed tuition, paid, and outstanding. |
| **Waiting list** | A CSV of everyone waiting. |
## The right column
Program owners see three or four cards down the right side.
* **Recent activity** — a running list of what happened in this class: sign-ups, payments, invites, and more.
* **Revenue** — two numbers. **Revenue** is the total tuition students agreed to pay. **Collected** is the money you have actually received.
* **Sign-up pace** — a chart of how fast seats are filling. It hides itself when there is nothing to plot, and collapses once class starts.
* **How it's going** — average rating, once students have rated the class.
Instructors do not see these cards.
## Editing the class
Everything about the class record — name, dates, instructors, price, seats, status, and visibility — is edited on the **Settings** tab. See [Class settings](/cohort-management/settings-overview).
## See also
* [Creating a cohort](/cohort-management/creating-a-cohort) — Set up a new class.
* [Students and invites](/cohort-management/students-and-invites) — Invite students and transfer them.
* [Class settings](/cohort-management/settings-overview) — Change anything about the class.
# Recurring patterns
Source: https://docs.firstrespondershub.com/cohort-management/recurring-patterns
The weekly pattern your class dates come from: which days, what time, and where.
A **recurring pattern** is the weekly rhythm of a class. "Every Monday, 6–10 PM, Main Campus." "Every Wednesday, 6–9 PM, virtual, skills lab."
The pattern is a template. It does not create anything by itself. You use it to **build the class dates**, and those dates are what students and instructors actually see.
## Where to set it
**Settings → Schedule → Step 2 · Which days it meets.**
You can also set a pattern while [creating a cohort](/cohort-management/creating-a-cohort).
## The simple way
Most classes meet at the same time, in the same room, every day they meet. So the editor asks three things:
1. **Which days** — tick Monday, Wednesday, and so on.
2. **What time** — one start time and one end time for all of them.
3. **Where** — one location, or virtual.
That is it.
## When days are different
Some classes meet 6–10 PM on Monday and 9 AM–5 PM on Saturday. Turn on the switch for per-day settings and each day gets its own time, place, and session type.
If your saved schedule already varies by day, the switch turns itself on when you open the editor.
## Session types
Each day can be tagged with what kind of session it is — Lecture, Skills Lab, Clinical, Examination, and so on. This shows up for students and feeds your teaching records.
## Changing a pattern later
Saving a pattern **does not change dates that already exist**. Nothing moves until you rebuild.
That is why the pattern and the rebuild sit on the same page. After you save a pattern, Step 3 tells you whether your calendar still matches it:
* Green: *12 class dates, matching the pattern above.*
* Yellow: *These dates no longer match the pattern.* Rebuild, or leave them if you changed the calendar on purpose.
Rebuilding deletes every class date and makes new ones. Attendance, instructor hours, feedback surveys, and lesson plans attached to those dates go with them. The confirmation screen counts exactly what you would lose before you click.
## Example
Your EMT class runs Tuesday and Thursday nights, 6–10 PM, at Station 2, from September 8 to December 18.
1. Open the class → **Settings** → **Schedule**.
2. **Step 1** — first day September 8, last day December 18. Save.
3. **Step 2** — tick Tuesday and Thursday. Set 6:00 PM to 10:00 PM. Pick Station 2. Save.
4. **Step 3** — click **Build 30 class dates**.
Thirty real dates land on the calendar. Instructors can take attendance against each one.
## One-day events
An event has no pattern. It has one date, a start time, and an end time. That is the whole schedule.
## See also
* [Schedule and sessions](/cohort-management/schedule-and-sessions) — Working with the dates day to day.
* [Editing and cancelling sessions](/cohort-management/editing-and-cancelling-sessions) — Change one date without rebuilding.
* [Creating a cohort](/cohort-management/creating-a-cohort) — Set a pattern at the start.
# Schedule and sessions
Source: https://docs.firstrespondershub.com/cohort-management/schedule-and-sessions
Build the class dates from a pattern, then work with them one at a time.
There are two schedule screens, and they do different jobs.
| Screen | What it's for | Who can use it |
| ----------------------- | ------------------------------------------------------------------------- | ---------------------- |
| **Settings → Schedule** | Set up the schedule: dates, weekly pattern, and building the class dates. | Program owners |
| **The Schedule tab** | Work with the dates: take attendance, move one class, cancel one class. | Owners and instructors |
## Setting up: Settings → Schedule
Three steps, in order.
### Step 1 · First and last day
The range everything else is built inside. Set the first day and the last day of the class.
### Step 2 · Which days it meets
The weekly pattern. See [Recurring patterns](/cohort-management/recurring-patterns).
### Step 3 · Build the class dates
Turns steps 1 and 2 into real dates.
If the class has no dates yet, you get one button: **Build 30 class dates** (or however many the pattern makes).
If it already has dates, a banner tells you whether they still match the pattern:
* **Green** — the calendar matches. Nothing to do.
* **Yellow** — the pattern would make a different number of dates than the calendar has. Rebuild to bring them in line, or leave them alone if you changed the calendar on purpose.
### Rebuilding
**Rebuilding replaces every class date, and it cannot be undone.**
Before you confirm, the screen counts exactly what would be deleted with them:
* Attendance records
* Instructor hour entries — these feed instructor pay
* Student feedback surveys
* Lesson plans attached to a date
* Per-date instructor assignments
* Dates you added by hand — the pattern will not recreate these
* Cancelled dates come back as normal classes
Read that list before you click.
Most of the time you do **not** need to rebuild. If one date moved, edit that one date instead.
## Day to day: the Schedule tab
The **Schedule** tab shows the calendar of real class dates. Click any date to work with it.
* **Manage session** — change the title, date, time, location, or type; add notes; cancel the date; record what was taught; attach lessons; and see the history of changes.
* **Take attendance** — mark each student Present, Late, Absent, or Excused.
Instructors use this tab. They never see Settings.
## Which one do I want?
| You want to… | Go to |
| ---------------------------------------- | ------------------------------------------ |
| Set up a brand-new class | Settings → Schedule |
| Add a day to the weekly pattern | Settings → Schedule, then rebuild |
| Move one class from Tuesday to Wednesday | Schedule tab → that date → Manage session |
| Cancel one snow day | Schedule tab → that date → Manage session |
| Take attendance | Schedule tab → that date → Take attendance |
## If you move the class dates
Moving a class's start date also moves any **access codes** that were scheduled to go out relative to the start. The platform re-dates them for you and tells you how many moved. See [When students get access](/student-access/when-students-get-access).
## See also
* [Recurring patterns](/cohort-management/recurring-patterns) — Define the weekly rhythm.
* [Editing and cancelling sessions](/cohort-management/editing-and-cancelling-sessions) — Change a single date.
* [Session topics and segments](/cohort-management/session-topics-and-segments) — Record what was taught.
* [Attendance](/cohort-management/attendance) — Take attendance.
* [Sessions and lessons](/courses/sessions-and-lessons) — Attach lessons to a date.
# Seats and stopping sign-ups
Source: https://docs.firstrespondershub.com/cohort-management/seats-and-capacity
Set how many seats a class has, run a class with no limit, and close sign-ups in one click.
**Settings → Signing up → How many seats** controls how many students can join the class.
The saved row reads like this:
`24 seats · 18 taken · 6 open`
## Setting the number
Click **Edit**. Use the **−** and **+** buttons, or type the number.
**Taken** means enrolled students **plus** invited people who have not accepted yet. An invite holds a seat.
You cannot set the seat count below the number already taken. If 18 seats are taken, 18 is the lowest you can go. To go lower, cancel an invite or unenroll a student first.
The most seats a class can have is 500.
### Seats held by "must pay before enrolling" invites
An invite that requires payment first holds its seat only until the **hold date** you set when you sent it. If the money never arrives, we cancel the invite and give the seat back on our own, once a day. You do not have to watch for it.
The hold never runs past the class start date. See [Students and invites](/cohort-management/students-and-invites#hold-the-seat-for).
## Running with no limit
A class can have no seat limit at all. Then anyone can sign up until the class starts, or until the last day to sign up.
* To remove a limit, open the row and click **Remove the limit**.
* To add one back, click **Set a limit**.
With no limit, the class never turns Full on its own, because there is no last seat to fill.
## What happens when the last seat fills
The class turns **Full** by itself. Anyone else who tries to enroll can join the waitlist instead.
You do not need to watch for this or do anything.
## Stop new sign-ups
Sometimes you want to close a class early. Maybe the room is smaller than you planned, or you decided 12 students is enough.
Open the **How many seats** row and scroll past the Save button. You will see **Stop new sign-ups**.
Click **Stop sign-ups at 12** (or whatever your current number is) and three things happen:
1. The seat count is set to exactly what is already taken.
2. The class turns **Full**.
3. Anyone else who tries to enroll can join the waitlist.
Everyone already enrolled or invited keeps their seat.
This button saves on its own. The Save button above it is only for the seat count.
### One thing to watch
If the class is **Getting ready** or on a **Pre-enrollment waitlist**, stopping sign-ups opens it first, then marks it Full. Opening a class puts it on your website. The page warns you before you click.
## Example
You planned an EMT refresher for 30 students. Twelve signed up, and the training room you booked only fits 12 anyway.
1. Open the class → **Settings** → **Signing up**.
2. Open **How many seats**.
3. Click **Stop sign-ups at 12**.
The class now shows Full. The twelve students keep their seats. Number thirteen lands on the waitlist, so you have a list to call from if someone drops.
## See also
* [Status and who can find it](/cohort-management/status-and-visibility) — What Full means and who sets it.
* [Waitlists](/cohort-management/waitlists) — What happens to people who arrive after the seats run out.
* [Students and invites](/cohort-management/students-and-invites) — Cancel an invite to free a seat.
# Session topics and segments
Source: https://docs.firstrespondershub.com/cohort-management/session-topics-and-segments
Where to record what was taught in each session: topics, duration, and instructors (Teaching tab).
Session **segments** let you record what was actually taught in a session—which topics, for how long, and by which instructors. That supports instructor hours for CME or recertification and gives you a clear record of what was covered.
## Where it lives
1. Go to [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts) and open the cohort.
2. Open the **Schedule** tab and click the session.
3. Click **Manage Session**, then open the **Teaching** tab.
In the Teaching tab you add one or more **segments**. Each segment has a **teaching topic** (from your organization’s topic list), a **duration**, and **instructor(s)**. Segment durations should add up to the total session length.
## Why use segments
* **Instructor hours** — Time per topic and per instructor is used for the [Instructor Hours report](/teaching-topics-and-instructor-hours/instructor-hours-report) (e.g. for CME or recertification).
* **Audit trail** — You can see what was taught when and by whom. The **History** tab in the same Manage Session panel shows past changes to teaching assignments.
* **Co-teaching** — You can assign more than one instructor to a segment; each gets full credit for that segment’s duration in the report.
## Full details on segments and topics
For a full walkthrough of segments (how to add them, set duration, assign instructors, and use the History tab), see [Session segments (Manage Teaching)](/teaching-topics-and-instructor-hours/session-segments).
To manage the list of teaching topics your organization can use in segments, see [Teaching topics](/teaching-topics-and-instructor-hours/teaching-topics).
## See also
* [Schedule and sessions](/cohort-management/schedule-and-sessions) — How to open Manage Session from the Schedule tab.
* [Session segments (Manage Teaching)](/teaching-topics-and-instructor-hours/session-segments) — Detailed guide to segments.
* [Teaching topics](/teaching-topics-and-instructor-hours/teaching-topics) — Set up and manage your topic list.
* [Instructor Hours report](/teaching-topics-and-instructor-hours/instructor-hours-report) — How segment data is used in the report.
# Class settings
Source: https://docs.firstrespondershub.com/cohort-management/settings-overview
The Settings tab: what each section holds, how rows save one at a time, and what changes when you save.
The **Settings** tab is where you change the class itself: its name, its dates, its price, how many seats it has, and whether people can sign up.
Only program owners see this tab. Instructors do not.
## How the page works
Settings has a menu down the left side. Pick a section and its rows appear on the right.
Each row shows what is saved right now. Click **Edit** and the row opens in place. Change it, then click **Save**.
**Rows save one at a time.** Saving the name does not touch anything else. If one row will not save, the rest of your work is safe.
Closing a row without saving throws away what you typed. Nothing is lost from the saved record.
Some rows do not have a Save button, because picking an option saves right away. Those rows say so at the top.
## The sections
| Section | What's in it |
| ----------------------------- | ------------------------------------------------------------------------------------------- |
| **The basics** | Class name, who teaches it, tuition, and the early sign-up price. |
| **Schedule** | First and last day, which days it meets, and building the class dates. |
| **Signing up** | Status, seat count, last day to sign up, who can find the class, and where students enroll. |
| **Document fields** | Values that change between classes, like a course ID that goes on a PDF or an access code. |
| **Cancel, archive or delete** | Three ways to take the class down. |
## The basics
### Name
The program name always sits in front of the class name. So name only the part that tells this class apart from the next one — when it runs and when it meets.
**Good:** `Sep - Dec 2026 - Monday & Wednesday Nights`
Students then see: **EMT Basic: Sep - Dec 2026 - Monday & Wednesday Nights**
**Not so good:** `EMT Basic Fall` — the program name is already there, so students see "EMT Basic: EMT Basic Fall."
The name can be up to 70 characters.
### Who teaches it
Pick one or more instructors. Instructors can see the roster, take attendance, and mark who passed. **They never see money.**
### Tuition
Tuition is set on the **program**, not on the class. Every class in that program shares it. The row shows the price and a link to open the program if you need to change it.
### Early sign-up price
A lower price for students who sign up before a date you choose. Turn on the switch, enter the price, and pick the last day for it.
Two rules the page checks for you:
* The early price has to be **lower** than the tuition.
* The early deadline has to be **at least one day before** the last day to sign up.
Students see the early price with the regular tuition crossed out next to it. After the deadline, the regular price applies on its own. You do not have to do anything.
## Schedule
See [Schedule and sessions](/cohort-management/schedule-and-sessions). In short, it is three steps in order:
1. **First and last day** — the range everything else is built inside.
2. **Which days it meets** — the weekly pattern, like Monday and Wednesday, 6–10 PM.
3. **Build the class dates** — turns steps 1 and 2 into real dates on the calendar.
A one-day event is simpler: one date, a start time, and an end time.
## Signing up
This section answers two different questions, and it is worth keeping them apart:
* **Status** — where the class is in its life. Is it open for sign-ups?
* **Who can find this class** — who is allowed to see it at all.
See [Status and who can find it](/cohort-management/status-and-visibility) and [Seats and stopping sign-ups](/cohort-management/seats-and-capacity).
Two rows in this section are set on the **program**, not the class, so you can read them but not change them here:
* **Where students enroll** — on FirstRespondersHub, on your own website, or nowhere (the page shows a "Request information" form instead).
* **Tuition**, back in The basics.
If your program sends students to your own website and asks each class for its own link, an **External application link** row appears. If you leave it empty, the apply button is hidden on that class's public page.
## Document fields
See [Document fields](/cohort-management/document-fields).
## Cancel, archive or delete
See [Cancel, archive, or delete](/cohort-management/deleting-a-cohort).
## See also
* [The cohort page](/cohort-management/overview-and-editing) — What the other tabs do.
* [Enrollment deadlines](/cohort-management/enrollment-deadlines) — The last day and time students can sign up.
# Status and who can find it
Source: https://docs.firstrespondershub.com/cohort-management/status-and-visibility
The three statuses you pick, the three we set for you, and public vs unlisted vs private.
Two settings on **Settings → Signing up** decide whether anyone can sign up for your class. They sound alike, but they answer different questions.
* **Status** — where the class is in its life.
* **Who can find this class** — who is allowed to see it at all.
A class that is **Open** but **Private** takes no sign-ups from the public, because nobody outside your roster can find it.
## Status
### The three you pick
| Status | What it means |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Getting ready** | Nobody can sign up, and the class stays off your website. Use this while you set it up. |
| **Pre-enrollment waitlist** | Sign-ups are not open yet, but people can add their name now. Use it to see who wants a seat before you start selling. |
| **Open** | Students can sign up and pay. |
Pick one and it saves right away. There is no Save button.
### The three we set for you
You never pick these. The platform sets them.
| Status | When it switches on |
| ----------------- | ----------------------------------------------------------- |
| **Full** | The last seat fills, **or** the last day to sign up passes. |
| **Happening now** | The first class date starts. |
| **Finished** | The last class date ends. |
**Full has two triggers, not one.** A class can turn Full with seats to spare if its sign-up deadline has passed. If a class went Full and you cannot see why, check the last day to sign up.
When a class is Full, anyone else who tries to enroll can join a waitlist. That is the sold-out waitlist — not the same as the **Pre-enrollment waitlist** status you pick before selling starts. See [Waitlists](/cohort-management/waitlists).
### When a status is greyed out
If you cannot pick a status, the card tells you why. The common reasons:
| Message | What to do |
| ------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| "Add a class date under Schedule first." | Build the class dates in **Settings → Schedule**. |
| "This class has already started, so it cannot take sign-ups." | Nothing. A class in the past cannot reopen for sign-ups. |
| "The last day to sign up has passed." | Change or clear the sign-up deadline in the row below. |
| "Every seat is taken." | Add seats, or cancel an invite. |
| "Set it to Getting ready first." | The class is Full. Go back to Getting ready, then fix seats or the deadline. |
| "Reopen the class first." | The class is cancelled. Reopen it under **Cancel, archive or delete**. |
**Archived** and **Cancelled** are not statuses you pick here. Both live under [Cancel, archive, or delete](/cohort-management/deleting-a-cohort).
## Who can find this class
Three choices. Picking one saves right away.
| Choice | Who can see it |
| ------------ | ------------------------------------------------------------------------------ |
| **Public** | Anyone. It shows on your organization page and in search. |
| **Unlisted** | Only people you send the link to. It is hidden from your page and from search. |
| **Private** | Only students you invite. There is no public page to share. |
### Example
You are running a department-only refresher for one fire company. You do not want it on your website, but you do want to email a sign-up link to the crew.
Set the class to **Open** and **Unlisted**. Copy the link from the **Copy link** button at the top of the class page, and email it out.
The program can be more restrictive than the class. If the program is set to Unlisted or Private, this class is at least that restricted no matter what you pick here. The page tells you when that is happening.
## See also
* [Seats and stopping sign-ups](/cohort-management/seats-and-capacity) — Set the seat count, or close a class early.
* [Enrollment deadlines](/cohort-management/enrollment-deadlines) — The last day and time students can sign up.
* [Waitlists](/cohort-management/waitlists) — The two kinds of waitlist.
# Students and invites
Source: https://docs.firstrespondershub.com/cohort-management/students-and-invites
The roster, inviting one student or a whole list, the three tuition choices, seat holds, and moving a student to another class.
The **Students** tab is your roster. It shows everyone connected to the class. From here you invite people, decide how they pay, and move a student to another class.
## Where to find the roster
1. Go to [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts) and open the class.
2. You land on the **Students** tab. The big card is called **People**.
3. Click a chip to switch lists: **Enrolled**, **Invited**, **Waitlist**, **Asked about it**, **Results**.
Use the search box above the chips to find someone by name, email, or phone.
Three buttons sit at the top right of the People card:
| Button | What it does |
| ----------------- | ----------------------------------------------------- |
| **Invite** | Invite one person. Opens a panel on the right. |
| **Invite a list** | Upload a CSV and invite everyone in it. |
| **Download** | Export the roster, the money report, or the waitlist. |
Both invite buttons turn off when every seat is taken. Free up a seat first, or raise the seat count. See [Seats and stopping sign-ups](/cohort-management/seats-and-capacity).
## Inviting one student
Click **Invite**. A panel titled **Invite student** slides in from the right.
1. Type the student's **Email**. This is the only required field.
2. Add a **First name** and **Last name** if you have them.
3. Under **Tuition**, pick how this student pays. There are three choices, explained below.
4. Click **Send invite**.
The panel switches to **Student invited**. We already emailed the link; the panel shows it so you can copy it and send it by text or chat too. Then click **Invite another** or **Close**.
## The three tuition choices
Every invite uses one of these. Pick the one that matches how you collect the money.
| Choice | What happens | Use it when |
| ----------------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| **No tuition owed** | The student joins with a \$0 balance. | The bill is handled outside FirstRespondersHub — a department pays you directly, or the class is free to them. |
| **Enroll now, invoice after** | The student joins as soon as they accept. An invoice is waiting in their dashboard. | You trust them to pay after they start. |
| **Must pay before enrolling** | We hold the seat, but they are not enrolled until their payment goes through. | You want the money first. |
When you pick either of the last two, a **Tuition amount** box appears. It is filled in with the class price. Change it for this one student if you need to — a partial scholarship, a prorated transfer, a one-off discount.
**Why "Must pay before enrolling" matters.** Enrolling a student sets off everything an enrollment sets off, including sending a vendor access code. With this choice there is no enrollment until the money lands, so nothing goes out early.
## Setting up "Must pay before enrolling"
Pick that choice and one more block appears: **What they can choose to pay**.
### What they can choose to pay
Check every option you want to offer. The student picks one.
| Option | What the student pays now | What happens next |
| ----------------- | ------------------------- | ---------------------------------------------------------------------------------- |
| **Pay in full** | The whole tuition. | Nothing else to pay. |
| **Pay a deposit** | The deposit you set. | The rest becomes an invoice after they join, due on the program's normal schedule. |
| **Payment plan** | The down payment. | Monthly installments are charged to the same card automatically. |
If you check **Pay a deposit**, a **Deposit amount** box appears under it.
An option is greyed out when the program does not allow it. The line under it tells you why, for example *"Turn on deposits for this program to offer them on invites."* Fix it on the program offering, then come back. See [Payment configurations](/payment-settings/payment-configurations).
### Hold the seat for
Below the options is **Hold the seat for \_\_\_ days**. This is how long the seat stays reserved while you wait for the money.
* The default comes from the program. You can change it per invite.
* Allowed range: **1 to 90 days**.
* A hold never runs past the class start date. If it would, we shorten it and warn you right in the panel: *"This cohort starts Mar 15 — the hold will end then, not in 30 days."*
* A hold is always at least one day long, even if the class already started.
When the hold ends and no money has arrived, we cancel the invite and put the seat back. That happens on its own once a day.
## Rules to know
These are checked when you send. If something is off, you get a plain message telling you which field to fix.
* Tuition must be more than **\$0** whenever you charge.
* A deposit must be more than **\$0** and **less than** the tuition.
* You must offer at least one way to pay.
* A payment plan needs a **down payment above \$0**. With no down payment we would collect nothing before the student enrolls, which defeats the point.
* Payment plans need a **Growth** or **Scale** plan and a set number of installments.
* You cannot offer something the program has switched off. The program's payment settings always win.
* **The terms are locked in when you send.** If you edit the program's payment settings later, invites you already sent keep the terms the student was shown.
## Where the defaults come from
You should not have to re-decide all of this every time. Open the program offering → **Payment Configuration** → **Invited Students** and set your normal choice there. Every invite panel opens with those settings already filled in, and you can still change them for one person.
See [Payment configurations](/payment-settings/payment-configurations#invited-students).
## Inviting a list (CSV)
Click **Invite a list**.
1. Upload a CSV. The first row must be headers, and one column must be **email**. First and last name columns are optional. Header names are flexible — `email`, `Email`, `first_name`, and `firstName` all work.
2. Review the list. Good rows show as **Valid**; bad ones show as **Invalid** and are skipped.
3. Under **Tuition for everyone in this list**, pick one of the same three choices. It applies to the whole file.
4. If you pick **Must pay before enrolling**, set the payment options, deposit, and seat hold the same way as a single invite.
5. Send.
The result screen shows how many invites were **Created**, **Skipped** (they already had a pending invite or were already enrolled), and how many had **Errors**.
Use **Download Example CSV** on the upload screen to get a file with the right headers.
## Reading the Invited list
Click the **Invited** chip. The table has four columns.
| Column | What it shows |
| ------------------- | ------------------------------------------------------------- |
| **Person** | Name and email. |
| **Tuition & terms** | The amount, plus one short line about where the money stands. |
| **Invited** | The day you sent it. |
| **Email sent** | The day the email went out, or **Sending…**. |
The line under the amount tells you the real status:
| You see | It means |
| ----------------------------------------------------------------------- | ---------------------------------------------------- |
| **Paid externally** | No tuition owed. Nothing to collect here. |
| **invoice after they accept** | They get an invoice once they join. |
| **pay first · not started · hold ends Mar 3** | They have not picked a way to pay yet. |
| **pay first · awaiting full payment** (or *deposit*, or *payment plan*) | They picked, but the money is not in yet. |
| **paid \$985.00 · finishing signup** | They paid. They still have to click through to join. |
| **hold expired** | The hold ran out. The seat went back. |
## Resending, copying, and cancelling
Open the **⋯** menu at the end of any row in the Invited list.
* **Copy link** — grab the invite link to send it yourself.
* **Re-send invite** — send the same email again.
* **Cancel invite** — shut the invite off. The link stops working and the seat is free again.
Cancelling a **Must pay before enrolling** invite also cancels the student's payment link. That is on purpose. Without it, they could pay for a seat that is gone. If we cannot cancel the payment link, we leave the invite active and ask you to try again.
## Automatic reminders
You do not have to chase people. If an invite is not accepted, we send reminder emails on our own:
* The first one goes out **2 days** after the invite.
* After that, at least **2 days** pass between reminders.
* Up to **10** reminders per invite.
Reminder emails match the invite. A student being charged tuition is told about the tuition, and a student whose seat is on hold is told when the hold ends. You can still use **Re-send invite** any time.
A student paying their own tuition gets one reminder stream, not two. They never get the "complete a sponsored purchase" emails meant for employers and departments.
## What the student goes through
1. **The email.** It names the class and says exactly how tuition works: no balance, an invoice after they join, or *"Your seat is being held until March 3 — pay tuition of \$985.00 to claim it."*
2. **The invite page.** They sign in, or create an account, using the same email you invited. A different email is blocked.
3. **Forms first.** If your program requires an application or agreements, they finish those before anything else. Nobody pays and then finds out they cannot complete the paperwork.
4. **What you'll pay.** They see the amount and, for a pay-first invite, the options you allowed. They pick one and click **Pay & join**.
5. **Payment.** They pay on a hosted page. They get a **"Payment received — finish joining"** email.
6. **Joining.** They come back and finish. Now they are enrolled.
7. **Anything left over.** A deposit leaves a balance invoice with a working pay button and a due date. A payment plan sets up the monthly installments on the card they just used.
An invoice from an invite is never late the day it is made. If the normal due date would already be in the past, we move it out to **at least 7 days from today**. That way the student still gets the reminder emails before it goes overdue.
## Seat holds and your seat count
An invite that has not been accepted still takes a seat. That is why you cannot drop the seat count below the number taken.
* **No tuition owed** and **Enroll now, invoice after** invites hold the seat until they accept or you cancel.
* **Must pay before enrolling** invites hold the seat until the hold date. After that we cancel the invite and give the seat back, once a day, on our own.
See [Seats and stopping sign-ups](/cohort-management/seats-and-capacity).
## Transferring a student to another class
If a student needs a different start date or a different location, transfer them instead of refunding and re-enrolling.
1. Find the student under the **Enrolled** chip.
2. Use **Transfer** on their row.
3. Pick the class they are moving to and confirm.
Their enrollment moves. They lose the old class's schedule and materials and gain the new one's. Payments follow the enrollment.
### What happens to their access codes
If the course sends vendor access codes:
* A code that has **not been sent yet** is taken back from the old class and reissued for the new one. The activity log calls this *Moved to the new class*.
* A code that has **already been sent** stays with the student. They keep it.
See [Refunds and unused codes](/student-access/refunds-and-unused-codes).
## See also
* [Payment configurations](/payment-settings/payment-configurations#invited-students) — Set the defaults every invite starts with.
* [Seats and stopping sign-ups](/cohort-management/seats-and-capacity) — Seats, and why an invite counts as one.
* [Waitlists](/cohort-management/waitlists) — When a spot opens, enroll someone from the waitlist or invite them.
* [Invoices and balances](/payment-settings/invoices-and-balances) — Invoices, payment links, and reminders after the student joins.
* [Payment plans](/payment-settings/payment-plans) — How monthly installments are charged.
* [When students get access](/student-access/when-students-get-access) — Why a held seat does not hand out an access code.
# Cohort waitlists
Source: https://docs.firstrespondershub.com/cohort-management/waitlists
The two kinds of waitlist, how people get on one, and how to email the list.
A **waitlist** is a list of people who want a seat in a class they cannot have yet.
There are two kinds, and they happen at different times.
| Kind | When it happens | How you turn it on |
| --------------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------- |
| **Pre-enrollment waitlist** | Before you start selling. You want to know who is interested. | Set the class status to **Pre-enrollment waitlist**. |
| **Sold-out waitlist** | After every seat is taken. | Nothing to turn on. It opens by itself when the class turns Full. |
Both feed the same list.
## Where to find the list
1. Open the class from [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts).
2. Stay on the **Students** tab.
3. Click the **Waitlist** chip.
You see everyone waiting: name, status, phone, and the date they joined.
The Waitlist chip hides itself once the class starts **if the list is empty**. If people are still on it, the chip stays.
## Three buttons
* **Email the list** — sends a message to everyone eligible. Sending shows progress, and people who have been contacted are marked so you do not email them twice by mistake.
* **Add someone** — put a person on the list yourself. Enter their name, email, and phone.
* **Download CSV** — a spreadsheet of everyone waiting.
You can also download the waitlist from the **Export** menu at the top of the Students tab.
## How people get on the list
* They click the waitlist button on your class page, when the class is Full or on a pre-enrollment waitlist.
* You add them by hand with **Add someone**.
* You add them from a lead's profile. See [Waitlists (Leads)](/leads/waitlists).
## When a seat opens
Waitlist entries do not convert on their own. When someone drops, you decide who gets the seat.
1. Free up the seat — cancel an invite or unenroll the student.
2. Raise the seat count if you had lowered it. See [Seats and stopping sign-ups](/cohort-management/seats-and-capacity).
3. Invite the person from the waitlist with the **Invite** button on the Students tab. If you want the money before the seat is really theirs, pick **Must pay before enrolling** on the invite. See [Students and invites](/cohort-management/students-and-invites).
## Example
Your 20-seat CPR class sells out in a week. Six more people join the waitlist.
Two students drop. You:
1. Unenroll the two students, which frees two seats.
2. Set the status back to **Open** if it turned Full.
3. Email the waitlist and invite the first two who reply.
## See also
* [Status and who can find it](/cohort-management/status-and-visibility) — Pre-enrollment waitlist vs Full.
* [Students and invites](/cohort-management/students-and-invites) — Invite someone off the waitlist.
* [Waitlists (Leads)](/leads/waitlists) — Add a lead to a class waitlist.
# The contact record
Source: https://docs.firstrespondershub.com/contacts/contact-record-and-sources
What is stored on a contact, where contacts come from, what program interest means, and the three email statuses.
A contact is one person in your address book. Their **email address** is what makes them unique — one email, one contact.
## What's on a contact
| Field | Notes |
| ----------------------- | --------------------------------------------------------------------- |
| **Email** | Required. This is what keeps duplicates out. |
| **First and last name** | Optional. You can edit these. |
| **Phone** | Optional. You can edit this. |
| **Original source** | How they first showed up. This never changes. |
| **Program interests** | Which programs they care about. Usually filled in for you. |
| **Tags** | Labels you make up and apply. A contact can have as many as you like. |
| **Email status** | Active, Unsubscribed, or Bounced. |
| **Created date** | When they were first added. |
## Where contacts come from
Every contact has one **original source**, set the first time their email shows up in your organization.
| Source | What it means |
| ------------------ | ------------------------------------------------------------------------ |
| **Lead** | They filled in the Request Program Information form on your public page. |
| **Cart abandoned** | They started checkout and did not finish. |
| **Waitlist** | They joined a class waitlist and were not already a contact. |
| **Enrolled** | They enrolled in a class. |
| **Imported** | You uploaded them from a spreadsheet. |
| **Manual** | You added them by hand. |
The original source never changes, even if the person comes back another way.
Say you import Dana from a spreadsheet. Six months later, Dana fills in your info request form. Dana's source is still **Imported**. But Dana now picks up a new program interest and a new lead record.
## Program interest
**Program interest** is the answer to "which of my programs does this person care about?"
A contact gains interest in a program when they:
* Join a waitlist for any class in it
* Send an information request about it
* Start checkout for a class in it and stop
* Are imported with that program selected
Interest goes away when they enroll in a class of that program, or when you remove it by hand.
This is the useful part: interest survives from one class to the next. When your next EMT class opens, you can email everyone who ever showed interest in EMT — not just the people who asked this month.
## The three email statuses
| Status | What it means |
| ---------------- | ---------------------------------------------------------------------- |
| **Active** | You can email them. |
| **Unsubscribed** | They clicked unsubscribe. They are left out of every future send. |
| **Bounced** | An email to them hard-bounced. They are left out of every future send. |
You cannot switch someone back to Active yourself. That is deliberate — it is what keeps you on the right side of anti-spam law. Someone who wants back in has to opt in again through your public form.
You can filter the contacts table by status, and the counts for each status sit at the top of the page.
## The detail panel
Click any row to open the contact. From there you can:
* Edit the name and phone
* Add and remove tags, including making a new tag on the spot
* See which programs they are interested in and which classes those tie to
* Read their history: form submissions, waitlist joins, enrollments, abandoned checkouts
* Use **Promote to lead** to start tracking them as a [lead](/leads) for a specific program
## See also
* [Tags](/contacts/tags) — Labels you control.
* [Custom lists](/contacts/custom-lists-and-audience-builder) — Build an audience from these fields.
* [Unsubscribe and compliance](/contacts/unsubscribe-and-compliance) — The rules behind the statuses.
# Custom lists and the audience builder
Source: https://docs.firstrespondershub.com/contacts/custom-lists-and-audience-builder
Build filter-based custom lists, preview the match count live, save, edit, and email directly from a list.
A **custom list** is a saved set of filter conditions that resolves live — every time you open it or send email to it, the system recomputes who matches. That means a list like "Interested in EMT and not enrolled" stays correct as contacts join, leave, and enroll.
## Opening the audience builder
From the **Overview** tab on Contacts, click **New custom list**. A side sheet opens with:
* **List name** — Required.
* **Condition rows** — One or more filter conditions, joined with AND.
* **Live preview** — As you edit, the builder shows the match count and sample names with a short debounce.
* **Save** — Writes the list; **Save and email** opens the email composer scoped to the list.
## Filter conditions
Each row has a **property**, an **operator**, and a **value**. Available properties:
| Property | Operators | Value |
| ------------------------- | ------------------------------------------------------- | --------------------------------------------------------- |
| **Interested in program** | is / is not | A program offering |
| **Enrollment status** | has enrolled in / has never enrolled in / has completed | A program offering |
| **Cohort** | is enrolled in / is on waitlist for | A cohort |
| **Source** | is / is not | Lead form, Waitlist, Enrolled, Imported, Manual |
| **Email status** | is | Active, Unsubscribed, Bounced |
| **Tag** | has tag / does not have tag | An org tag |
| **Date added** | is in the last / is after / is before / is between | Relative (7d, 30d, 60d, 90d, 6mo, 1yr) or a specific date |
| **Date enrolled** | same date operators | Optionally scoped to a program |
| **Date completed** | same date operators | Optionally scoped to a program |
| **Date joined waitlist** | same date operators | Optionally scoped to a program |
Conditions combine with **AND** — a contact must satisfy every row to be included.
To build **OR** logic (e.g. "interested in EMT OR interested in Paramedic"), save separate custom lists and email them in two sends, or use the **Tag** property to consolidate across programs.
## Live preview
The preview updates after a short debounce as you edit. It shows:
* Total matching contact count (excluding unsubscribed and bounced by default)
* A few sample contact names
If the preview is `0`, double-check date ranges and program selections — a common mistake is combining `Interested in program X` with `Has never enrolled in X`, which is valid but narrower than it looks.
## Saving and editing
* **Save** — Stores the list for reuse. It appears under **Saved custom lists** on the Overview tab.
* **Edit** — From the Overview tab, open a saved list to see its resolved contacts. Use **Edit filters** to re-open the builder; your conditions are reloaded exactly.
* **Delete** — From the saved list detail page or the list row menu.
Because lists resolve live, editing a condition changes who will receive future emails sent to that list. Past sends are unaffected — [Send History](/contacts/send-history-and-deliverability) records the exact audience size at send time.
## Emailing a list
Three ways to email a list:
1. From the builder, click **Save and email** — opens the email composer with the list pre-selected.
2. From the Overview tab, use the list's row menu → **Send email**.
3. From the email composer, choose audience type **Custom list** and pick the saved list.
Contacts with status `Unsubscribed` or `Bounced` are always excluded at send time, even if they match the filter conditions.
# Email campaigns
Source: https://docs.firstrespondershub.com/contacts/email-campaigns
Compose and send an email to a contact audience: audience picker, recipient count preview, test sends, and what's attached to every email.
The composer sends one email to any group of contacts you choose.
That might be everyone interested in a program, one class's waitlist, a saved list, or everyone with a tag.
## Opening the composer
The composer opens from several entry points, each pre-scopes the audience:
* **Overview tab** — Click **Send email** on a program or cohort card to email that audience directly.
* **Overview → Saved custom list** → **Send email**.
* **All Contacts → bulk select → Send email** — Scoped to the selected contacts only.
* **Custom list builder → Save and email** — Opens pre-scoped to the list you just saved.
You can also open it blank and pick an audience.
## Audience types
| Audience | Who it resolves to |
| ------------------------- | -------------------------------------------------------------- |
| **All contacts** | Every active contact in the organization. |
| **Interested in program** | Contacts with program interest in the selected offering. |
| **Cohort students** | Contacts enrolled in the selected cohort. |
| **Cohort waitlist** | Contacts on the selected cohort's waitlist. |
| **Custom list** | The contacts currently matching a saved custom list's filters. |
| **Tagged contacts** | Contacts with a specific tag. |
Contacts with email status `Unsubscribed` or `Bounced` are always excluded. The dialog shows both the eligible recipient count and the excluded count.
## Writing the email
* **Subject** — Required.
* **Body** — Plain text. Line breaks render as `
` in the delivered email. Rich text is not currently supported.
Every delivered email automatically includes:
* Your organization's name and address (from organization settings)
* A per-recipient unsubscribe link (see [Unsubscribe and compliance](/contacts/unsubscribe-and-compliance))
* A CAN-SPAM compliant footer
## Recipient count preview
The composer fetches the eligible recipient count as you change the audience, with a short debounce. Counts refresh when you change the audience, program, tag, or saved list.
The preview is also the pre-send safety check — if the count is `0`, the send button is disabled.
## Test send
Before sending for real, click **Send test**. The test goes to your own email address (the one you're signed in with) with:
* The same subject and body as the real send
* `[TEST]` prefix on the subject line
* The CAN-SPAM footer rendered
Test sends don't count against your monthly email quota.
## Sending
Clicking **Send** queues a background job (Inngest) that sends sequentially with rate limiting to protect deliverability. The dialog closes immediately and you can watch progress on the **Send History** tab — see [Send history and deliverability](/contacts/send-history-and-deliverability).
**Quota enforcement is at send time.** If sending would push you over your monthly email limit, the send is rejected with `email_limit_exceeded` and a toast suggesting an upgrade. Recipient count is checked against remaining quota, not the plan cap. See [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits).
## What you cannot do (yet)
* A/B tests, drip campaigns, scheduled sends, or open/click tracking.
* Rich-text / image / attachment composition — this is enrollment-focused communication, not a full marketing platform.
* Re-subscribe on behalf of a contact who has unsubscribed.
# Importing contacts
Source: https://docs.firstrespondershub.com/contacts/importing-contacts
Upload a CSV or TSV, map columns, optionally set program interest and tags, and track the import.
You can bulk-import contacts from a spreadsheet so you can email them alongside leads, waitlisted contacts, and enrolled students.
## Opening the import dialog
From [Program Dashboard → Contacts](https://firstrespondershub.com/program-dashboard/contacts), click **Import Contacts** in the page header.
## File requirements
* **Format:** CSV or TSV (tab-separated). The delimiter is detected automatically — if your file contains a tab character on the first line, it's treated as TSV.
* **Max size:** 10 MB per upload.
* **Header row:** Required. The first row is read as column names.
* **Minimum columns:** Email is required. First name, last name, and phone are optional.
**Need a template?** The import dialog has a **Download example** button that gives you a ready-to-fill CSV with the right columns.
## Steps
### 1. Upload
Choose a file. The dialog reads the first few rows for preview and advances to the mapping step.
### 2. Map columns
The dialog auto-detects common header names (anything containing "email", "first", "last", "phone" or "mobile"). Override the mapping as needed:
* **Email** — Required. The deduplication key.
* **First name** — Optional.
* **Last name** — Optional.
* **Phone** — Optional.
Any columns you don't map are ignored.
### 3. Optional: program interest and tags
Before kicking off the import, you can:
* Pick one **program offering** — every imported contact will be given program interest for that offering. Useful when you're importing a list that all signed up for a specific program off-platform.
* Pick one or more **tags** — applied to every contact in the batch. You can create a new tag inline.
### 4. Process
Click **Import**. The dialog switches to a processing view with a progress bar. The import runs in the background (an Inngest job), so you can close the dialog — a subsequent visit to **All Contacts** shows the new rows.
## How duplicates are handled
The importer deduplicates by email within your organization:
* If the email is **new** to your org → a new contact is created with source `Imported`.
* If the email **already exists** → the existing contact is updated. First name, last name, and phone are filled in only if they were previously empty. The contact's original source is preserved. Program interest and tags selected for the import are added (never removed).
## After import
* Sources filter on the All Contacts table will show an `Imported` option — use it to find just the rows you uploaded.
* If you tagged the batch, filter by that tag to see only this import.
* Imported contacts are marked `Active` and can be emailed immediately, subject to your [plan's email limit](/plans-and-billing/plan-tiers-and-limits).
By importing a contact list, you're asserting you have permission to email those people. The platform's CAN-SPAM footer and unsubscribe link are attached to every campaign, but the opt-in itself must come from your side. See [Unsubscribe and compliance](/contacts/unsubscribe-and-compliance).
# Overview
Source: https://docs.firstrespondershub.com/contacts/index
One list of everyone who has ever contacted your organization, with tags, saved lists, and email.
**Contacts** is your address book. It holds everyone who has ever dealt with your organization: people who asked about a program, joined a waitlist, started checkout, enrolled, or came from a spreadsheet you uploaded.
Each person is one record. No duplicates, because the email address is what identifies them.
## Where to find it
Go to [**Program Dashboard → Contacts**](https://firstrespondershub.com/program-dashboard/contacts).
There are four tabs.
| Tab | What it's for |
| ---------------- | --------------------------------------------------------------------------------------------------- |
| **Overview** | Quick lists by program and class, your saved lists, recent sends, and how much email quota is left. |
| **All contacts** | The full table. Search, filter, tag in bulk, delete in bulk, and email. |
| **Tags** | Make, rename, and delete tags, and see how many people have each one. |
| **Send history** | Every campaign you have sent and how it did. |
## What you can do
* **Add people** — one at a time, or a whole spreadsheet at once.
* **Filter** — by status, source, program, class, tag, or date. Save any filter as a **custom list** you can reuse.
* **Tag** — put your own labels on people, one at a time or in bulk.
* **Email** — send to everyone, to everyone interested in one program, to a class roster or waitlist, to a saved list, or to a tag. Send yourself a test first.
* **Promote to lead** — start tracking someone as a real sales lead for one program.
## How contacts get created
A contact is created — or matched, if that email is already there — whenever someone:
* Sends a Request Program Information form
* Starts checkout and does not finish
* Joins a class waitlist
* Enrolls in a class
Or whenever you:
* Import a spreadsheet
* Add someone by hand
See [The contact record](/contacts/contact-record-and-sources).
## Before you can send email
* **Your plan has to allow it.** Starter cannot send campaigns. See [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits).
* **Your organization needs an email address and a mailing address.** Anti-spam law requires the mailing address in the footer. Set both in [Organization profile](/organization-settings/organization-profile).
Program owners and instructors can both use Contacts.
## Learn more
| Guide | What it covers |
| ------------------------------------------------------------------ | -------------------------------------------------------------------- |
| [The contact record](/contacts/contact-record-and-sources) | What's stored, where people come from, and the three email statuses. |
| [Managing contacts](/contacts/managing-contacts) | The table: filters, bulk actions, and the detail panel. |
| [Tags](/contacts/tags) | Your own labels, and how to use them. |
| [Custom lists](/contacts/custom-lists-and-audience-builder) | Build an audience once and reuse it. |
| [Importing contacts](/contacts/importing-contacts) | Upload a spreadsheet and map the columns. |
| [Email campaigns](/contacts/email-campaigns) | Pick an audience, preview the count, and send. |
| [Send history](/contacts/send-history-and-deliverability) | What was delivered, what failed, and why. |
| [Promote to lead](/contacts/promote-to-lead) | Start working someone as a lead. |
| [Unsubscribe and compliance](/contacts/unsubscribe-and-compliance) | The rules, and what we handle for you. |
# Managing contacts
Source: https://docs.firstrespondershub.com/contacts/managing-contacts
The All Contacts table: search, filters, bulk actions, and the detail panel.
The **All Contacts** tab of [Program Dashboard → Contacts](https://firstrespondershub.com/program-dashboard/contacts?tab=all) is the full searchable directory of everyone in your organization.
## Search and filter
Filters stack — each one narrows the result. The subscriber counts shown in the status filter reflect the current filtered view.
| Filter | Options |
| -------------- | ------------------------------------------------------------------------------------------ |
| **Search** | Searches name and email with a 300 ms debounce. |
| **Status** | All / Active / Unsubscribed / Bounced — counts update live. |
| **Source** | Lead, Waitlist, Enrolled, Imported, Manual. |
| **Program** | Any program offering in your organization. Matches contacts with interest in that program. |
| **Tag** | Any organization-wide tag. |
| **Date range** | Filter by date the contact was added. |
## Bulk actions
Select contacts with the row checkboxes. After selecting, a bulk action bar surfaces:
* **Select all matching** — Selects every contact matching your current filter set (not just the current page). Useful for list sizes larger than one page.
* **Apply tag** — Apply a single tag to all selected. You can create a new tag inline.
* **Send email** — Opens the email composer scoped to just the selected contacts.
* **Delete** — Permanently removes the selected contacts. Deleting more than 10 at once requires you to type `delete` to confirm.
Deleting a contact removes them from your organization but does not delete related records (enrollments, waitlist entries, lead submissions) — those remain for historical and financial accuracy. The contact can be re-created if they return through any new touchpoint.
## The contact detail panel
Clicking a row opens the detail panel on the right. See [The contact record](/contacts/contact-record-and-sources#the-detail-panel) for what's inside: editable fields, tags, program interests, activity history, and the **Promote to lead** action.
## Header stats
The page header shows **Emails this month: X / Y** when your plan has an email limit. If you're over 80% of the quota, a warning banner appears; at 100%, sends are blocked until the monthly reset or a plan upgrade. See [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits).
## Quick actions from the header
* **Import Contacts** — Opens the CSV/TSV import dialog. See [Importing contacts](/contacts/importing-contacts).
* **Add Contact** — Manually create one contact (email required; first/last name and phone optional).
# Promote a contact to a lead
Source: https://docs.firstrespondershub.com/contacts/promote-to-lead
Turn someone in your address book into a tracked sales lead for one program.
A **contact** is a person in your address book. A **lead** is a person you are actively working, for one specific program.
Promoting is how you move someone from the first to the second.
## When to promote
Do it when:
* Someone you imported or added by hand tells you they want a specific program.
* You want to log calls and emails against that program. Notes live on the lead, not the contact.
* You want them counted in your pipeline numbers for that program.
## When you do not need to
You do not need to promote anyone who:
* Filled in the **Request Program Information** form — a lead is made for you.
* Started checkout and left — a lead is made for you.
Both of those also create the contact, so the two stay connected.
## How to do it
1. Open [**All contacts**](https://firstrespondershub.com/program-dashboard/contacts) and click the person's row.
2. Click **Promote to lead** in the panel.
3. Pick a **program**. Picking a class is optional.
4. Submit.
They now show up in [Program Dashboard → Leads](https://firstrespondershub.com/program-dashboard/information-requests) with the full lead toolkit: status, notes, activity, waitlists, and invitation emails.
## Duplicates
If an active lead already exists for that person and that program, nothing new is created. You get a message saying so and a link straight to the existing lead.
## What does not change
* Their email status and tags stay exactly as they were.
* Their **original source** stays as it was. Promoting does not rewrite how they first found you.
* Program interest for that program is either already there, or gets added.
Program owners and instructors can both promote contacts.
## See also
* [The contact record](/contacts/contact-record-and-sources) — Contacts versus leads.
* [Viewing and filtering leads](/leads/viewing-and-filtering-leads) — Working the pipeline.
# Send history and deliverability
Source: https://docs.firstrespondershub.com/contacts/send-history-and-deliverability
Review past campaigns, see what was delivered and what failed, and fix a send that did not go out.
The **Send history** tab on [Program Dashboard → Contacts](https://firstrespondershub.com/program-dashboard/contacts?tab=sends) lists every campaign you have sent, newest first.
## What each row shows
| Column | What it means |
| -------------- | ----------------------------------------------------------------------------------------- |
| **Subject** | The subject line. |
| **Audience** | Who it went to, in plain words — "EMT interested contacts" or "Custom list: Alumni 2024". |
| **Sent date** | When you queued the send. |
| **Recipients** | How many people it went to, after unsubscribed and bounced contacts were removed. |
| **Delivered** | How many the email provider accepted and delivered. |
| **Failed** | How many did not make it. Only shown when there is at least one. |
| **Status** | `Sending` while it runs, `Sent` when it finishes, `Failed` if the whole job errored. |
## What "delivered" means
It means the email provider accepted the message and delivered it to the mailbox.
It does **not** mean anyone read it. There is no open tracking, on purpose.
## What "failed" means
A recipient counts as failed when:
* The provider rejects the address.
* The message hard-bounces — a bad mailbox or a dead domain.
* We are rate-limited and the retries run out.
A hard bounce sets that contact to **Bounced**, and they are left out of every future send. That protects your sender reputation, so your other emails keep landing in inboxes.
## Unsubscribes
Every email has an unsubscribe link that is unique to that person. When someone clicks it:
1. They land on your [unsubscribe page](/contacts/unsubscribe-and-compliance).
2. Their contact status changes to **Unsubscribed**.
3. They are left out of every future send from your organization.
Unsubscribes do not show on the send history row, because they happen after the send. You see them on the contact record and in the status counts on **All contacts**.
## Sending to the same list again
Nothing stops you. Two things to know:
* Anyone who unsubscribed or bounced since last time is dropped automatically.
* The recipient count in the composer is today's count. It can be lower than last time for that reason.
## When a whole send fails
| Cause | Fix |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **No organization mailing address** | Anti-spam law requires a physical address in the footer. Add yours in [Organization profile](/organization-settings/organization-profile), then send again. |
| **Sending address problem** | Emails go out from `team@firstrespondershub.com`. If sends keep failing, contact support. |
| **You ran out of email quota mid-send** | The rest of the list is skipped. Upgrade your plan, then send to the people who were missed. See [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits). |
If only a few recipients failed inside an otherwise good send, you do not need to do anything. Their status updates on its own.
## See also
* [Email campaigns](/contacts/email-campaigns) — Writing and sending one.
* [Unsubscribe and compliance](/contacts/unsubscribe-and-compliance) — The legal side.
# Tags
Source: https://docs.firstrespondershub.com/contacts/tags
Your own labels for contacts: making them, applying them in bulk, and using them to build audiences.
A **tag** is a label you invent and stick on contacts. `Newsletter`. `Alumni`. `Fire department`. `Called, no answer`. Anything that helps you group people.
Tags are yours. Nothing applies or removes them but you.
That is what makes them different from [program interest](/contacts/contact-record-and-sources#program-interest), which the platform fills in on its own.
## Where to manage them
Go to the **Tags** tab on [Program Dashboard → Contacts](https://firstrespondershub.com/program-dashboard/contacts?tab=tags).
You see every tag, when it was made, and how many contacts have it. The row menu lets you **rename** or **delete**.
Deleting a tag removes the label from everyone who had it. It does not delete any contacts.
## Making a tag
You can make one in four places:
* The **Tags** tab, with **New tag**
* A contact's detail panel — type a new name and press Enter
* The import dialog, so a whole spreadsheet gets tagged as it lands
* The bulk-tag menu on the contacts table
Names have to be unique in your organization, and capital letters count. `Alumni` and `alumni` would be two different tags.
## Applying a tag
| To | How |
| -------------- | ------------------------------------------------------------------------------------- |
| One person | Open their detail panel and use the tag box. |
| Many people | Select rows in the contacts table and use **Apply tag**. |
| A whole import | Pick the tags in the [import dialog](/contacts/importing-contacts) before you upload. |
## Using tags
Tags work everywhere audiences are built:
* **Contacts table** — filter by one tag.
* **Custom lists** — use `has tag` and `does not have tag` conditions, and combine them. "Has tag *Alumni* and does not have tag *Do not call*."
* **Email** — pick **Tagged contacts** as your audience.
## Example
You go to a county fire expo and collect 40 cards. You import them with the tag `Expo 2026`.
Two weeks later you email everyone with that tag about your spring EMT class. Six months after that you build a custom list of people with `Expo 2026` who never enrolled, and try again.
## See also
* [Custom lists](/contacts/custom-lists-and-audience-builder) — Combine tags with other filters.
* [Email campaigns](/contacts/email-campaigns) — Send to a tag.
* [Importing contacts](/contacts/importing-contacts) — Tag as you import.
# Unsubscribe and compliance
Source: https://docs.firstrespondershub.com/contacts/unsubscribe-and-compliance
How unsubscribe links work, what is added to every email, and what you need before you can send.
Email law in the United States is called CAN-SPAM. Every campaign you send from Contacts follows it automatically.
You do not have to build any of this. You do have to know what it does.
## What is added to every email
| Added automatically | Why |
| ------------------------------------------------------- | ------------------------------------------ |
| Your organization's **name** | So people know who is writing. |
| Your organization's **mailing address** | The law requires a real physical address. |
| A **one-click unsubscribe link**, unique to that person | The law requires an easy way out. |
| A short footer saying the email is from you | So it cannot be mistaken for someone else. |
You cannot turn these off.
If your organization has no mailing address saved, sends fail. Add it in [Organization profile](/organization-settings/organization-profile) before your first campaign.
## What happens when someone unsubscribes
1. They click the link and land on a page at `firstrespondershub.com/unsubscribe`.
2. The page names your organization and says what they are opting out of.
3. They click **Unsubscribe**. That is the whole thing — one click.
4. Their status changes to **Unsubscribed** right away.
Unsubscribing is per organization. Someone who unsubscribes from you can still hear from a different school on FirstRespondersHub.
## Who gets left out of a send
Anyone marked **Unsubscribed** or **Bounced**.
They are removed twice: once when the recipient count is worked out, and again when each message is actually sent. So the number you see in the composer is already the real number.
You cannot put someone back on the list yourself. If they want back in, they have to sign up again through your public form or at checkout. That rule is what keeps you compliant.
## Bounces
A **hard bounce** means the address does not exist, or the domain refuses mail. That contact is marked **Bounced** and left out of every future send.
This is protecting you. Mail providers watch how many of your emails bounce. Too many, and your good emails start landing in spam.
A **soft bounce** — a full mailbox, a server having a bad day — is not marked. The provider retries on its own.
## What you need before you can send
* An **email address** for your organization
* A **mailing address**: street, city, state, ZIP
* A plan that includes email campaigns — see [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits)
* Quota left for the month
## What is still on you
We handle the plumbing. You are responsible for:
* Having permission to email the people you added or imported.
* Honest subject lines and honest content.
* Sending at a sensible pace. Even inside your quota, hammering a list that never opens anything hurts your deliverability — and everyone else's.
# Assigning courses to program offerings
Source: https://docs.firstrespondershub.com/courses/assigning-to-offerings
Attach courses to an offering so enrolled students get access; set order and required
Program offerings define what students get when they enroll in a cohort (e.g. “EMT Spring 2025”). Assigning **courses** to an offering makes those courses available to everyone enrolled in any cohort that uses that offering.
## How it works
* **Program offering** — A template for a program (name, price, application, etc.). When you create a cohort, you attach it to an offering.
* **Assigned courses** — The list of courses you attach to that offering. Every student enrolled in a cohort under that offering gets access to those courses in the order you set, and you can mark any course as required.
You assign courses when creating or editing the offering. The courses must already exist in your organization’s [Courses](https://www.firstrespondershub.com/program-dashboard/courses) list.
## Assigning courses to an offering
1. Go to [**Program Dashboard → Program Offerings**](https://www.firstrespondershub.com/program-dashboard/program-offerings).
2. Create a new offering or open an existing one to edit.
3. Find the **Courses** section (or “Courses in this offering”).
4. **Add courses:** Add courses from your organization. Pick from the list of existing courses; they are added to the offering.
5. **Reorder:** Drag courses up or down to set the order students see them (e.g. “Course A” then “Course B”).
6. **Required:** For each course, you can mark it as **Required**. Required courses usually count toward completion or compliance for the program.
7. **Remove:** Use the remove button on a course to remove it from the offering. This does not delete the course; it only removes it from this offering.
Save or confirm the offering when done. The new list applies to all cohorts that use this offering (and to future enrollments).
## Effect on cohorts and students
* **Cohorts** — Each cohort is tied to one offering. The cohort gets the list of courses assigned to that offering.
* **Students** — When a student enrolls in a cohort, they get access to all courses assigned to that cohort’s offering. They see them in their dashboard in the order you set; required courses are indicated as such.
If you change the offering’s course list (add, remove, reorder, or change required), the change applies to that offering and thus to all its cohorts and their enrolled students. You do not assign courses per cohort; you assign them once per offering.
## Assigning vs standalone sales
* **Assigning to an offering** — Gives access to students who **enroll in a cohort** that uses that offering. They get the course as part of the program; no separate purchase.
* **Standalone course** — Sold or given **without enrollment**. Students get access by purchasing (or claiming) the course directly. See [Standalone courses](/courses/standalone-courses).
A single course can be both: assigned to one or more offerings (for enrolled students) and enabled for standalone purchase (for anyone who buys it separately).
If the course uses vendor access codes, enrolled students get those codes on the **enrollment** timing you set (right after enrollment, before class, or when staff sends it). See [Student access](/student-access).
## Where to find it
* **Program offerings:** [Program Dashboard → Program Offerings](https://www.firstrespondershub.com/program-dashboard/program-offerings).
* **Courses section:** Open an offering to create or edit; the Courses section is on that page.
# Content and media
Source: https://docs.firstrespondershub.com/courses/content-and-media
Add lesson content: video uploads, URLs, text, PDFs, embeds, and resources
Lesson content is added in the **lesson editor**. Each lesson can have multiple pieces of content (videos, text, PDFs, embeds, etc.) and optional **resources** (files or links) for download or reference.
## Content types
You can add these types of content to a lesson:
| Type | Description |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| **Uploaded video** | Video uploaded through the platform and hosted on First Responders Hub. Best for reliable playback and progress tracking. |
| **Video URL** | Link to a video hosted elsewhere. |
| **YouTube video** | Embed a YouTube video by URL. |
| **Vimeo video** | Embed a Vimeo video by URL. |
| **Rich text** | Formatted text (headings, lists, links, etc.) written in the editor. |
| **PDF URL** | Link to a PDF (e.g. hosted on your site or elsewhere). |
| **Embed URL** | Content from another website shown inside the lesson (e.g. an interactive or embedded page). |
| **File upload** | File stored and linked from the lesson (e.g. document or image). |
Content has an **order** within the lesson. You can change the order by dragging in the lesson editor. Students see and complete them in that order.
## Uploading videos
Videos you upload are stored on First Responders Hub and prepared so students can stream them.
1. In the lesson editor, click **Add content** and choose **Video** (or the option that creates an upload).
2. Select the video file. The browser uploads it to the platform.
3. The page will show **Processing** while the video is being prepared. This can take a few minutes depending on the video’s length and size.
4. When processing is complete, the video shows as **Ready** and students can play it. How far they’ve watched is saved so they can pick up where they left off.
* **While it’s processing** — You can leave the page and come back; the video will show as ready when it’s done.
* **For students** — Videos play securely on the platform so only enrolled or authorized students can view them.
If you prefer not to upload a file, you can add a **Video URL**, **YouTube**, or **Vimeo** link instead and paste the URL.
## Adding other content
* **Text** — Choose the rich text option and type or paste. Use the toolbar for formatting and links.
* **PDF / embed / file** — Choose the matching type and enter a URL or upload a file as prompted. For file uploads, the file is stored and linked from the lesson.
You can mix types in one lesson (e.g. a short video plus a text summary plus a PDF). Reorder items by dragging.
## Lesson resources (files and links)
In addition to content items, a lesson can have **resources**: files or links meant for download or reference (e.g. handout PDF, external form).
* **File** — Upload a file; it’s stored and students can download it.
* **Link** — Provide a URL; students open it in a new tab or copy it.
Resources are listed separately from the main content items (e.g. in a “Resources” area in the lesson editor and on the student view). They have a display name and order.
## Reordering and removing content
* **Reorder:** In the lesson editor, drag content (and resources) to change the order. Changes save automatically.
* **Remove:** Use the delete or remove button on the piece of content or resource. Removing it deletes it from the lesson.
## Where to find it
* **Lesson editor:** [Program Dashboard → Courses](https://www.firstrespondershub.com/program-dashboard/courses) → open a course → **Course Builder** → click a lesson.
* Content and resources are managed on the same screen.
# Creating and managing courses
Source: https://docs.firstrespondershub.com/courses/creating-and-managing
Create a course, edit settings, and understand course management vs the course builder
This guide covers creating a course, editing its settings (title, description, estimated hours, completion, prerequisites), and when to use course settings versus the course builder.
## Creating a course
1. Go to [**Program Dashboard → Courses**](https://www.firstrespondershub.com/program-dashboard/courses).
2. Click **Create Course**.
3. In the dialog, enter:
* **Title** (required)
* **Description** (optional)
4. Click **Create**. The course is created and you are taken to the **Course Builder** to add modules and lessons.
You can add modules and lessons right away or return later from the Courses list by opening the course and choosing **Course Builder**.
## Course settings (edit course)
Course settings control the course as a whole: how it’s described, what counts as “complete,” and whether it can be sold on its own. To edit them:
* From the Courses list: open a course, then use **Edit Course Settings** (or the settings or gear icon on the course).
* From the Course Builder: click **Edit Course Settings** in the header.
You can edit:
| Setting | Description |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Title** | Display name of the course. |
| **Description** | Summary or overview; shown on the course page and in lists. |
| **Delivery model** | Whether students get **Lessons on FirstRespondersHub**, **Access from another provider** (codes/links), or **Both**. See [Student access](/student-access). |
| **Estimated hours** | Optional. How long the course typically takes (e.g. for display or planning). |
| **Completion threshold** | Percentage of required content students must complete for the course to count as complete (e.g. 100%). |
| **Required** | Whether the course is required in contexts where it’s used (e.g. in an offering). |
| **Prerequisite course** | Optional. Another course that must be completed before this one (when both are in the same offering or purchase path). |
| **Required agreements** | For standalone courses: which agreements students must accept before completing purchase. See [Standalone courses](/courses/standalone-courses) and [Agreements](/enrollment/agreements). |
| **Max seats per purchase** | For standalone courses that send access codes: how many seats one checkout can buy (1–50). See [Buying more than one seat](/student-access/buying-more-than-one-seat). |
Standalone sale options (sell without enrollment) are also in course settings; they are described in [Standalone courses](/courses/standalone-courses). If the delivery model includes provider access, finish setup under **Student access**. See [Set up a course](/student-access/set-up-a-course).
## Course setup vs learning content vs student access
When you open a course you get a sidebar:
* **Course setup** — Title, description, delivery model, estimated hours, completion, prerequisites, and standalone sale options (price, visibility, max seats). Use this when you want to change how the course is described or how it behaves at the course level.
* **Learning content** — Structure (modules and lessons) and, via the lesson editor, the actual content (videos, text, resources). This section only appears when the delivery model includes lessons on FirstRespondersHub.
* **Student access** — Provider name, fields, timing, and the student message. This section only appears when the delivery model includes access from another provider. See [Set up a course](/student-access/set-up-a-course).
You do not edit module or lesson content from Course setup. Open **Learning content**, then the lesson editor.
## Deleting a course
From the Courses list, you can delete a course. You can only delete a course when it’s not in use—for example, not assigned to any program offering and not set up for standalone sale. If you see a message that deletion isn’t allowed, remove the course from offerings or turn off standalone sales first, then delete.
## Where to find it
* **Courses list:** [Program Dashboard → Courses](https://www.firstrespondershub.com/program-dashboard/courses)
* **Course setup / Learning content / Student access:** Open a course from the list. The sidebar sections depend on the delivery model.
# Overview
Source: https://docs.firstrespondershub.com/courses/index
What courses are, where to manage them, and how they connect to program offerings and standalone sales
Courses are reusable learning units in First Responders Hub. Each course has a title, description, estimated hours, and completion rules. You build a course once, then assign it to program offerings (so enrolled students get access) and optionally sell it as a standalone product.
## What's in this section
| Guide | What it covers |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| [Creating and managing courses](/courses/creating-and-managing) | Creating a course, editing settings (title, description, prerequisites), and when to use the course builder versus course settings |
| [Structure: modules and lessons](/courses/structure-modules-lessons) | Organizing content into modules and lessons, reordering, and marking required |
| [Content and media](/courses/content-and-media) | Adding lesson content: videos (upload and URLs), text, PDFs, embeds, and resources |
| [Assigning to program offerings](/courses/assigning-to-offerings) | Attaching courses to an offering so cohorts get access; order and required flag |
| [Sessions and lessons](/courses/sessions-and-lessons) | Assigning lessons to specific cohort sessions on the schedule |
| [Standalone courses](/courses/standalone-courses) | Selling a course without enrollment: visibility, pricing, public page, and purchases |
| [Student access](/student-access) | Access codes and links from Jones & Bartlett, AHA, or a custom provider |
## High-level flow
1. **Create a course** — From the Courses list, use **Create Course** (title and description). You are taken to the course builder.
2. **Build structure** — Add modules, then lessons inside each module. Reorder as needed.
3. **Add content** — Open each lesson in the lesson editor and add content (e.g. upload videos, add text or links).
4. **Assign and/or sell** — Assign the course to one or more [program offerings](/courses/assigning-to-offerings) so enrolled students see it. Optionally enable [standalone purchase](/courses/standalone-courses) so anyone can buy the course.
5. **Send vendor access (if needed)** — If students need Jones & Bartlett, AHA, or another provider, set the delivery model and import codes. See [Student access](/student-access).
```mermaid theme={null}
flowchart LR
subgraph course [Course]
M1[Module 1]
M2[Module 2]
M1 --> L1[Lesson]
M1 --> L2[Lesson]
M2 --> L3[Lesson]
end
course --> PO[Program Offering]
course --> SP[Standalone Purchase]
course --> SA[Student access codes]
PO --> Cohorts[Cohorts]
SP --> Students[Students]
SA --> Students
```
## Where to find Courses
Go to [**Program Dashboard → Courses**](https://www.firstrespondershub.com/program-dashboard/courses) to:
* See all courses for your organization
* Create a new course
* Open a course to edit its settings or go to the course builder (structure and content)
* Delete a course (if not in use)
From a course you can open **Course setup** (title, delivery model, standalone sale), **Learning content** (modules and lessons), and **Student access** (vendor codes and timing) when those sections apply.
# Sessions and lessons
Source: https://docs.firstrespondershub.com/courses/sessions-and-lessons
Assign lessons to cohort sessions so content appears on the schedule
Cohorts have a **schedule** made of **sessions** (e.g. “Week 1 – Monday 9am,” “Skills Lab – Wednesday”). You can attach **lessons** to specific sessions so students know which lessons are intended for which date and so the schedule shows a clear plan.
## Course in offering vs lesson on session
* **Course in offering** — Determines *which courses* a student gets when they enroll in a cohort. You set this when you [assign courses to the program offering](/courses/assigning-to-offerings). Every student in that cohort has access to those courses and their modules and lessons.
* **Lesson on session** — Determines *when* a lesson appears on the cohort’s schedule. You assign lessons to sessions so that, for example, “Vital Signs” is linked to “Week 1 – Monday.” This is for planning and display; students can still open lessons from the course view even if they are not linked to a session.
So: the offering defines *what* courses (and thus lessons) exist for the cohort; session assignment defines *which* lessons are tied to *which* sessions on the calendar.
## Assigning lessons to sessions
1. Open the **cohort** (e.g. from Program Dashboard → Cohorts).
2. Go to the cohort’s **schedule** or **sessions** view.
3. Open the **session–lesson assignment** panel (e.g. “Assign lessons” or the panel that lists sessions and lessons).
4. For a given session (or in a view that shows all sessions), select which **lessons** from the cohort’s courses should be linked to that session. Lessons come from the courses that are assigned to the cohort’s offering.
5. Save. The schedule then shows those lessons under the corresponding sessions.
You can assign multiple lessons to one session and leave some sessions with no lessons. Revisit this whenever you change the schedule or add new lessons.
## How students see it
* **Course view** — Students see their courses and can open any lesson and complete content regardless of session assignment.
* **Schedule view** — Students see sessions on the calendar; sessions that have lessons assigned show those lessons (e.g. “Vital Signs,” “Patient Assessment”). This helps them follow the intended plan.
Completion and progress are tracked per lesson; linking a lesson to a session doesn’t change how completion is tracked.
## Where to find it
* **Cohorts:** [Program Dashboard → Cohorts](https://www.firstrespondershub.com/program-dashboard/cohorts).
* **Session–lesson assignment:** From a cohort, open its schedule or sessions and use the option to assign lessons to sessions (e.g. “Assign lessons to session”).
To record what was taught and by whom (teaching topics, duration, instructors), use **Manage Session** on a session, then the **Teaching** tab. See [Session segments (Manage Teaching)](/teaching-topics-and-instructor-hours/session-segments) for details.
# Standalone courses
Source: https://docs.firstrespondershub.com/courses/standalone-courses
Sell or offer a course without enrollment: visibility, pricing, public page, and purchases
**Standalone courses** are courses that students can purchase (or get for free) without enrolling in a cohort. You create and build the course the same way; then you enable standalone sale and set a price and visibility. Students can find the course on a public page, purchase it, and access it from their dashboard like a course from an enrollment.
## Enabling standalone for a course
1. Open the [Courses](https://www.firstrespondershub.com/program-dashboard/courses) list and select the course.
2. Open **Edit Course Settings** (or the course management / settings view).
3. Enable **Standalone purchasable** (or “Sell as standalone,” “Available for standalone purchase,” etc.).
4. Set:
* **Price** — Amount in dollars (e.g. 50.00). Set to **0** for a free standalone course.
* **Visibility** — Who can see the course and purchase it:
* **Public** — Listed and purchasable by anyone (e.g. on your organization’s public pages and the direct course link).
* **Private** — Not listed publicly; only people with the direct link (and who are allowed to purchase) can buy.
* **Coming soon** — Shown as “coming soon”; purchase is disabled until you change visibility.
* **Required agreements (optional)** — In the same Edit Course Settings modal, use **Required agreements** to select which published agreements students must accept before completing purchase. If none are selected, no agreement step is shown. See [Agreements](/enrollment/agreements) for creating and publishing agreements.
Save the course. The course can still be assigned to [program offerings](/courses/assigning-to-offerings); enrolled students get it via the offering, and others can get it via standalone purchase.
## Public course page
When a course is standalone and visible (public or private with link), it has a **public course page**. The URL is typically:
* `https://www.firstrespondershub.com/courses/[courseId]`
On that page, visitors can see:
* Course title and description
* Curriculum (modules and lesson titles; no full content until they have access)
* Price (or “Free”)
* A **Purchase** or **Get access** button
If the course is **private**, the same page may be reachable only via direct link and might still show curriculum and price so the visitor can purchase. **Coming soon** shows the course but disables purchase.
## Purchase flow
If the course has **required agreements** assigned in course settings, an **Agreements** step appears in the purchase flow (after sign-in and profile, before payment or free confirmation). The student must accept all required agreements; acceptances are recorded with the purchase.
* **Paid course** — Student clicks purchase, enters payment, and gets immediate access once payment succeeds. They see the course in their student dashboard and can complete it like any other course.
* **Free course** — Student clicks the free/claim button and confirms; they get access without payment.
After purchase (or free claim), the student’s access is tied to their account. They can open the course from their dashboard and use the same lesson viewer and progress tracking as for enrollment-based courses.
## Where students see purchased courses
* **Student dashboard** — Purchased courses appear in the student’s course list (e.g. “Purchased” or “My courses”) alongside courses they have from enrollments.
* **Progress and completion** — Completion and progress are tracked the same way as for enrollment courses. Refunds and access are handled per your [refund](/payment-settings/refunds) and platform policies; when a purchase is refunded, access to that course is typically removed.
## Refunds and access
If you issue a **refund** for a standalone course purchase, the student’s access to that course is removed once the refund is processed. They keep access to courses they still have from enrollments or other purchases.
Refund handling is covered in [Refunds](/payment-settings/refunds). Standalone course refunds use the same payment system; you process them from your transactions page or the student’s profile. If the course sent access codes, also see [Refunds and unused codes](/student-access/refunds-and-unused-codes).
## Access codes on a standalone course
If students need a vendor code or link (Jones & Bartlett, AHA, or custom), set the delivery model to **Access from another provider** or **Both**, then complete [Student access](/student-access).
* Buyers get codes on the **standalone** timing you set (right after purchase, or when staff sends it). See [When students get access](/student-access/when-students-get-access).
* A buyer can purchase more than one seat in one checkout. Each seat gets its own code. See [Buying more than one seat](/student-access/buying-more-than-one-seat).
* A refund takes those seats' codes back. See [Refunds and unused codes](/student-access/refunds-and-unused-codes).
## Summary
| Action | Where |
| ------------------------------------------------ | ------------------------------------------------------- |
| Turn standalone on/off, set price and visibility | Course setup |
| Set max seats per purchase (access-code courses) | Course setup → **Max seats per purchase** |
| Assign required agreements for purchase | Course setup → Required agreements |
| Public course page | `/courses/[courseId]` (link in settings or “Copy link”) |
| Student access after purchase | Student dashboard → Courses and **Your Credentials** |
| Refund a standalone purchase | From your transactions page or the student’s profile |
A course can be both assigned to offerings (for enrolled students) and available for standalone purchase (for everyone else). Build the course once; use both assignment and standalone as needed.
# Structure: modules and lessons
Source: https://docs.firstrespondershub.com/courses/structure-modules-lessons
Organize course content into modules and lessons; add, edit, reorder, and set required
Courses are organized in a two-level structure: **modules** (sections) and **lessons** (units inside a module). You manage this structure in the Course Builder.
## Hierarchy
* **Course** — The top-level container (e.g. “EMT Continuing Education”).
* **Module** — A section within the course (e.g. “Week 1: Patient Assessment”). Each module has a title, optional description, order, and can be required.
* **Lesson** — A single learning unit inside a module (e.g. “Vital Signs”). Each lesson has a title, optional description, order, required flag, and holds the actual content (videos, text, resources).
You control the order of modules and lessons. You can reorder them by dragging in the Course Builder.
## Managing modules
### Adding a module
1. Open the course in the [Course Builder](https://www.firstrespondershub.com/program-dashboard/courses) (open a course, then **Course Builder**).
2. In the **Course Structure** area, click **Add Module**.
3. Enter the module **title** and, if you want, a **description**. You can also set **Required**.
### Editing a module
Click the module’s edit button in the Course Builder. You can change:
* **Title**
* **Description**
* **Required** — Whether the module is required for course completion.
### Reordering modules
In the Course Builder, use the module’s drag handle to move it up or down. The new order is saved automatically. Lesson order within each module is independent.
### Deleting a module
Use the module’s delete button in the Course Builder. Deleting a module removes it and all its lessons and content. This cannot be undone.
## Managing lessons
### Adding a lesson
1. In the Course Builder, expand the module you want.
2. Click **Add Lesson** for that module.
3. Enter the lesson **title** and, if you want, a **description**. You can set **Required** as needed.
### Editing a lesson’s title and description
To change a lesson’s title, description, or whether it’s required:
* Click the lesson in the Course Builder to open the **Lesson editor**. At the top you can edit the title, description, and required setting.
* Or use the lesson’s edit button if you see one in the builder.
To add or change the lesson’s **content** (videos, text, PDFs, etc.), use the same lesson editor; see [Content and media](/courses/content-and-media).
### Reordering lessons
Lessons are ordered within their module. In the Course Builder, use the lesson’s drag handle to move it up or down within that module. Order is saved automatically.
### Deleting a lesson
Use the lesson’s delete button. Deleting a lesson removes it and all its content and resources. This cannot be undone.
## Lesson types (video, text, mixed)
The platform automatically labels each lesson based on the content you add:
* **Video** — The lesson is all video (e.g. videos uploaded to First Responders Hub or video links).
* **Text** — The lesson is all text (e.g. rich text).
* **Mixed** — The lesson has a mix of video, text, or other types (e.g. PDF, embed, file).
You don’t set the type yourself; it updates as you add or remove content. This helps you and students tell “video” lessons from “reading” lessons at a glance.
## Where to find it
* **Course Builder:** [Program Dashboard → Courses](https://www.firstrespondershub.com/program-dashboard/courses) → open a course → **Course Builder**.
* **Lesson editor:** From the Course Builder, click a lesson to open it and add or edit content.
# Attribution
Source: https://docs.firstrespondershub.com/dashboard-and-reports/attribution
Find out which ads, posts, and links actually bring in enrollments — not just clicks.
**Attribution** answers the question every training program asks: *which of the things I do actually fills classes?*
Open it from the sidebar under **Insights → Attribution**.
## How it works
You make a **tracking URL** for each place you advertise. Anyone who clicks it is tagged, and the platform follows them all the way through to an enrollment.
So instead of "the Facebook ad got 400 clicks," you get "the Facebook ad got 400 clicks, 12 information requests, and 4 paid enrollments worth \$3,400."
## Making a tracking URL
Click **New tracking URL** and fill in:
| Field | Example | What it's for |
| -------------------------- | --------------------- | -------------------------------------------------- |
| **Destination page** | Your April EMT class | Where the link sends people. |
| **utm\_source** (required) | `meta` | Which platform. |
| **utm\_medium** | `paid_social` | What kind of thing it was. |
| **utm\_campaign** | `april_emt_stratford` | Which push it belongs to. |
| **utm\_content** | | Which version of the ad, when you are testing two. |
| **utm\_term** | | The keyword, for search ads. |
Give the link a name you will recognize later, like `Meta — April EMT — Stratford lookalike`.
Then use that URL everywhere instead of your plain page address.
Make a separate link for every place you post — the ad, the newsletter, the flyer QR code, the Facebook group. One link for everything tells you nothing.
## Reading the report
Switch between **Per source** (all your Facebook traffic together) and **Per link** (one specific ad).
| Column | What it counts |
| ----------------------------------- | -------------------------------------- |
| **Visitors** | People who arrived. |
| **Visits** | Times they arrived. |
| **Info requests** | People who asked for information. |
| **Enrollment started** | People who reached checkout. |
| **Enrollment finished** | People who paid. |
| **Application started / submitted** | For programs that need an application. |
| **Course sales** | Standalone course purchases. |
| **Revenue** | Money from those people. |
| **Ad spend** | What you told us you spent. |
Enter your ad spend and you can see what each enrollment actually cost you.
## Example
You spend $300 on Facebook and $150 on a local newsletter for your April EMT class.
The report shows Facebook brought 620 visitors and 2 enrollments. The newsletter brought 45 visitors and 5 enrollments.
Facebook looked busier. The newsletter filled the class. Next time you know where the money goes.
## See also
* [Where leads come from](/leads/where-leads-come-from) — What happens after someone clicks.
* [Pipeline metrics](/leads/pipeline-metrics) — What your leads are worth.
* [Dashboard](/dashboard-and-reports/dashboard) — The short version.
# Calendar
Source: https://docs.firstrespondershub.com/dashboard-and-reports/calendar
Every class date across every class, in one place — with attendance one click away.
The **Calendar** shows every class date your organization has, across every class. Open it from the sidebar under **Operations → Calendar**.
Instructors can use it too. It is often the only page they need.
## What you see
Each entry is one class date. In-person and virtual sessions are shown separately, so you can tell at a glance who needs a room and who needs a link.
Times show in **your** local timezone, not the class's. The calendar says so at the top. If you run classes in two timezones, check the class itself before you tell someone what time to show up.
## What you can do from here
Click a session and you get:
* **Manage attendance** — mark students Present, Late, Absent, or Excused. See [Attendance](/cohort-management/attendance).
* **Edit session** — change the date, time, room, or type, or cancel that date. See [Editing and cancelling sessions](/cohort-management/editing-and-cancelling-sessions).
That saves you the trip through Cohorts → the class → Schedule → the date.
## When a date is missing
If a class has no dates on the calendar, its schedule has not been built yet. Open the class, go to **Settings → Schedule**, and build the dates from the pattern. See [Schedule and sessions](/cohort-management/schedule-and-sessions).
## See also
* [Schedule and sessions](/cohort-management/schedule-and-sessions) — Where class dates come from.
* [Attendance](/cohort-management/attendance) — Taking attendance.
* [Session topics and segments](/cohort-management/session-topics-and-segments) — Recording what was taught.
# Dashboard
Source: https://docs.firstrespondershub.com/dashboard-and-reports/dashboard
Your home page: the numbers that matter, what needs attention today, and what just happened.
The **Dashboard** is the first page you land on. Open it from the sidebar under **Operations → Dashboard**.
It answers three questions: how are we doing, what needs me today, and what just happened.
## Setup checklist
New organizations get a checklist at the top with a progress bar. It walks you through the four things you have to do before you can take a single enrollment:
1. Create your first program offering
2. Create your first cohort
3. Set up payment processing
4. Share your organization page
It goes away once you finish.
## The numbers
Four cards across the top, all for the **last 30 days**:
| Card | What it counts |
| ----------------------- | -------------------------------------- |
| **Revenue** | Money collected. |
| **New students** | People who enrolled or bought. |
| **New leads** | People who asked about a program. |
| **Average cohort fill** | How full your classes are, on average. |
## Needs attention
This is your to-do list. It only shows items that actually need something from you, so an empty list means you are caught up.
Typical items:
* **Send course codes** — students are waiting on access codes.
* **Review credential deliveries** — something needs a decision.
* **Fix failed deliveries** — an email did not go out.
* **Return callback requests** — someone asked you to call them.
Click any item to go straight to it.
## Recent activity
A live feed of what is happening: sign-ups, payments, invites accepted, refunds. Read it once a morning and you know what happened overnight.
## Charts
* **Revenue trend** — money over time.
* **Program mix** — which programs bring in the enrollments and the money.
* **Rating** — your NPS and average rating from student feedback.
## Lead and review cards
* **Pipeline** — how many active leads you have and what they are worth. See [Pipeline metrics](/leads/pipeline-metrics).
* **Top opportunities** — the leads worth calling first.
* **Recent reviews** — the latest thing a student said about you.
## Active classes
A list of classes running now, with how full each one is. Click one to open it.
## See also
* [Calendar](/dashboard-and-reports/calendar) — What is happening this week.
* [Leads](/leads) — Working the pipeline.
* [Revenue report](/dashboard-and-reports/revenue-report) — The full money picture.
# Feedback and reviews
Source: https://docs.firstrespondershub.com/dashboard-and-reports/feedback-and-reviews
Ratings and reviews across every class you run, not just one.
The **Feedback & Reviews** page pulls student feedback together across your whole organization. Open it from the sidebar under **Insights → Feedback & Reviews**.
For feedback on one class, use the **Feedback** tab inside that class. See [Feedback](/cohort-management/feedback).
## Filters
Narrow everything on the page by **program** and by **class**.
## The numbers
| Number | What it means |
| ------------------------ | ------------------------------------------------------- |
| **Overall rating** | The average star rating from students. |
| **Total reviews** | How many students left one. |
| **Response rate** | How many of the students you asked actually answered. |
| **Organization NPS** | How likely students are to recommend your organization. |
| **Program offering NPS** | The same score, for one program. |
NPS runs from −100 to +100. Anything above 0 means more fans than critics. Above 50 is strong.
## Category ratings
Students rate more than one thing — instruction, materials, facilities, and so on. **Internal category ratings** are the ones only your team sees, so you get honest answers about things students would not say in public.
## Reviews
**Recent reviews** lists what students wrote. Click one to read the whole thing, including the private feedback that does not go on your public page.
## Session surveys
After a class date, students can rate that session. **Recent survey results** shows those, so you can spot a single bad night rather than waiting for the end-of-course review.
## Using it
* A category that keeps scoring low is a fixable problem. Low facility scores mean the room, not the teaching.
* One low session in an otherwise strong class usually means a topic, not an instructor.
* A low response rate makes every other number on the page shaky. Ask students in class, not just by email.
## See also
* [Feedback (one class)](/cohort-management/feedback) — The same data for a single class.
* [Dashboard](/dashboard-and-reports/dashboard) — Your rating at a glance.
# Dashboard and reports
Source: https://docs.firstrespondershub.com/dashboard-and-reports/index
The pages you check rather than edit: your dashboard, calendar, student list, money, feedback, and marketing.
Most of this documentation is about setting things up. This section is about the pages you **look at**.
## In this section
| Guide | What it covers |
| ------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| [Dashboard](/dashboard-and-reports/dashboard) | Your home page: the numbers, what needs attention, and recent activity. |
| [Calendar](/dashboard-and-reports/calendar) | Every class date across every class, in one view. |
| [Students](/dashboard-and-reports/students) | Everyone who ever enrolled or bought, and one student's full record. |
| [Transactions](/dashboard-and-reports/transactions) | Every payment, refund, and correction. |
| [Revenue report](/dashboard-and-reports/revenue-report) | Gross and net revenue for a date range you pick. |
| [Feedback and reviews](/dashboard-and-reports/feedback-and-reviews) | Ratings across all your classes, not just one. |
| [Attribution](/dashboard-and-reports/attribution) | Which ads and links actually produce enrollments. |
## What instructors see
Instructors can open the **Calendar** and the classes they teach. Everything else in this section is for program owners, because most of it is money.
# Revenue report
Source: https://docs.firstrespondershub.com/dashboard-and-reports/revenue-report
Gross and net revenue for any date range, broken down by source and payment channel.
The **Revenue report** answers "what did we make?" for a stretch of time. Open it from the sidebar under **Billing → Revenue Report**.
Program owners only.
## Running one
1. Pick a start and end date.
2. Generate the report.
Nothing appears until you pick a range. That is on purpose — there is no default period that is right for everyone.
## What you get
Three totals at the top:
| Total | What it means |
| ------------------------- | ------------------------------------------------------- |
| **Gross revenue** | Everything students paid, before anything is taken out. |
| **Refunds** | What you gave back in that period. |
| **Net revenue collected** | What you actually kept. |
Then two breakdowns:
* **By revenue source** — which programs and courses the money came from.
* **By payment channel** — how it was paid.
And below those, the full transaction detail, with the student or beneficiary on each line.
The report follows the dates money **moved**, not the dates classes ran. A student who paid in February for a June class shows in February.
## Example
It is April 3 and your board wants first-quarter numbers.
1. Set the range to January 1 through March 31.
2. Generate.
3. Read **Net revenue collected** for the headline number, and **By revenue source** for which programs earned it.
## See also
* [Transactions](/dashboard-and-reports/transactions) — One payment at a time.
* [Refunds](/payment-settings/refunds) — What lands in the refunds column.
* [Stripe Connect](/payment-settings/stripe-connect) — Where the money goes.
# Students
Source: https://docs.firstrespondershub.com/dashboard-and-reports/students
Every student across every class, and the full record for any one of them.
The **Students** page in the sidebar lists everyone across your whole organization — not just one class. Open it under **Operations → Students**.
Use it when you know the person's name but not which class they are in.
## The list
Four numbers sit at the top: **Total students**, **New students**, **Total purchases**, and **Purchases**. Switch the range between the last 7 and last 30 days.
Below that is the table. Search by name, and filter by program or by purchase type.
The list covers both kinds of student: people enrolled in a class, and people who bought a standalone course.
## One student's record
Click a student to open their full record.
| Section | What's in it |
| ---------------------- | -------------------------------------------------------------------------------------------------------- |
| **Contact details** | Email, phone, and address. |
| **Program summary** | Which programs and classes they are in. |
| **Active enrollments** | Classes they are in right now. |
| **Past enrollments** | Classes they finished, withdrew from, or left. |
| **Invitations** | Invites they have not accepted, including how tuition was set on each one. You can cancel one from here. |
| **Payment history** | Every payment, invoice, and refund. |
| **Course purchases** | Standalone courses they bought, with transactions. |
| **Agreements** | What they accepted, when, and from what IP address. |
| **Outcomes** | Results you recorded — passed, failed, certified, withdrawn. |
| **Access** | Their vendor access codes, with a resend button. |
| **Internal notes** | Notes for your team. Students never see these. |
Instructors can open a student and see their access codes, but not their money.
## Common jobs
| You want to… | Do this |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| Resend an access code | Open the student → **Access** → **Resend**. |
| See what someone owes | Open the student → **Payment history**. |
| Check a signed waiver | Open the student → **Agreements**. |
| Move someone to another class | Do it from the class instead. See [Students and invites](/cohort-management/students-and-invites). |
| Withdraw someone | Open the student, find the enrollment, click **Unenroll**. See [Unenrolling](/outcomes/unenrolling-from-cohort). |
## See also
* [Students and invites](/cohort-management/students-and-invites) — The roster for one class.
* [Invoices and balances](/payment-settings/invoices-and-balances) — Billing a student.
* [What students see](/student-access/what-students-see) — Their side of the access codes.
# Transactions
Source: https://docs.firstrespondershub.com/dashboard-and-reports/transactions
Every payment, refund, and correction, with the detail behind each one.
**Transactions** is the ledger. Every payment, refund, and correction lands here. Open it from the sidebar under **Billing → Transactions**.
Program owners only.
## Filters
Narrow the list by:
* **Class**
* **Type** — payment, refund, correction, purchase
* **Status** — pending, processing, failed, canceled
* **Source** — invoice, direct, or a course purchase
## What one row tells you
Click a row to open the detail. It is grouped into four parts.
| Part | What's in it |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Basic information** | Date, description, amount, status, and notes. |
| **Payer information** | Who paid, their email, and whether it was the student or a sponsor. |
| **Class information** | Which program and class the money was for, and the enrollment it belongs to. |
| **Additional details** | Invoice number, payment method, promo code used, the platform fee, the net amount, and the refund ID if there was one. |
**Original amount** is what the student was charged. **Platform fee** is what FirstRespondersHub took. **Net amount** is what reached your bank. See [Payment settings](/payment-settings) for the fee on your plan.
## Pending sponsorships
Sponsorships that have not been paid yet show separately, so a promise from a fire department does not get counted as money you have. See [Sponsored payments](/payment-settings/sponsored-payments).
## Transactions versus the revenue report
| Use | For |
| ----------------------------------------------------------- | ------------------------------------------ |
| **Transactions** | One payment. "Did Dana's card go through?" |
| **[Revenue report](/dashboard-and-reports/revenue-report)** | A period. "What did we make in March?" |
## See also
* [Invoices and balances](/payment-settings/invoices-and-balances) — What a student owes.
* [Refunds](/payment-settings/refunds) — Giving money back.
* [Revenue report](/dashboard-and-reports/revenue-report) — Totals for a date range.
# Agreements
Source: https://docs.firstrespondershub.com/enrollment/agreements
Create, publish, and assign legal agreements required during student enrollment or course purchase
Agreements are documents (e.g. program policies, liability waivers, or terms) that students must accept during enrollment or when purchasing a [standalone course](/courses/standalone-courses). You create and publish them in one place, then choose which ones are required for each program offering or for each standalone course.
## Where to find this
Go to [**Program Dashboard → Agreements**](https://www.firstrespondershub.com/program-dashboard/agreements). Only **program owners** can access this page.
## Agreement statuses
| Status | Meaning |
| ------------- | ----------------------------------------------------------------------------------------------------------- |
| **Draft** | Saved but not visible to students. You can edit and then publish. |
| **Published** | Live. Students see it when the offering or course requires it. You can still edit; you can also archive it. |
| **Archived** | No longer used. Not listed for assignment to offerings or courses. You can view or delete. |
Only **published** agreements can be assigned to program offerings or to standalone courses. Draft and archived agreements do not appear in offering or course settings.
## Creating an agreement
1. On the Agreements page, click **Create New Agreement**.
2. Fill in:
* **Internal name** — A short label for your team (e.g. "EMT Program Policy"). Shown in the agreements list and in program offering settings.
* **External name** — The title students see when they accept the agreement (e.g. "EMT Program Terms and Policies").
* **Content** — The full text of the agreement. Use the editor to format and structure the content.
3. Click **Save as draft** to keep it editable, or **Publish** to make it available for assignment.
You can edit a draft or published agreement at any time. Changes to a published agreement apply the next time a student goes through enrollment.
## List actions
From the agreements table you can:
* **View** — Open the agreement in read-only mode.
* **Edit** — Change internal name, external name, or content (draft or published).
* **Publish** — Move a draft to published (so it can be assigned to offerings).
* **Archive** — Move a published agreement to archived (it will no longer be assignable).
* **Duplicate** — Create a copy as a new draft (useful for similar agreements).
* **Delete** — Permanently remove an agreement (typically used for drafts or archived items).
## Assigning agreements to a program offering
Agreements are required **per program offering**, not globally.
1. Go to [**Program Dashboard → Program Offerings**](https://www.firstrespondershub.com/program-dashboard/program-offerings).
2. Open the program offering you want to configure.
3. Open the **Settings** tab.
4. In the left sidebar, select **Required Agreements**.
5. Check the published agreements that students must accept for this offering.
6. Click **Update Program Offering** to save.
You can assign multiple agreements to one offering. Students will see each required agreement during enrollment and must accept all of them before continuing.
## Assigning agreements to a standalone course
Agreements can also be required for **standalone course purchases** (courses sold without enrollment).
1. Go to [**Program Dashboard → Courses**](https://www.firstrespondershub.com/program-dashboard/courses).
2. Open the course you want to configure.
3. Open **Edit Course Settings**.
4. In the same modal, find the **Required agreements** section (below price, visibility, and promo codes).
5. Check the published agreements that students must accept before completing purchase.
6. Click **Save Changes** to persist assignments.
Only **published** agreements from your organization appear. The same agreements you create for program offerings can be assigned to standalone courses. Students see these agreements in the standalone course purchase flow and must accept all before payment (or free confirmation).
## What students see
**During enrollment** — When a student enrolls in a cohort whose program offering has required agreements:
1. During the enrollment flow, an **Agreements** step appears (after sign-in and profile info, and before payment if applicable).
2. Each required agreement is shown with its **external name** and full **content**.
3. The student must check a box to accept each agreement.
4. They cannot proceed to the next step until all required agreements are accepted.
Accepted agreements are stored with the enrollment for your records.
**For standalone course purchases** — When a student purchases a standalone course that has required agreements assigned in course settings, an **Agreements** step appears in the purchase flow (after sign-in and profile, before payment or free confirmation). The student must accept all required agreements; acceptances are recorded with the purchase.
# Overview
Source: https://docs.firstrespondershub.com/enrollment/applications
Create application forms, manage submissions, and set when applications are required (before, during, or after enrollment)
Application forms let you collect structured information from students (e.g. prerequisites, experience, or program-specific questions). You create forms once, then assign one form per program offering and choose when students complete it: before checkout, during enrollment, or after payment.
## Where to find this
Go to [**Program Dashboard → Applications**](https://www.firstrespondershub.com/program-dashboard/applications). Here you create and edit forms and view or review submissions.
## More detail on building forms
| Topic | What it covers |
| ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Sections and fields](/enrollment/applications-sections-fields) | How sections work, required vs optional, all field types (text, email, phone, date, select, file, image, address, etc.), validation, and options for select/radio/multiselect |
| [Section templates](/enrollment/applications-templates) | Pre-built section templates (Student Information, Mailing Address, Screening Questions, Additional Information, Custom) and when to use them |
| [Profile field mapping](/enrollment/applications-profile-mapping) | Which application fields can sync to the student’s profile (name, email, phone, address, profile picture) and how that works on submit |
## Creating an application form
1. On the Applications page, click **Create New Application**.
2. Set:
* **Form name** — Internal label for your team.
* **Form title** — Title applicants see.
* **Form description** — Optional; shown to applicants.
* **Allow multiple submissions** — Whether the same person can submit more than once (e.g. for different cohorts).
3. Build the form using the editor: add sections and fields (text, dropdowns, checkboxes, etc.) as needed.
4. Save. The form gets a **public slug** used in the application URL (e.g. for sharing or embedding).
You can edit an existing form at any time. Changes apply to future submissions; existing submission data is unchanged.
## Managing submissions
* **Submissions list:** On the Applications page you see submissions across forms. Use filters to narrow by application form, cohort, or status (e.g. submitted, approved, rejected).
* **Per-form view:** Open a form, then go to its **Submissions** tab to see only that form’s submissions.
* **Review:** Open a submission to view answers, then **Approve** or **Reject**. You can add review notes. Rejected applicants can be given a reason and your organization’s contact info.
* **Submission history:** You can view a student’s submission history (e.g. multiple submissions for different cohorts) to see past decisions and notes.
Approved submissions are linked to the student and cohort. For forms set to **Needs approval**, the student can complete checkout only after approval.
## One application per offering
Each program offering can have **only one** application form assigned. If you need different questions per cohort, you can use multiple forms and assign the right form to each offering.
## Assigning an application to a program offering
1. Go to [**Program Dashboard → Program Offerings**](https://www.firstrespondershub.com/program-dashboard/program-offerings).
2. Open the program offering.
3. Open the **Settings** tab.
4. In the left sidebar, select **Required Applications**.
5. Check the application form you want for this offering.
6. Choose **Application timing** (see below).
7. Click **Update Program Offering** to save.
To change or remove the application, edit the offering again and update the Required Applications section.
## Application timing
When an application is assigned to an offering, you choose **when** the student completes it:
| Timing | Label in UI | What it does |
| ------------------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Needs approval** | Needs Approval | Student submits the application first. You review and approve or reject. The student can complete payment only after approval. |
| **As part of enrollment** | As part of enrollment | The application is filled out during the enrollment flow (e.g. after agreements, before or with payment). No separate approval step required to proceed. |
| **Post-enrollment** | Post-Enrollment | Student completes the application **after** payment. They can do it from the student dashboard. |
Choose the option that matches your process (e.g. screen applicants before payment vs. collect info after they’re enrolled).
## Summary
* Create and edit forms under **Applications**; build sections and fields in the form editor.
* View and filter submissions; approve or reject with optional notes.
* Assign **one** application per program offering in the offering’s **Required Applications** section.
* Set **application timing** to control whether students must be approved before checkout, fill the form during enrollment, or complete it after enrollment.
# Profile field mapping
Source: https://docs.firstrespondershub.com/enrollment/applications-profile-mapping
Which application fields sync to the student profile and how they are updated on submit
Some application form fields can be **mapped** to the student’s profile. When an applicant submits the form, the values they enter in those fields are used to update their profile (the **users** record). That keeps the student’s name, contact info, address, and profile picture in one place and lets you use the same data across the platform (e.g. student dashboard, program dashboard, emails).
## Where to set this
When [editing an application form](https://www.firstrespondershub.com/program-dashboard/applications), open a section and edit a field. In the field editor, find **Auto-fill from User Profile**. The dropdown lists the profile fields that are valid for that field type. Choose one to map the field to the student profile, or **None** so the value is only stored in the submission.
## Mapped profile fields
The following profile mappings are supported. Not every field type is suitable for every mapping (e.g. “Profile Picture” only applies to **Image upload** fields).
| Mapping | Profile field | Typical form field type | What happens on submit |
| ------------------- | --------------------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **First Name** | `first_name` | Text | Value is saved to the user’s first name. |
| **Last Name** | `last_name` | Text | Value is saved to the user’s last name. |
| **Email** | `email` | Email | Value is saved to the user’s email. |
| **Phone** | `phone` | Phone | Value is normalized to digits and saved to the user’s phone. |
| **Address Line 1** | `address_line1` | Text (or address) | Value is saved to the user’s address line 1. |
| **Address Line 2** | `address_line2` | Text (or address) | Value is saved to the user’s address line 2. |
| **City** | `city` | Text (or address) | Value is saved to the user’s city. |
| **State** | `state_code` | Text or Select (e.g. state codes) | Value is saved to the user’s state code. |
| **ZIP Code** | `zip_code` | Text (or address) | Value is saved to the user’s ZIP code. |
| **Profile Picture** | `profile_picture_url` | **Image upload** only | The uploaded image is copied to the student’s profile photo storage and the profile picture URL is updated. |
If you do **not** set a mapping (None), the value is still stored in the application submission but is **not** written to the user profile.
## Pre-fill from profile
When a field has a profile mapping, the application form can **pre-fill** that field from the student’s current profile (if they are logged in and the profile already has data). So returning applicants may see name, email, phone, or address already filled in. They can change the values; on submit, the profile is updated with whatever they submitted.
## Profile picture (image upload)
* Only **Image upload** fields can use the **Profile Picture** mapping.
* On submit, the image file is copied from the application uploads storage to the **student profile photos** storage. The user’s `profile_picture_url` is then set to that new image.
* If the applicant uploads multiple images, the first one is used as the profile picture.
* If the copy or update fails (e.g. storage error), the application submission still succeeds; the profile picture is simply not updated.
## When updates happen
Profile updates from application submissions happen **when the applicant submits the form** (e.g. after clicking Submit on the application page, or when completing the form during or after enrollment). The submission is saved first; then any fields with profile mappings are applied to the **users** table for that user. The enrollment flow does not change: approval, payment, and post-enrollment steps work the same whether or not you use profile mapping.
## Summary
* Use **Auto-fill from User Profile** on a field to map it to a profile field (first name, last name, email, phone, address fields, or profile picture).
* Mapped fields can be pre-filled from the profile and are updated on submit.
* **Profile Picture** is only for Image upload fields; the uploaded image is copied to profile photo storage and the profile picture URL is set.
* Unmapped fields are stored only in the submission, not on the profile.
# Sections and fields
Source: https://docs.firstrespondershub.com/enrollment/applications-sections-fields
How application form sections and fields work: required rules, field types, validation, and options
Application forms are built from **sections** (groups of questions) and **fields** (individual questions). Each section has a title, optional description, and a “required” setting. Each field has a type (e.g. text, email, select), optional help text, required/optional behavior, and for some types, options or validation rules.
## Where to configure
When [editing an application form](https://www.firstrespondershub.com/program-dashboard/applications), use **Form Sections** to add sections (from templates or custom), then add or edit fields inside each section. Sections and fields can be reordered by dragging.
## Sections
* **Section title** — Shown to the applicant (e.g. “Student Information”, “Mailing Address”).
* **Section description** — Optional text below the title (e.g. “Please provide your current contact details.”).
* **Required section** — When turned **on**, every field in that section is required. When **off**, you can mark each field as required or optional individually.
* **Order** — Sections are shown in the order you set (drag to reorder).
You can add sections by choosing a [section template](/enrollment/applications-templates) (e.g. Student Information, Mailing Address) or a **Custom** section and then adding your own fields.
## Required: section vs field
* If **Section** is required: all fields in that section are required. The “Required field” switch on each field is ignored (and disabled in the editor).
* If **Section** is not required: each field can be set to required or optional via the “Required field” switch.
Use a required section when the whole block must be completed (e.g. “Student Information”). Use a non-required section when only some questions are mandatory.
## Field types
Each field has a **field type** that controls how the applicant enters data and how it is validated and stored.
| Type | Description | Typical use |
| ---------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| **Text** | Single-line text. Optional placeholder. | Short answers (name, certification number). |
| **Email** | Email input with format validation. | Email address. |
| **Phone** | Phone input; stored as digits. | Phone number. |
| **Date** | Date picker. | Date of birth, certification date. |
| **Number** | Numeric input. | Age, years of experience. |
| **Textarea** | Multi-line text. Optional row count. | Comments, longer responses. |
| **Select** | Dropdown; one option. | State, shirt size, single choice. |
| **Multi-select** | Multiple options from a list. | “Select all that apply.” |
| **Radio** | Single choice from radio buttons. | Yes/No, one of several options. |
| **Checkbox** | Single checkbox (e.g. “I agree”). | Consent, one-off yes/no. |
| **Address** | Full address: line 1, line 2, city, state, ZIP. | Mailing or billing address. |
| **Image upload** | Image file(s). Optional “allow multiple”; size limit 5MB per file. Accepted: JPEG, PNG, GIF, WebP, HEIC, HEIF, AVIF. | Profile photo, ID photo. |
| **File upload** | Document file(s). Optional “allow multiple”; size limit 8MB per file. Accepted: PDF, DOC, DOCX, XLS, XLSX, TXT, CSV. | Resumé, certificate. |
For **Select**, **Radio**, and **Multi-select** you define the **options** (one per line in the editor). At least two options are required. The applicant sees these in the order you enter them.
## Field settings (per field)
* **Field label** — The question or prompt (e.g. “First Name”, “Date of Birth”).
* **Help text (optional)** — Shown below the label to clarify the question.
* **Required field** — Whether the applicant must fill this field (see [Required: section vs field](#required-section-vs-field) above).
* **Field type** — One of the types in the table above.
* **Options** — For select/radio/multiselect: one option per line.
* **Auto-fill from User Profile** — If set, the field is [mapped to the student profile](/enrollment/applications-profile-mapping): it can be pre-filled from the profile and is updated on submit when applicable.
For **Image** and **File upload** you can also set:
* **Allow multiple files** — Whether the applicant can upload more than one file.
* **Maximum number of files** — When multiple is allowed, between 2 and 10.
## Validation
* **Email** and **Phone** — Validated for format; phone is normalized to digits for storage.
* **Address** — Address fields are validated as appropriate (e.g. state as a code, ZIP format).
* **Select / Radio / Multi-select** — Only the options you define are accepted.
* **Number** — Only numeric input is accepted.
* **Date** — Only valid dates.
For **Text** or **Textarea** you can use **validation rules** (e.g. regex pattern and error message) if your form editor exposes them. Example: ZIP code pattern `^[0-9]{5}(-[0-9]{4})?$` with a “Please enter a valid ZIP code” message. Validation rules are stored in the field configuration and applied when the applicant submits.
## Summary
* Build forms from **sections**; each section has a title, optional description, and required on/off.
* **Required section** = all fields in that section required; otherwise set **Required field** per field.
* Use the right **field type** (text, email, phone, date, number, textarea, select, multiselect, radio, checkbox, address, image, file) and configure **options** for select/radio/multiselect.
* Use **Auto-fill from User Profile** so a field syncs to the [student profile](/enrollment/applications-profile-mapping) and is pre-filled/updated on submit where applicable.
# Section templates
Source: https://docs.firstrespondershub.com/enrollment/applications-templates
Pre-built application section templates: Student Information, Mailing Address, Screening Questions, Additional Information, and Custom
When you add a section to an application form, you can start from a **section template**. Templates are pre-built sets of sections with suggested titles, descriptions, and fields (including field types and, where relevant, profile mapping). You can use them as-is or edit the section and fields after adding.
## Where to find this
When [editing an application form](https://www.firstrespondershub.com/program-dashboard/applications), click **Add Section** (or the equivalent). A **Select a Section Template** dialog lists the available templates. Choose one to preview its fields, then click **Use Template** to add it to your form. You can reorder sections and edit or remove any field.
## Available templates
### Student Information
* **Template type:** `student_info`
* **Purpose:** Basic contact and personal information.
* **Typical fields:** First Name, Last Name, Email Address, Phone Number, Date of Birth, Gender (select), Shirt Size (select). Many of these are set up with [profile field mapping](/enrollment/applications-profile-mapping) so they sync to the student’s profile (e.g. first name, last name, email, phone).
* **Use when:** You want a standard “about the applicant” block that can also update the student profile.
### Mailing Address
* **Template type:** `mailing_address`
* **Purpose:** Mailing and billing address.
* **Typical fields:** Address Line 1, Address Line 2, City, State (dropdown of US state codes), ZIP Code (with validation), and an optional “Use this address for billing” checkbox. Address fields are mapped to profile address fields where applicable.
* **Use when:** You need a full address for mailings, billing, or records.
### Screening Questions
* **Template type:** `screening_questions`
* **Purpose:** Pre-enrollment yes/no or short screening questions.
* **Typical fields:** Radio questions such as “Do you have a valid driver’s license?”, “Are you at least 18 years of age?”, “Do you have a high school diploma or GED?”, “Have you been convicted of a felony?”, “Are you currently employed?” (optional). Options are typically “Yes” / “No”.
* **Use when:** You want a quick screening block; you can edit the questions and options to match your program.
### Additional Information
* **Template type:** `additional_info`
* **Purpose:** Extra details and comments.
* **Typical fields:** Certification Number (text), County (text), “How did you hear about us?” (select), Referral Source Details (text), Additional Comments (textarea). No profile mapping by default.
* **Use when:** You want a catch-all section for optional or program-specific info.
### Custom Section
* **Template type:** `custom`
* **Purpose:** Empty section; you add all fields yourself.
* **Use when:** None of the pre-built templates fit; you define the section title, description, required/optional, and every field and its type.
## System vs custom templates
The templates above are **system templates**: they are built in and available to all organizations. When you “use” a template, a **copy** of that section (and its fields) is added to your form. Changing your form does not change the template; the template stays the same for future forms.
Organizations do not create or delete system templates. You only choose a template when adding a section, then edit the resulting section and fields as needed (e.g. add/remove fields, change labels, set required, or add profile mapping).
## After adding a template
* Reorder the section by dragging it in the form editor.
* Edit the section title or description.
* Toggle **Required section** for that section.
* Add, edit, reorder, or remove fields.
* For any field, set **Auto-fill from User Profile** (profile field mapping) if you want that value to [sync to the student profile](/enrollment/applications-profile-mapping).
So templates are a starting point; the form you build is fully editable.
# Deleting or discontinuing program offerings
Source: https://docs.firstrespondershub.com/enrollment/deleting-or-discontinuing-program-offerings
When you can delete a program offering, where to find the option, and using Discontinued when delete is not available.
You can permanently delete a program offering only when it has no enrollments in any of its cohorts. If it has enrollments, you can set it to **Discontinued** instead so it no longer appears on the public site while keeping the data in your dashboard.
## Where to find it
1. Go to [**Program Dashboard → Program Offerings**](https://www.firstrespondershub.com/program-dashboard/program-offerings) and open the offering.
2. Open the **Settings** tab.
3. In the left sidebar, click **Danger Zone**.
The Danger Zone section shows either **Delete program offering** or **Set to Discontinued**, depending on whether the offering has enrollments.
## When you can delete
You’ll see a **Delete program offering** button only when the offering has **no enrollments** in any of its cohorts.
If you delete the offering:
* The program offering and **all of its cohorts** are permanently removed.
* This action **cannot be undone**.
After you confirm, you’ll be taken back to the Program Offerings list.
## When you cannot delete (use Discontinued instead)
If the offering has one or more enrollments (in any cohort), the Danger Zone will not show Delete. Instead you’ll see **Set to Discontinued**.
**What Discontinued does:**
* The offering is **hidden from the public site** (students and visitors no longer see it).
* The offering and its data **remain in your dashboard** so you can keep records, view enrollments, and manage cohorts.
Use **Set to Discontinued** when you want to stop new signups and hide the offering from the public without losing enrollment or cohort data. Deleting is only for offerings that have no enrollments and that you want to remove entirely.
## See also
* [Program offering enrollment settings](/enrollment/program-offerings-settings) — Configure agreements, applications, and payment per offering.
* [Cohort Management](/cohort-management) — Create and manage cohorts for your offerings.
* [Deleting a cohort](/cohort-management/deleting-a-cohort) — When and how to delete a cohort.
# Email notifications
Source: https://docs.firstrespondershub.com/enrollment/email-notifications
Student confirmation and admin notification emails: when they're sent and what they contain
When a student completes enrollment (after successful payment or free enrollment), two emails are sent automatically: one to the student and one to the program owner. You do not need to turn these on; they are part of the enrollment confirmation flow.
## When the emails are sent
Both emails are sent **as soon as enrollment is confirmed**. That happens when:
* The student completes payment (full, deposit, or a payment plan's down payment), or
* The student completes a free enrollment (no payment), or
* An invited student finishes joining from their invite link.
There is no separate setting to enable or disable these emails; they are sent every time an enrollment is confirmed.
## Student confirmation email
* **Who receives it:** The student (at the email address they used to enroll).
* **What it contains:**
* Confirmation that they are enrolled (or that their event registration is confirmed, for event-type offerings).
* Program name and cohort name.
* Cost and date paid.
* Confirmation number (for your and their records).
* Cohort start and end dates.
* Program location.
* Your organization’s contact email and phone (so they know who to reach out to).
* A link to the student dashboard.
The exact wording varies slightly for **programs** vs **events** (e.g. “Enrollment confirmed” vs “Event registration confirmed”), but the information above is always included.
## Admin notification email
* **Who receives it:** The **program owner** for the organization (the user who can access Agreements and full program settings).
* **What it contains:**
* Notice that a new student has enrolled.
* Student name and email.
* Program name and cohort name.
* Cost and date paid.
* Confirmation number.
* Cohort start and end dates.
* Program location.
* Organization contact details.
* A link to the program dashboard so you can view the student or enrollment details.
This gives you a quick summary of each new enrollment without logging in.
## Emails an invited student gets
A student you invite to a class gets a different set of emails first. They are all automatic.
| Email | When it goes out |
| ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **You're Invited to Join `{class}`** | Right after you send the invite. The wording matches the tuition choice: no balance, an invoice after they join, or "your seat is being held until `{date}` — pay tuition of `{amount}` to claim it." |
| **Reminder: Accept your invitation to join `{class}`** | 2 days after the invite, then at least 2 days apart, up to 10 times. It repeats the same tuition terms, so a reminder can never contradict the first email. |
| **Payment received — finish joining `{class}`** | Only for **Must pay before enrolling** invites, once their payment lands. It tells them what they paid and links them back to finish. |
| **Student confirmation** (above) | When they actually become enrolled. |
| **Invoice created** | When anything is still owed after they join — a full invoice for "enroll now, invoice after", or the remaining balance after a deposit. It includes a working pay link. |
A student paying their own tuition is never sent the sponsor emails ("complete a sponsored purchase"). Those are only for an employer or department paying on someone else's behalf. See [Sponsored payments](/payment-settings/sponsored-payments).
Full details of the invite itself: [Students and invites](/cohort-management/students-and-invites).
## What you can't configure (for these emails)
* You cannot turn the student confirmation or admin notification on or off in the dashboard.
* You cannot change the content or layout of these emails from the app (e.g. add custom fields or change wording). The platform uses the data from the enrollment and offering (program name, cohort, cost, dates, contact info) to fill the templates.
## After enrollment: what students see
In addition to the confirmation email, students see:
* The **enrollment confirmation page** right after they complete enrollment. It can show your **welcome message** and **next steps** if you configured them in the program offering’s [Post-Enrollment Instructions](/enrollment/program-offerings-settings#post-enrollment-instructions).
* The **student dashboard**, where the same welcome message and next steps can appear. They can also complete any **post-enrollment** application form from the dashboard if you assigned one to the offering.
So the confirmation email is the main “receipt” and summary; the confirmation page and dashboard carry your custom post-enrollment instructions and tasks.
# Overview
Source: https://docs.firstrespondershub.com/enrollment/index
Everything that shapes how a student signs up: agreements, application forms, offering settings, and the emails that go out.
This section is about how a student goes from "interested" to "enrolled."
Four things shape that: the agreements they have to accept, the forms they have to fill in, the settings on the program itself, and the emails that go out afterward.
## What's in this section
| Guide | What it covers |
| ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| [Agreements](/enrollment/agreements) | Waivers and terms students accept while signing up. |
| [Applications](/enrollment/applications) | Forms you build, when they are required, and how to review them. |
| [Program offering settings](/enrollment/program-offerings-settings) | What each program requires: agreements, applications, what's included, and how students pay. |
| [Email notifications](/enrollment/email-notifications) | What the student gets, what you get, and when. |
| [Deleting or discontinuing offerings](/enrollment/deleting-or-discontinuing-program-offerings) | Taking a program down without breaking your records. |
## Where these live
| Feature | Where to find it | Who can use it |
| --------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| **Agreements** | [Program Dashboard → Agreements](https://www.firstrespondershub.com/program-dashboard/agreements) | Program owners |
| **Applications** | [Program Dashboard → Applications](https://www.firstrespondershub.com/program-dashboard/applications) | Owners build forms; instructors can review submissions |
| **Offering settings** | [Program Dashboard → Program Offerings](https://www.firstrespondershub.com/program-dashboard/program-offerings) | Program owners |
## Program versus class
Settings in this section belong to the **program**, so every class in it shares them. If you need something to differ from one class to the next, that lives on the class instead. See [Class settings](/cohort-management/settings-overview).
# Program offering enrollment settings
Source: https://docs.firstrespondershub.com/enrollment/program-offerings-settings
Configure required agreements, applications, post-enrollment instructions, what's included & costs, and payment options per offering
Program offering settings control how students enroll and what they see before and after payment. This page describes the settings that directly affect enrollment: required agreements, required applications, post-enrollment instructions, what’s included & costs, and payment configuration.
## Where to configure
Go to [**Program Dashboard → Program Offerings**](https://www.firstrespondershub.com/program-dashboard/program-offerings), open an offering, and select the **Settings** tab. Use the left sidebar to switch between sections. Click **Update Program Offering** at the bottom to save changes (except where noted).
## Required Agreements
* **What it is:** The list of agreements students must accept during enrollment for this offering.
* **How to set:** In the sidebar, open **Required Agreements**. Check each published agreement you want to require. You can select multiple agreements.
* **Student experience:** During enrollment, students see each selected agreement and must accept all of them before continuing. See [Agreements](/enrollment/agreements) for creating and publishing agreements.
## Required Applications
* **What it is:** The single application form required for this offering, and when the student completes it.
* **How to set:** In the sidebar, open **Required Applications**. Select one application form and choose **Application timing**: Needs approval (submit first, then you approve before checkout), As part of enrollment (filled during the flow), or Post-enrollment (completed after payment).
* **Student experience:** Depends on timing: pre-approval blocks checkout until you approve; during enrollment shows the form in the flow; post-enrollment lets them complete it from the student dashboard after they’re enrolled. See [Applications](/enrollment/applications) for forms and submissions.
## Post-Enrollment Instructions
* **What it is:** A welcome message and a list of “next steps” (e.g. complete forms, bring documents, join a group) shown to students after they enroll.
* **How to set:** In the sidebar, open **Post-Enrollment Instructions**.
* **Welcome message (optional):** Text shown on the enrollment confirmation page and in the student dashboard. Use it to thank them and set expectations.
* **Next steps:** Add steps with a **title** (required), optional **description**, and optional **link** (must start with `http://` or `https://`). Drag to reorder. Students see these in the order you set.
* **Student experience:** After payment (or free enrollment), the confirmation page and dashboard show the welcome message and the ordered list of next steps. Links open in a new tab.
## What's Included & Costs
* **What it is:** Line items that describe what’s included in the offering and any extra costs (e.g. materials, fees). Shown to students during or after enrollment.
* **How to set:** In the sidebar, open **What's Included & Costs**. Add items with a category (e.g. tuition, materials, other), title, optional description, and either a price or a pricing note (e.g. “Included” or “TBD”). You can reorder items by dragging.
* **Student experience:** Students see this breakdown so they understand what they’re paying for and what’s included.
## Payment Configuration
* **What it is:** Tuition amount and how students can pay: full payment upfront, deposit with balance due later, a monthly payment plan, or enrollment without payment. Also when the balance is due (relative to cohort start or end).
* **How to set:** In the sidebar, open **Payment Configuration**. Set the **Tuition amount** (use 0 for a free offering). For paid offerings, enable one or more of: **Allow full payment upfront**, **Allow deposit** (and deposit amount), **Allow payment plan** (down payment, plan total, number of installments), **Allow enrollment without payment**. Set **Invoice due date** reference (days before cohort start or end) and the number of days.
* **Student experience:** During enrollment, students see the options you enabled (e.g. “Pay in Full” or “Pay Deposit Now”) and complete payment or choose “Enroll Without Payment” if allowed. Balance due is invoiced later per your due-date rules.
### Invited Students
At the bottom of Payment Configuration, a separate **Invited Students** card sets the defaults for people your staff invite to a class by email:
* **How they are billed:** **No tuition owed**, **Enroll now, invoice after**, or **Must pay before enrolling** (the seat is held and no enrollment exists until the money lands).
* **What they can choose to pay** (pay-first only): pay in full, pay a deposit, or a payment plan. You can only offer what you turned on above, and a payment plan needs a down payment greater than \$0.
* **Hold the seat for (days):** 1–90 days, default 14. A hold never runs past the cohort start date, and an unpaid seat is released automatically.
Staff can override any of these on a single invite. Whatever they send is locked onto that invite, so later edits here do not change terms a student has already been shown.
Full details (full vs deposit vs plan vs no payment, balance due rules, invited students, currency) are in [Payment configurations](/payment-settings/payment-configurations). For the invite form itself, see [Students and invites](/cohort-management/students-and-invites).
## Other offering settings
The same offering page includes other sections that support the program but are not enrollment-specific:
* **Program Information** — Name, description, template, modality, status.
* **Full Description** — Rich description for the public program/offering page.
* **Location & Logistics** — Location and schedule type.
* **Courses** — Which courses are part of this offering and their order.
* **Promo Codes** — Promo codes scoped to this offering (see [Coupons](/payment-settings/coupons)).
* **FAQs** — Frequently asked questions for the offering.
* **Feedback & Reviews** — Feedback and review settings for the offering.
You can configure these in the same Settings tab; they do not change the enrollment flow steps described above.
## See also
* [Deleting or discontinuing program offerings](/enrollment/deleting-or-discontinuing-program-offerings) — When you can delete an offering or set it to Discontinued (Danger Zone).
# Introduction
Source: https://docs.firstrespondershub.com/guides/introduction
Concepts and definitions for First Responder Training Organizations
This page explains the words FirstRespondersHub uses. Read it once and the rest of the docs will make sense.
## Quick reference
| Term | Description |
| ----------------------------------------------- | ------------------------------------------------------------------------------------ |
| [Organization](#organization) | Training provider entity; has locations and program offerings |
| [Location](#location) | Physical or virtual place where training occurs |
| [Program template](#program-template) | Platform-level program type (e.g. EMT, Paramedic); you create offerings from it |
| [Program offering](#program-offering) | Your version of a program; recurring (weeks/months) or single-day event |
| [Cohort](#cohort) | A specific run of an offering with dates and capacity |
| [Cohort status](#cohort-status) | Where a class is in its life: Getting ready → Open → Full → Happening now → Finished |
| [Session](#session) | Single class meeting within a cohort (lecture, lab, exam) |
| [Modality](#modality) | Delivery: in-person, virtual, or hybrid |
| [Enrollment](#enrollment) | A student’s place in a cohort and its status |
| [Application forms](#application-forms) | Custom forms attached to offerings (before or after enrollment) |
| [Enrollment agreements](#enrollment-agreements) | Terms/waivers students must accept during enrollment |
| [Roles](#roles) | Program owner, Instructor, Student, Sponsor |
| [Student access](#student-access) | Vendor codes and links (Jones & Bartlett, AHA, custom) sent to students |
| [How it fits together](#how-it-fits-together) | Diagram: organization → offerings → cohorts → sessions & enrollments |
## Core concepts
### Organization
Your **organization** is the training provider entity on the platform. It has a name, contact details, description, and one or more locations and program offerings.
### Location
A **location** is a physical or virtual place where training occurs. Organizations can have multiple locations. Each location has an address (or virtual designation), timezone, and can host sessions for your cohorts.
### Program template
A **program template** is a standardized program type defined at the platform level—for example, EMT-Basic, Paramedic, or Firefighter I/II. It describes the credential type, accreditation body, industry category (e.g. EMT, paramedic, fire, basic healthcare), and typical duration. Your organization does not create templates; you create **program offerings** that implement a template. If a program template you need is not available, please [reach out to support](https://www.firstrespondershub.com/support) and we will add it.
**Example:** EMT.
### Program offering
A **program offering** is your organization’s version of a program. You define its name, description, delivery modality (in-person, virtual, or hybrid), schedule types, tuition, default capacity, and which locations it uses. Each offering can have multiple **cohorts** (specific runs with dates and capacity). Application forms and enrollment agreements are attached at the offering level. Offerings can be **recurring** (programs with classes over weeks or months, e.g. an EMT course) or **events** (single-day workshops or classes).
**Example:** EMT Accelerated (4 Weeks) and EMT Part Time (14 Weeks).
### Cohort
A **cohort** is one run of a program offering — for example, "Fall 2026 EMT Class." It has a start date, an end date, a seat count, a sign-up deadline, and a status. Students enroll in a cohort, not in the offering. In the dashboard you will often see a cohort called a **class**.
**Example:** For EMT Accelerated (4 Weeks)—January 2026, March 2026. For EMT Part Time (14 Weeks)—February – May 2026, June – September 2026.
```mermaid theme={null}
flowchart TB
EMT["Program template: EMT"]
EMT --> Acc["Program offering: EMT Accelerated (4 Weeks)"]
EMT --> PT["Program offering: EMT Part Time (14 Weeks)"]
Acc --> C1["Cohort: January 2026"]
Acc --> C2["Cohort: March 2026"]
PT --> C3["Cohort: February - May 2026"]
PT --> C4["Cohort: June - September 2026"]
```
### Cohort status
A class moves through these states. You pick three of them. The platform sets the other three for you.
**You pick:**
* **Getting ready** — You are still setting it up. Nobody can sign up, and it stays off your website.
* **Pre-enrollment waitlist** — Sign-ups are not open, but people can add their name.
* **Open** — Students can sign up and pay.
**We set:**
* **Full** — The last seat filled, or the sign-up deadline passed.
* **Happening now** — The first class date started.
* **Finished** — The last class date ended.
Two more states sit outside this list, because neither is about selling: **Cancelled** (the class was called off) and **Archived** (filed away). See [Status and who can find it](/cohort-management/status-and-visibility).
### Session
A **session** is a single class meeting within a cohort—e.g. a lecture, lab, exam, or skills practice. Sessions have start and end times, can be tied to a location (or virtual link), and together form the cohort’s schedule.
### Modality
**Modality** describes how a program is delivered:
* **In-person** — Training occurs at a physical location.
* **Virtual** — Training is fully online.
* **Hybrid** — Mix of in-person and virtual.
### Enrollment
An **enrollment** is a student’s place in a cohort. Each enrollment has a status, such as:
* **Enrolled** — Active student in the cohort.
* **Completed** — Finished the program.
* **Paid pending application** — Payment received; awaiting required post-enrollment form(s).
* **Withdrawn** — Student withdrew.
* **Dropped** — Student was dropped.
* **Failed** — Did not complete successfully.
### Application forms
**Application forms** are custom forms you attach to program offerings. They can be required **before** enrollment (e.g. background or certification info) or **after** enrollment (e.g. post-payment paperwork). Some forms require organization approval before the student can complete checkout.
### Enrollment agreements
**Enrollment agreements** are terms, waivers, or policies (e.g. liability, code of conduct) that students must accept during enrollment. You create and manage them at the organization level and assign which agreements are required per program offering. Acceptance is recorded for compliance.
### Roles
* **Program owner** — Can do everything: offerings, classes, applications, enrollments, agreements, money, and settings.
* **Instructor** — Sees the classes they teach. Takes attendance and records results. Never sees money.
* **Student** — Enrolls in classes and uses the student dashboard.
* **Sponsor** — An employer or department that pays for someone else's seat.
See [Users and roles](/organization-settings/users-and-roles).
### Student access
**Student access** (also called access codes or credentials) is how you give students the codes, links, or logins they need for a vendor site such as Jones & Bartlett Navigate or American Heart Association eLearning. You import unused codes, the platform holds one set per student, and it sends them by email and the student dashboard. See [Student access](/student-access).
## How it fits together
```mermaid theme={null}
flowchart LR
Org[Organization] --> Loc[Locations]
Org --> Offerings[Program offerings]
Template[Program template] --> Offerings
Offerings --> Cohorts[Cohorts]
Cohorts --> Sessions[Sessions]
Cohorts --> Enrollments[Enrollments]
Offerings --> Apps[Application forms]
Offerings --> Agreements[Enrollment agreements]
```
Organizations have locations and program offerings. Each offering implements a program template and has cohorts. Cohorts have sessions and enrollments. Application forms and enrollment agreements are configured per offering.
## Need help?
For support or questions about the platform, visit [First Responders Hub Support](https://www.firstrespondershub.com/support).
# Setup Overview
Source: https://docs.firstrespondershub.com/guides/setup-overview
Step-by-step guide to configuring your organization, instructors, offerings, cohorts, and payments so you can accept enrollments.
This guide walks through setting up your organization on First Responders Hub. Follow the steps in order: configure your organization and team, create program offerings and cohorts, connect payments (if you charge tuition), then open cohorts so students can enroll.
For definitions of organizations, locations, [program offerings](/guides/introduction#program-offering), [cohorts](/guides/introduction#cohort), and [cohort lifecycle](/guides/introduction#cohort-lifecycle), see [Key Concepts](/guides/introduction).
## 1. Set up your organization (info, locations, FAQs)
**Where:** [Organization Profile](https://firstrespondershub.com/program-dashboard/settings/organization-information).
* **Basic Information** — Enter your organization name, type (e.g. Community College, Fire Department), website, phone, email, and description. Set your **public slug** (used in your public URLs). Use **Save** to apply; you can copy your public organization URL from this section.
* **Locations** — Add, edit, or remove locations (name, address, timezone). Locations are used when scheduling sessions and when defining program offerings. You need at least one location for in-person or hybrid programs.
* **FAQs** — Add and reorder organization-level FAQs. These can be shown on your public pages.
* **Program Display** — Optional settings for how your programs are displayed to the public.
Complete Basic Information and at least one Location before creating program offerings that use them.
## 2. Add and invite instructors (profiles and headshots)
**Where:** [Users](https://firstrespondershub.com/program-dashboard/settings/organization-users).
* **Instructor profiles** — Create a profile for each instructor: email, display name, title, and optional description. You can add an optional **headshot** (upload and crop). Profiles can exist before the person has an account; they are linked to a user once the invite is accepted.
* **Invites** — Send an organization invite with the **instructor** role. You can link the invite to an existing instructor profile so the invitee’s name, title, description, and photo appear after they accept. Only program owners can invite users.
* **Cohort assignment** — When [creating or editing a cohort](#4-create-cohorts), assign instructors to that cohort. Assigned instructors appear on the public cohort page. If you have no instructor profiles yet, the UI will direct you to add them under **Settings → Users** first.
## 3. Create program offerings
**Where:** [Program Offerings](https://firstrespondershub.com/program-dashboard/program-offerings).
* **Create** — Use **Create program offering**. Choose:
* **Program type** — Program (multi-session) or single-day Event.
* **Template** — e.g. EMT, Paramedic (platform-defined; contact support if you need another).
* **Primary location** (optional for virtual-only).
* **Program name** and **description**.
* **Modality** — In-person, virtual, or hybrid.
* **Schedule types** — e.g. part-time, evening, weekend.
* **Tuition amount** (0 for free offerings).
* **Status** — e.g. Active.
* **Payment configuration** — For paid offerings, set:
* Whether to allow **full payment**, **deposit**, or **no payment** (free).
* **Deposit amount** and when the **balance is due** (e.g. days before start or end).
* **Currency** (e.g. USD).
After creation, offerings appear in the list. You can edit each offering (payment config, application forms, enrollment agreements) from the program offerings area or the offering’s detail page.
## 4. Create cohorts
**Where:** [Cohorts](https://firstrespondershub.com/program-dashboard/cohorts). To create a new cohort: [Create cohort](https://firstrespondershub.com/program-dashboard/cohorts/create).
* **Create flow** — Select a **program offering**, then set:
* **Cohort name** (e.g. “Fall 2026”). Students see it as “EMT Training: Fall 2026” (program name + cohort name).
* **Start** and **end dates**, **enrollment deadline**, and **capacity**.
* **Recurrence/schedule** — e.g. weekly, specific days and times.
* **Location** for sessions (if applicable).
* **Instructors** — Assign one or more instructor profiles to this cohort.
* **Save as draft vs Publish** — Saving as **draft** keeps the cohort in [lifecycle](/guides/introduction#cohort-lifecycle) **Planning** (not visible for enrollment). **Publish** sets the lifecycle to **Open** so it can accept enrollments (see section 6).
After creation, open the cohort from the Cohorts list and go to the **Settings** tab. There you edit the name, dates, seat count, and status — including switching it to **Open** when you are ready for students. See [Class settings](/cohort-management/settings-overview).
## 5. Connect Stripe Connect and manage payment settings
**Where:** [Payment Settings](https://firstrespondershub.com/program-dashboard/settings/payments) (under Student Billing in the sidebar). Only **program owners** can manage payment accounts.
* **Stripe Connect** — Create or connect a Stripe account. The platform creates a connected account and sends you to Stripe’s onboarding flow. Complete business and banking details. When you return, the account status moves from **pending** → **onboarding** → **active** once Stripe has enabled charges and payouts.
* **Accepting payments** — After Stripe is fully onboarded, turn on the **Accept payments** toggle for your organization. This enables paid enrollments. **Free offerings** (tuition \$0) do not require Stripe or this toggle.
* **Plan limits** — Payment processing may be gated by your subscription plan; if the option is unavailable, check your plan or contact support.
## 6. Open cohorts for enrollment
To allow students to enroll in a cohort:
* **Lifecycle** — The cohort must be **Open**. Cohorts start in **Planning**; you change this when you’re ready to accept enrollments.
* **Where to set it** — [Cohorts](https://firstrespondershub.com/program-dashboard/cohorts) → select a cohort → **Overview** tab. Edit the cohort and set **Lifecycle state** to **Open**. (If you chose **Publish** when creating the cohort, it is already Open.)
**Requirements for public enrollment:**
* **Cohort** — Lifecycle is **Open** (or **Waitlist open** / **Full** as applicable).
* **Free offerings** — Your subscription must allow student enrollments.
* **Paid offerings** — Your subscription must allow payment processing, **Accept payments** must be on for the organization, and the offering must have tuition greater than zero.
Students use the public enroll URL for your org, program, and cohort (e.g. `…/enroll/[orgSlug]/[programSlug]/[cohortSlug]`). You can share links to your organization and cohort pages from the Program Dashboard.
## 7. Optional: courses and student access
If students complete lessons on FirstRespondersHub, [create a course](/courses/creating-and-managing) and [assign it to the offering](/courses/assigning-to-offerings).
If they also need codes or links from Jones & Bartlett, the American Heart Association, or another vendor, set the course delivery model and import codes. See [Student access](/student-access).
## Need help?
For support or questions, visit [First Responders Hub Support](https://www.firstrespondershub.com/support).
# FirstRespondersHub
Source: https://docs.firstrespondershub.com/index
Documentation for First Responder Training Organizations
Welcome to the FirstRespondersHub documentation.
## Getting started
The words we use, explained once: organizations, programs, classes, and enrollments.
Set up your organization, staff, programs, classes, and payments, in the right order.
## Documentation
The pages you check: your dashboard, calendar, student list, money, feedback, and marketing.
Take money from students: Stripe, payment options, invoices, promo codes, and refunds.
Waivers, application forms, program settings, and the emails that go out when someone signs up.
Run a class: set it up, fill the seats, build the schedule, take attendance, and record results.
Build a course out of modules and lessons, add videos and files, and attach it to a program.
Send students their Jones & Bartlett, AHA, or custom access codes, at the right time, without copy and paste.
Record what was taught and by whom, then pull the hours your instructors need for recertification.
Record who passed, who failed, and who got certified — one student or a whole class at a time.
Follow up with people who asked about your programs or left checkout without paying.
One list of everyone who has ever contacted you, with tags, saved lists, and email.
Post an announcement to one class or everyone, and choose whether it also goes out by email.
What your subscription covers, what each plan costs you, and how to change it.
Your public profile and locations, your staff and what they can see, and your own login.
# What updates automatically
Source: https://docs.firstrespondershub.com/leads/automatic-updates
What the platform does on its own when a lead enrolls or buys, so you do not have to.
You do not have to close out a lead by hand. When someone enrolls or buys, the platform updates things for you.
## The lead is marked Converted
When a student finishes enrolling in a class or buying a course, the platform looks for **active leads with the same email address**.
Any match is:
* Marked **Converted**
* Given a note saying they enrolled, with the confirmation number
So a lead who asked about EMT in March and enrolled in June moves to Converted on its own. Open the lead any time to read the full history.
## Reminder emails stop
If the lead came from an abandoned checkout, up to three reminder emails are queued. The moment they enroll or buy, any reminder that has not gone out is **cancelled**.
Nobody gets a "come back and finish" email after they have already finished.
You can still see the cancelled steps in the lead panel, which is how you know they converted partway through.
## Email statuses keep themselves current
As the email provider reports back, the status of each reminder updates on its own: scheduled, sent, delivered, failed, or cancelled.
There is nothing to refresh and nothing to click.
## The short version
| What happens | What the platform does |
| --------------------------------- | ---------------------------------------------------------- |
| Student enrolls or buys | Marks matching active leads **Converted** and adds a note. |
| That student had reminders queued | Cancels the ones that have not gone out. |
| The email provider reports back | Updates the status of each reminder. |
Your job is the **Active** list. The rest keeps itself tidy.
## See also
* [Viewing and filtering leads](/leads/viewing-and-filtering-leads) — Work the active list.
* [Cart abandonment emails](/leads/cart-abandonment-emails) — The reminder sequence.
# Cart abandonment emails
Source: https://docs.firstrespondershub.com/leads/cart-abandonment-emails
The three automatic follow-up emails sent to people who started checkout and stopped, and when they get cancelled.
Someone signs in, goes to checkout, and then closes the tab. That is an abandoned cart.
FirstRespondersHub follows up for you. It sends up to **three** emails reminding them what they were looking at, with a link straight back to checkout.
You do not have to do anything. The emails go out on their own.
| Email | When it goes out |
| ----- | ------------------------------- |
| 1 | 1 hour after they left checkout |
| 2 | 24 hours after |
| 3 | 48 hours after |
## What you see in the lead panel
Open the lead and look for **Cart abandonment emails**. You will see all three steps.
| Column | What it tells you |
| ----------------- | ----------------------------------------------------- |
| **Email 1, 2, 3** | Each step in the sequence. |
| **Status** | Scheduled, sent, delivered, failed, or cancelled. |
| **Dates** | When it was scheduled, and when it actually went out. |
So at a glance you know whether the reminders went out and whether they worked.
## When the emails stop
The moment the person enrolls or buys the course, two things happen:
1. Any reminder that has not gone out yet is **cancelled**. Nobody gets a "come finish your order" email after they have already ordered.
2. The lead status changes to **Converted**. See [What updates automatically](/leads/automatic-updates).
The lead panel still shows the cancelled steps, so you can see the person converted before the sequence finished.
## Example
Dana starts checkout for your March EMT class at 2 PM and stops at the payment step.
* **3 PM the same day** — email 1 goes out. Dana does not open it.
* **2 PM the next day** — email 2 goes out. Dana clicks it and enrolls.
* **Email 3 is cancelled.** The lead is now marked Converted.
## If someone comes back and leaves again
Coming back to checkout within 48 hours does not start a new sequence. It is the same abandoned cart.
After 48 hours, it counts as a fresh one, and a new set of three emails is scheduled.
## See also
* [Where leads come from](/leads/where-leads-come-from) — Cart abandonment is one of several sources.
* [What updates automatically](/leads/automatic-updates) — What else changes without you touching it.
# Overview
Source: https://docs.firstrespondershub.com/leads/index
Overview of leads and information requests: where they come from, how to view and manage them, status, notes, waitlists, and pipeline metrics.
Leads are people who asked for information about your programs or who started checkout but did not complete enrollment. The Leads section helps you track and follow up with them.
## Where to find Leads
Go to [**Program Dashboard → Leads**](https://firstrespondershub.com/program-dashboard/information-requests) in the sidebar. Program owners and instructors can view and manage leads for their organization.
## What you can do
* **View and filter leads** — See all leads in a table and filter by status (Active, Converted, Lost).
* **Open a lead** — Click a row to open the lead detail panel with full contact info, history, and actions.
* **Update status** — Mark leads as Active, Converted (enrolled or purchased), or Lost, with optional notes.
* **Add notes and activity** — Log calls, emails, meetings, or general notes so your team can see the full timeline.
* **Manage waitlists** — Add a lead to one or more cohort waitlists from the lead panel.
* **See cart abandonment emails** — For leads who left checkout, view the status of automated follow-up emails.
* **Review pipeline metrics** — Use the cards at the top (active pipeline value, converted count, lost count, new leads) to track progress.
## Learn more
| Guide | What it covers |
| ----------------------------------------------------------------- | ----------------------------------------------------------------------- |
| [Where leads come from](/leads/where-leads-come-from) | How leads are created: information request form and cart abandonment |
| [Viewing and filtering leads](/leads/viewing-and-filtering-leads) | Table columns, status filter, and opening the lead detail panel |
| [Lead details and status](/leads/lead-details-and-status) | Contact info, status meanings, and how to update status |
| [Notes and activity](/leads/notes-and-activity) | Logging calls, emails, meetings, and notes on a lead |
| [Waitlists](/leads/waitlists) | Adding leads to cohort waitlists and seeing which waitlists they are on |
| [Cart abandonment emails](/leads/cart-abandonment-emails) | Automated follow-up emails and when they are cancelled |
| [Pipeline metrics](/leads/pipeline-metrics) | What the four metric cards mean and how to use them |
| [What updates automatically](/leads/automatic-updates) | How leads and emails update when students enroll or purchase |
# Lead details and status
Source: https://docs.firstrespondershub.com/leads/lead-details-and-status
What the lead detail panel shows and how to update lead status.
When you click a lead in the table, the lead detail panel opens. It shows everything about that lead and lets you update their status and add notes.
## What the panel shows
At the top you’ll see:
* **Name** and current **status** (Active, Converted, or Lost)
* **Email** and **phone** (click to email or call)
* **Program / course** and **cohort** (if they chose one)
* **Lead value** (program tuition when available) and **created** date
Further down you’ll find status management, status history, activity timeline (notes), waitlist management, and (for cart abandonment leads) cart abandonment emails.
## Lead statuses
* **Active** — You’re still working this lead or they haven’t enrolled or purchased yet.
* **Converted** — They enrolled in a cohort or completed a course purchase. You can also mark a lead Converted manually if they signed up outside the platform.
* **Lost** — They’re no longer pursuing (e.g. chose another program or decided not to enroll).
## How to update status
1. In the lead detail panel, find the **Status Management** section.
2. Choose the new status from the **Status** dropdown (Active, Converted, or Lost).
3. Optionally add **Notes** to explain the change (e.g. “Enrolled in Fall 2026 cohort” or “Went with another provider”).
4. Click **Update Status**.
The lead’s status updates immediately and a new entry is added to **Status History** so you can see who changed it, when, and any notes. If you mark a lead Converted, it’s a good idea to add a short note so the rest of your team knows what happened.
## Status history
The **Status History** section lists every status change for this lead: the previous and new status, the date and time, and who made the change (if they’re a user in your organization). Any notes entered when updating status appear here too. This gives you a clear record of how the lead moved through your pipeline.
# Notes and activity
Source: https://docs.firstrespondershub.com/leads/notes-and-activity
How to log calls, emails, meetings, and other activities on a lead.
Logging notes and activities on a lead keeps your team aligned and gives you a clear timeline of what’s been done. You can add notes from the lead detail panel and they stay attached to that lead.
## Why log activities
* **Team visibility** — Anyone with access to Leads can see what was discussed and when.
* **Follow-up** — You can see the last contact date and what was said so you don’t repeat yourself or miss a next step.
* **History** — If a lead returns later or enrolls, you have a record of the journey.
## Adding a note
1. Open the lead by clicking their row on the Leads page.
2. In the lead detail panel, scroll to **Activity Timeline**.
3. Choose an **Activity type**:
* **Note** — General note or comment
* **Call** — Phone call
* **Email** — Email exchange
* **Meeting** — In-person or virtual meeting
* **Other** — Anything else (e.g. text, form response)
4. Type your **Content** in the text box (what was discussed, outcome, next steps, etc.).
5. Click **Add Note**.
The note appears in the activity list with the type, date and time, your name, and the content. You can add as many notes as you need; the most recent appear at the top.
## Where notes appear
All notes for a lead are listed in the **Activity Timeline** section of the lead detail panel. Each entry shows the activity type, when it was added, who added it, and the full content. The Leads table also shows a **Notes** column with the count of notes for each lead so you can see at a glance which leads have the most activity.
Notes are tied to the lead and visible to other program owners and instructors in your organization. They are not sent to the student; they are for internal use only.
# Pipeline metrics
Source: https://docs.firstrespondershub.com/leads/pipeline-metrics
What the four metric cards on the Leads page mean and how to use them.
At the top of the Leads page, four cards summarize your pipeline: how much potential value you have in active leads, how many leads have converted or were lost, and how many new leads you’ve gotten recently. These numbers help you prioritize follow-up and track progress.
## The four cards
### Active pipeline
* **Top number** — Total value (in dollars) of all leads currently marked **Active**, based on the program tuition for each lead.
* **Subtitle** — “Active pipeline” and the count of active leads.
Use this to see how much potential enrollment value is in your pipeline and how many leads you’re still working. A growing active pipeline may mean you need to dedicate more time to follow-up or that interest is strong.
### Converted
* **Top number** — Count of leads marked **Converted** (enrolled or purchased).
* **Subtitle** — “Converted” and “Successfully enrolled.”
This is your count of leads who became students. Track this over time to see how well you’re converting interest into enrollments.
### Lost
* **Top number** — Count of leads marked **Lost** (no longer pursuing).
* **Subtitle** — “Lost” and “No longer pursuing.”
These are leads you’ve closed out as not enrolling. Keeping this updated (by marking leads Lost when appropriate) keeps your active pipeline accurate and your follow-up list focused.
### New leads
* **Top number** — Number of new leads in the **last 7 days**.
* **Subtitle** — “New leads” and “X last 7 days, Y last 30 days.”
This shows recent interest. A spike in new leads might mean a marketing push or seasonal interest; you can then prioritize responding quickly to those new leads.
## How to use the metrics
* **Follow up on active pipeline** — Use the Leads table filtered to Active to work through your list and update status or add notes.
* **Measure conversion** — Compare Converted count over time and against New leads to see how well you turn interest into enrollments.
* **Keep the pipeline clean** — Mark leads as Converted when they enroll or Lost when they’re no longer interested so the Active pipeline and counts stay meaningful.
Lead value and pipeline totals use the program tuition for each lead when available. Leads tied only to a course (and not a program offering with tuition) may not add to the active pipeline dollar amount, but they still appear in the table and in the lead count.
# Viewing and filtering leads
Source: https://docs.firstrespondershub.com/leads/viewing-and-filtering-leads
Read the leads table, filter by status, and open a lead to work it.
The Leads page lists everyone who has asked about your programs. Metric cards sit at the top. The table sits below.
Open it from the sidebar: **Sales → Leads**.
## What each column tells you
| Column | What it shows |
| -------------- | --------------------------------------------------------- |
| **Date** | When the lead came in. |
| **Student** | Their name. A badge means they are on a waitlist. |
| **Status** | Active, Converted, or Lost. |
| **Email** | Click it to write to them. |
| **Phone** | Click it to call. |
| **Program** | What they asked about. |
| **Cohort** | The class, if they picked one. A dash means they did not. |
| **Lead value** | The tuition for that program, when we know it. |
| **Notes** | How many notes and activities you have logged. |
## Filter by status
Use the status dropdown above the table.
| Status | Who is in it |
| ------------- | ------------------------------ |
| **Active** | People you are still working. |
| **Converted** | People who enrolled or bought. |
| **Lost** | People who are not coming. |
The count next to the filter tells you how many leads you are looking at.
Filter to **Active** and work that list top to bottom. Converted and Lost are history — they are there for your records, not your to-do list.
## Opening a lead
Click any row. A panel slides in from the right with everything about that person: contact details, status history, your notes, waitlists they are on, and cart abandonment emails if they have any.
From the panel you can change the status, add a note, and add them to a class waitlist.
Close the panel and the list refreshes, so your change shows right away.
## See also
* [Lead details and status](/leads/lead-details-and-status) — What each status means and when to change it.
* [Notes and activity](/leads/notes-and-activity) — Keeping a record of your follow-up.
* [Pipeline metrics](/leads/pipeline-metrics) — The cards at the top of the page.
# Waitlists
Source: https://docs.firstrespondershub.com/leads/waitlists
Adding leads to cohort waitlists and viewing which waitlists they are on.
A lead can be on one or more cohort waitlists. From the lead detail panel you can see which cohorts they’re already on and add them to another cohort’s waitlist using their name, email, and phone.
## Waitlist management in the lead panel
When you open a lead, scroll to **Waitlist Management**. You’ll see:
* **Currently in waitlists** — A list of cohorts this lead is already on, with cohort name, program name, and when they were added.
* **Add to cohort waitlist** — A dropdown to choose another cohort and a button to add them.
## Adding a lead to a waitlist
1. Open the lead from the Leads table.
2. In **Waitlist Management**, open the **Add to Cohort Waitlist** dropdown.
3. Choose the cohort you want. Only cohorts that accept waitlist signups appear (e.g. open, full, or waitlist-open cohorts).
4. Click **Add to Waitlist**.
The lead’s name, email, and phone from the lead record are used for the waitlist entry. If the lead is already on that cohort’s waitlist, you’ll see a message and the system won’t create a duplicate. After adding, the cohort appears under “Currently in waitlists” and the lead will show the waitlist indicator (e.g. star) in the main Leads table.
## Which cohorts appear in the dropdown
Only cohorts that are in a lifecycle state that allows waitlist signups are listed—for example open, full, or waitlist open. If you don’t see a cohort, it may be in planning or closed, or it may not have waitlist enabled. You can manage the cohort’s lifecycle and waitlist settings from the Cohorts area of the program dashboard.
## Seeing waitlist status on the Leads table
In the main Leads table, a star or badge next to a lead’s name means they are on at least one waitlist for your organization. Open the lead to see exactly which cohorts they’re on.
# Where leads come from
Source: https://docs.firstrespondershub.com/leads/where-leads-come-from
The two ways a lead is created: an information request, or an abandoned checkout.
Leads come from two places.
## 1. Someone asks for information
A visitor uses the **Request Program Information** button on your public program or class page.
Here is what happens:
1. They enter their name, email, and phone, and send the form.
2. They get a confirmation email saying the request went through.
3. You get an email with their details and what they asked about.
4. A new lead appears in [Program Dashboard → Leads](https://firstrespondershub.com/program-dashboard/information-requests).
Now you can call or email them, and record what happened in the lead panel.
## 2. Someone starts checkout and stops
A signed-in visitor opens the checkout page for a class or a course, then leaves without paying.
Here is what happens:
1. A lead is created, so you can see who was interested. If they already had a recent lead for the same thing, that one is reused instead of a new one being made.
2. Up to three reminder emails go out automatically. See [Cart abandonment emails](/leads/cart-abandonment-emails).
3. If they come back and finish, the lead is marked **Converted** and the remaining reminders are cancelled.
This is the quiet one. It catches people who were ready to buy and got interrupted, and it often converts them without you lifting a finger.
## See also
* [Cart abandonment emails](/leads/cart-abandonment-emails) — The three reminders.
* [What updates automatically](/leads/automatic-updates) — What the platform handles for you.
* [The contact record](/contacts/contact-record-and-sources) — Every lead is also a contact.
# Your organization
Source: https://docs.firstrespondershub.com/organization-settings/index
Organization profile, staff and instructors, your own login, and integrations.
These are the settings that describe your organization and the people who work in it.
Find them in the dashboard sidebar, under **Organization** and **Account**.
## In this section
| Guide | What it covers |
| ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| [Organization profile](/organization-settings/organization-profile) | Your name, contact details, public web address, locations, FAQs, and how programs are ordered on your page. |
| [Users and roles](/organization-settings/users-and-roles) | Inviting staff, the two roles, instructor profiles, and approving people who ask to join. |
| [Login and security](/organization-settings/login-and-security) | Your own password and account details. |
## The two roles
| Role | What they can do |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Program owner** | Everything: settings, money, students, courses, and plans. |
| **Instructor** | See the classes they are assigned to, take attendance, record results, and post to their classes. They never see money and never see class Settings. |
See [Users and roles](/organization-settings/users-and-roles).
## See also
* [Setup overview](/guides/setup-overview) — The order to set things up in.
* [Plans and billing](/plans-and-billing) — Your subscription.
* [Teaching topics](/teaching-topics-and-instructor-hours/teaching-topics) — Set up what instructors can log hours against.
# Login and security
Source: https://docs.firstrespondershub.com/organization-settings/login-and-security
Change your password, update your own details, and what to do if you are locked out.
These two pages are about **your** account, not your organization. Every user has them, including instructors.
## My profile
[**Program Dashboard → Account → My Profile**](https://www.firstrespondershub.com/program-dashboard/settings/your-information)
Your name and contact details. This is the name students and staff see next to your actions.
## Login and security
[**Program Dashboard → Account → Login & Security**](https://www.firstrespondershub.com/program-dashboard/settings/login-security)
### Change your password
1. Enter your current password.
2. Enter the new one twice.
3. Save.
The page lists the password requirements as you type, so you can see when the new one is strong enough.
### If you are locked out
Use **Forgot password** on the sign-in page. You get an email with a link to set a new one. The link expires, so use it soon after it arrives.
If the email does not show up, check your spam folder, then confirm you are using the address you signed up with.
## Keeping your organization safe
* Give people the smallest role that lets them do their job. Most teachers only need **Instructor**.
* Remove people the day they leave.
* Do not share one login between staff. Activity is recorded per person, and shared logins make that record useless.
See [Users and roles](/organization-settings/users-and-roles).
# Organization profile
Source: https://docs.firstrespondershub.com/organization-settings/organization-profile
Your name, contact details, public web address, locations, FAQs, and how programs appear on your public page.
Your organization profile is what the public sees. It fills your public page, your program listings, and the details students use to reach you.
Go to [**Program Dashboard → Organization → Organization Profile**](https://www.firstrespondershub.com/program-dashboard/settings/organization-information).
The page has a menu down the left with five sections.
## Basic information
| Field | What it's for |
| --------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Organization name** | What students see everywhere. |
| **Organization type** | Community college, fire department, private training company, and so on. |
| **Description** | A short paragraph about who you are. It appears on your public page. |
| **Primary contact email** | Where student questions go. |
| **Primary contact phone** | Shown on your public page. |
| **Website** | Your own site, if you have one. |
| **Public web address** | The last part of your FirstRespondersHub address, like `firstrespondershub.com/organizations/**your-name**`. |
| **Google Business Profile** | Connect it and you get a ready-made review link to send students. |
Set the public web address early and then leave it alone. Changing it breaks any link you already gave out.
## Locations
Add every place you actually teach: a campus, a station, a training center.
Locations matter for more than the address. A class picks a location, and the location's **timezone** decides when sign-ups close and when class times display. See [Enrollment deadlines](/cohort-management/enrollment-deadlines).
Add at least one location before you create program offerings that use one.
## FAQs
Questions and answers that show on your public page. Good ones save your staff a lot of phone calls: what to bring, where to park, what the refund policy is, whether books are included.
## Program display
Controls the order your programs appear in on your public page.
* **Display order mode** — sort them automatically, or drag them into the order you want.
* Put your best sellers first. Most people never scroll.
## Corporate training
A section on your public page for departments and companies that want group training. You control the headline, the description, a trust line, highlights, the services you offer, and where inquiries go.
If you do not sell corporate training, leave this off.
## AI sales advisor
Available on the Scale plan. Avery answers questions from visitors on your public page, qualifies them, and passes real leads to you.
See [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits).
## See also
* [Setup overview](/guides/setup-overview) — Where this fits in getting started.
* [Users and roles](/organization-settings/users-and-roles) — Adding your team.
* [Leads](/leads) — What happens to the inquiries your page collects.
# Users and roles
Source: https://docs.firstrespondershub.com/organization-settings/users-and-roles
Invite staff, understand the two roles, add instructor profiles, and approve people who ask to join.
Go to [**Program Dashboard → Account → Users**](https://www.firstrespondershub.com/program-dashboard/settings/organization-users).
Only program owners can open this page.
## The two roles
| Role | What they can do | What they cannot do |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| **Program owner** | Everything. Settings, money, students, courses, plans, and other users. | — |
| **Instructor** | See their assigned classes, take attendance, record results, post to their classes, and view a student's access codes. | See money, edit class settings, import codes, or change courses. |
Instructors never see revenue, invoices, or tuition. That is by design, and there is no setting to change it.
## Inviting someone
1. Click **Invite user**.
2. Enter their email.
3. Pick the role.
4. Send.
They get an email with a link. Until they accept, they show under **Pending invitations**.
## People who ask to join
Someone can find your organization and ask to join it. Those requests appear under **Pending approvals**.
Approve them and they get the role you choose. Deny them and they move to a denied list, so the same person cannot keep asking.
If someone signs up with an email at your organization's own domain, their request can be approved automatically. That saves you a step for a big department.
## Instructor profiles
An **instructor profile** is a teacher record. It does not need a login.
Use one when you have a guest instructor, an adjunct, or someone whose hours you track but who never signs into FirstRespondersHub.
You can assign an instructor profile to a class and to a teaching segment, and their hours appear in the [instructor hours report](/teaching-topics-and-instructor-hours/instructor-hours-report).
If that person later needs to take attendance themselves, invite them as an instructor user.
## Removing someone
Remove a user and they lose access right away. Their history stays — the classes they taught, the attendance they took, and the hours they logged are all still recorded.
## See also
* [Organization profile](/organization-settings/organization-profile) — Your public details.
* [Instructor hours report](/teaching-topics-and-instructor-hours/instructor-hours-report) — What instructors taught, and for how long.
* [Class settings](/cohort-management/settings-overview) — Assigning instructors to a class.
# Overview
Source: https://docs.firstrespondershub.com/outcomes/index
Record what happened to each student — passed, failed, certified, withdrew — and report on it.
An **outcome** is a result you record for a student: they finished the class, passed the state exam, earned a certification, withdrew, or got hired.
Recording outcomes is how you answer the questions people ask about your program. What is our pass rate? How many students certified last year? Who withdrew, and when?
## The two main pages
| Page | What you do there |
| --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| [**Results & Certifications**](https://www.firstrespondershub.com/program-dashboard/results-and-certifications) | See every outcome you have recorded. Filter, export, edit, and add one at a time. |
| [**Outcome types**](https://www.firstrespondershub.com/program-dashboard/settings/outcome-subtypes) | Set up the results you can record — exam names, Completed, Withdrawn, and so on. Program owners only. |
Both are in the sidebar under **Outcomes**.
## Two other places to record them
* **From a class.** Open the class, stay on the **Students** tab, and click the **Results** chip. This is where you record a whole class at once after an exam. See [Outcomes from a cohort](/cohort-management/outcomes).
* **From a student.** Open a student from the [Students](https://www.firstrespondershub.com/program-dashboard/students) list and use their outcomes section. The student is already picked, so you only choose the class, type, date, and result.
## Where to start
Set up your [outcome types](/outcomes/outcome-types) first. You cannot record a result until there is a result to pick.
## Learn more
* [Results & Certifications](/outcomes/results-and-certifications) — The main page: numbers, filters, exports, and history.
* [Outcome types](/outcomes/outcome-types) — Set up what you can record.
* [Recording in bulk](/outcomes/recording-in-bulk) — A whole class at once.
* [Unenrolling from a cohort](/outcomes/unenrolling-from-cohort) — Withdrawing a student and what it changes.
# Outcome Types
Source: https://docs.firstrespondershub.com/outcomes/outcome-types
Where to set outcome types (subtypes), how to add or edit them, and how built-in options work.
**Outcome types** are the categories and labels you use when recording an outcome—for example “Completed,” “Withdrawn,” “NREMT,” or “Final Exam.” You manage them on the **Outcome Types** page so they appear when you record outcomes.
## Where to set them
In the Program Dashboard sidebar, go to **Outcomes** → **Outcome Types**. Or open [Outcome Types](https://www.firstrespondershub.com/program-dashboard/settings/outcome-subtypes) directly.
Only **program owners** see and can manage this page. Instructors can record outcomes using the types you configure but cannot add or change outcome types.
## What outcome types are
There are four **categories**:
* **Cohort Progression** — Whether a student completed the cohort, withdrew, or is still enrolled (e.g. Completed, Withdrawn).
* **Certification Exam** — External or official exams (e.g. NREMT, state certification).
* **Internal Assessment** — Your own exams or assessments (e.g. Final Exam, Midterm, Skills Check).
* **Placement** — What happened after completion (e.g. Employed, Continuing Education).
Under each category you have **subtypes**—the specific options that appear when you record an outcome. For example: under **Certification exam** you might have "NREMT" and "State EMT." Under **Cohort progression** you have "Completed" and "Withdrawn."
## System defaults
For **Cohort Progression** and **Placement**, some subtypes are built-in and shared by all organizations. They appear as **System Default** and cannot be edited or removed. Examples:
* Cohort Progression: Completed, Withdrawn.
* Placement: Employed, Continuing Education, Unknown (or similar).
You can still add **custom** subtypes for these categories if you need extra options (e.g. another placement label). System defaults always stay available.
## Certification Exam and Internal Assessment
For **Certification Exam** and **Internal Assessment**, there are no system defaults that you must use. You add subtypes in one of two ways:
### Explore Options
**Explore Options** shows a list of built-in options (e.g. common certification exams or assessment names). You can search, preview, and add any of them to your organization with one click. Once added, they appear when you record outcomes and you can edit or delete them like any custom subtype.
### Create Custom Subtype
**Create Custom Subtype** lets you define your own:
* **Name** — What you see when recording (e.g. “NREMT Written”).
* **Code** — A short internal identifier (often auto-filled from the name).
* **Scored** — Whether this subtype uses a numeric score (yes/no).
* **Max score** and **Passing score** — If scored, you can set the maximum and the passing threshold.
* **Repeatable** — Whether a student can have more than one record of this subtype (e.g. multiple exam attempts).
* **Accreditation body** — For certification exams, you can optionally link the subtype to an accreditation body (e.g. NREMT).
Save the subtype and it appears under that category when you record outcomes.
## Editing and deleting
* **Custom subtypes** (yours or ones you added from Explore Options) can be **edited** — change the name, code, scored settings, passing score, repeatable, or accreditation body.
* **Custom subtypes** can be **deleted**. Deleting only deactivates the subtype so it no longer appears for new records. Existing outcome records that used it stay valid and visible; you are not asked to reassign them.
System default subtypes cannot be edited or deleted.
## See also
* [Results & Certifications](/outcomes/results-and-certifications) — Where you record outcomes using these types.
* [Recording outcomes in bulk](/outcomes/recording-in-bulk) — Recording many outcomes at once from a cohort.
# Recording outcomes in bulk
Source: https://docs.firstrespondershub.com/outcomes/recording-in-bulk
When and how to record outcomes for many students at once from a cohort.
**Recording outcomes in bulk** lets you add outcome records for many students in one go—for example after a cohort-wide exam or assessment when the same type, subtype, and date apply to everyone.
## When to use it
Use bulk recording when:
* Many students in one cohort had the same outcome on the same date (e.g. everyone took the NREMT written exam on March 15).
* You want to set one outcome type and subtype, one date, and then enter each student’s result (pass/fail or score) in a single flow instead of opening “Record Outcome” many times.
If you only need to add one outcome, use **Record Outcome** from [Results & Certifications](https://www.firstrespondershub.com/program-dashboard/results-and-certifications) or from the student’s profile instead.
## Where to do it
Bulk recording is **only available from a cohort**. You cannot start it from Results & Certifications or from a student’s profile.
1. Go to [**Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts).
2. Open the cohort you want (e.g. “EMT Basic Fall 2024”).
3. Click the **Outcomes** tab.
4. Click **Record outcomes in bulk**.
The bulk recording panel opens for that cohort.
## Steps
1. **Choose outcome type and subtype**\
Select the category (e.g. Certification Exam) and the specific subtype (e.g. NREMT Written). Only enrolled students in this cohort are included.
2. **Set the date**\
Enter the date the outcome occurred (e.g. the exam date). This date is used for every record you create in this bulk flow.
3. **Set each student’s result**\
You’ll see a list of enrolled students. For each student you can:
* **Include or exclude** — Leave the student in the list to create a record, or remove them if they didn’t take this exam or assessment.
* **Result** — For exams and assessments: choose Pass or Fail and, if the subtype uses scores, enter the numeric score. For cohort progression (e.g. Withdrawn): choose the subtype or withdrawal reason as prompted.
* **Notes** — Optionally add notes for that student.
4. **Submit**\
Click the button to create all the outcome records at once. Each student you included gets one new record with the shared type, subtype, and date, and their individual result and score.
After submitting, the new records appear under the **Results** chip on the cohort's Students tab and on [Results & Certifications](https://www.firstrespondershub.com/program-dashboard/results-and-certifications) (filter by that cohort if needed).
## Difference from recording one at a time
| | Single record | Bulk |
| ------------ | ----------------------------------------------------------------------------- | --------------------------------- |
| **Where** | Results & Certifications, a cohort's **Results** chip, or a student's profile | Only from a cohort's Students tab |
| **Use when** | One student, or a few students with different types/dates | Many students, same type and date |
Single records can be added from anywhere you see **Record Outcome** or **Add Outcome Record**. Bulk is only from the cohort **Outcomes** tab via **Record outcomes in bulk**.
## See also
* [Results & Certifications](/outcomes/results-and-certifications) — View, filter, and export outcome records; record or edit one at a time.
* [Outcome Types](/outcomes/outcome-types) — Add or edit the subtypes (e.g. exam names) you use when recording.
* [Outcomes (from a cohort)](/cohort-management/outcomes) — Recording results from the cohort's Students tab.
# Results & Certifications
Source: https://docs.firstrespondershub.com/outcomes/results-and-certifications
View and manage outcome records, record outcomes one at a time, filter, export, and edit or view history.
The **Results & Certifications** page is where you see all outcome records for your organization and record, edit, or export them.
## Where to find it
In the Program Dashboard sidebar, go to **Outcomes** → **Results & Certifications**. Or open [Results & Certifications](https://www.firstrespondershub.com/program-dashboard/results-and-certifications) directly.
## What you see
When you **select a cohort** in the filter, the top of the page shows summary cards:
* **Graduation rate** — Percentage and count of students who completed the cohort.
* **Attrition rate** — Percentage and count of students who withdrew.
* **Employment rate** — For placement outcomes: percentage and count of graduates who are employed.
* **Still enrolled** — Number of students currently active in the cohort.
Below that is the **Outcome records** table. Each row shows:
* **Student** — Name (click to open the student’s profile).
* **Cohort** — Which cohort the outcome belongs to.
* **Type** — Category: Cohort Progression, Certification Exam, Internal Assessment, or Placement.
* **Subtype** — More specific label (e.g. Completed, Withdrawn, or the name of an exam or assessment).
* **Date** — When the outcome occurred.
* **Result** — Pass/fail for exams and assessments, or the subtype label for progression/placement (e.g. Completed, Withdrawn).
* **Score** — Numeric score if the outcome type uses one.
* **Actions** — Edit, View History, and (for program owners) Delete.
## Filtering
Use the filters above the table to narrow the list:
* **Search** — By student name or email.
* **Cohort** — Show only records for one cohort or all cohorts.
* **Type** — Show only one outcome type (Cohort Progression, Certification Exam, Internal Assessment, or Placement).
Click **Clear filters** to reset.
## Recording one outcome
1. Click **Record Outcome** (top right).
2. Choose **Cohort** and **Student** (only enrolled students in that cohort appear).
3. Choose **Outcome type** and **Subtype** (the list of subtypes depends on the type).
4. Set the **Date** the outcome occurred.
5. Enter the **Result**:
* For **Cohort Progression** or **Placement**: the result is usually the subtype (e.g. Completed, Withdrawn). If the subtype is a withdrawal, you may be asked for a withdrawal reason (e.g. Financial, Personal, Academic).
* For **Certification Exam** or **Internal Assessment**: choose Pass or Fail and, if the subtype uses scores, enter the numeric score.
6. Add **Notes** if you want (optional).
7. Click **Save**.
The new record appears in the table.
## Editing an outcome
1. In the outcome record row, open the **Actions** menu (three dots).
2. Click **Edit**.
3. Change the date, subtype, result, score, or notes as needed.
4. Enter a **Reason for change** (this is stored in the record’s history).
5. Save.
## Viewing history
To see who changed an outcome and when:
1. In the row, open the **Actions** menu.
2. Click **View History**.
You’ll see a list of changes (created, updated, or deleted) with who made the change and when.
## Deleting an outcome
Only **program owners** can delete outcome records.
1. In the row, open the **Actions** menu.
2. Click **Delete**.
3. Optionally enter a **Reason for deletion** (stored in history).
4. Confirm.
The record is removed from the table. Deletion is permanent, but the reason is kept in the audit history.
## Export
To download outcome records for use in a spreadsheet or report:
1. Set any **filters** you want (cohort, type, search).
2. Click **Export CSV** (top right).
A file is downloaded with the records that match your current filters (e.g. all records for the selected cohort and type).
## Opening a student’s profile
Clicking a **student name** in the table opens that student’s profile. From there you can view their full record, including the **Outcomes** tab where you can add or view outcomes for that student.
# Unenrolling a student from a cohort
Source: https://docs.firstrespondershub.com/outcomes/unenrolling-from-cohort
Withdraw a student, and see what changes for them, for your seat count, and for your reports.
**Unenrolling** a student means they are no longer in the class. You give a reason and a date, and the platform records a withdrawal.
Use it when someone leaves before the class ends. It is not the same as marking them **Completed**.
## How to do it
### From a class
1. Open the class from [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts).
2. Find the student on the **Students** tab.
3. Click **Unenroll**.
4. Pick a **reason** and a **withdrawal date**. Both are required.
5. Confirm.
### From a student
1. Open the student from [**Program Dashboard → Students**](https://www.firstrespondershub.com/program-dashboard/students).
2. Find the enrollment you want to end.
3. Click **Unenroll**, and fill in the same two fields.
### The reasons you can pick
Financial, Personal, Academic, Medical, Scheduling, Employment, Relocated, Military, or Other.
**Unenroll** is a shortcut. You can do the same thing with **Record outcome** by choosing Cohort Progression → Withdrawn. The button just fills those in for you.
## What gets recorded
Two things happen.
1. **A withdrawal record is created.** It shows the type, the reason, the date, and who did it. You will see it on [Results & Certifications](/outcomes/results-and-certifications), on the class's **Results** chip, and on the student's record.
2. **The enrollment is marked Withdrawn.** Everything else follows from that status.
## What changes for the student
| Where | What they see |
| ------------ | -------------------------------------------------------- |
| **Home** | The class still shows, labeled **Withdrawn**. |
| **Billing** | They can still see their payment history for that class. |
| **Schedule** | The class disappears. They no longer see its dates. |
| **Courses** | They lose access to that class's course material. |
## What changes for your seat count
Unenrolling **frees a seat**.
Only students who are Enrolled, Completed, or Paid pending application take up a seat. Withdrawn, Failed, and Dropped do not.
So after you unenroll someone, the class has one more open seat. If the class had turned **Full** because of capacity, it can open again.
## What changes in your reports
* Withdrawals show on **Results & Certifications** like any other outcome, and they are included in the CSV export.
* They feed your attrition and graduation numbers, so your pass rate stays honest.
## Undoing it
You can reverse a withdrawal. The enrollment's status comes from the **most recent** progression outcome, so removing or changing the withdrawal changes the status back.
1. Find the withdrawal record on Results & Certifications, or under the class's **Results** chip.
2. **Edit** it to something else, or **Delete** it. Only program owners can delete.
The student returns to Enrolled or Completed, depending on what other records exist.
## Access codes
If the course sends vendor access codes, unenrolling takes them back too, using the same rules as a refund. See [Refunds and unused codes](/student-access/refunds-and-unused-codes).
## See also
* [Results & Certifications](/outcomes/results-and-certifications) — View, edit, or export records.
* [Outcome types](/outcomes/outcome-types) — Where Withdrawn comes from.
* [Recording in bulk](/outcomes/recording-in-bulk) — Withdraw several students at once.
# Coupons (promo codes)
Source: https://docs.firstrespondershub.com/payment-settings/coupons
Create and manage promo codes for program offerings and courses
Promo codes (coupons) let you offer a **fixed discount in dollars** on a program offering or a standalone course. Students enter the code at checkout to reduce the amount they pay.
## Where promo codes live
* **Program offerings:** Promo codes can be attached to a **single program offering**. They apply when a student enrolls in a cohort of that offering (enrollment flow).
* **Courses:** Promo codes can be attached to a **single course**. They apply when a student purchases that course (e.g. standalone course purchase flow).
Each code belongs to **one** offering **or** one course, and to your **organization**. Codes are **unique per organization** (same code string cannot be used twice for different offerings/courses if you enforce uniqueness; the platform typically requires unique code per org).
## Creating a promo code
1. **Offering:** Open the [program offering](https://firstrespondershub.com/program-dashboard/program-offerings) (create or edit) and go to the **Promo codes** (or Coupons) section.\
**Course:** Open the course and its promo/coupon section.
2. Click **Add** (or equivalent).
3. Set:
* **Code:** The text the student will enter (e.g. `EARLYBIRD`, `SAVE50`). The system typically **normalizes** it: trim, uppercase, remove spaces — so `early bird` and `EARLYBIRD` are the same.
* **Discount:** Amount off in **dollars** (e.g. 50 = 50 dollars off). Must be positive and leave at least a small amount (e.g. 1.00 dollars) for payment processing when applied to a paid offering/course.
* **Active:** Toggle on so the code can be used.
4. Save.
**Validation:** The discount cannot exceed the price of the offering/course minus the minimum (e.g. 1 dollar). If the offering is 100 dollars, max discount is 99 dollars. You'll get an error if you enter more.
## Managing promo codes
* **List:** In the offering or course, you see all promo codes for that offering or course: code, discount, active, usage count, created/updated.
* **Edit:** Change discount or active status (and sometimes the code string, if the UI allows). Editing does not affect already-completed enrollments or purchases.
* **Deactivate:** Turn **Active** off so the code can no longer be used. Existing uses are unchanged.
* **Delete:** Remove the code. Usually only when it has never been used (or per your policy). Check the UI for delete vs deactivate.
## How validation works (student side)
When a student enters a promo code at checkout:
1. The platform normalizes the code (trim, uppercase, no spaces) and looks up an **active** promo for that **organization** and that **offering** (or **course**).
2. If found:
* **Enrollment:** The **agreed tuition** becomes `tuition − discount`. The amount due at checkout (full or deposit) is recalculated. If the discount is large enough, the student might pay only the deposit or even zero at enrollment; the rest is balance due.
* **Course purchase:** The price becomes `course price − discount`; the student pays the discounted amount.
3. If not found or inactive: “Invalid or inactive code” (or similar). No discount is applied.
Validation is **stateless** at checkout — no “reservation” of the code. Usage is incremented when an enrollment or purchase is completed.
## Usage count
The platform tracks how many times a promo code has been **used** (completed enrollments or course purchases). Use this to see how often a code was redeemed. There is no usage cap; codes can be used any number of times until you deactivate them.
## Best practices
* **Code format:** Use short, clear strings (e.g. `FALL2025`, `FIRST50`). Avoid spaces; the system will normalize.
* **Discount size:** Ensure the remaining amount after discount is at least the minimum required for payment (e.g. 1 dollar). For large discounts, “enrollment without payment” or a zero deposit may be more appropriate.
* **Scope:** One code per offering or per course. For different discounts per cohort, create multiple codes (e.g. `COHORT-A-50`, `COHORT-B-30`) or one code per offering and change the offering price.
* **Deactivate instead of delete:** To stop use without losing history, deactivate the code rather than deleting it.
## Summary
| Item | Description |
| ------------ | -------------------------------------------------------------------------------- |
| **Scope** | One promo code per program offering or per course; belongs to your organization. |
| **Discount** | Fixed amount off in dollars; must leave at least 1 dollar for payment. |
| **Code** | Normalized (trim, uppercase, no spaces); unique per org in practice. |
| **Active** | Only active codes can be applied at checkout. |
| **Usage** | Count of completed enrollments/purchases using the code. |
# Overview
Source: https://docs.firstrespondershub.com/payment-settings/index
Take payments from students: Stripe, payment options, invoices, coupons, and refunds.
This section is about collecting money from students.
You connect Stripe once. After that you decide how students pay for each program, send invoices, hand out promo codes, and issue refunds.
This is different from [Plans and billing](/plans-and-billing), which is what **you** pay FirstRespondersHub.
## What's in this section
| Guide | What it covers |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| [Stripe Connect](/payment-settings/stripe-connect) | Set up the account your money lands in, and finish Stripe's checks. |
| [Payment configurations](/payment-settings/payment-configurations) | How students pay for a program: in full, a deposit, a payment plan, or free. |
| [Payment plans](/payment-settings/payment-plans) | A down payment plus automatic monthly charges. |
| [Sponsored payments](/payment-settings/sponsored-payments) | Let a department or employer pay for one student or a whole group. |
| [Invoices and balances](/payment-settings/invoices-and-balances) | Send an invoice, take a payment, adjust a balance, and chase what is owed. |
| [Coupons](/payment-settings/coupons) | Promo codes for programs and courses. |
| [Refunds](/payment-settings/refunds) | Full and partial refunds, and what they do to a balance. |
## Before you can take payments
You need three things:
1. **A plan that allows it.** Growth and Scale can take payments online. Starter cannot. See [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits).
2. **A finished Stripe Connect account.** Stripe asks for your identity, your business, your bank details, and tax information.
3. **Accept online payments turned on.** The switch stays off until Stripe says you are ready.
## What it costs
FirstRespondersHub takes a fee on each student payment. The rest goes straight to your Stripe account.
| Plan | Fee per transaction |
| ------ | ------------------- |
| Growth | 4% + 30¢ |
| Scale | 3.25% + 30¢ |
## Who can do what
* **Program owners** set up Stripe, turn payments on, and manage everything on this page.
* **Instructors** cannot see money at all.
## Where to find it
Go to [**Program Dashboard → Billing → Payment Settings**](https://firstrespondershub.com/program-dashboard/settings/payments). From there you can:
* Turn **Accept online payments** on or off
* Set up or finish **Stripe Connect**
* Choose when **invoice reminder** emails go out
Two things live elsewhere:
* **How students pay for a program** is set on the [program offering](https://firstrespondershub.com/program-dashboard/program-offerings).
* **Someone else paying** is set up under [Sponsorships](https://firstrespondershub.com/program-dashboard/sponsorships).
## Related
If a student already received vendor access codes and you are about to refund them, read [Refunds and unused codes](/student-access/refunds-and-unused-codes) first.
# Invoices and balances
Source: https://docs.firstrespondershub.com/payment-settings/invoices-and-balances
Creating invoices, payment links, balance due, reminder emails, and manual balance adjustments
This guide covers how invoices and balances work for enrollments: creating invoices, sending payment links, configuring reminder emails, and adjusting balances manually.
## Concepts
* **Balance due:** For an enrollment, the amount still owed = agreed tuition (or offering tuition) minus payments already made (including refunds). It is shown on the student’s enrollment and in the [program dashboard](https://firstrespondershub.com/program-dashboard).
* **Invoice:** A bill for a specific amount (e.g. the remaining balance or a portion of it) with a due date. Invoices can be **open**, **partially\_paid**, **paid**, **overdue**, or **canceled**.
* **Payment link:** A unique, time-limited URL the student (or sponsor) uses to pay an invoice. You can send the link by email or copy it.
## Creating invoices
### When invoices are created
* **Balance invoices:** When a student enrolls with a **deposit** or **no payment**, the remaining balance is due later. The platform can create a **balance** invoice for that amount (or you create one manually). Due date comes from the offering’s payment configuration (e.g. X days before cohort start or end).
* **From a cohort invite:** Depends on the tuition choice made when the invite was sent. **Enroll now, invoice after** creates an open invoice the moment the student accepts. **Must pay before enrolling** collects money first — an invoice is created afterwards only for what is left over (the balance after a deposit). A payment plan gets installment invoices instead of one balance invoice. **No tuition owed** creates nothing. See [Students and invites](/cohort-management/students-and-invites#the-three-tuition-choices).
* **Manual creation:** From the [program dashboard](https://firstrespondershub.com/program-dashboard), open a student’s enrollment and use **Create invoice** (or equivalent) to create an invoice for a chosen amount and due date. You can create multiple invoices per enrollment as long as the total does not exceed the enrollment’s balance due.
### Create invoice dialog (manual)
When you create an invoice manually you typically set:
* **Amount:** Dollar amount to bill. It cannot exceed the **remaining balance** for that enrollment (total balance due minus any open/partially paid invoice amounts).
* **Due date:** When the invoice is due.
* **Payer type:** Student or sponsor (affects who can pay and who gets reminders).
* **Sponsor (if sponsor-paid):** Select the sponsor if the invoice is for a sponsor to pay.
After creation, you can generate a **payment link** and send it to the student or sponsor.
**Invoices from an invite are never born past due.** If the normal due date would already be in the past — for example a class that has already started — the due date is pushed out to **at least 7 days from today**, so the student still receives the "due soon" and "due today" reminders before it goes overdue. The student is also emailed as soon as the invoice is created, with a working pay link.
## Payment links
* **Generation:** When an invoice is created (or from the invoice actions menu), the system can create a **payment link** — a URL that includes a secure token.
* **Expiration:** Links are valid for a limited time (e.g. 90 days) and may have a max number of uses. You can create a new link if one expires.
* **Usage:** The payer opens the link, enters payment details, and completes payment. Success is recorded and the invoice and enrollment balance are updated.
Share the link by email or copy-paste. The invoice payment page is hosted by the platform and uses your organization’s connected Stripe account to charge the payer.
## Invoice statuses and balance
* **Open / Partially paid / Overdue:** Invoice still has an amount due. Balance due on the enrollment includes these amounts.
* **Paid:** Invoice is fully paid; it no longer counts as balance due.
* **Canceled:** Invoice is void and does not count toward balance.
Balance due is computed as: **agreed tuition − (payments − refunds)**. Outstanding invoices are a *breakdown* of that balance, not an extra amount.
## Invoice reminder settings
In [**Settings → Payments**](https://firstrespondershub.com/program-dashboard/settings/payments), you can configure **Invoice reminder** emails so payers get reminded relative to the invoice due date.
### Reminder types
* **Upcoming:** Sent X **days before** the due date (e.g. 7 days before, 14 days before). You can add multiple (e.g. 14, 7, 3 days before).
* **On due date:** Sent the **day the invoice is due** (one reminder per invoice).
* **Past due:** Sent X **days after** the due date (e.g. 3 days after, 7 days after).
You can enable up to **7 reminders** in total (e.g. 3 upcoming + 1 on due date + 3 past due). For each reminder you set the **days** (for upcoming: days before; for past due: days after) and a toggle to enable/disable it.
### Invoices that start out late
An invoice created after its own due date does not replay the reminders it missed, and it does not go silent either. Two rules apply:
* It **joins the ladder at the right rung**. An invoice that is already 8 days past due sends the "7 days past due" notice next, and every earlier stage is skipped for good.
* It sends **at most one reminder every 3 days**, so a very late invoice moves forward one notice at a time instead of firing a burst.
Reminders only ever move forward. Once a stage sends, that stage and every earlier one are done.
### Who receives reminders
Reminders are sent to the **billing contact** (if set on the invoice), otherwise to the **sponsor** (for sponsor invoices) or the **student**. The platform resolves the recipient from the invoice and enrollment data.
### Saving reminder settings
After adding or editing reminders, click **Save**. Settings apply to all future reminder runs (e.g. a nightly or scheduled job that evaluates due dates and sends emails per your rules).
## Manual payments and balance adjustments
### Recording a manual payment
If a student or sponsor pays outside the platform (check, wire, etc.), you can record a **manual payment** against the enrollment. This creates a transaction that **decreases** the balance due and can be attached to an invoice so the invoice status updates (e.g. to paid or partially paid). Manual payments do not go through Stripe; they are for record-keeping only.
### Balance adjustment
When you need to change the **total amount owed** (e.g. discount, fee change, or correction):
1. Open the enrollment in the [program dashboard](https://firstrespondershub.com/program-dashboard) and use **Adjust balance** (or the balance adjustment dialog).
2. Enter the **new balance** (in dollars). The system computes the difference from the current balance and applies it as an adjustment.
3. Optionally add a **reason** (e.g. “Discount approved” or “Tuition correction”).
**Effect:** The enrollment’s **agreed tuition** (or equivalent) is updated so that the new balance due equals the value you entered. Outstanding invoices may be updated or canceled so they do not exceed the new balance. Existing payment transactions are not changed; only the “amount owed” is corrected.
* **Decreasing balance:** Use when giving a discount or reducing what the student owes.
* **Increasing balance:** Use when adding a fee or correcting an undercharge (use sparingly and with a clear reason).
Balance adjustments are logged for audit. Only program owners or instructors should perform them.
## Super bills (sponsor billing)
Some workflows support **super bills** — bills sent to sponsors (e.g. employers) for one or more enrollments. Super bills have their own payment links and statuses. Creating and sending super bills is done from the [program dashboard](https://firstrespondershub.com/program-dashboard) (e.g. from a student’s enrollment or a sponsor view). Paying a super bill updates the related enrollment(s) and invoices according to how the super bill is configured.
## Summary
| Topic | Summary |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Creating invoices** | Automatically for balance due after deposit/no-payment enrollment, or manually from the enrollment with amount and due date. |
| **Payment links** | Generated per invoice; time-limited; share by email or copy. |
| **Reminders** | Configure in [Settings → Payments](https://firstrespondershub.com/program-dashboard/settings/payments): upcoming, on due date, past due (up to 7 total). |
| **Manual payment** | Record off-line payments to update balance and invoice status. |
| **Balance adjustment** | Set a new balance to correct tuition (discount/fee); invoices are updated accordingly. |
# Payment configurations
Source: https://docs.firstrespondershub.com/payment-settings/payment-configurations
Configure how students pay for a program offering: full payment, deposits, monthly payment plans, balance due dates, and free/no-payment enrollment
Payment configuration is set **per program offering**. It defines how students can pay for a cohort: full payment upfront, a deposit with the balance later, a **monthly payment plan**, or enrollment without payment. You also control when any remaining balance is due (relative to the cohort start or end date).
You can enable **any combination** of these options. Whatever you turn on becomes a choice the student sees at checkout.
## Where to configure
When you [**create** or **edit** a program offering](https://firstrespondershub.com/program-dashboard/program-offerings), open the **Payment Configuration** section.
* Payment options appear only when the offering uses **platform (hosted) enrollment**. If the offering sends students to an external link or is inquiry-only, no payment configuration is needed and the section is replaced with a short notice.
* The full payment options only appear when the offering has a **tuition amount greater than zero**. A \$0 offering is treated as free (see [Free offerings](#free-offerings-0-tuition)).
## Tuition amount
* **Tuition Amount (\$):** The total price for the offering in dollars (e.g. `1200.00`). This is the full amount a student owes before any promo code discount. It drives every downstream calculation (deposit balance, payment-plan totals).
* Setting tuition to **0** makes the offering **free** — see below.
Amounts are entered in **US dollars**. All offerings currently bill in **USD**.
## Payment options (paid offerings)
Enable one or more of the following. Each enabled option becomes a payment method the student can pick at enrollment.
### Allow full payment upfront
* **Label at checkout:** "Pay in Full"
* **Checked (default):** Students can pay the full tuition (or the discounted amount after a promo code) in one payment at enrollment.
* **Unchecked:** Students cannot pay in full at enrollment; they must use a deposit, payment plan, or "enroll without payment" if you allow those.
### Allow deposit payment
* **Label at checkout:** "Pay Deposit Now"
* **Checked:** Students pay a set **deposit** at enrollment. The rest becomes a **balance due** later, billed by invoice (with a payment link).
* **Deposit Amount (\$):** The dollar amount paid at enrollment (e.g. `300.00`). Required when deposit is enabled, and must be greater than zero and less than the full tuition. The balance-due schedule (below) controls when the remainder is invoiced.
### Allow payment plan (monthly installments)
**Payment plans are a newer feature.** They require a **Growth** or **Scale** subscription. On the Starter plan the option is disabled with an "Upgrade to Growth or Scale" prompt.
* **Label at checkout:** "Payment Plan"
* **Checked:** Students pay a **down payment** at enrollment, then a fixed number of **equal monthly installments** that are **automatically charged** to the card they enroll with.
* Configure three fields:
* **Payment Plan Total (\$):** The total the student pays across the whole plan. **Leave blank to match the tuition amount.** Set it **higher than tuition** to add a **financing fee** — the difference is shown to the student as an "includes financing fee" note. It cannot be lower than tuition.
* **Down Payment (\$):** The amount paid upfront at enrollment. Must be less than the plan total.
* **Number of Monthly Installments:** How many monthly payments follow the down payment. Allowed range is **1–24**.
* As you fill these in, a live **preview** shows the resulting schedule, e.g. *"$300 down + 6 payments of $150/mo = \$1,200 total."*
After enrollment, the platform auto-charges each installment on a monthly schedule, retries failed charges, emails the student on each attempt, and lets you pause, resume, or cancel the plan. See [**Payment plans**](/payment-settings/payment-plans) for the full lifecycle.
### Allow enrollment without payment
Enrolling without payment requires a **Growth** or **Scale** subscription. On Starter the option is disabled with an upgrade prompt.
* **Label at checkout:** "Enroll Without Payment"
* **Checked:** Students can complete enrollment without paying anything at enrollment. The full balance is billed by invoice, due according to the **balance due** rules below.
* **Unchecked:** Every student must pay something at enrollment (full, deposit, or a payment plan's down payment).
Use this for internal billing, sponsor-paid enrollments, scholarships, or when you collect payment outside the platform and record it manually.
## Balance due (invoice due dates)
When a student has a **balance due** — from a deposit or a "no payment" enrollment — the platform creates an **invoice** for the remaining amount. This section controls that invoice's **due date**. (Payment-plan installments have their own monthly due dates and are not governed by this setting.)
The balance-due settings appear when **deposit** is enabled, or when **enrollment without payment** is enabled.
### Invoice Due Date Reference
* **Days before cohort start date** — Due date = cohort **start date** − X days.
* **Days before cohort end date** — Due date = cohort **end date** − X days.
### Balance Due Days Before Start / End
* **Balance Due Days Before Start:** Used when the reference is "start." Example: `7` → the balance is due 7 days before the cohort starts. Default is **7**.
* **Balance Due Days Before End:** Used when the reference is "end." Example: `7` → the balance is due 7 days before the cohort ends. Default is **7**.
If a cohort has no end date, the platform falls back to the **start** date so the due date is still valid.
## Free offerings (\$0 tuition)
Set **Tuition Amount** to `0` to make an offering free. Payment options are hidden and students complete enrollment without payment.
Free ($0) offerings require a **Growth** or **Scale** subscription. On Starter, setting tuition to $0 shows an "Upgrade Required" prompt and the offering can't be saved as free.
## Invited students
The options above cover students who sign up on your public page. **Invited students** is a separate block that covers people your staff invite to a class by email. It sets what the invite form opens with, and it decides which options an invite may offer at all.
It appears under **Payment Configuration** on a paid offering, below the other options.
### How invited students are billed
Pick one. Staff can change it on any single invite.
| Choice | What happens |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **No tuition owed** | The student joins with a \$0 balance. Use this when tuition is handled outside the platform. |
| **Enroll now, invoice after** | The student joins as soon as they accept. An invoice waits in their dashboard, due on the balance-due schedule above. |
| **Must pay before enrolling** | The seat is held for them. No enrollment exists until their payment lands. |
**Must pay before enrolling** is the safe choice when a class hands out vendor access codes. Nothing is reserved or sent for a student who has not paid, because there is no enrollment yet.
### What they can choose to pay
Shown only for **Must pay before enrolling**. Check the ways an invited student may pay:
* **Pay in full** — needs *Allow full payment upfront* turned on above.
* **Pay a deposit** — needs *Allow deposit* turned on above. You can set a separate **Deposit for invited students**; leave it blank to use the program deposit. The rest is invoiced after they join.
* **Payment plan** — needs *Allow payment plan*, a **down payment above \$0**, a number of installments, and a **Growth** or **Scale** subscription.
An option you have not turned on above is greyed out, with a line telling you what to switch on. This is enforced on the server too, so an invite can never offer something the program has switched off.
A payment plan with **no down payment** cannot be used on a pay-first invite. Nothing would be collected before the student enrolls, which defeats the point. Use a deposit if you want "pay a little now."
### Hold the seat for (days)
How long a pay-first seat stays reserved while you wait for payment.
* Range: **1 to 90 days**. Default: **14**.
* A hold never outlives the cohort start date. If the number would run past it, the hold ends at the start date instead.
* If payment does not arrive, the invite is cancelled and the seat is released automatically, once a day.
### Terms are locked in when the invite is sent
Every invite copies these settings onto itself at the moment it goes out. If you edit the program later, invites already sent keep the terms the student was shown.
Full walkthrough of the invite form: [Students and invites](/cohort-management/students-and-invites).
## Plan requirements at a glance
| Capability | Starter | Growth / Scale |
| ------------------------------------------------------------- | :-----: | :------------: |
| Full payment upfront | ✅ | ✅ |
| Deposit + balance due | ✅ | ✅ |
| Monthly payment plans | — | ✅ |
| Enroll without payment | — | ✅ |
| Free (\$0) offerings | — | ✅ |
| Invited students: no tuition owed | ✅ | ✅ |
| Invited students: enroll now, invoice after | ✅ | ✅ |
| Invited students: must pay before enrolling (full or deposit) | ✅ | ✅ |
| Invited students: must pay before enrolling (payment plan) | — | ✅ |
## Summary table
| Option | Checkout label | Effect |
| ------------------------ | ---------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Allow full payment** | Pay in Full | Student pays the full (or discounted) amount at enrollment. |
| **Allow deposit** | Pay Deposit Now | Student pays a set deposit; the rest becomes a balance due, invoiced later. |
| **Allow payment plan** | Payment Plan | Student pays a down payment, then equal monthly installments auto-charged to their card. |
| **Allow no payment** | Enroll Without Payment | Student enrolls with \$0 at enrollment; full amount is invoiced as balance due. |
| **Tuition = 0** | — | Free offering; no payment options; students enroll without payment. |
| **Due reference: start** | — | Invoice due date = cohort start date − X days. |
| **Due reference: end** | — | Invoice due date = cohort end date − X days. |
| **Invited students** | — | The default billing choice, allowed payment options, and seat hold used when staff invite someone by email. |
## Examples
* **Full payment only:** Enable full payment; leave the others off. Everyone pays in full at enrollment.
* **Deposit + balance:** Enable full payment and deposit; set the deposit (e.g. \$300). The student chooses "Pay Deposit Now" or "Pay in Full." The balance is invoiced with a due date, e.g. 7 days before start.
* **Payment plan:** Enable the payment plan; set a $300 down payment and 6 monthly installments, leaving the plan total blank to match tuition. The student pays $300 to enroll, then \$150/mo for 6 months, auto-charged.
* **Payment plan with financing fee:** Same as above, but set the plan total above tuition (e.g. tuition $1,200, plan total $1,320). The student sees the \$120 financing fee and the installments are sized against the higher total.
* **Invoice-only (no payment at enrollment):** Enable "enroll without payment." Students enroll and receive an invoice for the full amount, paid by link or recorded manually.
* **Free cohort:** Set tuition to \$0. Payment options are hidden and enrollment is free.
## Related
* [**Payment plans**](/payment-settings/payment-plans) — how installment plans are charged, retried, paused, resumed, cancelled, and defaulted.
* [**Sponsored payments**](/payment-settings/sponsored-payments) — let an employer, department, or agency pay on a student's behalf.
* [**Invoices and balances**](/payment-settings/invoices-and-balances) — managing balances, payment links, reminders, and manual payments.
* [**Coupons (promo codes)**](/payment-settings/coupons) — discounts applied at checkout.
* [**Students and invites**](/cohort-management/students-and-invites) — sending invites and what the student sees.
Configurations are saved with the offering and apply to cohorts created from that offering until you edit the offering again.
# Payment plans
Source: https://docs.firstrespondershub.com/payment-settings/payment-plans
Let students pay tuition over time with a down payment and automatic monthly installments — including auto-charge, retries, pausing, cancelling, and defaults
A **payment plan** lets a student pay tuition over time: a **down payment** at enrollment, then a fixed number of **equal monthly installments** that are **automatically charged** to the card they enrolled with. You can optionally add a **financing fee** so the plan total is higher than base tuition.
Payment plans require a **Growth** or **Scale** subscription. On the Starter plan the option is disabled with an upgrade prompt.
## Enabling payment plans
Payment plans are turned on **per program offering**, in the [**Payment Configuration**](/payment-settings/payment-configurations#allow-payment-plan-monthly-installments) section. Check **Allow payment plan (monthly installments)** and set:
* **Payment Plan Total (\$)** — total the student pays across the plan. Leave blank to match tuition; set higher to add a financing fee.
* **Down Payment (\$)** — paid upfront at enrollment (must be less than the plan total).
* **Number of Monthly Installments** — how many monthly payments follow the down payment (**1–24**).
The offering form shows a live preview, e.g. *"$300 down + 6 payments of $150/mo = \$1,200 total."*
## What the student experiences
1. At checkout the student picks **"Payment Plan"** and sees the schedule (down payment, number of payments, monthly amount, and any financing fee).
2. They pay **only the down payment** to enroll. The card they use is saved on file.
3. Each month, the platform automatically charges the next installment to that card.
4. The student is emailed when a charge succeeds and when one fails, and can **update the card** on file from their student dashboard.
The final installment absorbs any rounding, so the sum of all charges exactly equals the plan total.
### Updating the card on file
The student opens their **student dashboard**, finds the payment plan card on the enrollment, and clicks **Update card**. Future installments are charged to the new card.
### Invited students can use a plan too
If a class invite was sent as **Must pay before enrolling** and you allowed the payment plan, the student picks it right on the invite page. Their **down payment claims the seat**, the card they pay with is saved, and the monthly installments are set up as soon as they finish joining. A plan with a **\$0 down payment cannot be offered on an invite** — nothing would be collected before they enroll. See [Students and invites](/cohort-management/students-and-invites).
On a payment plan there is no single balance invoice. The installments **are** the invoices, so the student's billing page lists several with their own due dates, and the **Pay** button on the top card pays the soonest one.
## How installments are charged
* Charges run on a **daily** schedule and collect any installment that is due.
* Each installment is charged **off-session** to the saved card and routed to your connected Stripe account (a destination charge), with the platform application fee applied — the same way other online payments work.
* **Retries:** A failed charge is retried automatically (by default up to **3 attempts**, spaced a few days apart). The student receives a payment-failed email on each failure.
* **Grace period & default:** If an installment is still unpaid after the retry attempts and a grace period, the plan is marked **defaulted** and the student is notified. Reach out to the student to update their card or arrange payment.
## Managing a plan
Open the enrollment in the **Program Dashboard** to see the payment plan card: current status, an "X of Y installments paid" progress bar, and the list of installments with due dates.
You can take these actions (available to team members who can record payments):
| Action | What it does |
| --------------- | -------------------------------------------------------------------------------------- |
| **Pause plan** | Stops automatic charges while keeping the plan intact. Only available on active plans. |
| **Resume plan** | Restarts automatic charges on a paused plan. |
| **Cancel plan** | Ends the plan and **voids all remaining open invoices**. Automatic charges stop. |
Cancelling a plan voids all remaining open invoices and cannot be undone. If a student still owes a balance after cancellation, invoice them separately.
Students see a read-only version of the plan (status and progress) on their dashboard and can update the payment method on file at any time.
## Plan status reference
| Status | Meaning |
| ------------- | -------------------------------------------------------------------- |
| **Active** | Installments are being charged on schedule. |
| **Paused** | Automatic charges are temporarily stopped. |
| **Completed** | All installments have been paid. |
| **Cancelled** | The plan was cancelled by an admin; remaining invoices were voided. |
| **Defaulted** | An installment went unpaid past the retry attempts and grace period. |
## Related
* [**Payment configurations**](/payment-settings/payment-configurations) — enable and size payment plans per offering.
* [**Invoices and balances**](/payment-settings/invoices-and-balances) — installment invoices, payment links, and manual payments.
* [**Refunds**](/payment-settings/refunds) — refunding payments a student has already made.
* [**Students and invites**](/cohort-management/students-and-invites) — offering a plan on a class invite.
# Refunds
Source: https://docs.firstrespondershub.com/payment-settings/refunds
When and how to issue refunds; partial vs full; how they affect balances
This guide explains how refunds work for enrollment payments: when you can refund, full vs partial, how they’re processed through Stripe, and how they affect student balances and invoices.
## When refunds apply
Refunds in the platform apply to **payments that went through Stripe** (card or other Stripe payment methods). For each such payment we store a **Stripe charge ID** (or payment intent). You can issue a refund for:
* A **single transaction** (one enrollment payment), or
* The underlying **Stripe charge** (which may be split across multiple transactions in edge cases, e.g. super bills).
**Manual payments** (recorded as “paid outside the platform”) do **not** have a Stripe charge, so they **cannot** be refunded through the platform. To reverse a manual payment you would use a **balance adjustment** (e.g. increase the balance by the same amount) and optionally add a note.
## Who can issue refunds
Only **program owners** and **instructors** can create refunds for enrollments in their organization. Refunds are created from the [program dashboard](https://firstrespondershub.com/program-dashboard) (e.g. from a student’s enrollment or the transactions list) via the **Refund** action.
## Refund flow (overview)
1. You choose a **succeeded** payment transaction that has a Stripe charge (or payment intent we can resolve to a charge).
2. The system computes the **refundable amount**: original charge amount minus any refunds already made against that charge.
3. You choose **full** or **partial** refund and, optionally, a **reason**.
4. The platform creates a **refund in Stripe** (on the platform/connected account that holds the charge). Stripe returns the refund (e.g. `succeeded` or `pending`).
5. The student's **balance due** goes back up by the refunded amount.
6. If the payment was applied to an invoice, the refund is tied to that invoice so invoice status and balance due stay consistent.
Refunds are **irreversible** in Stripe. Only issue them when you intend to return money to the payer.
## Full vs partial refund
* **Full refund:** Leave amount blank (or select “Full refund”). The refund amount = refundable amount (entire remaining charge amount). The student’s balance increases by that full amount.
* **Partial refund:** Enter an amount (in dollars). It must be ≤ refundable amount. The student’s balance increases by that partial amount. You can issue multiple partial refunds until the refundable amount is exhausted.
## Refund reasons
When creating a refund you can optionally set a **reason** (for your records and sometimes for Stripe):
* **Requested by customer**
* **Duplicate**
* **Fraudulent**
* **Other**
This does not change the refundable amount; it’s for reporting and dispute handling.
## Effect on balance and invoices
* **Balance due:** A refund **increases** the student’s balance due by the refunded amount. So if they had paid 500 dollars and you refund 200 dollars, their balance goes from zero back to 200 dollars (assuming no other changes).
* **Invoices:** If the original payment was against an invoice, the refund is associated with that invoice. Outstanding or future invoices for that enrollment will reflect the higher balance so the student can be billed again if needed.
## Refundable amount rules
* **Refundable amount** = amount originally charged (for that charge) minus any refunds already created for that charge.
* We do not allow refunding more than the refundable amount. If you need to “refund” more than was paid (e.g. goodwill), that’s a **balance adjustment** (reduce balance) plus possibly sending money outside the platform; the platform does not create a Stripe refund greater than the charge.
## Timing and Stripe status
* **Succeeded:** Stripe has processed the refund; money is returned to the payer. Refunds typically take 5–10 business days to appear (timing depends on their bank or card).
* **Pending / Failed:** Rare; the UI or webhook will show status. If a refund fails, the student’s balance is not increased; you can retry or contact support.
Webhooks from Stripe keep our transaction status in sync (e.g. when a pending refund succeeds).
## Where to issue a refund
1. Open the **student’s enrollment** in the [program dashboard](https://firstrespondershub.com/program-dashboard) (or go to **Transactions** and find the payment).
2. Find the **payment transaction** (the one that decreased balance).
3. Use **Refund** (or “Issue refund”). The refund dialog may fetch the **refundable amount** and show:
* Original amount
* Already refunded
* Refundable amount
4. Enter amount (or leave blank for full) and optional reason, then confirm. After the refund is created, the list refreshes and the student’s balance reflects the refund.
## Access codes and refunds
If the student already received vendor access codes (Jones & Bartlett, AHA, or custom), the refund dialog may **warn** you or **block** the refund until you check **Override and refund anyway**. That depends on the course's Student access settings.
* Codes that were not sent yet go back to unused stock automatically.
* Codes that were already sent wait in a review list until someone confirms they were never used.
See [Refunds and unused codes](/student-access/refunds-and-unused-codes). For standalone course purchases you can refund specific seats.
## Summary
| Topic | Summary |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Eligible payments** | Only Stripe payments (we have a charge ID). Manual payments cannot be refunded via Stripe. |
| **Full refund** | Refund entire refundable amount; balance increases by that amount. |
| **Partial refund** | Refund part of the charge; balance increases by that part. Multiple partial refunds allowed up to refundable amount. |
| **Balance** | Refunds **increase** the student’s balance due. |
| **Reasons** | Optional: requested\_by\_customer, duplicate, fraudulent, other. |
| **Who** | Program owners and instructors for their organization’s enrollments. |
| **Access codes** | If the student already received vendor codes, the refund may warn or block. See [Refunds and unused codes](/student-access/refunds-and-unused-codes). |
# Sponsored payments
Source: https://docs.firstrespondershub.com/payment-settings/sponsored-payments
Let an employer, fire department, or agency pay for one or more students — a single payment link, seat holds, reminders, and refunds
**Sponsored payments** let a third party — an employer, fire department, government agency, or family member — pay for someone else's training. The **sponsor** (who pays) is kept separate from the **student** (who trains). A single sponsor can cover **multiple people** with **one payment link and one charge**.
Use this when a department enrolls a group of employees, when an employer covers tuition, or when you want to bill an outside payer instead of the student.
## What a sponsor can pay for
A sponsorship can cover any mix of the following:
* **A cohort seat** — reserves a seat in a cohort for a new student. The seat is **held** (counts toward capacity) until the invited student claims it.
* **A standalone course** — covers a self-paced/standalone course for someone, who then claims access.
* **An existing student's balance** — covers what an **already-enrolled** student still owes (their full remaining balance or a specific invoice).
## Setting up a sponsorship
Go to [**Program Dashboard → Sponsorships**](https://firstrespondershub.com/program-dashboard/sponsorships) and start a new sponsorship. A three-step wizard walks you through it:
Pick an existing sponsor or add a new one. For a new sponsor you provide their **email**, **first name**, **last name**, and optionally an **organization name** (the employer, department, or agency). The sponsor gets **one payment link** covering everyone they pay for.
Add the people the sponsor is covering. You can mix **already-enrolled students** (the sponsor covers what they still owe) with **brand-new people** who get a cohort seat or course invite to claim.
Review the people covered and the total, then **send** the sponsor a payment link by email — or **save as a draft** to send later. You can also generate a link without sending the email.
When a program owner builds the sponsorship, you can choose to cover a **partial** amount (for example, a partial scholarship where the sponsor pays part and the student pays the rest).
## Sponsor self-serve
Sponsors who have an account can also start a purchase themselves from the **Sponsor Dashboard** — they choose your organization, the course or cohort, and the members to cover. In self-serve mode the price is **fixed** by the selected course or cohort; the sponsor pays the set amount.
## How payment and enrollment flow
1. The sponsor receives an **invoice email with a payment link** covering everyone in the group.
2. New students are held as **pending invites** (cohort seats are reserved and count toward capacity) until payment clears.
3. When the sponsor pays, the payment is routed to your connected Stripe account. Invited students can then **claim** their seat or course; balance sponsorships settle straight into the existing enrollment's ledger.
4. Both the sponsor and the students are notified throughout.
## Managing sponsorships
The **Sponsorships** page lists every sponsorship with its status. Filter by **All**, **Waiting to be paid**, **Paid**, or **Drafts**, and switch between the **Sponsorships** and **Sponsors** tabs.
| Action | What it does |
| ------------------- | --------------------------------------------------------------------------------------------------- |
| **Send / Reminder** | Send a draft's payment link, or nudge a sponsor who hasn't paid. |
| **Edit draft** | Adjust a sponsorship before it's sent. |
| **Resend invite** | Re-send a claim invite to an individual student. |
| **Cancel** | Cancel an **unpaid** sponsorship; any held cohort seat is released and the payment link is revoked. |
| **Refund** | Refund a paid sponsorship — per person or the whole group. |
### Payment reminders
Sponsors who haven't paid are automatically reminded by email as the payment link nears expiry (around **7, 3, and 1 days** before it expires). Students whose enrollment is covered by a sponsor are excluded from the normal student invoice reminders, so they aren't billed twice.
A student paying **their own** tuition on a class invite is not a sponsor and is left out of these reminders. They get the invite reminders instead. See [Students and invites](/cohort-management/students-and-invites#automatic-reminders).
### Refunds
You can refund a paid sponsorship for a **single person** or the **entire sponsorship**, including **partial** amounts (up to the amount paid). Refunds go back to the sponsor's original payment method, with reasons such as *Requested by sponsor*, *Duplicate*, or *Fraudulent*, and an option to revoke the student's access.
## Related
* [**Payment configurations**](/payment-settings/payment-configurations) — the per-offering payment options students see when they pay for themselves.
* [**Invoices and balances**](/payment-settings/invoices-and-balances) — invoices, balances, and manual payments.
* [**Refunds**](/payment-settings/refunds) — how refunds work across payment types.
# Stripe Connect
Source: https://docs.firstrespondershub.com/payment-settings/stripe-connect
Set up, verify, and manage your Stripe Connect account for payment collection
First Responders Hub uses **Stripe Connect** so your organization gets its own connected Stripe account. You receive payouts to your bank account, and you manage disputes and tax reporting in your own Stripe Dashboard. This guide covers setup, verification, and what to expect.
## Overview
* **Standard connected accounts:** Your organization’s account is a full Stripe account. You handle chargebacks and negative balances; the platform does not hold or move your funds beyond routing payments.
* **Stripe-hosted onboarding:** You complete signup and verification in Stripe’s secure flow. We generate a link from [**Settings → Payments**](https://firstrespondershub.com/program-dashboard/settings/payments) and send you to Stripe to finish.
* **Requirements:** All plans (Starter, Growth, Scale) can accept payments; only **program owners** can create the account and complete onboarding. Instructors can view status only.
## Setting up your account
### Step 1: Open Payments settings
1. In the Program Dashboard, go to [**Settings → Payments**](https://firstrespondershub.com/program-dashboard/settings/payments).
2. In the **Set Up Payment Collection** card, click **Set Up Payments**.
### Step 2: Create the connected account
When you click **Set Up Payments**, the platform:
1. Creates a **Stripe Connect Standard account** for your organization (country and business name are set from your organization profile).
2. Stores the account in our system and generates a one-time **Account Link** from Stripe.
3. Redirects you to **Stripe’s onboarding** (or shows the link to open it).
You do not need to create an account on stripe.com first; we create the connected account for you.
### Step 3: Complete Stripe onboarding
Stripe’s flow will ask for:
* **Identity:** Name, date of birth, address, and often a government-issued ID. For some accounts, last 4 of SSN or equivalent.
* **Business information:** Business name, address, phone, and sometimes business registration or tax documents.
* **Banking:** A bank account where Stripe will send payouts.
* **Tax:** Tax ID (e.g. EIN in the US) and related details where required.
* **Terms:** Acceptance of Stripe’s terms of service.
Requirements vary by country, business type, and risk. Stripe may ask for **beneficial owner** or **representative** information in supported regions (e.g. US, Australia, parts of Europe).
* **Refresh URL:** If you leave onboarding before finishing, use **Complete Setup** or **Continue Setup** again from the same page; we generate a new link (links expire after about 24 hours).
## Verification and requirements
### What Stripe checks
Stripe uses the information you submit to verify identity and business. Typical requirement categories you might see in the app or in Stripe:
| Category | Examples |
| ------------ | ----------------------------------------------------------------------------------- |
| **Identity** | Government-issued ID, date of birth, full address, last 4 of SSN (where applicable) |
| **Business** | Business name, address, phone, tax ID, business documents |
| **Banking** | Bank account for payouts, account holder name |
| **Tax** | Tax ID number, tax forms (region-dependent) |
| **Other** | Terms of service acceptance |
If something is missing or needs to be updated, Stripe will show **currently\_due** or **eventually\_due** requirements. The [Payments page](https://firstrespondershub.com/program-dashboard/settings/payments) shows a short summary of what’s left (e.g. “Complete your banking details to start collecting payments”) and, when applicable, grouped requirements (identity, business, banking, tax).
### Status indicators
On [**Settings → Payments**](https://firstrespondershub.com/program-dashboard/settings/payments), your account can show:
* **Not Set Up** — No Stripe account has been created yet.
* **Setup Incomplete** — Account exists but Stripe still needs information (e.g. `charges_enabled` or `payouts_enabled` is false).
* **Action Required** — There are requirements in `currently_due`; Stripe needs more info before you can charge or get payouts.
* **Under Review** — Details are submitted; Stripe is reviewing (e.g. before enabling payouts).
* **Fully Onboarded** — You can accept charges and receive payouts.
Only when the account is **Fully Onboarded** (details submitted, charges enabled, and in practice payouts enabled) can you turn on **Accept Online Payments** for your organization.
### What to expect after submitting
* **Timing:** Verification can be quick or take a few business days depending on country, business type, and whether Stripe needs more documents.
* **Payouts:** Stripe may enable payouts after verification. Initial payouts can be delayed (e.g. 7–14 days); after that, payouts follow your Stripe schedule (e.g. rolling).
* **Restrictions:** If required information is missing or overdue, Stripe may pause charges or payouts until you complete it. You’ll see requirements in the Dashboard and, where we surface them, on the [Payments page](https://firstrespondershub.com/program-dashboard/settings/payments).
* **Updates:** Keep business and banking details up to date in your [Stripe Dashboard](https://dashboard.stripe.com); Stripe may email you about required updates.
## Maintaining a balance for refunds
Refunds are paid **out of your Stripe account balance** — not pulled from your bank on demand. When you [issue a refund](/payment-settings/refunds), Stripe deducts it from the money currently sitting in your connected account. If your balance is too low to cover it, the refund can't be processed until funds are available.
That leaves you with a few options when a refund comes up:
* **Wait for more revenue.** New student payments add to your balance; once enough has settled, the refund can go through. This is unpredictable and can leave a customer waiting.
* **Top up from your bank.** You can add funds to your Stripe balance by transferring from your bank account — but this takes time to settle, so it's slow when a refund is time-sensitive.
* **Keep a minimum balance (recommended).** Retain a cushion in your Stripe account so a refund can always be processed immediately, without waiting on new revenue or a bank transfer.
### Set up a minimum balance in Stripe
By default, Stripe pays out your entire available balance to your bank on your payout schedule, which can leave little or nothing behind to cover refunds. A **minimum balance** tells Stripe to hold back a set amount on each automatic payout so funds are always on hand for refunds, disputes, and fees.
To set one up in your [Stripe Dashboard](https://dashboard.stripe.com/settings/payouts):
Go to **Settings → Payouts** (or open [dashboard.stripe.com/settings/payouts](https://dashboard.stripe.com/settings/payouts)).
Under the **Minimum balance** section, turn the option on.
Enter the amount you want Stripe to retain. Automatic payouts will only send funds **above** this threshold — for example, with a $10,000 total balance and a $2,000 minimum, Stripe pays out $8,000 and keeps $2,000 available.
Save your settings. Future automatic payouts now keep the minimum in reserve.
Size the minimum to your typical refund exposure — roughly the largest refund (or few refunds) you'd expect to issue at once. Stripe suggests a cushion of several times your average daily sales. You can change or turn off the minimum at any time from the same Payout settings page.
For the full details, see Stripe's guide on [minimum balances for automatic payouts](https://docs.stripe.com/payouts/minimum-balances-for-automatic-payouts#set-up-minimum-balances).
## Enabling payment acceptance
1. Finish Stripe onboarding until the account shows **Fully Onboarded** (and **Refresh** doesn’t show new requirements).
2. On [**Settings → Payments**](https://firstrespondershub.com/program-dashboard/settings/payments), turn **Accept Online Payments** **On**.
3. Students can then pay for enrollments (and for other paid flows you’ve configured) according to each offering’s payment configuration.
If you turn the toggle **Off**, online payment for new enrollments is disabled; existing invoices and payment links can still be paid until you change or cancel them.
## Continuing or updating onboarding
* **Complete Setup / Continue Setup:** Use the button in the **Payment Account Status** card on [**Settings → Payments**](https://firstrespondershub.com/program-dashboard/settings/payments). Use this if you left onboarding early or if Stripe has added requirements.
* **Refresh:** Use **Refresh** to reload status from Stripe (e.g. after you’ve completed steps in the Stripe Dashboard or in an email link).
* **Stripe Dashboard:** For detailed requirement lists, bank details, payouts, and tax settings, log in to [Stripe Dashboard](https://dashboard.stripe.com) with the connected account (you may get there via a “Manage in Stripe”–style link if we add one, or by signing in to Stripe and selecting the connected account).
## Roles and permissions
* **Program owners:** Can create the Stripe account, start or continue onboarding, see the Stripe account ID, and toggle **Accept Online Payments**.
* **Instructors:** Can see that a payment account is configured and its high-level status (e.g. Fully Onboarded); they cannot create the account, open onboarding links, or change the acceptance toggle.
## Troubleshooting
* **“Only program owners can create payment accounts”** — You’re signed in as an instructor. Ask a program owner to set up payments.
* **“Payment processing requires an active plan”** — Restore your subscription or contact support if you expect payment access.
* **“Please complete your Stripe Connect onboarding before enabling payment acceptance”** — Resolve any **currently\_due** requirements in Stripe (use **Complete Setup** and finish the flow, or fix items in the Stripe Dashboard), then refresh and try the toggle again.
* **Link expired or invalid** — Click **Complete Setup** or **Continue Setup** to generate a new Account Link.
* **Account under review** — Wait for Stripe to finish review; they may email you. If something is missing, complete it in the Stripe Dashboard or via the link we provide.
For Stripe-specific verification or payout questions, use [Stripe Support](https://support.stripe.com) or the help in your Stripe Dashboard.
# Plans and billing
Source: https://docs.firstrespondershub.com/plans-and-billing/index
What your FirstRespondersHub subscription covers, where to change it, and how billing works.
Your **plan** is your subscription to FirstRespondersHub. It decides which features your organization can use and what you pay per transaction.
This is separate from what your **students** pay you. Student tuition and refunds live under [Payment settings](/payment-settings).
## Where to find it
Go to [**Program Dashboard → Account → My Plan**](https://www.firstrespondershub.com/program-dashboard/settings/your-plan).
Only program owners can see this page.
## The three plans
| Plan | Best for |
| ----------- | ----------------------------------------------------------------------- |
| **Starter** | Getting listed and collecting leads. No online enrollments or payments. |
| **Growth** | Taking enrollments and payments online. |
| **Scale** | Higher volume, lower transaction fees, and the Avery AI sales agent. |
See [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits) for what each one includes.
## Trials
New organizations start on a **14-day Starter trial**. A card is required to start it, but you are not charged during the trial.
The My Plan page shows **Days remaining** while a trial is running.
## In this section
| Guide | What it covers |
| ----------------------------------------------------------------- | -------------------------------------------------------------- |
| [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits) | What each plan unlocks, and what happens when you hit a limit. |
| [Managing your plan](/plans-and-billing/managing-your-plan) | Change plans, update your card, read invoices, and cancel. |
## See also
* [Payment settings](/payment-settings) — Taking money from students.
* [Stripe Connect](/payment-settings/stripe-connect) — Connecting the account your student payments land in.
# Managing your plan
Source: https://docs.firstrespondershub.com/plans-and-billing/managing-your-plan
Change plans, update your card, read your invoices, and cancel — including how refunds work on annual plans.
Go to [**Program Dashboard → Account → My Plan**](https://www.firstrespondershub.com/program-dashboard/settings/your-plan).
Only program owners can open this page.
## What's on the page
| Section | What it shows |
| ------------------- | --------------------------------------------------------- |
| **Current plan** | Which plan you are on, monthly or annual, and the status. |
| **Days remaining** | Only during a trial. |
| **Recent invoices** | Your subscription invoices, newest first. |
| **Payment method** | The card your subscription is billed to. |
These are **your** invoices from FirstRespondersHub. Invoices you send to students live under [Invoices and balances](/payment-settings/invoices-and-balances).
## Monthly or annual
Every plan can be billed monthly or annually. Annual costs less per month.
## Upgrading
Pick the new plan and confirm. The new features are available right away.
Upgrade when you hit a limit — you need an eleventh program offering, you want to take payments online, or you ran out of campaign emails. See [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits).
## Cancelling
What happens depends on how you are billed.
### Monthly plans
Your plan is cancelled **at the end of the period you already paid for**. You keep access until then. There is no refund, because there is nothing left over — you paid for the month you are using.
### Annual plans
Your plan is cancelled **right away** and you get a refund for the part you did not use.
The refund is worked out like this: you are charged the normal **monthly** rate for every month you started, and the rest comes back.
You give up the annual discount when you cancel early. That is the trade for paying less up front.
A started month counts as a whole month, exactly the way a monthly plan would have billed you. If you cancel on the 3rd day of month five, you are charged for five months.
### During a trial
Cancelling during a trial ends the plan when the trial ends. You are never charged.
## What happens to your data
Cancelling does not delete anything. Your students, classes, payments, and records stay. What changes is which features you can use.
## See also
* [Plan tiers and limits](/plans-and-billing/plan-tiers-and-limits) — What each plan includes.
* [Invoices and balances](/payment-settings/invoices-and-balances) — Invoices you send to students.
* [Stripe Connect](/payment-settings/stripe-connect) — Where student payments land.
# Plan tiers and limits
Source: https://docs.firstrespondershub.com/plans-and-billing/plan-tiers-and-limits
What Starter, Growth, and Scale each unlock, the limits on each, and what happens when you reach one.
FirstRespondersHub has three plans. Each one unlocks more of the platform.
Current prices are on the [pricing page](https://www.firstrespondershub.com/pricing). This page is about **what changes** between plans.
## The short version
| | Starter | Growth | Scale |
| ------------------------------- | -------- | ----------- | ------------------------- |
| Public listing and lead capture | Yes | Yes | Yes |
| Online enrollments and payments | No | Yes | Yes |
| Program offerings | Up to 10 | Up to 20 | Unlimited |
| Transaction fee | — | 4% + 30¢ | 3.25% + 30¢ |
| Agreements and waivers | No | Yes | Yes |
| Email campaigns | No | 1,000/month | 5,000/month |
| Roster exports | No | Yes | Yes |
| Avery AI sales agent | No | No | Yes |
| Support | Standard | Standard | Priority + VIP onboarding |
Contacts are unlimited on every plan. The limit is on **email sends**, not on how many people you store.
## What each limit means in practice
### Program offerings
A **program offering** is a program you sell, like "EMT Basic" or "BLS Provider." Cohorts inside an offering do not count toward the limit — you can run as many classes of one program as you like.
If you have 10 offerings on Starter and want an eleventh, upgrade.
### Transaction fees
When a student pays you online, FirstRespondersHub takes a percentage plus 30¢. The rest goes to your connected Stripe account.
* Growth: **4% + 30¢**
* Scale: **3.25% + 30¢**
For an $850 EMT tuition, that is $34.30 on Growth and \$27.93 on Scale.
Starter cannot take online payments at all, so there is no transaction fee.
### How students enroll
| Plan | How students can sign up |
| -------------------- | ------------------------------------------------------------------- |
| **Starter** | Send them to your own website, or use a "Request information" form. |
| **Growth and Scale** | All of the above, plus enrolling and paying on FirstRespondersHub. |
See [Program offering enrollment settings](/enrollment/program-offerings-settings).
### Email campaigns
Email campaigns are for reaching contacts — past students, leads, a saved list. See [Email campaigns](/contacts/email-campaigns).
* **Starter** cannot send campaigns.
* **Growth** can send 1,000 a month.
* **Scale** can send 5,000 a month.
The Contacts page header shows **Emails this month: X / Y**. At 80% of your quota a warning banner appears. At 100%, sends stop until the month resets or you upgrade.
The check happens **when you press send**, and it counts the recipients in that send. If a campaign would push you past your limit, the whole send is rejected rather than sent halfway. Trim the audience or upgrade.
Emails that are part of running your programs — enrollment confirmations, invoices, access codes, class announcements — are **not** campaign emails and do not count toward this limit.
### Agreements and waivers
Starter cannot create agreements. Growth and Scale can. See [Agreements](/enrollment/agreements).
### Roster exports
Starter cannot export rosters. Growth and Scale can export to PDF, CSV, and Excel.
### Avery, the AI sales agent
Avery answers questions from prospects on your website, qualifies them, and hands you real leads. Scale only.
## What happens when you hit a limit
Nothing breaks and nothing is deleted. The action you tried is refused with a message that says which limit you reached and offers an upgrade.
Work you have already done stays exactly as it is.
## Changing plans
See [Managing your plan](/plans-and-billing/managing-your-plan).
## See also
* [Managing your plan](/plans-and-billing/managing-your-plan) — Upgrade, downgrade, or cancel.
* [Stripe Connect](/payment-settings/stripe-connect) — Where your student payments land.
* [Email campaigns](/contacts/email-campaigns) — What counts against your email quota.
# Creating and publishing a post
Source: https://docs.firstrespondershub.com/posts/creating-a-post
Write a post with rich text, attach files, link lessons, and publish it to your cohort.
Posts are created from within a cohort. You can draft a post, add content and attachments, and publish it when ready — optionally notifying all enrolled students by email.
## Where to find it
Go to [**Program Dashboard → Cohorts**](https://firstrespondershub.com/program-dashboard/cohorts), open a cohort, click the **Posts** tab, and then click **Create Post**.
## Creating a post
1. Open the cohort and go to the **Posts** tab.
2. Click **Create Post**.
3. Enter a **title** for the post.
4. Write the post body using the rich text editor.
5. Optionally add file attachments and lesson links (see below).
6. Click **Save Draft** to save without publishing, or **Publish** to make it visible to students.
## The rich text editor
The editor supports:
* **Bold**, **Italic**, and **Underline** text formatting
* **Headings** (H1, H2, H3)
* **Bullet lists** and **numbered lists**
* **Links** — add or edit URLs inline
* **Inline images** — upload images directly into the post body
Use the toolbar at the top of the editor to apply formatting. Undo and redo are available if you need to reverse changes.
## Adding file attachments
You can attach files for students to download from the post.
* Click **Add Attachment** below the editor to upload a file.
* Up to **10 files** per post, each up to **25 MB**.
* Each attachment shows its file name and size.
* To remove an attachment, click the remove button next to it.
Attachments are available to students when they view the published post.
## Linking lessons
You can link a post to specific lessons from the courses assigned to the cohort's program offering. This lets students navigate directly from the post to a lesson.
* Click **Add Lesson Link** to search for and select a lesson.
* Only lessons from courses assigned to the cohort's program offering are available.
* You can link multiple lessons to a single post.
* To remove a lesson link, click the remove button next to it.
When students view the post, each linked lesson appears with its course and module context, and they can click through to open the lesson.
## Saving as draft
If you are not ready to publish, click **Save Draft**. Drafts are only visible to program owners and instructors — students cannot see them. You can return to a draft at any time from the cohort's **Posts** tab and continue editing.
## Publishing a post
When you are ready for students to see the post:
1. Click **Publish**.
2. You will be asked whether to **send an email notification** to enrolled students.
3. If you check the notification option, an email is sent to all currently enrolled students in the cohort with a link to the post.
4. Once published, the post appears in the student post feed immediately.
After publishing, the post is visible to all students enrolled in the cohort. You can still edit the post — see [Managing posts](/posts/managing-posts) for details.
For more about how email notifications work, see [Post email notifications](/posts/email-notifications).
# Post email notifications
Source: https://docs.firstrespondershub.com/posts/email-notifications
When post notifications are sent, who receives them, and how to resend.
When you publish a post, you can choose to send an email notification to all enrolled students in the cohort. This page explains how post notifications work.
## When notifications are sent
Notifications are sent in two situations:
1. **On publish** — When you publish a post and check the option to send an email notification.
2. **Manual resend** — When you click the email icon on a published post in the Posts tab and confirm.
Notifications are not sent automatically — you always choose whether to notify students.
## Who receives them
The email is sent to all students currently enrolled in the cohort. This includes students with an enrollment status of enrolled, completed, or paid and pending application review.
Students who enroll after the notification was originally sent will not receive it unless you resend the notification.
## What the email contains
The notification email includes:
* Your organization's name and branding
* The cohort name
* The post title
* A link to view the full post on the student dashboard
Students click the link in the email to open the post directly in their student dashboard.
## Sending a notification on publish
When you click **Publish** on a post, a dialog asks whether you want to send an email notification. Check the option to notify students, or leave it unchecked to publish without sending an email. You can always send the notification later.
## Resending a notification
To resend a notification for a published post:
1. Go to the cohort's **Posts** tab.
2. Find the published post.
3. Click the **email icon** in the post's action menu.
4. Confirm in the dialog that appears.
Resending is useful when new students have enrolled since the original notification, or when you want to remind students about an important post. The **Email Sent** badge on the post updates to reflect that a notification has been sent.
# Posts
Source: https://docs.firstrespondershub.com/posts/index
Create and share announcements, resources, and lesson links with your cohort students.
Posts are announcements scoped to a cohort. Program owners and instructors use posts to share updates, attach files, link to specific lessons, and notify enrolled students — all from within a cohort.
## Where to find Posts
**As a program owner or instructor:** Go to [**Program Dashboard → Cohorts**](https://firstrespondershub.com/program-dashboard/cohorts), open a cohort, and click the **Posts** tab. From here you can create, publish, pin, and manage posts.
**As a student:** Go to [**Student Dashboard → Posts**](https://firstrespondershub.com/student-dashboard/posts) to see published posts from your enrolled cohorts.
## What you can do
* **Create posts with rich text** — Write announcements using headings, lists, bold/italic text, links, and inline images.
* **Attach files** — Upload up to 10 files per post (25 MB each) for students to download.
* **Link lessons** — Connect a post to specific lessons from the cohort's courses so students can navigate directly to them.
* **Save as draft** — Work on a post without publishing it. Drafts are only visible to program owners and instructors.
* **Publish and notify** — Publish a post to make it visible to students, with the option to send an email notification to all enrolled students.
* **Pin important posts** — Pin up to 3 posts per cohort so they always appear at the top of the student feed.
* **Edit or delete** — Update published posts or remove them when they are no longer relevant.
## Learn more
| Guide | What it covers |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| [Creating and publishing a post](/posts/creating-a-post) | Writing a post, using the editor, adding attachments and lesson links, saving drafts, and publishing |
| [Managing posts](/posts/managing-posts) | Viewing your posts, editing, pinning, resending notifications, and deleting |
| [Student post feed](/posts/student-post-feed) | What students see: the post feed, filtering by cohort, post details, downloading attachments, and lesson links |
| [Post email notifications](/posts/email-notifications) | When notifications are sent, who receives them, what the email contains, and how to resend |
# Managing posts
Source: https://docs.firstrespondershub.com/posts/managing-posts
View, edit, pin, and delete posts from the cohort Posts tab.
After creating posts, you can manage them from the cohort's **Posts** tab — edit content, pin important announcements, resend notifications, or remove posts that are no longer needed.
## Where to find it
Go to [**Program Dashboard → Cohorts**](https://firstrespondershub.com/program-dashboard/cohorts), open a cohort, and click the **Posts** tab.
## Viewing your posts
The Posts tab lists all posts for the cohort. Each post shows:
* **Title** — click to open and edit
* **Status** — **Published** or **Draft**
* **Pinned indicator** — if the post is pinned
* **Author** — who created the post
* **Date** — publication date (for published posts) or creation date (for drafts)
* **Content preview** — a short excerpt of the post body
* **Attachment count** — number of attached files
* **Lesson link count** — number of linked lessons
* **Email Sent** badge — if a notification email was sent
Use the status filter at the top to show **All Posts**, **Published**, or **Drafts** only.
## Editing a published post
Click a post to open the editor. You can update the title, body, attachments, and lesson links. When you save changes to a published post, an **Edited** badge appears on the post so students know it has been updated. The updated content is visible to students immediately.
## Pinning posts
Pinned posts appear at the top of the student post feed, above all other posts. You can pin up to **3 posts** per cohort.
To pin or unpin a post, click the **pin icon** in the post's action menu. Only published posts can be pinned. If you already have 3 pinned posts and want to pin a different one, unpin an existing post first.
## Resending email notifications
If you published a post with an email notification and want to notify students again — for example, after new students have enrolled — click the **email icon** in the post's action menu. A confirmation dialog will appear before the notification is sent.
The action shows **Send** if no notification has been sent yet, or **Resend** if one was sent previously.
## Deleting posts
To delete a post, click the **delete icon** in the post's action menu and confirm.
* **Draft posts** are permanently removed.
* **Published posts** are hidden from students but preserved in the system. Students will no longer see the post in their feed.
## Draft vs. published at a glance
| | Draft | Published |
| ----------------------- | ------------------- | ----------------------------------- |
| **Visible to students** | No | Yes |
| **Can be edited** | Yes | Yes (shows "Edited" badge) |
| **Can be pinned** | No | Yes |
| **Email notification** | Not available | Available on publish and via resend |
| **Delete behavior** | Permanently removed | Hidden from students |
# Student post feed
Source: https://docs.firstrespondershub.com/posts/student-post-feed
How students view posts: the feed, cohort filtering, post details, attachments, and lesson links.
Students see published posts from their enrolled cohorts in a dedicated post feed on the student dashboard. This guide describes what students see and how they interact with posts.
## Where to find it
Go to [**Student Dashboard → Posts**](https://firstrespondershub.com/student-dashboard/posts). The post feed shows all published posts from cohorts the student is enrolled in.
## The post feed
The feed is divided into two sections:
* **Pinned posts** — Posts pinned by the instructor appear at the top, marked with a pin icon so they stand out.
* **Recent posts** — All other published posts, sorted by newest first.
Each post in the feed shows:
* Post title
* Author name
* Program name
* Publication date (e.g. "2 hours ago")
* **Edited** badge, if the post was updated after publishing
* Content preview (first 150 characters)
* Attachment and lesson link counts
## Filtering by cohort
If a student is enrolled in more than one cohort, a **cohort filter** appears at the top of the feed. Use it to show posts from all programs or from a specific program.
## Post detail view
Click a post to open the full detail view. The detail page shows:
* **Title** and publication date
* **Author** and program/cohort name
* **Edited** badge (if applicable)
* **Full post content** with all formatting, images, and links
### Downloading attachments
If the post has file attachments, they appear in an **Attachments** section below the content. Each attachment shows the file name and size. Click the **download** button to save the file.
### Lesson links
If the post links to specific lessons, they appear in a **Lesson Links** section. Each link shows the course, module, and lesson name. Click a lesson link to navigate directly to that lesson in your course view.
## Recent posts on the dashboard home
The student dashboard home page includes a **Recent Posts** section that shows the latest posts across all enrolled cohorts. Click a post to go to its detail view, or click through to the full post feed.
## Posts on the student home page
Students do not have to open the Posts page to see an announcement. Their **home** page shows the four most recent posts from their classes, with pinned ones first and a short preview of the text.
Tapping one opens the full post.
That is the reason to pin something. A pinned post sits at the top of the feed **and** the top of the home page, so it is the first thing a student reads when they log in.
# Activity and stock alerts
Source: https://docs.firstrespondershub.com/student-access/activity-and-alerts
See who sent codes, when you ran out, which emails failed, and how to get warned before stock hits zero
**Credential Activity** is the history of student access: imports, sends, emails, stock problems, and team edits.
## Where to find it
Go to [**Program Dashboard → Courses → Credential Activity**](https://www.firstrespondershub.com/program-dashboard/credentials/activity).
Only **program owners** can open this page.
Each code also has **Status history** on its inventory detail.
## Summary tiles
* **Codes available** — unused stock
* **Waiting to send** — held but not sent yet
* **Sent (7 days)** — recently released
* **Needs attention** — stockouts, failed emails, missing shared values
## Category tabs
| Tab | Typical events |
| ---------------- | ------------------------------------------------------------------------------------------------------ |
| **All** | Everything |
| **Sent** | Held for a student, sent to student, reused existing access |
| **Stock issues** | Needs more codes, out of stock alert, low stock warning, missing access details, course not configured |
| **Emails** | Email sent, email failed, email resent |
| **Imports** | Codes imported, hand-entered, archived, values edited |
| **Team changes** | Timing changed, fields updated, verification resolved, returned to stock |
You can also filter by **course**, **search**, and date range (**Last 7 days**, **Last 30 days**, **All time**).
Open a row to see **When**, **Course**, **Student**, **Who**, and **How**.
**Who** is written in plain language:
* **Team member**
* **System**
* **Automatic**
* **Import**
**How** examples:
* When a student enrolled
* When a course was purchased
* CSV upload
* Released by a team member
* Scheduled release
## Emails your team receives
Students do not get these. They go to your organization admin email.
### Out of stock
**Subject:** `[Action needed] Credential stockout: {course}`
Sent when a student enrolled or bought and there was no unused code to hold.
The email includes the course, student, confirmation number, how many could not be filled, and a link to import inventory.
### Low stock
**Subject:** `[Action needed] Low credential stock: {course}`
Sent when you cross a threshold you set on the course (count left, or days of stock left). It sends **once** until you add stock again.
Set the thresholds under **Student access** → **Advanced operations**:
* **Email when fewer than this many codes are left**
* **Email when codes would run out within this many days**
Days of stock uses recent paid seats (about the last 30 days) to estimate how fast you are using codes.
### Student access email failed
If the student email fails, activity shows **Email failed to send**. The codes can still be on the dashboard. Use **Resend** after you fix the address or spam issue.
## What "needs attention" usually means
1. **Waiting for codes** — import stock.
2. **Couldn't send — missing access details** — fill in Course ID or another shared field.
3. **Couldn't set up access — course has no credentials configured** — the course gives access but has no credential fields yet. Add them under **Student access** on the course.
4. **Couldn't send — no credentials to send** — the delivery had nothing in it. Same fix: finish setting the course up.
5. **Email failed** — resend; confirm the student's email.
6. **Needs verification** — finish the refund check so codes do not sit unused.
Work those first. The rest of the activity feed is a record, not a to-do list.
# Buying more than one seat
Source: https://docs.firstrespondershub.com/student-access/buying-more-than-one-seat
Let a department buy several access codes in one checkout, and how each seat gets its own code
A **seat** is one person's worth of access. If a fire department buys Heartsaver for three people, that is **3 seats** and **3 unique codes**.
This only applies to [standalone course](/courses/standalone-courses) purchases of a course that uses student access. Program enrollment still uses one seat per enrolled student.
## Set the max on the course
1. Open the course → **Course setup**.
2. Turn on standalone sale if it is not on already.
3. Set **Max seats per purchase**.
Rules:
* Default is **10**
* You can set **1** to **50**
* The checkout page tells the buyer: **Each seat receives its own credential code or link. Up to `{max}` per purchase.**
This control only appears when the delivery model is **Access from another provider** or **Both**.
## What the buyer sees
On the public course page, they choose **Number of seats**.
* The price updates to match (quantity × price).
* If they change the number after payment has started to load, the total refreshes. They may see **Updating total...** or **Setting up secure payment...**.
* If they somehow submit an old total, checkout is rejected with a message that the seat quantity changed. They try again with the new total.
Required [agreements](/enrollment/agreements) still apply once, for the purchase, not once per seat.
## What you see after the purchase
The purchase creates **one delivery per seat** (Seat 1, Seat 2, Seat 3).
* All seats follow the **standalone** timing rule.
* If timing is immediate, they often get **one digest email** with every code.
* In the dashboard, codes are grouped: **Access code 1 of 3**, and so on.
On **Pending deliveries**, filter to that student or course and you will see one row per seat.
## Partial refunds
You can refund some seats and keep others.
1. Open the refund dialog on the purchase.
2. Select **Seat 1**, **Seat 2**, and so on.
3. The refund amount is proportional.
4. Only the selected seats have access taken back.
See [Refunds and unused codes](/student-access/refunds-and-unused-codes).
## Stock planning
Three seats hold **three** unused codes at purchase time. If you only have two codes in stock:
* Some seats may go to **Waiting for codes**
* You get a stockout email
* Import more codes; the waiting seats fill in
If a department often buys 10 at a time, keep at least that many unused codes before you share the purchase link.
## Example
Station 4 buys your AHA Heartsaver course.
1. Max seats is 10. They choose **Number of seats: 3**. Price is \$75 × 3.
2. They pay once.
3. Three Course URLs are held.
4. Because timing is **Right after purchase**, they get one email with three links, labeled code 1, 2, and 3 of 3.
5. They forward each link to a different firefighter (or you asked them in the student message to open each link on the correct person's AHA account).
Write that last part in **Student message**. The platform cannot know which seat belongs to which firefighter unless you tell the buyer how to hand them out.
# Different values per class
Source: https://docs.firstrespondershub.com/student-access/different-values-per-class
Give March a different Course ID than June, pull shared values from cohort document fields, and avoid sending the wrong class code
Some values should be the same for every student in a **course**. The Navigate website is a good example.
Some values should be the same for every student in a **class (cohort)**, but different from the next class. The Navigate **Course ID** is the usual example.
This page is about those per-class values.
## Course default vs class override
On **Student access**, shared fields have a course-level value. That is the default.
On the class itself, go to **Settings → Document fields**. The card called **Credential details for this cohort** lets you set a different value for that class. What you type there **wins** at send time for students in that class.
A June student never inherits March's Course ID. If June has no override and no course default, send is blocked until you fill it in. That is on purpose, so nobody joins the wrong Navigate course.
### Example
Course default Course ID: `BLS-DEFAULT`
| Cohort | Override | Students in that class get |
| ----------------------------- | ----------- | -------------------------- |
| March 2026 | `BLS-MAR26` | `BLS-MAR26` |
| June 2026 | `BLS-JUN26` | `BLS-JUN26` |
| A new cohort with no override | (none) | `BLS-DEFAULT` |
Unique access codes still come from the shared **Access codes** list. Only **shared** fields override per class.
## Where to set the override
1. Open the class from [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts).
2. Click the **Settings** tab.
3. Choose **Document fields** in the left menu.
4. Scroll to **Credential details for this cohort**.
5. Fill in the fields that should be different for this class, and click **Save** on each one.
Each field tells you exactly what students will get:
* *Blank uses the course default, `BLS-DEFAULT`. Students get `BLS-DEFAULT`.*
* Or, once you type something: *Students get `BLS-MAR26`.*
* Or, if there is no default and no value: *Students get nothing yet, which holds their access.*
The card only appears when a course in this program actually has a value that can change per class. If you do not see it, there is nothing to set here.
## Pulling a value from document fields
Instead of typing the Course ID on the credential panel, you can say: "use this cohort's document field."
On the course field (shared fields only):
1. Set the source to the cohort **document field**.
2. Pick the field key (for example the offering's Course ID field).
3. If you also sell the course as [standalone](/courses/standalone-courses), add a **Standalone default**. Standalone buyers have no cohort, so they need that fallback.
If the document field is empty on a class, that class cannot send access until you fill it in. The page shows it as unset and **holds the send**.
Document fields are the extra pieces of information you already store on a class — approval numbers, classroom links, session numbers. Student access can reuse them, so you do not type the same course ID in two places. See [Document fields](/cohort-management/document-fields).
## Standalone buyers
People who buy the course without joining a cohort always use:
* The course-level shared value, or
* The **Standalone default** you set on a document-field-backed field
They never use a cohort override.
## Checklist before you open a new class
* [ ] Unique codes are in stock
* [ ] This class's Course ID (or other shared fields) is set
* [ ] Timing still makes sense for this start date
* [ ] Student message still matches this vendor
If you skip the Course ID, students can still enroll. Their access just waits until you fill it in.
## See also
* [Document fields](/cohort-management/document-fields) — The full picture, including how changes affect signed PDFs.
* [When students get access](/student-access/when-students-get-access) — Timing, and what happens when a class moves.
# Import and manage codes
Source: https://docs.firstrespondershub.com/student-access/import-and-manage-codes
Upload access codes, search by exact value, understand statuses, and keep unused codes in stock
**Access codes** is your unused-code shelf. You import the list you bought from the vendor. The platform then holds one unused set for each student and marks it **Sent** after it goes out.
## Where to find it
Go to [**Program Dashboard → Courses → Access codes**](https://www.firstrespondershub.com/program-dashboard/credentials/inventory).
Only **program owners** can open this page.
You can also jump here from a course's **Student access** page.
## What you are importing
Each import row is **one student worth of unique fields**.
* For AHA, that is usually one Course URL.
* For Jones & Bartlett, that is usually one 10-digit Access Code.
* For a custom login, that might be username **and** password on the same row.
Shared fields (Course ID, course website) are **not** in the spreadsheet. You set those on the course.
Keep leading zeros. A code like `0123456789` must stay `0123456789`. The importer does not turn codes into numbers.
## Add inventory
1. Click **Add inventory**.
2. Select the course (the left list shows how many codes are **available** for each course).
3. Optionally enter a **Batch name** so you can tell orders apart later. Example: `Spring 2026 J&B order`.
4. Choose how to add codes:
Use this when there is **one** unique field (AHA URLs, or a single access-code column).
Paste **one code or URL per line**, then continue to preview.
Use this when you have columns, or more than one unique field.
1. Upload the file.
2. **Map column for** `{field}` so each unique field matches a column.
3. Continue to preview.
5. Review the preview. Fix any rejected rows (bad URLs, duplicates).
6. Click **Commit import**.
You should see a toast such as **Imported 40 packets**. If students were already waiting because you were out of stock, you may also see **fulfilled N waiting delivery(ies)**. Those waiting students get a code as soon as stock exists (and then follow the course's send timing).
### What the importer skips
* Duplicate values already in the file
* Values that already exist in stock (unless the old one is **Already used** or **Archived**)
* Invalid URLs, for URL fields
If an AHA batch looks like it mixed two different courses (the URLs do not match), you will see a warning. Check the file before you commit.
## Statuses you will see
| Status | Meaning |
| ---------------------- | ---------------------------------------------------------------------------------- |
| **In stock** | Unused. Ready for the next student. |
| **Held for a student** | Reserved for someone who enrolled or bought, but not sent yet. |
| **Sent** | The student has this code (email and/or dashboard). |
| **Needs verification** | Taken back after a refund of a **sent** code. A person must check it before reuse. |
| **Already used** | Burned. Do not give it to anyone else. |
| **Entered by hand** | A team member typed this set for one student. |
| **Archived** | Removed from active stock on purpose. |
The top of the page also shows **Waiting for codes**. That is how many students enrolled or bought while you were out of stock.
## Search, edit, and archive
* **Search by exact code** — paste the full code or URL. Partial search is not used, so you do not accidentally match the wrong student.
* **Edit values** — only while the set is **In stock**.
* **Archive** — hide an unused set so it is not given out (for example, a code your vendor voided).
* **View history** — see every status change for that set.
## After a refund: return to stock
If a **sent** code comes back, it usually lands in **Needs verification**. Open it and choose:
* **Mark available** — put it back **In stock**
* **Mark burned** — mark it **Already used**
If someone marked a code **Already used** by mistake, use **Return to stock**.
Full refund behavior is in [Refunds and unused codes](/student-access/refunds-and-unused-codes).
## Consumption (will we run out?)
The inventory page can show a short forecast:
* **Paid seats (30d)** — how many paid seats used codes in the last 30 days
* **Daily rate** — average per day
* **Available** — unused codes right now
* **Projected exhaustion** — roughly when you will hit zero at that rate
This is a planning aid, not a promise. Set [stock alerts](/student-access/activity-and-alerts) if you want an email before you run out.
## Tips that save support tickets
* Import **before** you open enrollment, so the first students are not stuck on **Waiting for codes**.
* Name each batch after the vendor order (`AHA Heartsaver Mar 2026`).
* Never email a leftover code from the spreadsheet. Let the platform assign it so the status stays correct.
* If a student says "this code is already used," search the exact code here. You will see who it was held for or sent to.
# Overview
Source: https://docs.firstrespondershub.com/student-access/index
Give students access codes, course links, and logins from providers like Jones & Bartlett and the American Heart Association
Some courses live on FirstRespondersHub. Other courses live on a vendor site, like Jones & Bartlett Navigate or American Heart Association eLearning. **Student access** is how you give each student the codes, links, or logins they need for that vendor.
You import the codes once. The platform holds one set for each student, sends it at the right time, and shows it in the student's dashboard and email.
In the product you will see **Student access**, **Access codes**, and **Pending deliveries**. Those all belong to this feature. Older notes may also say "credentials." Same thing.
## A simple example
Jordan enrolls in your BLS class. The online part is on Jones & Bartlett Navigate.
1. You already uploaded a list of 10-digit access codes.
2. When Jordan enrolls, the platform holds one unused code for them.
3. Seven days before class starts, Jordan gets an email with the course website, the Course ID, and their unique access code.
4. The same details appear under **Your Credentials** in Jordan's student dashboard.
You did not copy and paste anything into an email. If Jordan later gets a refund, the platform takes that code back so you can decide whether to reuse it.
## What's in this section
| Guide | What it covers |
| ------------------------------------------------------------------------ | ----------------------------------------------------------------------- |
| [What students receive](/student-access/what-students-receive) | Access codes vs lessons, delivery models, and real examples |
| [Set up a course](/student-access/set-up-a-course) | Turn on provider access, pick a vendor preset, fill the setup checklist |
| [Vendor presets](/student-access/vendor-presets) | Jones & Bartlett, American Heart Association, and custom fields |
| [Import and manage codes](/student-access/import-and-manage-codes) | Upload codes, search, statuses, and what "in stock" means |
| [When students get access](/student-access/when-students-get-access) | Right away, before class, or when staff sends it |
| [Send access to students](/student-access/send-access) | Pending deliveries, Release, Resend, and hand-enter |
| [Different values per class](/student-access/different-values-per-class) | A different Course ID for March vs June |
| [What students see](/student-access/what-students-see) | Dashboard, emails, and what "Pending" means |
| [Buying more than one seat](/student-access/buying-more-than-one-seat) | Departments that buy several codes in one checkout |
| [Refunds and unused codes](/student-access/refunds-and-unused-codes) | What happens to codes after a refund |
| [Activity and stock alerts](/student-access/activity-and-alerts) | History, low-stock emails, and who did what |
| [Troubleshooting](/student-access/troubleshooting) | Common questions and how to fix them |
## How it fits together
```mermaid theme={null}
flowchart LR
Setup[Set up the course] --> Import[Import access codes]
Import --> Enroll[Student enrolls or buys]
Enroll --> Hold[Platform holds one code]
Hold --> Send[Code is sent]
Send --> Student[Email and dashboard]
```
1. **Set up the course** — Choose **Access from another provider** or **Both**. Add the fields students need (Course ID, access code, Course URL, and so on).
2. **Import codes** — Upload a spreadsheet or paste codes under **Access codes**.
3. **Student enrolls or buys** — The platform immediately holds one unused set of codes for that student.
4. **Codes are sent** — Right away, a few days before class, or when you click **Release**.
5. **Student uses them** — They get an email and can copy the details from **Your Credentials**.
## Where to find it
| Place | What it's for | Who can use it |
| ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | ----------------------------------- |
| [**Courses**](https://www.firstrespondershub.com/program-dashboard/courses) → open a course → **Student access** | Set up fields, timing, and the student message | Program owners |
| [**Courses → Access codes**](https://www.firstrespondershub.com/program-dashboard/credentials/inventory) | Import and manage unused codes | Program owners |
| [**Courses → Pending deliveries**](https://www.firstrespondershub.com/program-dashboard/credentials/deliveries) | See who is waiting and send codes | Owners manage; instructors can view |
| [**Courses → Credential Activity**](https://www.firstrespondershub.com/program-dashboard/credentials/activity) | See what happened and what needs attention | Program owners |
| **Students** → open a student → **Access** | See that student's codes and resend email | Owners and instructors |
## Who this is for
* **Program owners** set up courses, import codes, send access, and handle refunds.
* **Instructors** can view pending deliveries and a student's Access tab. They cannot change course setup or import codes.
* **Students** never see unused codes in your stock. They only see their own details after those details are sent.
## Related guides
Student access works with [courses](/courses), [standalone course sales](/courses/standalone-courses), [enrollment](/enrollment), and [refunds](/payment-settings/refunds).
# Refunds and unused codes
Source: https://docs.firstrespondershub.com/student-access/refunds-and-unused-codes
What happens to access codes when you refund, withdraw a student, or take access back — and how to put a code back in stock
When you return money or remove a student, the platform also **takes back** that student's access. What happens to the **code itself** depends on whether it was already sent, and on the course's refund settings.
Money refunds still follow the normal [Refunds](/payment-settings/refunds) flow. This page is only about the codes.
## The two course settings that matter
Set these under **Student access** → **Advanced operations**.
### After a refund, can the code be reused?
| Setting | What happens to a code that was already sent |
| -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Hold the codes until someone checks them** | The code goes to **Needs verification**. Nobody else gets it until a team member marks it available or already used. |
| **Reuse the codes after you cancel access** | Same first step (it still needs a check). Your job is to turn the student off at the vendor, then mark the code available again. |
If the code was **not sent yet** (still pending or scheduled), it returns to **In stock** automatically. No review list.
### If the student already has codes, can staff refund?
| Setting | What staff see |
| ----------------------------------------- | ------------------------------------------------------------------ |
| **Allow the refund, but warn first** | Yellow warning. They can continue. |
| **Stop the refund unless staff override** | Refund is blocked until they check **Override and refund anyway**. |
The block screen is **Refund blocked — access codes already sent**.
Use **block** when a used AHA URL cannot be taken back, or when a code costs you real money.
## What staff see during a refund
The refund dialog asks the credential system first.
* If any seat is **Released**, you get the warning or the block, based on the setting above.
* For a multi-seat purchase, you can pick **Seat 1**, **Seat 2**, and refund only those.
* After you confirm, those deliveries show **Refunded**.
## Status labels after access is taken back
| Label | Why |
| --------------- | -------------------------------------------------------- |
| **Refunded** | Purchase or enrollment refund |
| **Withdrawn** | Student was withdrawn |
| **Transferred** | Enrollment moved |
| **Taken back** | A team member took it back, or another enrollment change |
The student no longer sees the values in **Your Credentials**.
## What happened to the code?
Open the delivery. You will see a plain-language fate:
| Message | Meaning |
| ------------------------------------------------- | ------------------------------------- |
| **Code in stock** / **In stock for next student** | Safe to assign again |
| **Code needs a check** | **Needs verification**. Do not guess. |
| **Already used — not in stock** | Marked burned |
| **Held for another student** | Already reserved for someone else |
| **Sent to another student** | Already released to someone else |
### Resolve verification
1. Go to **Access codes** (or the delivery detail).
2. Open the set that **Needs verification**.
3. Confirm with the vendor whether the student used it.
4. Choose **Mark available** or **Mark burned**.
**Example (AHA):** Jordan got a Course URL on Monday and requested a refund Tuesday. You log into Training Central. If the keycode is unused, **Mark available**. If Jordan already launched the course, **Mark burned** and keep the refund decision separate.
**Example (Jones & Bartlett):** After you disable Jordan in Navigate, **Mark available** so the next student can use that access code, if your vendor allows reuse.
## Return to stock (undo "already used")
If someone marked a code **Already used** by mistake:
1. Open the code.
2. Click **Return to stock**.
3. Confirm **Return this code to stock?**
History will show **Returned to stock after being marked used**.
## Withdrawals
Taking a student out of a class also takes back their access, using the same rules as a refund. Check **Pending deliveries** and **Access codes** so the code does not sit in **Needs verification** forever.
## Transfers to another class
Transferring a student is not the same as removing them. They still need access — just for a different class.
| Their code | What happens |
| ------------ | ----------------------------------------------------------------------------------------------------- |
| Not sent yet | Taken back from the old class and reissued for the new one. History shows **Moved to the new class**. |
| Already sent | Stays with the student. They keep it. |
If the new class uses a different course ID or a different value for anything, the reissued code picks up the new class's value.
See [Students and invites](/cohort-management/students-and-invites) for how to transfer.
## When a class is cancelled or archived
Cancelling or archiving a class stops every code that has not gone out yet. Those codes go straight back into your stock. Nothing needs a check, because nobody ever saw them.
The delivery shows **Class cancelled** or **Class archived**, with a note explaining that the code went back into stock.
Codes already sent are not affected.
Reopening a cancelled class puts its codes back in the send queue. See [Cancel, archive, or delete](/cohort-management/deleting-a-cohort).
## Duplicate protection
The same unique value cannot sit in stock twice (unless the old copy is burned or archived). If a student already has **released** access for a course and enrolls again, the platform reuses that access instead of handing out a second code.
## Receipts
Standalone buyers can open a **receipt** for the payment (Stripe hosted receipt). That is the payment record. It is separate from the access email.
# Send access to students
Source: https://docs.firstrespondershub.com/student-access/send-access
Use Pending deliveries to release codes, resend email, hand-enter a missing code, and fix students who are waiting
**Pending deliveries** is the list of students who should get access codes: waiting, scheduled, sent, or stuck.
## Where to find it
Go to [**Program Dashboard → Courses → Pending deliveries**](https://www.firstrespondershub.com/program-dashboard/credentials/deliveries).
* **Program owners** can release, resend, bulk release, and hand-enter.
* **Instructors** can view the list.
The Courses menu can show a badge when people are waiting on **manual** release or **Waiting for codes**.
You can also open one student: **Students** → select the student → **Access**.
## Filter tabs
| Tab | Who is in it |
| --------------------- | ----------------------------------------------------------- |
| **All** | Everyone, including taken-back / refunded rows |
| **Pending** | Held, waiting for you or for the scheduled time |
| **Scheduled** | Will send automatically when the date arrives |
| **Needs fulfillment** | You were out of stock. Import more codes. |
| **Released** | Student already has the values |
| **Failed** | Something went wrong on send (not including normal refunds) |
Refunded or withdrawn rows show as **Refunded**, **Withdrawn**, **Transferred**, or **Taken back**. They stay under **All**. They are not in the **Failed** tab.
## What each row shows
* **Student**
* **Course**
* **Seat** — for a multi-seat purchase, Seat 1, Seat 2, and so on
* **Status**
* **Timing** — a short line such as **Reserved, waiting manual release**
* **Actions** — **Release**, **Resend**, **View**
## Release (send the codes now)
Use **Release** when timing is **When staff sends it**, or when you want to send a scheduled code early.
1. Find the row (or open **View**).
2. Click **Release**.
3. The student gets the access email. The values appear in **Your Credentials**.
To send several at once, check the boxes and click **Release (N)**.
Release only works if:
* Unique codes are in stock (or already held for that student)
* Shared values are filled in (Course ID, website, and so on)
If a shared value is missing, send is blocked until you fill it in on the course or cohort.
## Resend the email
Use **Resend** when the student already has access in the dashboard but cannot find the email.
* Works for **Released** rows
* Also works if the email failed but the codes are still on the dashboard
* Does **not** work after a refund took the access back
If the email fails, the student can still copy codes from the dashboard. The row may note that email failed. Resend when their inbox is fixed.
## Hand-enter a code
Use this when one student is missing a code and you do not want to wait on a full import. Example: the vendor emailed you a replacement URL for Jordan only.
1. Open **View** on that delivery.
2. Choose **Hand-enter code**.
3. Type the unique field values.
4. Save. If the delivery was waiting, it can release right after.
Hand-entered sets are marked **Entered by hand** in inventory history.
## Out of stock (Needs fulfillment)
If a student enrolled or bought when you had no unused codes:
1. The row shows **Waiting for codes** / **Needs more codes**.
2. Your team gets an email: `[Action needed] Credential stockout: {course}`.
3. The student is told the organization will send codes when ready. They are **not** told you ran out.
4. Import more codes under **Access codes**. Waiting rows are filled automatically from the new stock.
5. After that, send follows the course timing (immediate, scheduled, or wait for **Release**).
## Open a delivery (the detail sheet)
**View** opens the full record:
* Each field and its value (owners see values; timing still hides unsent values from students)
* Whether the unique code is in stock, held, sent, or needs a check
* Email history
* Actions: Release, Resend, Hand-enter, and after a take-back, what happened to the code
## Student profile → Access
On a student record, the **Access** tab lists that person's courses:
* Status chips
* **Release access**
* **Resend access email**
Same tools as Pending deliveries, focused on one person.
## Who can do what
| Action | Program owner | Instructor |
| ----------------------- | ------------- | --------------------------------------------------------- |
| View Pending deliveries | Yes | Yes |
| Release / bulk release | Yes | No |
| Resend email | Yes | From the student Access tab, depending on your role tools |
| Import codes | Yes | No |
| Change course timing | Yes | No |
# Set up a course
Source: https://docs.firstrespondershub.com/student-access/set-up-a-course
Turn on provider access, complete the setup checklist, and write the message students see with their codes
This guide walks through turning a course into one that sends vendor access codes. Do this **before** students enroll or buy, if you can. Some settings lock after the first student has access.
## Where to go
1. Open [**Program Dashboard → Courses**](https://www.firstrespondershub.com/program-dashboard/courses).
2. Open the course.
3. Use the course sidebar:
| Section | What you do there |
| -------------------- | -------------------------------------------------------------- |
| **Course setup** | Name, delivery model, and (if you sell it) price and max seats |
| **Learning content** | Modules and lessons (only if the course includes lessons here) |
| **Student access** | Provider name, fields, timing, and the student message |
**Student access** only appears after you choose **Access from another provider** or **Both**. Only **program owners** can edit it.
## Step 1: Choose a delivery model
In **Course setup**, pick how students get this course:
* **Lessons on FirstRespondersHub** — no vendor codes
* **Access from another provider** — codes or links only
* **Both** — lessons here plus vendor access
Save. If you picked a provider option, **Student access** appears in the sidebar.
You can still edit the course after students enroll (title, lessons, price, codes, timing, and the student message).
What you **cannot** change later is the **delivery model** (Lessons / Access from another provider / Both). That locks once any of these exist:
* A student is **enrolled** in a program that includes this course
* Someone has **purchased** the course on its own
* The course already has an access-code delivery (even if it is still pending)
The picker still looks clickable. Saving a different model then fails. If you picked the wrong one, make a new course.
## Step 2: Complete Student access
Open **Student access**. The top of the page shows **Setup progress**. You want **Ready to deliver** (5 of 5).
| Checklist item | Done when |
| ------------------------------------------ | ------------------------------------------------------------------ |
| **Access fields are set up** | You have at least one field, and every field has a label |
| **Same-for-everyone values are filled in** | Shared fields (like Course ID or course website) have a value |
| **Access codes are in stock** | If any field is unique per student, you have unused codes imported |
| **Provider contact is saved** | **Provider name** is filled in (for example, Jones & Bartlett) |
| **Student message is written** | You wrote the instructions students see with their codes |
Work through the four tasks on the page.
### Provider and access details
1. Enter **Provider name**. Example: `Jones & Bartlett` or `American Heart Association`.
2. Choose **Start from a vendor preset**:
* **Jones & Bartlett (Navigate)**
* **American Heart Association**
* **Custom**
3. Review the fields. Each field is either:
* **Same for every student** (you type it once)
* **One per student** (it comes from imported codes)
You can add, rename, or reorder fields. For a full walkthrough of each preset, see [Vendor presets](/student-access/vendor-presets).
After students have already received access, field types lock. You can still edit labels and the student message. You cannot change what kind of field it is (shared vs unique).
### Codes and shared information
* For unique fields, click through to **Access codes** and [import your list](/student-access/import-and-manage-codes).
* For shared fields, type the value on this page (course website, Course ID, approval number, and so on).
If March and June need different Course IDs, set a course default here, then override it on the cohort. See [Different values per class](/student-access/different-values-per-class).
### When students receive access
Set two rules if the course is used both ways:
* **When enrolled students receive access**
* **When standalone purchasers receive access**
Options are explained in [When students get access](/student-access/when-students-get-access).
### Student message
Write the steps a student should follow after they get their codes. This text shows:
* In the student's dashboard, under **Instructions**
* In the access email, as plain text
You can use headings, lists, bold text, and links.
Click **Preview student email** to see a sample with placeholder values.
You do **not** edit the email subject or the first sentence. Those are the same for every organization. You only write the instructions block.
**Example student message (Jones & Bartlett):**
1. Go to the course website in your access details.
2. Create or sign in to your Navigate account.
3. Enter the Course ID, then enter your Access Code.
4. If you get stuck, email our office. Do not share your code with anyone else.
## Step 3: Advanced operations (optional)
Open **Advanced operations** for refund and stock settings.
### After a refund, what happens to the codes?
| Setting | When to use it |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Hold the codes until someone checks them** | Default. After a refund, the code waits in a review list. A team member confirms it was never used before putting it back in stock. Best for AHA URLs and other one-time links. |
| **Reuse the codes after you cancel access** | You can turn the student off at the vendor, then put the same code back in stock. Common for some LMS logins. |
### If the student already has their codes, can staff still refund?
| Setting | What happens |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Allow the refund, but warn first** | Staff see a yellow warning, then can continue. |
| **Stop the refund unless staff override** | Refund is blocked until someone checks **Override and refund anyway**. Use this when codes are expensive or hard to take back. |
### Stock alerts
You can email your team when you are about to run out:
* **Email when fewer than this many codes are left** — example: email when fewer than 10 unused codes remain.
* **Email when codes would run out within this many days** — example: you have 20 codes left and you have been using about 2 per day. That is about 10 days of stock. If you set this to 14, you get an email because 10 is less than 14.
See [Activity and stock alerts](/student-access/activity-and-alerts).
## After setup
1. [Import codes](/student-access/import-and-manage-codes) if you have unique fields.
2. [Assign the course to a program offering](/courses/assigning-to-offerings) and/or [turn on standalone sale](/courses/standalone-courses).
3. Watch **Pending deliveries** as students enroll or buy.
## Who can do this
Only **program owners** can change Course setup and Student access. Instructors can still view pending deliveries and a student's Access tab.
# Troubleshooting
Source: https://docs.firstrespondershub.com/student-access/troubleshooting
Fix missing codes, wrong Course IDs, failed emails, locked settings, and other common student-access problems
Start here when a student says they do not have access, or when a send button does nothing. Each item is a symptom, then the fix.
## The student has no codes
Codes are held but not sent yet.
1. Open **Pending deliveries** for that student.
2. If timing is **Reserved, waiting automatic release**, wait until the date (the sender runs about once an hour). Or click **Release** to send now.
3. If timing is **Reserved, waiting manual release**, click **Release**.
4. If it says **Waiting for codes**, you were out of stock. [Import codes](/student-access/import-and-manage-codes).
The send worked. The inbox did not.
Click **Resend**. Ask them to check spam. The subject looks like `Your access credentials for {course}`.
Access was not released, or it was taken back.
Check **Pending deliveries** and the student's **Access** tab. If the row is **Refunded** or **Taken back**, they should not have codes. If it is still pending, release or wait for the schedule.
Confirm the course delivery model is **Access from another provider** or **Both**, and that the course is assigned to that program offering (or they bought the standalone course).
Lessons-only courses never create access rows.
The course is marked as giving access, but it has **no credential fields**. We stop rather than email a blank access message.
Look for **Couldn't set up access — course has no credentials configured** in the activity log. Open the course → **Student access** and add the fields. The next automatic sweep picks the student up and sends their access.
If the invite was sent as **Must pay before enrolling**, there is no enrollment until their payment goes through — so there is nothing to hold or send. Check the **Invited** list on the class: the line under the amount says whether they have started, paid, or let the hold run out. See [Students and invites](/cohort-management/students-and-invites#reading-the-invited-list).
## You cannot send
A **same for every student** field is empty (Course ID, website, approval number, or a cohort document field).
Fill it in on **Student access** or on **Credential settings for this cohort**. June does not borrow March's Course ID.
Import unused codes for that course. Waiting students are filled automatically. Then follow the course timing (you may still need **Release** if timing is manual).
You may have mapped the wrong column, imported for a different course, or every row was a duplicate.
Open the import preview next time before you commit. Search one code from the file with **Search by exact code**.
## The student has the wrong details
Set the override on that [cohort](/student-access/different-values-per-class). Students who already received access keep what they were sent. New sends use the new Course ID. If someone already has the wrong ID, hand-enter a note in **Instructions** or contact [support](https://www.firstrespondershub.com/support).
Search the **exact** code under **Access codes**. See who it was sent to.
If this student never used it, the vendor may have consumed it another way. Hand-enter a replacement, and mark the old one **Already used**.
That should not happen for in-stock unique values. Search the code. If you pasted the same code into two hand-enters, stop and mark one burned. Import from the vendor file going forward.
## Refunds and leftover codes
The course uses **Stop the refund unless staff override**, and codes were already sent.
Confirm the student should get money back, check **Override and refund anyway**, then [verify the code](/student-access/refunds-and-unused-codes) so it is not given to the next student while still active.
If it was already sent, it is in **Needs verification**. Open it and **Mark available** or **Mark burned**.
If it was never sent, it should already be **In stock**.
Open it and click **Return to stock**.
## Settings will not change
That one setting locks after a student is enrolled in a program that includes this course, after a standalone purchase, or after any access-code delivery exists. Everything else on the course is still editable. If you picked the wrong model, create a new course.
After students have received access, unique vs shared is locked. You can still edit labels and the student message.
The delivery model is still **Lessons on FirstRespondersHub**, or you are signed in as an instructor. Only program owners see **Student access**.
That page is program owners only. Instructors use **Pending deliveries** and the student's **Access** tab.
## Email and timing oddities
Automatic send runs about once an hour. This is expected. Click **Release** if someone needs it immediately.
Standalone purchases have no class date. Use **Right after purchase** or **When staff sends it**.
If they already had released access for that course, the platform reuses it on purpose so you do not burn a second keycode.
That is normal. One digest can include every seat. In the dashboard they still show as Access code 1 of N, 2 of N, and so on.
## Quick "where do I click?" map
| I want to… | Go here |
| ------------------------------- | -------------------------------------------------------- |
| Turn on vendor access | Course → **Course setup** → delivery model |
| Add Course ID / student message | Course → **Student access** |
| Upload codes | **Courses → Access codes** |
| Send or resend | **Courses → Pending deliveries** or student → **Access** |
| Different Course ID for June | Cohort → **Credential settings for this cohort** |
| See why something happened | **Courses → Credential Activity** |
| Change refund rules | Course → **Student access** → **Advanced operations** |
If you have checked this page and it still looks wrong, contact [First Responders Hub Support](https://www.firstrespondershub.com/support) with the student name, course, and the status shown on Pending deliveries.
# Vendor presets
Source: https://docs.firstrespondershub.com/student-access/vendor-presets
Jones & Bartlett Navigate, American Heart Association Course URLs, and custom fields — with examples you can copy
A **vendor preset** is a starting set of fields. Pick one so you do not have to invent labels from scratch. You can still add or rename fields after you pick a preset.
Go to the course → **Student access** → **Start from a vendor preset**.
## Jones & Bartlett (Navigate)
Use this when students redeem a **shared Course ID** plus a **unique 10-digit access code**.
| Field | Same for everyone or unique? | What to put there |
| --------------------- | --------------------------------- | ------------------------------------------------------------------ |
| **Course website** | Same for every student | The Navigate login or course page, as a URL |
| **Course ID** | Same for every student | The class Course ID. You can override this per cohort. |
| **Access Code** | One per student | 10-digit code from your keycode bank |
| **Course Approval #** | Same for every student (optional) | State or agency number, such as a Connecticut OEMS approval number |
### Example: BLS online for a spring cohort
Shared values you type once:
* Course website: `https://www.jblearning.com/cart/Default.aspx?bc=...`
* Course ID: `BLST2026`
* Course Approval #: `CT-OEMS-1234`
Unique values you import (one per student):
```txt theme={null}
4829103756
9102847365
1029384756
```
**Student message you might write:**
1. Open the course website from your access details.
2. Sign in or create a Navigate account.
3. Enter Course ID `BLST2026`.
4. Enter your Access Code. It is 10 digits. Do not share it.
5. If Navigate says the code is already used, contact our office before you try a second code.
If June's class has a different Course ID than March, keep the course-level Course ID as a default, then set a cohort override. See [Different values per class](/student-access/different-values-per-class).
## American Heart Association
Use this when each student gets a **unique Course URL** from Training Central (a pre-authorized, usually single-use link).
| Field | Same for everyone or unique? | What to put there |
| -------------- | ---------------------------- | ---------------------------------------- |
| **Course URL** | One per student | The full eLearning link for that student |
There is no shared Course ID in this preset. The URL **is** the access.
### Example: Heartsaver First Aid CPR AED
You export unused Course URLs from Training Central and import them. Each line is one student:
```txt theme={null}
https://elearning.heart.org/course/xxxx
https://elearning.heart.org/course/yyyy
https://elearning.heart.org/course/zzzz
```
**Student message you might write:**
1. Click the Course URL in your email or dashboard.
2. Create or sign in to your AHA account if the page asks you to.
3. Complete the eLearning. Bring your certificate to skills day.
4. Do not forward this link. It is only for you. If you open it on the wrong account, tell us right away.
AHA Course URLs are often one-time links. After a refund, use **Hold the codes until someone checks them**. Confirm the student never opened the link before you give it to someone else. If they already used it, mark it **Already used**.
## Custom
Use **Custom** when the vendor is not Jones & Bartlett or AHA, or when you need extra fields (username, password, license key, Zoom link, and so on).
For each field you add:
1. Give it a clear **label** (this is what the student sees).
2. Choose **Same for every student** or **One per student**.
3. Choose whether the value is **text** or a **URL**.
Unique fields always come from **Access codes** (your imported list). Shared fields are typed on the course (or pulled from a cohort document field).
### Example: a generic LMS login
| Field | Scope | Type |
| ------------------ | ---------------------- | ---- |
| Login page | Same for every student | URL |
| Username | One per student | Text |
| Temporary password | One per student | Text |
| Class code | Same for every student | Text |
Your import file would have two columns, one for username and one for password. Each row is one student.
## Changing presets later
* Switching presets **replaces** the field list with that preset's fields. Do this only before students have access.
* Adding an extra field (for example, Course website on top of AHA) does not force the course to **Custom**. The platform still treats a matching subset as that vendor.
* After students have received access, you can edit labels and help text, but you cannot change field types.
## Which preset should I pick?
| If students need… | Pick |
| --------------------------------------- | ------------------------------- |
| Shared Course ID + unique 10-digit code | **Jones & Bartlett (Navigate)** |
| One unique Course URL each | **American Heart Association** |
| Anything else | **Custom** |
# What students receive
Source: https://docs.firstrespondershub.com/student-access/what-students-receive
Access codes, course links, and logins from another provider — and how that is different from lessons on FirstRespondersHub
A **course** on FirstRespondersHub can do two different jobs:
* Teach with **lessons** you build here (videos, text, PDFs).
* Hand out **access details** for a site you do not host, such as Jones & Bartlett or the American Heart Association.
Those access details are what this section calls **student access**. They might be a 10-digit code, a one-time Course URL, a shared Course ID, a login page, or all of those together.
## Lessons vs access from another provider
Pick a **delivery model** on the course. This tells the platform what students should get.
| Delivery model | What it means | What students see |
| --------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- |
| **Lessons on FirstRespondersHub** | You host the learning here. | Modules, lessons, and progress in their dashboard. No vendor codes. |
| **Access from another provider** | The learning lives on a vendor site. You only send codes or links. | Access details by email and under **Your Credentials**. No lesson player for this course. |
| **Both** | Students do lessons here **and** get vendor access. | Lessons plus access details. |
You set the delivery model in **Course setup**. See [Set up a course](/student-access/set-up-a-course).
### Example: lessons only
You record your own airway videos and quizzes. Students complete them inside FirstRespondersHub. You do **not** need Student access.
### Example: access from another provider
You sell AHA Heartsaver eLearning. Each student needs a unique Course URL from Training Central. You do not build lessons here. You import the URLs and the platform sends one to each student.
### Example: both (hybrid)
Your EMT class uses Jones & Bartlett Navigate for the textbook, plus your own skills videos on FirstRespondersHub. Students get:
* Navigate: course website, Course ID, and a unique access code
* FirstRespondersHub: your modules and lessons
## What one student actually receives
Think of one student's access as a **set of fields**.
Some fields are **the same for every student** in that course or class. Example: the Navigate Course ID `BLST2026`.
Some fields are **one per student**. Example: a 10-digit access code `4829103756`. Those come from the codes you import.
When the platform sends access, the student gets the full set: shared values plus their unique code or link.
The platform always holds and sends a **whole set** for one student. It does not send "just the Course ID" to one person and "just the access code" to another.
## Where the unique codes come from
Vendors usually sell you a list of unused codes or links. Common names:
* Keycode bank
* Access codes
* Pre-authorized Course URLs
* License keys
You upload that list under **Access codes**. Each row becomes one unused set, ready for the next student. See [Import and manage codes](/student-access/import-and-manage-codes).
## What this is not
Student access is **not** the same as:
* [Outcomes and certifications](/outcomes/results-and-certifications) you record after a student finishes (pass/fail, NREMT result, employment)
* [Enrollment agreements](/enrollment/agreements) students sign at checkout
* Login to FirstRespondersHub itself (students already have an account)
It is only the details they need to open the **vendor** course.
## Can a course do both enrollment and standalone sales?
Yes. You can assign the same course to a [program offering](/courses/assigning-to-offerings) **and** sell it as a [standalone course](/courses/standalone-courses).
* Enrolled students get access when they join a cohort (on the enrollment timing you set).
* Buyers get access when they purchase (on the standalone timing you set).
Those two timings can be different. See [When students get access](/student-access/when-students-get-access).
# What students see
Source: https://docs.firstrespondershub.com/student-access/what-students-see
Where students find their codes, what emails they get, and what Pending means before codes are sent
Students never see your unused stock. They only see **their** access details, and only after those details are sent.
## Where students look
| Place | What they see |
| -------------------------------------- | -------------------------------------------------------- |
| **Student dashboard → Home** | A **Your Credentials** section |
| The **course page** in their dashboard | The same details, next to that course |
| After enrollment or purchase | A short summary and a link to continue to the portal |
| **Email** | Subject like `Your access credentials for {course name}` |
If they bought more than one seat, they see **Access code 1 of 3**, **Access code 2 of 3**, and so on. See [Buying more than one seat](/student-access/buying-more-than-one-seat).
## Before codes are sent
The card shows **Pending** (clock icon). Values are hidden.
They may see:
* `Credentials expected {date}.` when you scheduled a send
* A note that the organization will send codes when ready, if you use manual release or you were out of stock
They can still complete other onboarding. They should not email you in a panic unless the expected date has passed. If they do, check [Pending deliveries](/student-access/send-access).
## After codes are sent
The card shows **Released** (or **Partially released** if only some seats in a multi-seat purchase have gone out).
Students can:
* Read each field (Course ID, Access Code, Course URL, and so on)
* **Copy** a value, or **Copy all**
* Click URL fields to open them in a new tab
* Read your **Instructions** (the student message you wrote)
## Emails students receive
### 1. Enrollment or purchase confirmation
This is the normal "you're in" email. If the course uses vendor access, the confirmation includes a short note instead of "you have access to lessons right now."
Examples of that note:
* Access codes will be sent by email and appear in your dashboard shortly.
* Access codes will release on March 8, 2026.
* The organization will send your access codes when ready — watch your email and student dashboard.
### 2. The access email (the important one)
Sent when codes are actually released (and again if you click **Resend**).
Typical subject:
* One seat: **Your access credentials for BLS Online**
* Several seats: **Your 3 access codes for BLS Online**
* One seat inside a batch: **Your access credentials for BLS Online (code 2 of 5)**
The email includes:
* A **Your Credentials Are Ready** heading
* **Credential Details** (labels + values; links are clickable)
* **Instructions** from your student message
* Your organization contact footer
You cannot change the subject line or the first sentence. You only write the **Instructions** block on the course.
### 3. They do **not** get
* Your stockout or low-stock admin emails
* Other students' codes
* Codes that are still **Pending**
## If they say they never got the email
1. Ask them to open the student dashboard → **Your Credentials**. If the values are there, the send worked. Have them check spam for the email, or click **Resend** from their Access tab.
2. If the dashboard still says **Pending**, look at timing. It may not be due yet.
3. If the row says **Waiting for codes**, import stock.
4. If the row says **Reserved, waiting manual release**, click **Release**.
## After a refund or withdrawal
They lose access in the dashboard. The staff row shows **Refunded**, **Withdrawn**, **Transferred**, or **Taken back**. They should not keep using the vendor site if you also turned them off there. See [Refunds and unused codes](/student-access/refunds-and-unused-codes).
# When students get access
Source: https://docs.firstrespondershub.com/student-access/when-students-get-access
Send codes right after enrollment or purchase, a few days before class, or only when a team member clicks Release
Holding a code and **sending** a code are two different moments.
* **Hold** happens as soon as a student enrolls or a purchase is confirmed. That unused code is no longer available for someone else.
* **Send** happens when the student can actually see the values (email + dashboard).
**Both moments need a real enrollment.** If you invited the student with **Must pay before enrolling**, they are not enrolled until their payment goes through, so nothing is held and nothing is sent before then. Use that choice on any class where a code would otherwise go out to someone who has not paid. See [Students and invites](/cohort-management/students-and-invites).
You control **send** on the course under **Student access** → **When students receive access**.
## Two paths, two rules
A course can be used in a program **and** sold on its own. Set timing for each:
| Path | Setting name | Typical use |
| ---------------------------------- | --------------------------------------------- | ------------------------------------- |
| Student enrolls in a cohort | **When enrolled students receive access** | EMT class with a start date |
| Student buys the course on its own | **When standalone purchasers receive access** | A department buying Heartsaver online |
They do not have to match. Example: enrolled students get codes **7 days before class**. Standalone buyers get codes **right after purchase**.
## Options for enrolled students
| Option | What happens |
| -------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Right after enrollment** | Send as soon as the student is enrolled (if codes and shared values are ready). |
| **Before class starts** | Send on a date based on the cohort start date. You choose **Days before class starts**. |
| **When staff sends it** | The code stays hidden until someone clicks **Release** on [Pending deliveries](/student-access/send-access). |
### Before class starts, with an example
You set **7** days before class.
* Cohort start date: March 15
* Jordan enrolls on February 1
* Jordan's code is **held** on February 1
* Jordan's code is **sent** on March 8 (7 days before March 15)
If Jordan enrolls **late**, they still do not wait extra. The send time is the later of:
* When they enrolled
* Cohort start minus your number of days
So if Jordan enrolls on March 10, and class starts March 15 with a 7-day rule, they get access at enrollment (March 10), not on March 8 in the past.
The platform checks once an hour for codes that are due to send. A student might get the email a little after the exact minute of the scheduled time, not at 12:00:00 a.m. sharp.
## Options for standalone purchasers
| Option | What happens |
| ------------------------ | ------------------------------------------------------- |
| **Right after purchase** | Send as soon as payment (or a free claim) is confirmed. |
| **When staff sends it** | Hold until a team member clicks **Release**. |
Standalone purchases have **no class start date**, so **Before class starts** is not offered there.
## What students are told in the meantime
They never see the actual code until it is sent. They **do** see a clear status:
| Your timing | What they are told |
| ---------------------------------- | ------------------------------------------------------------------------------------------ |
| Right after enrollment or purchase | Access codes will be sent by email and appear in the dashboard shortly. |
| Before class starts | Access codes will release on `{date}` (or "before class"). |
| When staff sends it | The organization will send access codes when ready. Watch email and the dashboard. |
| You were out of stock | Same as staff-sends-it. They are not told you ran out. You get the stockout email instead. |
Exact student wording is in [What students see](/student-access/what-students-see).
## The course has to be set up first
A course can be marked as giving access codes and still have **no credential fields set up**. When that happens we now stop, instead of emailing the student a blank access email.
* Nothing is reserved and nothing is sent.
* The activity log shows **Couldn't set up access — course has no credentials configured**, or **Couldn't send — no credentials to send**.
* The student keeps their entitlement. Finish setting the course up under **Student access**, and the next automatic sweep fulfills and sends it normally.
See [Set up a course](/student-access/set-up-a-course).
## What you see as staff
On [Pending deliveries](/student-access/send-access) the timing line will look like:
* **Reserved, waiting automatic release** — scheduled, not due yet
* **Reserved, waiting manual release** — you must click **Release**
* **Waiting for codes** — you were out of stock when they enrolled or bought
* **Released** — already sent
On a student's enrollment or purchase you may also see a **Credential access** note with the same idea.
## Cohort-level timing
For the **enrollment** path, a cohort can override the course rule (for example, this one class should wait for staff even if the course is "7 days before"). Shared values like Course ID can also differ per class. See [Different values per class](/student-access/different-values-per-class).
## Which option should I pick?
| Situation | Suggested timing |
| ------------------------------------------------------------ | ------------------------------------------------------ |
| AHA link the student can start today | **Right after enrollment** or **Right after purchase** |
| Navigate access that should not open until the week of class | **Before class starts**, 3–7 days |
| You need to confirm payment, paperwork, or roster first | **When staff sends it** |
| Mix of "start now" buyers and a dated EMT cohort | Immediate for standalone, before class for enrollment |
Changing timing on the course does not rewrite history for codes already sent. It applies to new enrollments and purchases, and to deliveries that are still waiting.
## When you change the timing or move the class
Every scheduled send has a date stamped on it the moment the code is held. So two things have to update that date for students who are already in the queue. Both happen automatically.
### You change the course timing rule
Say you move a course from "7 days before class" to "14 days before class."
Every delivery that has **not gone out yet** is re-dated. When you save, a message tells you how many moved — for example, *Rescheduled 34 deliveries.*
Classes with their own timing override are left alone. Their rule still wins.
### You move a class start date
Say your March 15 class slips to March 22.
Deliveries timed **relative to the class start** move with it. Codes already sent do not change. The class page tells you how many moved.
If the re-dating fails, you get an error message. The date change itself still saved — only the send dates need another look. Check [Pending deliveries](/student-access/send-access).
## When a class is cancelled
Cancelling a class **voids every code that has not been sent yet**, so students are not emailed access for a class that was called off. Those codes go back into your stock for other classes.
Codes that already went out are not touched. Students keep them.
Reopening the class puts those codes back in the send queue with the right dates.
While a class is cancelled, its schedule is locked. That is deliberate: moving dates while codes are on hold could email students access for a class that has not started. See [Cancel, archive, or delete](/cohort-management/deleting-a-cohort).
## Sponsored students
When a sponsor pays for a student and that student claims their seat, a code is held for them at that moment, the same as any other enrollment. See [Sponsored payments](/payment-settings/sponsored-payments).
# Overview
Source: https://docs.firstrespondershub.com/teaching-topics-and-instructor-hours/index
Track what's taught, who teaches it, and run instructor hours reports for CME and recertification
This guide explains how to track what is taught in your sessions, who teaches it, and how to run reports on instructor hours for CME credit, recertification, or internal records. Everything is organized around **Teaching Topics**, **Cohorts**, **Session Segments**, and the **Instructor Hours** report.
## What's in this section
| Guide | What it covers |
| -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| [Teaching Topics](/teaching-topics-and-instructor-hours/teaching-topics) | Your organization's list of subject areas: create, edit, reorder, deactivate, and why they matter |
| [Session segments (Manage Teaching)](/teaching-topics-and-instructor-hours/session-segments) | Recording what was taught in each session: topics, duration, instructors, co-teaching, notes, and history |
| [Instructor Hours report](/teaching-topics-and-instructor-hours/instructor-hours-report) | Running and exporting the report by cohort, instructor, topic, and date for CME and recertification |
## Where to find things in the app
* **Teaching Topics:** [Program Dashboard → Settings → Teaching Topics](https://www.firstrespondershub.com/program-dashboard/settings/teaching-topics). Only **program owners** can access this page.
* **Instructor Hours:** [Program Dashboard → Instructor Hours](https://www.firstrespondershub.com/program-dashboard/instructor-hours). Program owners and instructors can view and run the report.
* **Session teaching (segments):** [Program Dashboard → Cohorts](https://www.firstrespondershub.com/program-dashboard/cohorts) → open a cohort → **Schedule** tab → **Manage Session** on a session → **Teaching** tab.
## Who can access what
* **Program owner:** Can manage Teaching Topics (create, edit, reorder, deactivate). Can record session segments and run the Instructor Hours report.
* **Instructor:** Can record session segments and run the Instructor Hours report. Cannot access Settings → Teaching Topics.
## Quick Reference: How It Fits Together
1. **Set up Teaching Topics** — In Settings → Teaching Topics, create the subject areas your organization uses (e.g. Airway, Trauma, Cardiac).
2. **Build cohorts and sessions** — Create your cohorts and their session schedule as usual.
3. **Record what was taught** — For each session, open Manage Session → Teaching tab. Add segments (topic + duration + instructors) so they add up to the session length.
4. **Run and export the report** — Go to Instructor Hours, set filters if needed, click Generate Report, and use Export CSV when you need a file for CME or recertification.
# Instructor Hours Report
Source: https://docs.firstrespondershub.com/teaching-topics-and-instructor-hours/instructor-hours-report
Run and export teaching hours by instructor and topic for CME, recertification, or internal records
The Instructor Hours report shows teaching hours credited to each instructor, broken down by [teaching topic](/teaching-topics-and-instructor-hours/teaching-topics). You can filter by cohort, instructor, topic, and date range, then export to CSV for CME submissions, recertification, or your own records.
## Where to find it
In the Program Dashboard, go to **Instructor Hours** (in the Operations section of the sidebar).
[**Program Dashboard → Instructor Hours**](https://www.firstrespondershub.com/program-dashboard/instructor-hours)
Program owners and instructors can view and run the report.
## What it shows
A report of teaching hours credited to each instructor, broken down by teaching topic. You see totals per instructor and per topic, and you can expand the view to see which sessions contributed (session title, date, hours, cohort, and program).
## Filters
You can narrow the report by:
* **Cohort** — one cohort or all.
* **Instructor** — one instructor or all.
* **Teaching topic** — one topic or all.
* **Start date** and **End date** — only sessions that start in this date range are included.
Choose your filters and click **Generate Report** to run it. Cancelled sessions are never included.
## How hours are calculated
Hours come from the [session segments](/teaching-topics-and-instructor-hours/session-segments) you set up in Manage Teaching. For each segment, every instructor assigned to that segment is credited with the full duration of that segment. So co-teaching a 4-hour segment gives each of those instructors 4 hours in the report.
## Export
Use **Export CSV** to download the report for CME submissions, recertification, or your own records.
# Session Segments (Manage Teaching)
Source: https://docs.firstrespondershub.com/teaching-topics-and-instructor-hours/session-segments
Record what was taught in each session: topics, duration, instructors, and co-teaching
Session segments let you record what was actually taught in a session—which topics, for how long, and by whom. You manage them in the **Teaching** tab after opening **Manage Session** for a session.
## Cohorts and sessions: where to start
**Cohorts** are your specific classes or program runs—for example "EMT Basic Fall 2024". Each cohort has a **schedule** of sessions.
**Sessions** are the individual class meetings: each has a date, time, location, and type (e.g. Lecture, Skills Lab).
To manage teaching for a session: go to [**Program Dashboard → Cohorts**](https://www.firstrespondershub.com/program-dashboard/cohorts), open the cohort you want, then open the **Schedule** tab. On the session you want to work with, click **Manage Session**, then open the **Teaching** tab.
## What a segment is
A session can be split into one or more **segments**. Each segment represents a block of time in that session and has:
* **Teaching topic** — chosen from your organization's [Teaching Topics](/teaching-topics-and-instructor-hours/teaching-topics) list.
* **Duration** — how long that topic was taught (e.g. 4 hours).
* **Instructors** — who taught that segment. You can assign more than one instructor to a segment (co-teaching).
## How to use it
* Add or remove segments so the session is broken into the blocks that match what actually happened in class.
* For each segment, choose a **topic** and **duration**. The segment durations should add up to the total session length.
* Assign **instructors** to each segment. The system will treat the instructor with the most teaching time in that session as the primary instructor.
* You can add optional **notes** per segment and an optional **change reason** when you save. The change reason and **History** tab help you keep an audit trail of who changed what and when.
* To see past changes, use the **History** tab in the same Manage Session panel.
## Co-teaching
If you assign multiple instructors to one segment, each of them receives full credit for that segment's duration in the [Instructor Hours report](/teaching-topics-and-instructor-hours/instructor-hours-report) (e.g. a 4-hour segment with two instructors gives each instructor 4 hours).
# Teaching Topics
Source: https://docs.firstrespondershub.com/teaching-topics-and-instructor-hours/teaching-topics
Create and manage your organization's list of subject areas for session segments and reporting
Teaching topics are your organization's list of subject areas you use when recording what was taught in a session—for example "Airway Management", "Trauma", or "Cardiac Care". This list is shared across all your programs and cohorts.
## Where to find them
In the Program Dashboard, go to **Settings** → **Teaching Topics**.
[**Program Dashboard → Settings → Teaching Topics**](https://www.firstrespondershub.com/program-dashboard/settings/teaching-topics)
Only **program owners** can access this page. Instructors can use the list when recording session segments but cannot create, edit, or reorder topics.
## What you can do
* **Create** a topic: give it a clear name and, if you like, a short description.
* **Edit** a topic: change its name or description.
* **Reorder** topics: use the up/down arrows so the list appears in the order you prefer when assigning topics to sessions.
* **Deactivate** a topic: move it to the inactive section so it no longer appears when you add new session segments. Past sessions that used this topic are unchanged.
* **Reactivate** a topic: move it back from the inactive section so you can use it again for new segments.
## Why they matter
Teaching topics are the only options you can assign to session segments. They also drive how the [Instructor Hours report](/teaching-topics-and-instructor-hours/instructor-hours-report) is broken down by topic, so setting them up well makes reporting and CME tracking straightforward.