> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kralis.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Classroom Access and Roles

> How school scoping, audiences, grants, roles, waiting rooms, and capacity work.

Classroom does not use public meeting links as authorization. A user must be signed in to Kralis, active, attached to the same school, able to view the event, and admitted when the waiting room is enabled.

## Access sources

A user can receive event access from more than one source:

* creating the event
* being a school administrator or dean
* a direct event grant
* membership of a granted Classroom collaboration group
* matching the event’s class and optional section audience
* the event’s school-wide audience

Kralis evaluates all sources and uses the strongest role. A weaker direct grant does not override a stronger group grant.

## Event roles

| Role | Purpose | Media defaults | Management authority |
| - | - | - | - |
| Host | Event owner and lead operator | Camera, microphone, and screen share | Full event and participant management |
| Moderator | Co-manages the event | Camera, microphone, and screen share | Event and lower-role participant management |
| Presenter | Teaches or presents | Camera, microphone, and screen share | Presentation controls, not event management |
| Participant | Ordinary attendee | Inherits event media settings | Own media, chat, and raise hand where enabled |
| Observer | Listen/watch-only attendee | Cannot publish media | No management authority |

The creator’s host grant cannot be revoked. School superusers, staff, administrators, and deans can manage school events as moderators.

A manager cannot mute, remove, or change media permissions for themselves, a host, or anyone with an equal or stronger event role.

## What can I do?

Kralis school roles and Classroom event roles are related but not identical. A student account can be a Classroom Participant, while a teacher can be assigned Presenter, Moderator, or Host for a particular event.

| User or event role | Discover and join permitted events | Use own media, chat, and raise hand | Present | Moderate participants | Manage event, access, and history |
| - | - | - | - | - | - |
| Student account | Yes; never sees drafts | Yes, according to assigned event role and settings | Only when granted a suitable event role | No | No; can view only personal attendance and published content |
| Participant | Yes | Yes, according to event settings | Screen sharing only when permitted | No | No |
| Presenter | Yes | Yes | Yes, including screen and whiteboard presentation | No | No |
| Moderator | Yes | Yes | Yes | Yes, below their role | Yes, subject to protected host actions |
| Host | Yes | Yes | Yes | Yes | Full event management; creator host access is protected |
| School administrator or dean | Yes within their school | Yes | Yes | Manages school events as a moderator | Can create and manage school events, settings, issues, and authorized history |

Observer is an additional event role for listen-and-watch access without publishing media or management authority.

## Direct and group grants

Event managers can grant one role to:

* an individual school user; or
* a Classroom collaboration group.

Changing access or group membership during a live event updates the affected user's role and media permissions. Fully revoking access disconnects a user who is already in the room.

Do not add access after an event has ended merely to expose old history. The UI disables access changes for closed events; publish a recording or create a new event when post-event sharing is intended.

## Waiting room

The lobby opens at:

`scheduled start − join-before-start minutes`

Before that point Kralis rejects the admission request. During the open window:

* hosts and moderators bypass the waiting room;
* all users bypass it when waiting room is disabled;
* other users create a persistent pending request;
* a host or moderator can admit or reject the request;
* an admitted user receives media access only after the event is live;
* revoking admission disconnects an already connected user.

Admission changes are saved in Kralis and appear in the lobby immediately. If an update is delayed, the lobby refreshes the status automatically.

## Capacity and reconnects

`maximum participants` is enforced before a user enters. Kralis counts distinct active users and users currently completing admission so simultaneous requests cannot exceed capacity.

Reconnecting users do not consume a second seat. A signed-in user may safely reconnect while their event access remains valid.

## School scoping

Every Classroom page and action stays within the signed-in user's school, including administrator access. Users see only event details, attendance, recordings, grants, and history permitted by their event role.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.