Skip to main content
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.
You control send on the course under Student accessWhen students receive access.

Two paths, two rules

A course can be used in a program and sold on its own. Set timing for each: 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

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

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: Exact student wording is in 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.

What you see as staff

On Pending deliveries 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.

Which option should I pick?

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.

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. 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.