Manage class videos and video meetings

This is different from publishing a reusable video:

Current integration boundary: Class meetings depend on a separately configured Jitsi service. The current staff and Online Client pages can obtain their meeting settings from different sources, and the staff host does not currently apply the generated room password to the provider. Have the deployment owner or support align and test both sides. Do not rely on the password option as the meeting's only access control until provider enforcement has been verified.

#Before you enable class meetings

Agree on the studio's operating and privacy rules before staff can start meetings:

• Choose an approved meeting service and trusted domain. Decide who owns its availability, security updates, moderation settings, and incident response.
• Decide which roles may host. A staff member who can teach a class is not necessarily authorized to update it or start its DSM meeting. Never share an administrator's login to work around a missing action.
• Define camera, microphone, waiting-room or lobby, display-name, participant-removal, chat, screen-sharing, and guest-access rules in the meeting service.
• Obtain any consent required for remote instruction, especially when children may appear or speak. Explain the external service and its privacy terms to clients.
• Treat recording as a separate, explicitly approved process. DSM does not automatically record a class meeting or add it to the client video library.
• Prepare a support path for a meeting that will not open or will not disappear from the client list. Do not improvise by exposing private room details or using an undocumented URL.
• Use a fictional class, fictional family, muted microphone, disabled camera, and two isolated browser profiles for training and verification.

#Check staff and client readiness

The host page and client page must both be ready. Success on one side is not proof that the other side is configured.

The staff-side integration is deployment configuration, while the Online Client also uses studio settings such as whether meetings are enabled, the domain, custom title, token, and password option. Ask the deployment owner or support to compare the effective values. Do not put raw environment values, tokens, passwords, or private room names in a support ticket, screenshot, or training video.

If the Video tab is absent or the page says Jitsi is not configured, stop. Configuration is not available from this class page. Have the deployment owner or support complete and test it.

#Prepare today's class occurrence

The current staff selector is limited to schedules dated today according to the server's date and time zone.

1. Open the class's Schedules tab first.
2. Confirm the exact date, start and end time, location, and instructor for the intended occurrence.
3. Confirm that the class and occurrence are active and not cancelled.
4. Review Students and confirm the exact fictional or real roster that should qualify for this schedule.
5. Confirm that the intended Online Client account is active and that the qualifying student is the signed-in member or an active direct child on the account.
6. Correct schedule or enrollment problems through their normal workflows before opening the meeting.

Important: A cancelled or inactive occurrence can still appear in the current Today's Schedule selector. Its presence is not approval to start it. Verify the occurrence independently before selecting Start.

Starting a meeting does not send an email, text message, push notification, or Online Client message. Communicate the date, time, client navigation, device requirements, privacy expectations, and fallback plan through the studio's approved messaging process.

#Start the meeting

Use one meeting at a time and keep the host page open until the controlled end-and-verify process is complete.

1. Open Group Classes and select the intended class.
2. Select Video.
3. Under Today's Schedule, select the exact occurrence you verified.
4. Recheck its date, start time, end time, and instructor.
5. Make sure the microphone is muted and the camera is off before a test.
6. Select Start once.
7. Wait for the embedded meeting service to load.
8. Confirm the class meeting subject and the provider's pre-join or meeting controls without exposing the room name, token, or password.
9. In a separate browser profile, sign in as the fictional eligible client and select Update List.
10. Confirm that exactly one intended meeting is shown before admitting or inviting real participants.

The server creates or reopens the DSM meeting record before the provider frame is initialized. If Start produces an empty area or the meeting service fails, a client-visible record may still have been opened. Do not press Start repeatedly or select another schedule. Follow the recovery steps under Troubleshooting and verify the client result.

Starting the same schedule again can reopen its existing DSM meeting record and reuse its saved room details. It is not a clean new session or a reliable way to repair a failed launch. Starting a different occurrence does not automatically close the first meeting.

