Before the meeting
This is a meeting workflow for organizers and participants, not a server-installation guide. The controls and rules below were checked against Jitsi Meet 11248 source on 26 October 2026. Private deployments, newer clients and mobile layouts can differ. No live group-assignment test was performed. [S2][S3]
Join the correct meeting and confirm that you have the intended moderator role. A server’s authentication policy determines who receives that role; do not assume the first person to arrive always becomes the organizer. Use the login and moderator guide if the role is unclear.
For a first rehearsal, use a disposable meeting with consenting participants. Decide how many groups you need, give them recognizable names and agree how people should return. Test the browser or app your attendees will actually use. [S1][S2]
Create and name the groups
- Open the meeting’s participants interface and look for Add breakout room. The reviewed visibility check requires local moderator status, server support and a configuration that does not hide this control. [S2]
- Add the rooms you need. The English default name is Breakout room followed by its number. [S3]
- Use the room’s available Rename action to set a useful label, such as the activity or group number. The rename control has its own visibility rules, so check the actual client if it is absent. [S3]
- Confirm that every intended room appears before assigning people. A named breakout room is a separate destination within the meeting workflow, not a separately scheduled calendar event. [S1][S2]
Assign participants or let them join
For a specific assignment, open the participant’s available room action, choose Send participant to: and select the destination. The reviewed room-participant menu is restricted to a moderator. Check the destination’s participant list and ask the attendee to confirm their room. [S2][S3]
For automatic groups, use Auto assign to breakout rooms when available. In the reviewed source it is shown in the main room to a moderator when breakout rooms exist, there are more than two participants and the control is not hidden. The action shuffles remote participant IDs and distributes them among the existing breakout rooms; it does not include the local organizer. Do not assume a manual seating plan will survive running auto-assignment again. [S2]
Participants can use an available room Join action to move themselves. A deployment can hide that action, so do not promise free room selection on every server. Ask the organizer if you cannot find your destination. [S3][S4]
Return, close and remove
| What you want | Relevant action | Verify afterward |
|---|---|---|
| Leave your group and return | Leave breakout room requests a move to the main room. [S3] | Check the displayed room and who is present |
| Bring a group’s participants back | A moderator’s Close action requests moves to the main room. [S1][S2] | Confirm each attendee returned before starting the next activity |
| Delete an unused room entry | The reviewed menu shows Remove for an empty non-main room. [S3] | Check that the unused entry disappears |
Leaving a breakout room is different from leaving the whole meeting. Closing a populated room and removing an empty one also have different purposes. If someone is still moving or reconnecting, wait for their actual membership to settle before treating the activity as finished. [S1][S2][S3]
Missing buttons or failed moves
- No Add control: check role, server support and visibility configuration first. Reinstalling an attendee’s browser does not establish any of those conditions. [S2]
- No Auto assign: return to the main room, create breakout rooms and check participant count and moderator status. The reviewed visibility conditions above are more specific than simply having the feature enabled. [S2]
- No Join action: the deployment may hide it. An operator should inspect
breakoutRooms.hideJoinRoomButtonin the configuration actually delivered to the client. Hiding a button is not, by itself, proof of a server-enforced access policy. [S4] - A move was requested but the attendee stayed put: record the exact client/server version, destination and sanitized error. Check whether the attendee disconnected or is still joining; do not repeatedly reassign everyone as the first diagnostic step. [S2]
- Keyboard or screen-reader controls are unusable: see web keyboard controls and native breakout accessibility. Test those separately from room membership.
For Docker and Debian/Ubuntu operators, this article establishes no new installation command or permission workaround. Inspect the deployed client and matching server configuration before changing access settings. The large-meeting guide covers a different problem: visitors and audience infrastructure.
Rehearsal checklist and sources
Rehearse create, rename, one manual move, automatic grouping if needed, an attendee joining, returning to the main room, closing a populated room and removing an empty one. Include a non-moderator so you can verify that organizer-only actions remain restricted. Check microphone/video reception after moves, not just the room list. These are recommended acceptance checks, not completed tests from this site.
- [S1] Official breakout-room API commands, checked 26 October 2026. Used to confirm action meanings and moderator requirements, not to claim a browser UI test.
- [S2] Meet 11248 immutable source: actions and visibility checks.
- [S3] Same release: room menu, participant destinations, return button and English labels.
- [S4] Official breakout configuration, checked 26 October; release-pinned room list. Recheck controls when upgrading. No server, device or meeting test claimed.