A learner cannot open a mini-course: check the boundary before resending

Ask what happened before asking the learner to retry

“It does not work” can mean the learner cannot find the destination, sees an access refusal, has no code, or enters a code without reaching the lesson. Capture the stage and visible message, not the secret. Never ask a learner to send you their password or a verification code.

Begin with the intended course and its publication state. If an administrator has taken the course offline or kept it in draft, another email will not repair it. Check whether the failure affects one learner or the intended group, and whether the direct route and an embedded route behave differently.

Check the collection and the invited identity

The invitation-only documentation limits access to selected learner groups and applies the boundary at collection level. It describes name, username and email fields for CSV imports, with username matching the learner email. A typo or an invitation sent to a different work alias is therefore worth checking before changing access rules.

Ask the administrator to compare the learner’s intended address with the approved group entry. Share only the minimum details needed to identify a mismatch. Do not add an unknown address just because someone can quote a course title. If the learner is not authorized, route the request to the owner who can make that decision.

Treat a new-browser prompt differently from a missing invitation

Email-verification documentation explains that a new device or cleared browser cookies can require verification again. That prompt is not by itself proof that the account disappeared. Check which address the learner entered and whether it is the intended identity; then inspect normal inbox filtering or delivery with the authorized mail administrator.

An email gate is also not the same as a selected-group gate. Verifying possession of an address does not automatically mean the person belongs to your intended employee group. Keep the mode aligned with the material. Do not switch a restricted collection to open access to make a support ticket go away.

Use a compact support note without exposing secrets

• Course or collection name and its ordinary share destination; omit tokenized access URLs.
• Expected access mode and whether the learner is in the authorized group.
• Visible failure stage: no destination, refusal, no email, rejected verification, or lesson display.
• Browser/device and whether this is a first visit or a return after clearing local data.
• Time and the exact non-sensitive message; do not attach learner answers or entire inbox screenshots.
• Checks already performed, so the next person does not repeat the same invitation or change the wrong collection.

For example: “Approved learner receives an access refusal on the collection link in a new browser. Administrator confirmed that the intended work address differs from the imported username. No code was requested again.” That points to an identity mismatch rather than an unexplained platform outage.

Stop at the right owner

If the identity and configuration are correct but mail still does not arrive, preserve the evidence and escalate through the merchant’s normal support route. Avoid repeated rapid resend attempts. If the system asks for an action the learner must perform, explain that single step and preserve the existing screen. Do not bypass a security challenge or borrow another learner’s session.

When access is restored, verify only the authorized lesson path. Access success does not establish course completion or competence, and it should not expose other restricted collections.