#What clients see and can do

An eligible client opens Video Meeting, or the studio's custom meeting label, and selects Update List to retrieve the latest meetings. The list does not update through a real-time notification.

A meeting can qualify through the signed-in active member or an active direct child assigned to its schedule. The current list also applies schedule-status and time-window rules. In general, it considers eligible schedules dated yesterday or later whose scheduled end is no more than six hours ahead. A meeting that exists on the staff side can therefore remain absent for a client whose account, family link, schedule assignment, status, or timing does not qualify.

The list does not identify which family member made the account eligible. If two family members qualify for the same occurrence, or duplicate meeting records exist, the same meeting can appear more than once. Do not infer that a duplicate card represents two separate classes.

To join, the client:

1. Selects Update List.
2. Confirms the subject and start time.
3. Selects Join Meeting.
4. Reviews the display name, camera, microphone, speaker, and browser permissions.
5. Joins only the expected room and follows the studio's participation rules.
6. Uses the meeting service's leave control when finished.
7. Selects Close Meeting to dispose of the embedded meeting view in that browser.

Close Meeting is local to that client browser. It does not end the room for the host or other participants, and it does not close the server's meeting record. The card can return as soon as the client updates the list.

#End the hosted meeting and verify closure

The current class Video page does not provide a separate visible staff Close Meeting button or a reliable closed-status confirmation. The staff page attempts to close the DSM record when the embedded provider signals that the hosted meeting is ready to close, but errors are not shown to the host.

1. Tell participants that the session is ending and allow them to leave.
2. Use the meeting provider's approved host end or leave workflow until the embedded room closes.
3. Keep the DSM class page available; do not assume that closing or refreshing the browser tab ended the server record.
4. In the separate fictional client profile, return to the meeting list and select Update List.
5. Confirm that the intended meeting no longer appears.
6. Confirm that no duplicate card or unintended second schedule remains active.
7. Record the class, schedule, host, start time, end time, and verification result in the studio's approved operational log when required.

If the meeting remains listed, do not restart it and do not try a hidden close URL. Capture the exact class and schedule identifiers, the time, the two account roles used, and the visible result without including credentials. Ask support to inspect and close the stale record through an authorized process.

#Know what each action affects

#Confirm the workflow is ready

Before announcing class meetings to clients, complete one controlled end-to-end test and retain the approved result:

• The intended current-day occurrence is active and appears once in the staff selector.
• An authorized fictional host can select Start, and the approved provider frame loads.
• An eligible fictional client sees exactly one meeting after Update List.
• An unrelated fictional client does not receive access.
• The eligible client can join with the correct display name and with camera and microphone initially off.
• Client Close Meeting is understood and documented as a local action only.
• The host completes the provider's approved close flow.
• The meeting disappears after the fictional client selects Update List.
• No real person, private conversation, token, password, room identifier, or unapproved provider screen appears in the evidence.
• A support owner and recovery path are documented for failed starts and stale meetings.

Do not treat the feature as production-ready when only the host frame loads. The client visibility, join, local close, host close, and final absence checks are all part of the test.

#Troubleshooting

#The class Video tab is missing

Confirm that you opened a group class and that your role has the intended Group Classes access. The tab can also be hidden when the deployment's meeting domain is unavailable. Ask an administrator or support to check role and integration readiness; do not use another person's login or a copied direct URL.

#The page says Jitsi is not configured

The staff-side meeting service has no effective domain. Configuration is outside this class page. Give the deployment owner or support the studio, class, time, and exact warning, but do not send environment files or credentials.

#Today's Schedule is empty or the expected occurrence is missing

Check the occurrence date in Schedules and compare the studio's expected time zone with the server date. Confirm that it belongs to this class. A future or prior-day occurrence cannot be selected from this staff page even if a client-facing time window would otherwise overlap it.

#A cancelled or inactive occurrence appears in the selector

Do not start it. The current selector does not reliably exclude every cancelled or inactive record. Verify status on the class and schedule pages, correct the source record through the approved workflow, and then reload.

#Start is missing or the server says the action is unauthorized

The account may be able to view or teach the class without having class-update authority. Ask an administrator to review the intended role. Do not elevate the role broadly or share credentials merely to start a meeting.

#Start was selected, but no meeting frame appeared

Wait once for scripts to load, then check the approved provider's availability, browser content blocking, and network policy. Use the fictional client profile to select Update List because an active DSM record may already exist. Do not press Start repeatedly. Record the visible error and time, then contact support if the record must be closed or provider initialization continues to fail.

#The Online Client menu item is missing

Confirm that meetings are enabled for the studio and that the custom label was not mistaken for another menu item. The client settings and host settings can differ. Ask support to compare the effective domain and feature flag without exposing the token or password.

#The client sees no meeting after Update List

Confirm the correct studio and primary account, an active signed-in member or active direct child, the exact schedule assignment, accepted member-schedule status, and the occurrence timing. Then confirm that the host started the same class and schedule. Starting a room does not enroll the student or bypass eligibility rules.

#The client sees the meeting twice

Do not join both cards or start another room. More than one eligible family assignment or duplicate active meeting records can produce duplicate cards. Record the subject, schedule, time, and account used, then ask support to inspect the data. Do not delete family assignments merely to hide the symptom.

#Join Meeting does nothing

The external script may not be ready even though the button is visible. Reload once, allow approved embedded content, and check browser extensions or network filtering. If it still fails, record the browser, time, and visible page state. Do not copy a room name or token into a public meeting site.

#The camera or microphone is unavailable

Check browser permissions for both the DSM site and approved meeting domain. Close other applications using the device, choose the intended camera and microphone, and rejoin. Begin muted and with the camera off. Never test another person's device or account without permission.

#A password is displayed, rejected, or never requested

Stop and use the studio's approved fallback. Although the client can display and submit a configured password, the current staff host does not apply the generated password to the provider. Treat password enforcement as unverified and ask the deployment owner or support to test it. Do not publish or repeatedly share the displayed value.

#The client selected Close Meeting, but the card returned

This is expected while the server record remains active. Close Meeting only closes that client's embedded view. The host must complete the approved provider close workflow, and the client must select Update List to verify the result.

#The host left, but clients still see the meeting

Closing a tab, refreshing, losing the connection, or silently failing the close request can leave a stale record. Do not restart the room or use an undocumented endpoint. Preserve the class, schedule, host, start and attempted-end times, and fictional client result, then contact support for an authorized close and root-cause review.

#Protect privacy and meeting access

• Use only the approved meeting domain. A room that looks similar on another domain is not the same trusted service.
• Never expose the integration token, JWT, room name, room password, environment setting, private join URL, or browser developer tools in client instructions or media.
• Treat any password shown in the client browser as private but not, by itself, proof that the provider enforced access.
• Use waiting-room, moderation, participant-removal, and guest controls in the approved provider when available and tested.
• Verify the signed-in display name before joining. Do not put diagnoses, financial information, safeguarding details, or other sensitive data in the room subject or chat.
• Keep cameras off and microphones muted until participants are ready. Use neutral backgrounds and prevent private household information from appearing.
• Do not record, transcribe, stream, or capture participants without the required notice, consent, retention plan, and access controls.
• Use fictional adults and students for screenshots, videos, rehearsals, and support reproduction. Never use a live children's class as a documentation fixture.
• Remember that ending the interactive meeting does not recall participant screenshots, chats, external recordings, or files already shared.

#Related articles

• Group Classes
• Manage class schedules
• Manage student enrollment
• Attendance and rosters
• Videos and on-demand content
• Prepare the Online Client for launch
• Change Global and Online Client settings
• Roles and permissions
• Choose message recipients and send
• Use messages, videos, meetings, and files