# Profile and Account Security
Source: https://docs.kralis.app/account/profile-and-security
Update your profile, change your PIN, sign out, and understand account deletion.
## Profile
Open **Profile** to review personal, contact, school-role, academic, teaching, and account information available to your account. Update editable details and save before leaving.
Some identity and school-assignment fields are read-only because an authorized school operator manages them.
| Information | Usually managed by |
| ----------------------------------------------------- | ------------------------------------------ |
| Personal and contact details | User where editable |
| Role, active status, class, or teaching relationships | Authorized school operator |
| Password or PIN | Signed-in user through the security action |
| School identity | School administrator |
```mermaid theme={null}
stateDiagram-v2
[*] --> SignedIn
SignedIn --> Updated: Save profile
SignedIn --> Secured: Change PIN or password
SignedIn --> SignedOut: Sign out
SignedIn --> DeletionReview: Request account deletion
DeletionReview --> SignedIn: Cancel
DeletionReview --> [*]: Complete authorized deletion
```
## Change your PIN
Use the account password or PIN change action, enter the requested current and new values, and keep the new credential private. Do not reuse another person's access PIN.
## Sign out
Use **Sign out** when leaving a shared device. Closing the browser tab is not a dependable substitute for ending the signed-in session.
## Account deletion
Account deletion can affect access to school records and connected product modules. Read the confirmation and contact the school if records must be transferred, archived, or retained before deletion.
Never share sign-in credentials, access PINs, password-reset links, or one-time payment information in Kralis AI, broadcasts, chat, or Classroom.
# Chats and History
Source: https://docs.kralis.app/ai/chats-and-history
Start conversations, continue earlier chats, and understand session-only history.
## Start a chat
Open **Kralis AI → Chat**, enter a message, and send it. Continue in the same conversation when follow-up questions depend on earlier context; start a new chat for an unrelated task.
## Open history
Select **History** to see conversations from the current login session. Each item shows its title, update time, and message count. Select one to reopen it.
Current chat history persists only within a particular login session. Do not rely on it as permanent school record storage.
| Action | Result |
| ----------------- | --------------------------------------------------------------- |
| Start new chat | Opens a separate conversation without earlier context |
| Continue chat | Sends another message with that conversation's current context |
| Open history item | Reopens the selected session conversation |
| Delete chat | Removes one item from visible session history |
| Clear All Chats | Removes the complete visible session history after confirmation |
```mermaid theme={null}
flowchart LR
A[Start chat] --> B[Ask question]
B --> C[Review answer]
C --> D{Same task?}
D -->|Yes| B
D -->|No| E[Start new chat]
C --> F[Open from session history]
```
## Delete history
Use the delete action on one conversation to remove it from the visible session history. **Clear All Chats** removes all conversations in that history after confirmation.
## If a response is incomplete
* Restate the intended output.
* Supply missing context without exposing sensitive data.
* Ask for a correction rather than assuming the first answer is final.
* Verify important work using the school's source records.
# Kralis AI
Source: https://docs.kralis.app/ai/overview
Start assisted conversations, revisit session history, and use generated responses responsibly.
Kralis AI provides a conversational assistant inside the signed-in Kralis experience. Access depends on the user's role and the school's enabled modules.
```mermaid theme={null}
flowchart LR
A[Open Kralis AI] --> B[Start chat]
B --> C[Ask a focused question]
C --> D[Review response]
D --> E[Continue or correct context]
E --> F[Open session history later]
```
## Good use
* Ask one clear task at a time.
* Include enough non-sensitive context to make the request understandable.
* Review factual, academic, and policy claims before acting on them.
* Treat generated material as a draft when correctness matters.
## Data care
Do not paste passwords, access PINs, payment credentials, private medical details, or unnecessary personal records into a chat. Use the smallest amount of information needed for the task.
AI can make confident mistakes. A school user remains responsible for reviewing generated scores, messages, learning content, decisions, and advice before use.
See [Chats and History](/ai/chats-and-history) for the interface workflow.
# Attendance Calendar and Statuses
Source: https://docs.kralis.app/attendance/calendar-and-statuses
Navigate attendance periods and understand daily activity labels.
## Calendar views
The Attendance Calendar supports views for a month, a year, a selected range, and the recent four months. Use the previous, next, and current-period controls to navigate.
| View | Best for |
| ------------- | ------------------------------------------------- |
| Month | Day-by-day attendance review |
| Year | A broad pattern across the calendar year |
| Range | A specific reporting interval |
| Last 4 months | Recent-term review without setting dates manually |
## Daily labels
| Label | Meaning |
| ----------------- | ------------------------------------------------------------------------ |
| Check in | An arrival or beginning-of-attendance attempt |
| Check out | A departure or end-of-attendance attempt |
| No activity | No matching Attendance-module attempt is shown for that day |
| Active / Inactive | Account-state filter for the people included, not a present/absent grade |
Select a calendar day to inspect its recorded attempts. More than one attempt can exist when a person's day contains several recorded activities or a correction is needed.
## Classroom comparison
```mermaid theme={null}
flowchart TD
A[User activity] --> B{Where did it happen?}
B -->|Attendance page| C[Daily school attendance]
B -->|Live Classroom room| D[Event presence intervals]
C --> E[Attendance calendar and review]
D --> F[Classroom event attendance]
```
Use the Classroom event's **Attendance** page for join duration and expected-participant status in that event.
# Checking Daily Attendance
Source: https://docs.kralis.app/attendance/checking-daily-attendance
Use Check Attendance for location-aware check-in and check-out activity.
## Your attendance page
The main Attendance page shows today's state, check-in and check-out actions when available, recent activity, and term or annual summaries.
## Check in or out
1. Open **Attendance** or **Check Attendance**.
2. Find the intended user when your role permits checking another person.
3. Select **Check in** at arrival or **Check out** when leaving.
4. Allow browser location access when requested.
5. Wait for the success message and confirm the new record appears.
## Location permission
Attendance may require the current device location so the school can verify that the action occurs within its configured area.
| Browser response | What to do |
| ---------------------- | --------------------------------------------------------------------- |
| Permission prompt | Choose **Allow** and keep location services enabled |
| Permission denied | Open browser site settings, allow location, then retry |
| Location unavailable | Move to a clearer location, enable device location, and retry |
| Outside permitted area | Confirm you are at the approved school location or contact the school |
Kralis requests location for the attendance operation. Browser and device privacy controls still determine whether coordinates can be supplied.
## Avoid duplicate activity
Check the current daily state before selecting an action. If the page still shows an old state after a successful message, refresh the attendance data before trying again.
# Managing and Correcting Attendance
Source: https://docs.kralis.app/attendance/managing-and-correcting
Create, edit, or delete school attendance records with care.
Open **Manage Attendance** when an authorized operator needs to correct a record rather than perform a normal check-in or check-out.
## Common corrections
* create a missing attendance attempt;
* correct whether an attempt is a check-in or check-out;
* correct the associated date or time when the form permits it;
* update the intended user; or
* delete an invalid duplicate or mistaken record.
## Correction workflow
```mermaid theme={null}
flowchart LR
A[Find user and date] --> B[Review existing attempts]
B --> C{Correct record exists?}
C -->|No| D[Create missing record]
C -->|Yes, but wrong| E[Update record]
C -->|Duplicate or invalid| F[Delete after confirmation]
D --> G[Review calendar]
E --> G
F --> G
```
## Safe correction rules
* Verify the person's identity and attendance date.
* Preserve valid check-in/check-out order.
* Do not invent location details.
* Read the delete confirmation before removing a record.
* Reopen Attendance Review or Calendar to confirm the final state.
Deleting attendance is appropriate for an invalid record, not for changing its meaning. Update the record when the original activity should still be retained.
# Attendance
Source: https://docs.kralis.app/attendance/overview
Check in and out, review daily activity, use the calendar, and correct records.
The Attendance module records general school attendance activity. Users check in and out, while permitted staff review and correct school attendance records.
| Attendance system | Purpose |
| -------------------- | ---------------------------------------------------------------------------- |
| Attendance module | General school attendance and location-aware daily activity |
| Classroom attendance | Presence calculated from joining and leaving a specific live Classroom event |
These records answer different questions and are reviewed on different pages.
## Guides
| Goal | Guide |
| -------------------------------------------------- | ------------------------------------------------------------------------- |
| Check yourself or other permitted users in and out | [Checking Daily Attendance](/attendance/checking-daily-attendance) |
| Search records and interpret summaries | [Reviewing Attendance History](/attendance/reviewing-history) |
| Create, edit, or remove an incorrect record | [Managing and Correcting Attendance](/attendance/managing-and-correcting) |
| Navigate month, year, range, and recent views | [Attendance Calendar and Statuses](/attendance/calendar-and-statuses) |
```mermaid theme={null}
flowchart LR
A[Open Attendance] --> B[Check in]
B --> C[School activity]
C --> D[Check out]
D --> E[Review history]
E --> F[Correct exceptions if permitted]
```
## Access by role
| Role | Typical access |
| ------------------------ | -------------------------------------------------------------------- |
| Student or ordinary user | Check their own permitted attendance and view their history/calendar |
| Authorized staff | Check selected users, review filtered records, and use the calendar |
| Dean or administrator | Manage and correct records according to school permissions |
# Reviewing Attendance History
Source: https://docs.kralis.app/attendance/reviewing-history
Search daily records, interpret summaries, and open a person's calendar.
Open **Attendance Review** to inspect attendance activity across users.
## Filters and results
Use search, date, class, user type, and active/inactive filters shown for your role. The result table includes the person, status, check-in time, check-out time, and class where relevant.
| Filter | Use |
| ----------------------- | ---------------------------------------- |
| Date | Review one school day |
| Search | Find a user by their displayed identity |
| Class | Narrow student records to a cohort |
| Active / Inactive / All | Include users according to account state |
## Summaries
Review summaries as counts within the current date and filters. Changing the class or user type changes the population being summarized.
## Open the calendar
Use **Calendar** beside a user or from the page actions to inspect attendance across a longer period. The calendar groups attempts by attendance date and shows daily check-in and check-out activity.
A missing daily attendance record means no qualifying Attendance-module activity was recorded for that date. It does not describe participation in a Classroom event.
# School Billing
Source: https://docs.kralis.app/billing/overview
Review the school's Kralis plan, invoices, payment status, and payment actions.
School Billing is for the school's Kralis subscription and service invoices. It is different from the **Fees** module, which manages charges owed by students or other school users.
## Billing page
Authorized administrators can open **School → Billing & Invoices** to review:
* the school's current plan and billing cycle;
* marketing package and discount information where applicable;
* invoice reference, payment code, academic scope, currency, and amount;
* payment status, channel, due date, and paid date; and
* available payment or payment-resumption actions.
```mermaid theme={null}
flowchart LR
A[Open billing invoice] --> B[Review amount and status]
B --> C[Choose Pay Now]
C --> D[Complete payment flow]
D --> E[Return to Kralis]
E --> F[Refresh and confirm status]
```
If a prior transaction can be resumed, the payment action uses the saved transaction information. Do not start several payment attempts because a status update is briefly delayed.
School Billing is restricted to authorized school management accounts. For a paid invoice that remains outstanding, preserve the invoice number and payment evidence, then contact Kralis support.
# Creating and Managing Broadcasts
Source: https://docs.kralis.app/broadcasts/managing
Write, target, publish, review, update, and safely delete announcements.
## Create and target
1. Open **School Broadcasts** and choose the add action.
2. Enter the title, message, duration or ending time, and visibility.
3. Save the details.
4. Open **Groups**, **Users**, **Classes**, **Subjects**, and **Courses** to select recipients.
5. Review the selected counts and update the broadcast.
Target tabs become available after the broadcast has been created.
| Target | Example |
| -------- | ------------------------------------------------ |
| Groups | A defined category of school users |
| Users | Named individuals found through recipient search |
| Classes | All matching learners in selected classes |
| Subjects | Users associated with selected subjects |
| Courses | Users associated with selected LMS courses |
Use the smallest audience that fulfills the communication goal. Combining targets can broaden who receives the announcement.
## Visibility lifecycle
Keep **Visible** off while drafting or checking recipients. Turn it on when the broadcast is ready. The ending time limits how long the announcement remains current.
Update a broadcast to correct its message, window, visibility, or targets. Delete only when the record should no longer exist; hiding it is safer when it may be needed for reference.
Review targets immediately before making a sensitive announcement visible. A clear message sent to the wrong audience is still a disclosure.
# School Broadcasts
Source: https://docs.kralis.app/broadcasts/overview
Create time-limited school announcements and deliver them to the right audience.
School Broadcasts place targeted announcements inside Kralis. A broadcast can be aimed at selected groups, users, classes, subjects, or courses.
```mermaid theme={null}
flowchart LR
A[Write broadcast] --> B[Save details]
B --> C[Select audiences]
C --> D[Review visibility window]
D --> E[Make visible]
E --> F[Recipients read it]
F --> G[Update, end, or delete]
```
## Broadcast fields
| Field | Purpose |
| ---------------------- | ------------------------------------------------------------- |
| Title | Short announcement heading |
| Message | Full recipient-facing content |
| Duration / ending time | Controls the broadcast window |
| Visible | Determines whether the broadcast is available to its audience |
| Targets | Limits recipients by group, user, class, subject, or course |
Authorized operators create and manage broadcasts. Other users see broadcasts that are visible, within their window, and match their school and targets.
See [Creating and Managing Broadcasts](/broadcasts/managing) for the complete workflow.
# Creating CBT Tests
Source: https://docs.kralis.app/cbt/creating-tests
Create test metadata, assemble questions, and prepare an assessment for a session.
## Find and filter tests
Open **CBT → Tests**. Use search and the available academic filters to find a test, then open it for details, editing, session management, or deletion.
## Create a test
1. Open the CBT editor.
2. Choose **Test** and create a new test.
3. Enter a clear title and the academic details shown by the form.
4. Save the test.
5. Add questions from the question bank or create new questions.
6. Arrange the questions in the intended order.
7. Review the completed test before creating a session.
## Build methods
| Method | Best use |
| ---------------------- | ---------------------------------------------------------------- |
| Add existing question | Reuse a reviewed question from the school question bank |
| Create question | Write a new question directly for the test |
| AI-assisted generation | Draft a test or questions that a teacher will review and correct |
AI output is a starting point. Check subject accuracy, wording, answer correctness, difficulty, and school suitability before using it with students.
## Related content
Related tests and related questions help authors connect reusable assessment material. A relationship does not automatically place a question inside a test; use the test's question controls for that.
## Reordering
Use the ordering controls in the editor to place questions in the sequence students should encounter. Reordering changes presentation order without changing the question itself.
## Prepare for delivery
Before creating a session:
* preview every question;
* verify the correct answer and any alternatives;
* confirm marks and required settings;
* remove duplicates;
* check the final order; and
* save all changes.
Deleting a test can affect its sessions and related assessment history. Read the confirmation and remove it only when the test itself should no longer exist.
# Computer-Based Testing
Source: https://docs.kralis.app/cbt/overview
Create question banks and tests, run timed sessions, review attempts, and sync scores.
Kralis CBT supports the full assessment journey, from reusable questions to student attempts and optional SRMS score synchronization.
```mermaid theme={null}
flowchart LR
A[Create questions] --> B[Create test]
B --> C[Arrange questions and answers]
C --> D[Create test session]
D --> E[Students attempt test]
E --> F[Review attempts]
F --> G[Recalculate if needed]
G --> H[Optional SRMS score sync]
```
## Guides
| Goal | Guide |
| ---------------------------------------------------- | --------------------------------------------------------------------------- |
| Create, configure, find, and prepare a test | [Creating CBT Tests](/cbt/creating-tests) |
| Build questions, answers, and reusable relationships | [Managing Questions and Answers](/cbt/questions-and-answers) |
| Schedule availability and manage eligible students | [Running a CBT Session](/cbt/running-sessions) |
| Complete and submit an attempt | [Taking a Test as a Student](/cbt/student-guide) |
| Review attempts, recalculate, and sync marks | [Reviewing Performance and Syncing Scores](/cbt/performance-and-score-sync) |
## Capabilities by role
| Role | Typical capabilities |
| --------------------- | ------------------------------------------------------------------------------------------------------------ |
| Student | Open eligible sessions, answer questions, navigate the test, submit, and view permitted feedback |
| Teacher | Create questions and tests, arrange content, run assigned sessions, and review performance |
| Dean or administrator | Manage school-wide tests and sessions, review attempts, recalculate scores, and sync eligible scores to SRMS |
A test defines assessment content. A test session controls when and for whom that test can be attempted.
# Reviewing Performance and Syncing Scores
Source: https://docs.kralis.app/cbt/performance-and-score-sync
Inspect attempts, recalculate outcomes, and safely send CBT marks to SRMS.
## Review performance
Open **CBT → Performance**, use the session and learner filters, and select an attempt for detailed review.
Review:
* attempt and submission state;
* learner answers;
* correct and incorrect responses;
* awarded score; and
* any timing information shown.
## Recalculate scores
Use **Recalculate Scores** after a correction that should change grading, such as fixing a correct answer or score rule. Recalculation uses the current assessment definition and may alter existing outcomes.
## Sync to SRMS
```mermaid theme={null}
flowchart LR
A[Review attempts] --> B{Scores correct?}
B -->|No| C[Correct and recalculate]
C --> A
B -->|Yes| D[Choose SRMS context]
D --> E[Sync scores]
E --> F[Review scoresheet entries]
```
Before syncing, verify the year, term, class, section, subject, destination score component, and selected learners. Then review the resulting SRMS entries.
## Delete attempts
Individual and multi-select deletion are intended for invalid records, not ordinary low scores. Confirm the exact selection before deletion; removing an attempt can also affect summaries and later score sync.
Score synchronization crosses module boundaries. A successful CBT score is not enough—the SRMS destination must also be correct.
# Managing Questions and Answers
Source: https://docs.kralis.app/cbt/questions-and-answers
Build a reusable question bank with correct answers and dependable ordering.
## Question workflow
```mermaid theme={null}
flowchart LR
A[Create question] --> B[Choose question type]
B --> C[Add answer options]
C --> D[Mark correct answer]
D --> E[Set order and marks]
E --> F[Review]
F --> G[Add to a test]
```
## Question types
Choose the type offered by the editor that matches how the learner should respond. The selected type determines whether answer options and a marked correct answer are required.
## Answer management
* Write answers so they are distinct and understandable.
* Mark the correct answer or answers according to the question type.
* Reorder options when their sequence matters.
* Update the question after changing an answer.
* Preview the result before using it in a live session.
## Question bank
The question bank keeps questions reusable. Search it before creating a duplicate, and use **Add existing question** when the right question already exists.
| Relationship | Meaning |
| ---------------- | ------------------------------------------------------------------------------ |
| Question in test | The question is part of that test's delivered content |
| Related question | The question is associated for discovery or reuse |
| Related test | The assessment is associated with another test; it is not merged automatically |
## AI-assisted questions
Provide enough context for useful drafts, then review every generated item. Never assume a generated answer is correct because it is marked as correct.
## Safe changes
Changing a reused question can affect more than one test. Check its test relationships before making a substantial edit. Prefer a new question when the intended wording or correct answer is materially different.
# Running a CBT Session
Source: https://docs.kralis.app/cbt/running-sessions
Control test availability, timing, eligibility, and the live attempt window.
A CBT session is the delivery window for a test. Open a test, then use its session controls to create and manage a session.
## Create a session
1. Confirm the test is complete.
2. Open the test's sessions area.
3. Create a session and complete the timing, availability, and eligibility fields.
4. Review the selected test and student audience.
5. Save and make the session available when ready.
## Session checks
| Check | Question to answer |
| ------------- | --------------------------------------------------- |
| Timing | When can students begin, and how long do they have? |
| Availability | Is the session currently open to attempts? |
| Eligibility | Which students can see and take it? |
| Attempt rules | Can a learner start or submit more than once? |
| Test content | Is the correct test attached and reviewed? |
## During the session
Monitor attempts from the performance area. Avoid editing delivered questions while students are actively answering unless correcting a serious problem and the consequences are understood.
## After the session
Review completed and incomplete attempts, recalculate scores only when necessary, and sync eligible scores to SRMS only after checking the destination academic context.
Deleting a session or several selected attempts removes assessment records. Verify the session, learners, and selection before confirming.
# Taking a Test as a Student
Source: https://docs.kralis.app/cbt/student-guide
Prepare, answer, navigate, and submit a Kralis CBT attempt.
## Student journey
```mermaid theme={null}
flowchart LR
A[Open CBT] --> B[Choose available session]
B --> C[Read instructions]
C --> D[Start attempt]
D --> E[Answer and navigate]
E --> F[Review answers]
F --> G[Submit]
G --> H[View permitted outcome]
```
## Before starting
* Confirm the test title and session.
* Read the instructions and timing information.
* Use a dependable device and connection.
* Close unrelated tabs or applications if they may distract you.
* Begin only when you have enough uninterrupted time.
## Navigate questions
Use **First**, **Previous**, **Next**, and **Last** to move through the test. Answer status and navigation help identify questions that still need attention.
Moving to another question is not the same as submitting the whole test. Review the visible answer state before the final submission.
## Submit
Select **Submit Quiz** only when finished. Read the confirmation carefully; final submission may end the attempt and prevent further editing.
## If something goes wrong
Do not repeatedly submit or refresh. Note the test and session, preserve any error message, and contact the teacher or school. The school can review the recorded attempt state.
# Classroom Access and Roles
Source: https://docs.kralis.app/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.
# Attendance and Session History
Source: https://docs.kralis.app/classroom/attendance-and-history
How Classroom derives attendance from verified presence and preserves every room run.
Classroom attendance is based on the time a participant is actually connected to the live room. Merely opening an event, requesting admission, or being expected does not count as attendance.
## Expected and actual attendance
For scheduled invite-only and class-audience events, Kralis snapshots the expected audience when the event starts. The snapshot includes:
* the creator;
* directly granted users;
* current members of granted collaboration groups; and
* students in the selected class and optional section.
This snapshot is necessary to record a true **absent** result for someone who never joins. Later class or group changes do not rewrite the original roster. Users explicitly added while the event is live can be appended to the expected roster.
Instant and school-wide events still track everyone who joins, but they do not create a potentially huge absence roster for every school user.
## Attendance time
Kralis records join and leave activity for each participant and live session. Reconnecting creates another attendance period without losing the time already recorded.
When calculating duration, Kralis:
1. clamps each interval to the event’s attendance window;
2. treats an open interval as continuing up to the calculation time;
3. merges overlapping intervals to prevent double counting;
4. sums the merged duration;
5. updates first join, last leave, total duration, and join count.
For scheduled events, the attendance window is the planned start-to-end window. For instant events, it is the actual event/session window.
## Attendance statuses
| Status | Meaning |
| ------- | ------------------------------------------------------------------------------------------ |
| Present | Duration meets the minimum percentage and first join was not late |
| Late | Duration meets the minimum percentage, but first join was after the configured late cutoff |
| Partial | The user joined, but duration was below the minimum percentage |
| Absent | The expected user accumulated no attendance duration |
| Excused | A manager applied an explicit manual override |
The calculated percentage and evidence remain available even when a manager overrides the displayed status.
## Manager attendance workflow
From an event details page, an event manager can open the attendance page to:
* see joined and expected counts;
* search and paginate the roster;
* review first join, duration, percentage, status, and source;
* set a manual status with a required reason;
* clear an override and return to the calculated result.
Every override and clear operation writes an audit event containing the actor, participant, event, status, and reason.
## Student attendance view
Students can see their own read-only attendance for a visible event, including status, joined time, duration, and percentage. Students cannot mark themselves present or change their recorded attendance activity.
## Session history
An event can have more than one Classroom session. Each session records:
* its sequence number;
* pending, starting, live, ended, or failed state;
* actual start and end;
* configured capacity;
* presentation state; and
* recordings and presence associated with that run.
If an event has more than one live run, the event page presents them as a timeline rather than combining them into one record.
## Event completion
When an event ends, Kralis closes active attendance periods, finishes the live session, recalculates attendance, and closes remaining waiting-room requests. Scheduled events receive the same final attendance processing when their time expires.
# Classroom Events and Scheduling
Source: https://docs.kralis.app/classroom/events-and-scheduling
Create, publish, start, end, archive, share, and understand Classroom events.
A Classroom event holds a live room's schedule, audience, settings, access, attendance, recordings, and history. Create and share the Kralis event so every participant enters through their existing account.
## Classroom home page
Open [Kralis Classroom](https://kralis.app/classroom) to see **Your classrooms**. The header also links to Whiteboards and Groups, while eligible non-student users receive **New classroom**.
Two filter rows control the event list:
| Filter | Choices | Purpose |
| ------------ | ----------------------------------------------------- | -------------------------------------------------------------- |
| Record state | Active or Archived | Switches between current records and retained archived history |
| Event status | All, Live, Scheduled, Drafts, Completed, or Cancelled | Narrows the selected record state by lifecycle status |
Students receive Active and Archived filters and all relevant status filters except Drafts. They do not receive **New classroom** or event-management actions.
Search matches visible classrooms using the submitted text. Filters and search work together. The result count reflects the current selection, and **Load more** appends the next set without removing events already displayed.
Events are ordered for practical use:
1. live events;
2. scheduled events from nearest to latest;
3. drafts;
4. completed and cancelled events from most recent to oldest.
## Who can create an event
The Kralis web app allows active non-student school users to create Classroom events. The creator receives the event’s protected **host** role.
Students see only events available to them and do not see the draft filter or the new-event action.
## Instant and scheduled events
### Instant
Use an instant event when the room should start on demand. It has no planned start or end timestamps. Start it explicitly when the host is ready.
### Scheduled
Use a scheduled event when participants need a known start and end. The end must be later than the start. The form shows both the event duration and how far the start is from the current time; selecting a start also proposes an end one hour later until the operator chooses another duration.
Scheduled events support:
* an early lobby window
* automatic activation at the scheduled start
* a live start countdown in the lobby
* live-room elapsed and remaining-time counters
* five-minute and two-minute end reminders
* automatic completion after the scheduled end
* Add to calendar, copy-link, and share actions
Calendar export and sharing are client-side conveniences. Access is still checked by Kralis when the recipient opens the event.
## Audience and context
Audience controls who can discover and enter the event. Context describes what the event is about.
### Audience scopes
* **Invite only**: only the creator, administrators, and users or collaboration groups granted access.
* **Class**: active students in the selected class. An optional section narrows that class audience.
* **School**: active users in the same school can receive participant access.
A section is never an independent audience. Select a class first; Kralis only accepts a general section or a section tied to that class.
### Academic context
* **Class and section** identify the intended student cohort.
* **Subject** labels the teaching context but does not grant access by itself.
* **Year and term** are captured automatically from the school’s current year and term when the event is created. They are shown on the details page and are not selected manually in the event form.
An event may remain generic with no class, section, or subject.
## Event settings
The event form also controls:
* participant microphone, camera, and screen-sharing defaults
* chat and raise hand
* waiting room
* recording policy: disabled, manual, or automatic
* maximum participants
* minutes before start when the lobby opens
* minutes after start that count as late
* minimum attendance percentage
The minimum attendance percentage is the percentage of the planned event window a user must attend before duration is sufficient for **present** or **late**. A lower percentage becomes **partial**.
## Lifecycle and available actions
| State | Meaning | Typical actions |
| --------- | ---------------------------------------- | -------------------------------------------------------------------- |
| Draft | Not visible to ordinary audience members | Edit, grant access, publish, start an instant event, cancel, archive |
| Scheduled | Published and waiting for its start | Edit, manage access, enter early lobby, start when allowed, cancel |
| Live | A current media session exists | Join, manage participants, present, record, end |
| Ended | The event and active sessions are closed | Review attendance, sessions, chat, and recordings; archive |
| Cancelled | The event will not run | Review details; archive |
Draft scheduled events must be published before ordinary audience members can discover them. Instant events are started directly rather than published.
The main timeline places live events first, then scheduled events from nearest to latest, then drafts, then completed or cancelled history from most recent. Users can search, filter by status, switch between active and archived records, and load additional cursor-paginated results. Students receive the same relevant history but not draft controls.
## Event details page
The event details page is the central record before, during, and after a classroom.
| Area | Available information or action |
| ---------------- | --------------------------------------------------------------------------------------------------------------- |
| Main actions | Enter, edit, publish, start, end, cancel, share, copy link, add to calendar, archive, or restore when permitted |
| Classroom setup | Audience, role and live-setting summary |
| Whiteboards | View attached boards, create and attach a new board, attach an existing board, or detach one |
| Session history | Every live run with start, end, duration, participation, presentation, and associated recordings |
| Recordings | Processing state, preview, publish, unpublish, playback, and delete controls |
| My attendance | The current user's read-only status, first join, duration, and percentage |
| Academic context | Class, section, subject, year, and term |
| Activity | Joined and expected counts plus a manager link to the complete attendance page |
| Access | Direct user and collaboration-group roles for an open event |
| Audit history | Important management actions visible to authorized managers |
Closed events keep their history stable. They do not accept new access grants or new whiteboard attachments.
## Automatic scheduling
Classroom opens the lobby at the configured early-entry time, starts an automatically scheduled event at its planned start, and ends it after its planned end. While waiting, the lobby shows a live countdown and moves an admitted user into the room when the event begins.
A brief update delay can occur around the scheduled start or end. Participants should remain on the lobby or live-room page while Classroom refreshes the event state.
## Archive is not delete
Archiving removes an eligible event from the active listing without destroying attendance, sessions, chat, recordings, or audit history. Draft, ended, and cancelled events may be archived and later restored. Live and scheduled events must first reach an eligible state.
# Joining and the Live Room
Source: https://docs.kralis.app/classroom/joining-and-live-room
Prepare devices, enter the lobby, use Classroom media, present, chat, and moderate participants.
The live-room experience is part of Kralis. Participants use their existing Kralis account rather than a separate meeting account or an embedded third-party interface.
## Before joining
1. Open the event details page.
2. Select **Enter room** when the lobby or live event is available.
3. Review the recording notice if the school requires acknowledgement.
4. Choose a microphone and camera, or turn either one off.
5. Continue to the Classroom lobby.
6. Wait for admission when required.
If no media device exists, both camera and microphone can remain off. The user can still enter in listen-only mode when their role allows access.
Scheduled lobbies display a live start countdown. Once the event becomes live, an admitted user is connected automatically.
## Camera, microphone, and browser permissions
The preparation screen requests only the devices the user chooses to enable. If a device fails:
1. allow camera or microphone permission for the Kralis site;
2. close another browser tab or application using the device;
3. select another available device; or
4. continue with that device off and retry from the live-room control.
If neither device is requested, Classroom enters without requesting camera or microphone access. A screen-sharing failure is handled separately and does not produce a microphone warning.
## Access checks
Before entry, Classroom checks the user's school, event access, role, admission, available capacity, removal status, and recording notice. The resulting camera, microphone, and presentation permissions reflect the event settings and any participant-specific changes made by a manager.
## Main controls
The bottom control bar contains the most frequently used actions:
* microphone
* camera
* present or stop presenting
* speaker mute for the local listener
* leave room
Less frequent controls are available under **More**, including low-bandwidth mode, recording controls for managers, and bulk participant controls.
The quick panel opens participants, chat, waiting-room requests, and attached whiteboards. Participant and chat buttons display counts, including unread chat activity.
## Participants and moderation
Hosts and moderators can, subject to role precedence:
* mute one user’s currently published microphone or camera;
* mute all controllable participants’ microphones or cameras;
* allow or prevent one user from publishing audio, video, or screen share;
* reset the user to event defaults;
* lower a raised hand;
* remove and later reinstate a participant;
* change live event-wide microphone, camera, screen-share, chat, raise-hand, and waiting-room settings.
Browsers do not allow a remote host to turn another person’s camera or microphone **on**. Kralis can stop a published track or revoke permission; the participant must deliberately turn media back on after permission is restored.
## Chat and raise hand
Classroom saves chat messages so the event can retain its conversation history. The UI supports replies, edits, deletions, and loading older messages.
Raise hand is also a Kralis participant state. A user controls their own hand, and managers can lower it. Both features can be disabled for the live event.
## Presentation behavior
Classroom has two presentation sources:
### Native whiteboard presentation
The presenter selects an attached board. Followers switch to the board view and see the active editor's drawing and cursor. A viewer can leave follow mode and return later. The presenter's camera can remain visible as picture-in-picture.
### Screen sharing
The browser prompts the presenter to choose a screen, window, or tab. Followers see the shared content, and the presenter camera can remain visible as picture-in-picture.
Only one authoritative presentation source is active for a session. Replacing an existing presentation requires confirmation.
Native board presentation is intentionally separate from screen sharing. Use native presentation for efficient live board viewing. Use screen sharing when the board or another application must be captured in a recording.
## Network and constrained devices
Classroom adjusts video delivery to the available connection. Network indicators use quality colors and a small percentage estimate. The elapsed timer is always visible; scheduled rooms also show remaining time.
On a slow network or lower-end device:
* turn off the local camera;
* enable low-bandwidth mode under **More**;
* avoid an unnecessary screen share;
* prefer the native whiteboard presentation when it does not need recording;
* close other camera-using tabs and applications.
Speakers are enabled by default, but browser autoplay rules may require the user to click **Enable classroom audio**. Local speaker mute affects only that listener.
## Mobile and small-screen layout
Classroom keeps the same event access, chat, attendance, and moderation rules on mobile, while adapting the live-room controls.
| Area | Small-screen behavior |
| -------------------------- | --------------------------------------------------------------------------------------------------------- |
| Camera grid | One or two tiles stack vertically; three or more use two columns, so four participants form a 2-by-2 grid |
| Header and bottom controls | Horizontally scroll when space is limited instead of overlapping |
| Whiteboard controls | Labels become compact icons while remaining available through titles and accessible names |
| Presenter camera | Appears as a compact picture-in-picture at the bottom right during board presentation |
| Quick panel | Participant and chat actions retain their count or unread badges |
Many mobile browsers do not provide screen sharing. Classroom detects this before attempting presentation and shows one clear message. Camera, microphone, chat, and native whiteboard presentation or viewing remain available.
# Managing Whiteboards and Groups
Source: https://docs.kralis.app/classroom/managing-whiteboards-and-groups
Practical workflows for creating, sharing, attaching, archiving, and restoring Classroom whiteboards and collaboration groups.
Whiteboards and collaboration groups are standalone Classroom resources. A board can exist without a live event, and a collaboration group can be reused for event roles and board access.
## Whiteboard workflow
```mermaid theme={null}
flowchart LR
A[Create board] --> B[Draw and save revisions]
B --> C{Who should use it?}
C -->|Specific people| D[Grant user access]
C -->|A class| E[Grant class access]
C -->|Reusable team| F[Grant group access]
D --> G[Optional event attachment]
E --> G
F --> G
G --> H[Present or reuse board]
H --> I{Still active?}
I -->|Yes| B
I -->|No| J[Archive or delete]
```
## Find and filter whiteboards
Open **Classroom → Whiteboards**.
The page starts with **Active** boards. Use:
* **Active** for boards that can currently be viewed or edited;
* **Archived** for retained boards that are no longer active;
* **All** to search both groups together;
* search to match a board title or description; and
* **Load more** when more results exist.
Archive is not delete. Archived boards retain their access, attachments, and revision history.
## Create a whiteboard
Any active school user can create a whiteboard.
1. Select **New whiteboard**.
2. Enter a title and optional description.
3. Choose **Private** or **Shared with school** visibility.
4. Select **Create whiteboard**.
The creator becomes the owner.
| Visibility | Who can view |
| ------------------ | ----------------------------------------------------------------------------------------- |
| Private | Owner, school administrators, explicit grants, and users who can access an attached event |
| Shared with school | Active users in the same school, in addition to managers and explicit grants |
Visibility controls viewing. Editing still requires ownership, administration, or an Editor grant.
## Draw and save
Select **Edit board** to begin editing. Only one person edits a board at a time; viewers continue seeing the drawing and current editor's cursor.
Classroom saves revisions automatically while keeping edit mode open. A manual **Save** action is also available. Select **Stop editing** when finished so another editor can take over immediately.
Imported images are saved with the Excalidraw board and remain available to later viewers. Keep the complete board below 10 MiB by resizing large images before importing them.
## Edit board details
On the whiteboard details page, scroll to **Actions** or use **Board options**, then select **Edit details**.
The dialog updates:
* title;
* description; and
* Private or Shared visibility.
Changing details does not replace the board drawing or revision history.
## Manage whiteboard access
The **Access** card summarizes explicit grants. Select **Manage** to open the access dialog.
The dialog provides **Users**, **Classes**, and **Groups** tabs. Each tab supports search, selection cards, and additional result loading where applicable.
1. Choose the target tab.
2. Search for and select a user, class, or collaboration group.
3. Choose **Viewer** or **Editor**.
4. Select **Grant access**.
Existing targets display their current Viewer or Editor badge. Select the pencil action or select the target again to change its access level. Use the delete action to revoke the explicit grant after confirmation.
| Access level | Capabilities |
| ------------ | ------------------------------------------------------------------ |
| Viewer | Open saved board state and receive live drawing and cursor updates |
| Editor | All Viewer capabilities, plus enter edit mode and create revisions |
Revoking one explicit grant does not necessarily remove all access. The user may still qualify through school-wide visibility, an attached event, administration, or another granted group.
## Attach a board to events
The **Attached events** card shows current attachments. Select an event row to open its details or select **Manage** to change attachments.
Inside the dialog:
* current attachments show the event title and status;
* the open action goes to the event;
* detach removes only the relationship after confirmation; and
* search finds active unattached events.
Ended and cancelled events cannot receive new board attachments. This keeps closed event history stable. Existing historical attachments remain visible and can be detached without deleting the board.
A board can also be attached from an event details page:
* **Create and attach** creates a board already linked to that event; or
* **Attach existing** searches manageable boards and links the selected one.
An attachment never transfers board ownership.
## Present a whiteboard
During a live event, open the whiteboard quick panel and select an attached board.
* **Present board** switches followers to the live board efficiently.
* The active editor's drawing and cursor update for viewers.
* The presenter camera can remain visible as picture-in-picture.
* A viewer can leave the presentation and return with **Follow presentation**.
To include the board in a recording, share the browser tab or screen containing it before recording. Native board presentation is not recorded automatically.
## Archive, restore, and delete
| Action | Result | Reversible |
| ------- | --------------------------------------------------------------------------- | ---------- |
| Archive | Removes the board from Active lists and prevents editing or new attachments | Yes |
| Restore | Returns an archived board to active use | Yes |
| Delete | Permanently removes the board and saved revisions | No |
An archived board must be restored before its details, access, attachments, or drawing can be changed.
If the saved drawing becomes unavailable, an owner or administrator may be offered **Recreate empty document**. This creates a new empty revision and cannot recover missing drawing content.
## Collaboration-group workflow
```mermaid theme={null}
flowchart LR
A[Create group] --> B[Search school users]
B --> C[Add members or managers]
C --> D[Grant event role]
C --> E[Grant board access]
D --> F[Reuse group]
E --> F
F --> G{Group still needed?}
G -->|Yes| C
G -->|No| H[Archive group]
H --> I[Restore when needed]
```
## Find and create groups
Open **Classroom → Groups**. Search by group name or description and switch between Active and Archived results.
Any active school user can create a group:
1. select **New group**;
2. enter a name and optional description; and
3. create the group.
The creator becomes the owner and initial manager.
## Add and manage members
Open a group and select **Add member**. The picker:
* searches active school users;
* shows full name and username;
* displays existing membership badges; and
* loads more users when needed.
Choose the intended group role before adding the user.
| Group role | Capabilities |
| ---------- | ----------------------------------------------------------------- |
| Member | Receives access contributed by the collaboration group |
| Manager | Receives group access and can update the group and manage members |
| Owner | Protected creator role with full group management |
Managers can change group details and remove eligible members. The owner cannot be removed implicitly.
## Use groups for access
A collaboration group is a reusable access target:
* an event grant assigns one event role to all active group members; and
* a whiteboard grant assigns Viewer or Editor access to all active group members.
Group membership changes affect the access contributed by that group. During a live event, Kralis updates the affected participant role and media permissions. Removing a user's final source of event access can disconnect them.
Groups do not change a user's global Kralis role and are separate from school permission groups.
## Archive and restore groups
Archiving a group disables the access it contributes while preserving its identity and membership history. Use the Archived filter to find and restore it later.
Before archiving a group, review events and boards that rely on it. Users may retain access through another direct grant, audience, group, or school role.
## Related guides
* [Whiteboards and Collaboration Groups](/classroom/whiteboards-and-groups)
* [Classroom Access and Roles](/classroom/access-and-roles)
* [Using Classroom as a Teacher](/classroom/teacher-guide)
* [Classroom Recordings](/classroom/recordings)
# Kralis Classroom
Source: https://docs.kralis.app/classroom/overview
Live classes, video meetings, attendance, recordings, whiteboards, and collaboration inside Kralis.
Kralis Classroom is the standalone live-teaching and video-meeting product in Kralis. A school can use it without LMS, CBT, or SRMS. Other Kralis products can attach their own context later without becoming a requirement for Classroom.
App entry:
* [https://kralis.app/classroom](https://kralis.app/classroom)
## What Classroom provides
* instant and scheduled classroom events
* school, class, section, group, and individual access
* host, moderator, presenter, participant, and observer roles
* camera, microphone, screen sharing, chat, and raise hand
* waiting-room admission and participant-capacity enforcement
* host controls for participant media, permissions, and removal
* persistent session history and verified attendance activity
* automatically calculated attendance with audited overrides
* manual or automatic MP4 recordings with controlled publication
* standalone Excalidraw whiteboards with revisions and live viewing
* Classroom collaboration groups for reusable access
* school-level limits, retention, recording notices, audits, and issue monitoring
## The core concepts
* **Event**: the school-owned classroom definition. It contains the title, schedule, audience, academic context, settings, access, and history.
* **Session**: one live run of an event. An event keeps its session history if it is started more than once.
* **Participant**: one Kralis user’s event-level role and participation summary.
* **Admission**: the persistent waiting-room decision for one user and event.
* **Presence interval**: a verified period between joining and leaving. Attendance is calculated from these periods, not from merely opening the event page.
* **Recording**: one separately numbered recording segment belonging to an event session.
* **Whiteboard**: an independently owned, persistent board that may optionally be attached to one or more events.
* **Collaboration group**: a Classroom-owned reusable set of school users. It is not a Django permission group and does not change global Kralis roles.
## End-to-end lifecycle
```mermaid theme={null}
flowchart LR
A[Create event] --> B{Instant or scheduled?}
B -->|Scheduled| C[Publish and open early lobby]
B -->|Instant| D[Start when ready]
C --> E[Start automatically or by manager]
D --> F[Live session]
E --> F
F --> G[Verified join and leave activity]
G --> H[Presence and attendance]
F --> I[Chat, presentation, moderation]
F --> J[Optional recording]
J --> K[Private recording]
K --> L[Manager publishes recording]
F --> M[End event]
M --> N[Session history and final attendance]
```
Classroom keeps access, attendance, chat, recordings, whiteboard revisions, and activity history together under the school. Users join with their existing Kralis account and never need a separate meeting account.
## Product independence
Classroom does not require an LMS course. Events can be generic meetings, school-wide sessions, class lessons, section-specific lessons, or explicitly invited groups. Whiteboards also work without an event.
When LMS integration is added, a course may request creation or attachment of a Classroom event. The Classroom event remains the source of truth for its live room, participants, attendance, recordings, and whiteboards.
## Start here
* [Using Classroom as a Teacher](/classroom/teacher-guide)
* [Using Classroom as a Student](/classroom/student-guide)
* [Events and Scheduling](/classroom/events-and-scheduling)
* [Access and Roles](/classroom/access-and-roles)
* [Joining and the Live Room](/classroom/joining-and-live-room)
* [Attendance and Session History](/classroom/attendance-and-history)
* [Recordings](/classroom/recordings)
* [Whiteboards and Groups](/classroom/whiteboards-and-groups)
* [Managing Whiteboards and Groups](/classroom/managing-whiteboards-and-groups)
* [Classroom School Settings](/classroom/school-settings-and-operations)
# Classroom Recordings
Source: https://docs.kralis.app/classroom/recordings
Recording policies, capture sources, processing, publication, playback, deletion, and retention.
Classroom creates recordings for a live session and keeps completed videos private until a manager chooses to publish them. Once recording has started, it does not depend on the teacher keeping the recording controls open.
## Recording policies
Each event has one policy:
* **Disabled**: recording cannot start.
* **Manual**: a host or moderator starts and stops recording in the live room.
* **Automatic**: recording is requested when a live session starts.
School operational policy can additionally require users to acknowledge a versioned recording notice before joining any recordable event.
## Recording controls in the live room
For manual recording, a host or moderator opens **More** in the bottom control bar and selects **Start recording**. The same menu provides **Stop recording** while a recording is active.
The room header identifies the current recording state and source. If a whiteboard is open when recording begins, Classroom requires an active screen share so the board is visibly included. The presenter chooses the correct browser tab, window, or screen before capture begins.
## What is recorded
Classroom supports two recording sources:
### Camera grid
When no screen presentation is active, the recording uses the published camera and audio tracks. A participant with their camera off may not appear as a visible tile in the finished video even if the live room shows their placeholder.
### Shared screen
When screen sharing is active, the shared screen becomes the main content in the recording. The presenter chooses the screen, window, or browser tab using the browser's sharing menu.
A whiteboard shown with **Present board** is not included automatically in the video. To record it, share the browser tab or screen containing the board before starting the recording. Stopping the recording does not stop the screen share.
## Start and stop lifecycle
Manual recording moves through a short sequence:
1. **Preparing** while Classroom starts the recording;
2. **Recording** while the live room is being captured;
3. **Processing** after the recording is stopped;
4. **Ready** when the video can be previewed or published.
The normal states are:
`preparing → recording → processing → ready`
The video is not available immediately after clicking stop. Processing time depends on the recording length. A recording that cannot be completed is marked **Failed** so a manager can distinguish it from one that is still processing.
| Displayed state | Meaning | Recommended action |
| --------------- | ---------------------------------------------------------- | -------------------------------------------------------------------- |
| Preparing | Classroom accepted the request and is starting capture | Keep the live room open and wait for Recording |
| Recording | Camera/audio or the active shared screen is being captured | Continue the class or select Stop recording when finished |
| Processing | Capture stopped and the video is being prepared | Wait; playback is not ready yet |
| Ready | The video can be previewed and managed | Preview, then publish if participants should see it |
| Failed | Classroom could not complete the recording | Review the event state and try a new recording only when appropriate |
## Separate recording segments
Stopping and then starting again creates another numbered recording for the same session. It does not append to the first MP4. A new segment can start while an earlier segment is still processing, provided school recording quotas allow it.
## Publication and visibility
Ready recordings are private by default. Event managers can preview them, then publish or unpublish them. Ordinary event viewers discover and play only published recordings. This prevents every completed recording from becoming student-visible automatically.
Recordings play in the built-in video viewer. Fullscreen and download availability depend on the user's browser and the actions allowed on the recording.
## Recordings after the event
Open the event details page and find **Recordings**. Each recording identifies its numbered segment and associated live session.
| Manager action | Result |
| -------------- | ------------------------------------------------------------------------------------------- |
| Preview | Plays a ready recording without publishing it to ordinary participants |
| Publish | Makes the ready recording available to users who can view the event |
| Unpublish | Hides it from ordinary event viewers without deleting it |
| Delete | Permanently removes the video after confirmation while preserving its deleted history state |
The session timeline also shows recordings belonging to each live run. Students see only published ready recordings.
## Delete and retention
Managers can delete a recording after confirmation. Its deleted state remains visible in the event history.
If the school configures recording retention, recordings older than that period are deleted automatically. School storage or simultaneous-recording limits can prevent a new recording from starting until capacity is available.
# Classroom School Settings
Source: https://docs.kralis.app/classroom/school-settings-and-operations
Configure school limits, recording notices, retention, and review Classroom activity.
School administrators and deans manage Classroom operational policy at:
* [https://kralis.app/school/classroom](https://kralis.app/school/classroom)
Kralis creates the school policy with safe defaults the first time it is needed. The settings page also shows current usage, incidents, and audit history.
## Policy fields
| Setting | Default | Effect |
| ----------------------------- | --------------------- | ------------------------------------------------------------------ |
| Maximum concurrent rooms | 6 | Limits active or starting school Classroom rooms |
| Maximum concurrent recordings | 6 | Limits recordings running at the same time |
| Maximum recording storage | No explicit limit | Prevents new recordings after the school reaches its storage limit |
| Recording retention | No automatic deletion | Deletes ready files older than the configured number of days |
| Recording consent required | Off | Requires notice acknowledgement before joining recordable events |
| Recording notice | Kralis default notice | Text shown before entry; changes create a new notice version |
Leaving an optional room, recording, storage, or retention limit empty means the school has not set a specific cap for that field.
## Recording notice versions
Changing the notice increments its version. An acknowledgement applies to the event, user, and notice version. Each recordable event requires its own acknowledgement when consent is enabled, and changing the notice invalidates an older acknowledgement for the same event.
Acknowledgement records are evidence that the notice was presented and accepted; schools remain responsible for choosing wording and practices that meet their local consent requirements.
## Current usage
The settings page compares current live rooms, recordings, and stored recording size with the school's limits. This helps administrators understand why another room or recording may be unavailable.
## Classroom issues
Classroom reports room, recording, storage, and background-processing problems on the school settings page. Repeated occurrences of the same problem are grouped together.
Issues have warning, error, or critical severity and remain open until an authorized administrator resolves them. Serious issues may also notify Kralis support.
Resolve an issue only after confirming that the affected Classroom action works again. Resolving it removes it from the open-issues list but does not itself repair the problem.
## Audit history
Sensitive product actions produce append-only audit events, including:
* event creation, publication, start, end, cancellation, and archive changes;
* event access changes and live role synchronization;
* participant permission changes, muting, removal, and reinstatement;
* attendance overrides;
* recording requests, publication, deletion, and policy changes;
* collaboration-group changes.
Audit visibility is restricted to authorized school managers and event managers as appropriate.
# Using Classroom as a Student
Source: https://docs.kralis.app/classroom/student-guide
Find, join, participate in, and review a Kralis Classroom event as a student.
Students use the same Kralis account they already use for school. There is no separate meeting account and an event link does not bypass school or classroom access.
## Complete student journey
```mermaid theme={null}
flowchart LR
A[Find classroom] --> B[Open event]
B --> C[Review schedule and details]
C --> D[Prepare camera and microphone]
D --> E{Recording notice?}
E -->|Yes| F[Read and acknowledge]
E -->|No| G[Enter lobby]
F --> G
G --> H{Waiting room?}
H -->|Yes| I[Wait for admission]
H -->|No| J[Join live room]
I --> J
J --> K[Participate]
K --> L[Review attendance and recordings]
```
## 1. Find a classroom
Open **Classroom** from the Kralis dashboard. Students see events made available through:
* their class and optional section;
* a school-wide audience;
* a direct invitation; or
* a Classroom collaboration group.
Students do not see drafts or event-management actions. Use search to find a title or description, select an available status filter, and use **Load more** when additional results exist.
## 2. Review the event
Open an event to review its:
* status and planned time;
* description and teacher;
* class, section, subject, year, and term where applicable;
* attached whiteboards;
* published recordings after completion; and
* personal attendance once attendance activity exists.
An event link still requires sign-in and valid access.
## 3. Prepare devices
Select **Enter room** when the lobby or live room is available. On the preparation screen:
1. choose a microphone and camera;
2. turn either device off if it is unavailable or not needed;
3. confirm the preview; and
4. select **Continue to classroom**.
Use **Cancel** to return to the event without entering. A student can join in listen-only mode when their role permits access and both devices are off.
If a camera or microphone does not start, allow permission for the Kralis site and close another tab or application using the same device.
## 4. Review recording consent
If the school requires a recording notice for recordable events, read and acknowledge it before entering. The acknowledgement applies to that event and the current notice. If the school updates the notice, Kralis may ask for acknowledgement again.
## 5. Enter the lobby
For a scheduled classroom, the lobby shows how long remains before the early-entry window or event start.
When a waiting room is enabled, send the admission request and remain on the page. The lobby updates when a host or moderator admits or rejects the request. Admission allows entry only while the event remains available.
## 6. Participate in the live room
Depending on the event settings and assigned role, a student can:
* turn their microphone or camera on and off;
* hear classroom audio or mute it locally;
* view a shared screen or presented whiteboard;
* send and reply to chat messages;
* edit or delete their permitted chat messages;
* raise or lower their hand; and
* leave and safely reconnect while the event remains live.
A teacher may mute active media, restrict publishing, lower a raised hand, or remove a participant. A teacher cannot remotely turn a student's camera or microphone on.
## 7. Follow a presentation
When the teacher presents a screen or whiteboard, the room follows that source. A student may leave the presentation view and return with **Follow presentation**.
During a whiteboard presentation, students see the current drawing and active editor's cursor. Editing is available only when the board grants Editor access and no one else is editing it.
## 8. Use Classroom on mobile
On a small screen:
* one or two video tiles stack vertically;
* larger groups use a compact two-column grid;
* whiteboard controls use compact icons;
* the presenter camera appears as a small picture-in-picture at the bottom right; and
* horizontal control areas can scroll instead of overlapping.
Many mobile browsers do not support sharing the device screen. When unavailable, Classroom shows a single screen-sharing message; camera, microphone, chat, and native whiteboard viewing still work.
If classroom audio does not begin automatically, select **Enable classroom audio**. Browser autoplay rules sometimes require this action.
## 9. Review attendance and recordings
After participation, the event details page can show **My attendance**, including:
* first join time;
* total duration;
* attendance percentage; and
* Present, Late, Partial, Absent, or Excused status.
Students cannot alter their own attendance. A manager can apply a documented override when necessary.
Published recordings appear on the event details page when ready. Processing or unpublished recordings are not available to ordinary participants.
## Related guides
* [Joining and the Live Room](/classroom/joining-and-live-room)
* [Attendance and Session History](/classroom/attendance-and-history)
* [Classroom Recordings](/classroom/recordings)
* [Whiteboards and Collaboration Groups](/classroom/whiteboards-and-groups)
# Using Classroom as a Teacher
Source: https://docs.kralis.app/classroom/teacher-guide
Create, run, moderate, and review a complete Kralis Classroom event.
This guide follows a classroom manager from planning through the final attendance and recording review. Depending on the event role, the same workflow applies to teachers, hosts, moderators, deans, and school administrators.
## Complete teaching workflow
```mermaid theme={null}
flowchart LR
A[Create event] --> B{Instant or scheduled?}
B -->|Scheduled| C[Publish event]
B -->|Instant| D[Start event]
C --> E[Share or add to calendar]
D --> F[Prepare devices]
E --> F
F --> G[Open lobby and admit users]
G --> H[Teach and moderate]
H --> I[Present or record]
I --> J[End event]
J --> K[Review attendance]
K --> L[Review sessions and recordings]
```
## 1. Create the event
Open **Classroom**, then select **New classroom**.
Choose:
* a clear title and optional description;
* **Instant** when the room should start on demand, or **Scheduled** when it needs a planned start and end;
* an invite-only, class, or school audience;
* an optional class section and subject;
* participant camera, microphone, screen-sharing, chat, and raise-hand defaults;
* waiting-room, capacity, recording, and attendance settings.
For a class audience, select the class before selecting a section. A section narrows the selected class; it is not an audience by itself. Year and term come from the school's current academic settings and appear on the event details page.
For scheduled events, the form shows the duration and how long remains before the start. Selecting a start initially proposes an end one hour later, which can be changed.
## 2. Publish or start
| Event type | What to do | What participants see |
| ---------- | ------------------------------------------------------- | -------------------------------------------------------------------------- |
| Scheduled | Publish the draft when its details and access are ready | Eligible participants can discover it and enter when the early lobby opens |
| Instant | Select **Start classroom** when ready | Eligible participants can discover and enter the live event |
Students cannot see scheduled drafts. Review the audience and explicit access before publishing.
## 3. Share and schedule externally
The event details page provides:
* **Copy link** for the Kralis event URL;
* **Share** when the browser or device supports its sharing menu; and
* **Add to calendar** for scheduled events.
The link is not a public meeting pass. Recipients still sign in to Kralis and must belong to the correct school and event audience.
## 4. Prepare and enter
Select **Enter room**, choose the intended microphone and camera, and continue to the lobby. You can enter with either device off and enable it later.
For scheduled events, the lobby opens according to **Join before start**. Hosts and moderators bypass the waiting room. They can remain in the lobby until the event starts or start it when the event permits manual starting.
## 5. Admit participants
When the waiting room is enabled, open the waiting-room panel to review pending requests.
| Action | Effect |
| ---------------- | --------------------------------------------------------------- |
| Admit | Allows the user to enter when the event is live |
| Reject | Declines the current request |
| Revoke admission | Removes admission and disconnects the user if already connected |
The maximum-participant setting applies while several users are entering at the same time. A reconnecting user does not consume another seat.
## 6. Teach and moderate
The bottom bar contains microphone, camera, presentation, local speaker, and leave controls. Open **More** for lower-bandwidth mode, recording, bulk microphone/camera actions, and other manager controls.
The right-side quick panel opens:
* participants, including the current participant count;
* chat, including unread activity;
* waiting-room requests; and
* attached whiteboards.
From the participant panel, a host or moderator can:
* mute an active microphone or stop an active camera;
* allow or prevent microphone, camera, and screen publishing;
* reset a participant to the event defaults;
* lower a raised hand;
* remove or reinstate a participant; and
* apply bulk microphone or camera actions from **More**.
A manager cannot remotely turn another person's camera or microphone on. The participant must enable it themselves after permission is restored.
## 7. Present content
Use **Present** to share a screen, application window, or browser tab. Use the whiteboard quick panel to open an attached board and **Present board** to make followers switch to its live view.
Only one presentation source is active at a time. Replacing the current source requires confirmation. During board presentation, the presenter's camera can remain visible as picture-in-picture.
To include a whiteboard in a recording, share the tab or screen containing the board. Native **Present board** viewing is not captured automatically.
## 8. Record when needed
For an event using manual recording, open **More** and select **Start recording**. The room displays whether it is preparing, recording, or processing. Stop recording from the same menu.
Stopping and starting again creates a separate numbered recording for the current session. Stopping the recording does not stop an active screen share.
## 9. End the event
Select **End classroom** when teaching is complete. Ending the event:
* closes the current live session;
* closes remaining waiting-room requests;
* finishes active attendance periods; and
* begins final attendance calculation.
A scheduled event also ends after its planned end time. The live room shows elapsed and remaining time and gives five-minute and two-minute reminders.
## 10. Review the event
Return to the event details page after completion.
| Area | What it provides |
| --------------- | ----------------------------------------------------------------------------------------------- |
| Attendance | Joined and expected counts, status, first join, duration, percentage, and manager overrides |
| Session history | Every live run, its start and end, duration, participant activity, presentation, and recordings |
| Recordings | Processing state, preview, publication, unpublication, playback, and deletion |
| Whiteboards | Boards created for or attached to the event |
| Access | Direct user and collaboration-group roles |
| Audit history | Important event, access, moderation, attendance, recording, and policy actions |
Ready recordings remain private until a manager publishes them. Review the video before making it available to participants.
## Related guides
* [Events and Scheduling](/classroom/events-and-scheduling)
* [Access and Roles](/classroom/access-and-roles)
* [Joining and the Live Room](/classroom/joining-and-live-room)
* [Attendance and Session History](/classroom/attendance-and-history)
* [Classroom Recordings](/classroom/recordings)
# Whiteboards and Collaboration Groups
Source: https://docs.kralis.app/classroom/whiteboards-and-groups
Create standalone Excalidraw boards, share editing access, preserve revisions, and attach boards to events.
Classroom whiteboards are independent school-owned resources. They do not need an event or LMS course and can be reused across teaching, planning, tutoring, and group work.
## Who can create a board
Any active Kralis user attached to a school can create a whiteboard. The creator becomes its owner. School administrators can manage boards in their school.
## Visibility and access
A board is either:
* **Private**: available to its owner, administrators, explicit grants, and users who can access an attached event.
* **Shared**: viewable by active users in the same school.
The owner can grant **viewer** or **editor** access to exactly one target per grant:
* a user;
* a class; or
* a Classroom collaboration group.
Viewer access permits loading saved and live board state. Editor access permits creating revisions. Only the owner or a school administrator manages metadata, access grants, event attachments, recovery, archive state, and deletion.
On the board details page, **Edit details** manages title, description, and visibility. The compact **Access** and **Attached events** cards open searchable management dialogs instead of placing large forms beside the canvas.
## Editing model
The board uses Excalidraw in the Kralis interface. Classroom intentionally uses one active editor at a time instead of multi-cursor co-editing.
1. an authorized user selects **Edit board**;
2. Kralis reserves editing for that user while they remain active;
3. the browser keeps that editing session active;
4. viewers receive scene changes and the current editor’s cursor in realtime;
5. autosave writes immutable snapshots without leaving edit mode;
6. leaving edit mode makes editing available to someone else.
If someone else is editing, Kralis identifies that person and prevents conflicting saves. An outdated browser must reload instead of overwriting newer work.
## Persistence and imported images
Each revision saves the complete Excalidraw board, including imported images. This ensures images remain visible to later viewers and in subsequent revisions.
Boards are limited to 10 MiB. Large or numerous embedded images can exceed that limit; resize source images before importing them when necessary.
Each saved revision is kept privately and remains available in the board's revision history. Realtime drawing and cursor updates are shown to viewers while the saved revisions preserve the board between visits. This works independently, so a standalone board does not require a live event.
## Attaching boards to events
An event manager can:
* create a board from the event and attach it immediately;
* attach an existing manageable board;
* detach a board without deleting it.
An attachment does not transfer ownership. During a live event, an attached board can become the native presentation source. Viewers follow it in the room, while the presenter camera may remain picture-in-picture.
To include the board in a recording, share the screen or browser tab containing the board. **Present board** is intended for efficient live viewing and is not captured automatically.
## Archive, delete, and recovery
Archiving removes a board from the active list and prevents editing, but keeps its metadata, grants, attachments, and revisions. Owners can restore it.
Deleting a board permanently removes the board and its revisions. Use archive when its history may still be needed.
If the latest saved board is unavailable, Kralis keeps the board details accessible and offers an owner or administrator a recovery action. Recovery starts a new empty revision; it cannot restore missing content, so use it only after confirming that the saved board cannot be loaded.
## Collaboration groups
Any active school user can create a Classroom collaboration group. The creator is the owner and an initial group manager. Group managers and school administrators can search school users, add or remove members, and assign a member or manager role.
Groups are reusable targets for event roles and whiteboard access. Archiving a group disables its access contribution without deleting historical membership. The owner cannot be removed implicitly.
For complete interface steps, including access tabs, attachment dialogs, member search, role changes, archive, and restore, see [Managing Whiteboards and Groups](/classroom/managing-whiteboards-and-groups).
# API Access, Templates, and Support
Source: https://docs.kralis.app/developers/access-and-support
Understand the developer offering, school access, templates, support, and public policy links.
## Developer offering
The Kralis Developer Hub describes the current developer package, API allowance, school-size options, templates, and support benefits. Use the live page for current commercial information rather than copying plan values into a client.
| Resource | What it provides |
| --------------------------------------------------- | ---------------------------------------------- |
| [Developer Hub](https://kralis.app/developers) | Current developer package and FAQs |
| [Contact Sales](https://kralis.app/contact) | School-specific plan and enterprise discussion |
| [Kralis Templates](https://templates.kralis.school) | School website starting points |
| [Support](https://kralis.app/support) | Product and API integration help |
## School and developer relationship
```mermaid theme={null}
flowchart LR
A[School chooses Kralis] --> B[School is onboarded]
B --> C[Developer access is confirmed]
C --> D[School data is configured in Kralis Web]
D --> E[Developer builds custom client]
E --> F[Users access Kralis through approved experiences]
```
Developers act for an onboarded school and should use accounts and data approved by that school. A developer arrangement does not permit access to unrelated schools.
## Templates
Templates can accelerate a school website, but API authentication and private school workflows still require the same security, scoping, pagination, and error handling as any other client.
## Ask support about
* API access or plan questions;
* an operation that is unclear in the live schema;
* approved origins or deployment-specific connectivity;
* a reproducible API failure;
* enterprise school-instance requirements; or
* a planned change that may affect an existing integration.
Include the school, API surface, named operation or REST path, timestamp and timezone, response status, and a sanitized error. Never send credentials or tokens.
## Policies
Using Kralis APIs is subject to the [Terms of Service](https://kralis.app/terms-of-service) and [Privacy Policy](https://kralis.app/privacy-policy).
# School Scoping and Authorization
Source: https://docs.kralis.app/developers/auth-and-scoping
Keep custom clients within the authenticated school and respect role-based API decisions.
Kralis is a multi-school platform. The authenticated user's school is the tenant boundary for normal application work.
```mermaid theme={null}
flowchart TD
A[Authenticated user] --> B[User role]
A --> C[User school]
A --> D[Academic relationships]
B --> E[Allowed operation]
C --> E
D --> E
E --> F[School-scoped result]
```
## Client responsibilities
| Do | Do not |
| --------------------------------------------- | ---------------------------------------------------- |
| Use the school returned during authentication | Ask the user to type an arbitrary school identifier |
| Use opaque IDs returned by the API | Guess IDs or build authorization from URL values |
| Hide actions unavailable to the current role | Assume hiding a button replaces server authorization |
| Handle permission errors as expected outcomes | Retry a forbidden operation with another school ID |
| Refresh context after role or school changes | Cache authorization decisions indefinitely |
## Roles and relationships
Access may depend on more than a broad role. A teacher's classes or subjects, a student's class and section, an LMS enrollment, a CBT session's eligibility, or a Classroom access grant can narrow what the user may see and do.
## IDs
Use IDs from authenticated responses for follow-up GraphQL operations. Do not derive authorization from a school acronym, name, slug, or a copied URL; the API applies the signed-in user's school and role.
## Diagnosing missing data
```mermaid theme={null}
flowchart LR
A[Expected record missing] --> B{Correct account?}
B -->|No| C[Sign in correctly]
B -->|Yes| D{Correct school and role?}
D -->|No| E[Fix account setup]
D -->|Yes| F{Filters and pagination?}
F -->|No| G[Correct variables or load next page]
F -->|Yes| H[Check eligibility and publication state]
```
A globally privileged-looking account is not permission to mix schools in a public client. Render and operate within the school context authorized by the API.
# Authentication
Source: https://docs.kralis.app/developers/authentication
Authenticate Kralis users, manage access and refresh tokens, and protect credentials in custom clients.
Kralis uses one SimpleJWT token family across its GraphQL and REST authentication interfaces.
| Client choice | Authenticate through | Product GraphQL route | Refresh through |
| ------------- | -------------------- | --------------------------- | ---------------------------- |
| GraphQL | `login` mutation | `/graphql/` or `/graphiql/` | `refreshLoginToken` mutation |
| REST | `POST /auth/login/` | `/graphql/` or `/graphiql/` | `POST /auth/token/refresh/` |
The two login interfaces apply the same account, school, and Access-PIN rules and issue compatible access and refresh tokens. Choose one lifecycle and use it consistently in your client.
## GraphQL authentication lifecycle
```mermaid theme={null}
stateDiagram-v2
[*] --> SignedOut
SignedOut --> SignedIn: login
SignedIn --> SignedIn: refreshLoginToken
SignedIn --> SignedOut: revokeLoginToken
SignedIn --> SignedOut: Tokens expire or become invalid
```
```graphql theme={null}
mutation Login($input: LoginInput!) {
login(input: $input) {
access
refresh
yearId
termId
user {
id
pk
username
fullName
role
}
school {
id
pk
schoolName
schoolAcronym
isActive
}
}
}
```
```json theme={null}
{
"input": {
"username": "YOUR_USERNAME",
"password": "YOUR_PASSWORD_OR_ACCESS_PIN"
}
}
```
## REST authentication lifecycle
```mermaid theme={null}
stateDiagram-v2
[*] --> SignedOut
SignedOut --> SignedIn: POST /auth/login/
SignedIn --> SignedIn: POST /auth/token/refresh/
SignedIn --> SignedOut: POST /auth/logout/
SignedIn --> SignedOut: Tokens expire or become invalid
```
| Endpoint | Purpose |
| --------------------------- | ------------------------------------------------------- |
| `POST /auth/login/` | Exchange username and password or Access PIN for tokens |
| `GET /auth/user/` | Read current authenticated user details |
| `POST /auth/token/refresh/` | Rotate a valid refresh token and issue new tokens |
| `POST /auth/token/verify/` | Verify an access or refresh token |
| `POST /auth/logout/` | Revoke the submitted refresh token and end the session |
Confirm current REST fields in [Swagger](https://api.kralis.app/schema/swagger/) or [ReDoc](https://api.kralis.app/schema/redoc/).
## Authorize GraphQL calls
```http theme={null}
Authorization: Bearer YOUR_ACCESS_TOKEN
```
The login response includes a deliberately limited user and school identity plus current academic context. Fetch fuller application data through the appropriate school-scoped GraphQL queries.
## Refresh and revocation
```graphql theme={null}
mutation Refresh($input: RefreshLoginTokenInput!) {
refreshLoginToken(input: $input) {
access
refresh
}
}
mutation Verify($input: VerifyLoginTokenInput!) {
verifyLoginToken(input: $input) {
valid
}
}
mutation Revoke($input: RevokeLoginTokenInput!) {
revokeLoginToken(input: $input) {
revoked
}
}
```
| Mutation | Input |
| ------------------- | --------------------------------------------- |
| `refreshLoginToken` | `{ "refresh": "YOUR_REFRESH_TOKEN" }` |
| `verifyLoginToken` | `{ "token": "YOUR_ACCESS_OR_REFRESH_TOKEN" }` |
| `revokeLoginToken` | `{ "refresh": "YOUR_REFRESH_TOKEN" }` |
Refresh tokens rotate. After a successful refresh, replace both stored tokens with the returned `access` and `refresh`; the previous refresh token cannot be reused. If refresh fails, clear local authentication and require sign-in. Do not create an infinite retry loop.
## Storage guidance
| Client | Preferred approach |
| ----------------------- | ------------------------------------------------------------------------------------ |
| Server-rendered web app | Keep tokens server-side and expose an HttpOnly, Secure session cookie to the browser |
| Browser-only app | Minimize token exposure; do not place credentials in source, URLs, or analytics |
| Mobile app | Use the operating system's secure credential storage |
| Development tool | Use temporary environment configuration excluded from version control |
Never return tokens to logs, error trackers, browser URLs, screenshots, or public support messages.
# Building a Kralis Client
Source: https://docs.kralis.app/developers/building-clients
Structure authentication, API access, permissions, caching, and school workflows in a custom frontend.
A dependable Kralis client is a presentation and interaction layer over Kralis-owned business rules. It improves the experience without trying to replace server authorization.
## Recommended client layers
```mermaid theme={null}
flowchart TD
A[Pages and screens] --> B[Feature workflows]
B --> C[Typed API operations]
C --> D[Auth and request transport]
D --> E[Kralis API]
B --> F[Local UI state]
C --> G[Normalized or query cache]
```
| Layer | Responsibility |
| ------------------- | ---------------------------------------------------------------------- |
| Auth/session | Login, token refresh, logout, current user and school context |
| Transport | API base URL, Bearer header, request cancellation, and network errors |
| Generated API layer | GraphQL operations and types derived from the current schema |
| Feature service | Product-specific variables, pagination, and result normalization |
| UI | Filters, forms, loading states, permission-aware actions, and feedback |
## Model school workflows, not database tables
Use product actions exposed by the API. For example, publishing a Classroom event, generating a result, syncing a CBT score, or promoting students carries rules beyond changing one field.
## Loading and mutation states
Every data-backed screen should distinguish:
| State | UI behavior |
| ---------------- | ------------------------------------------------------------------- |
| Initial loading | Show a skeleton resembling the expected content |
| Empty result | Explain the current filters and useful next action |
| Validation error | Keep entered values and show actionable field or operation feedback |
| Permission error | Remove unsafe retry loops and explain that access is unavailable |
| Network failure | Offer a bounded retry without duplicating a mutation |
| Mutation pending | Disable duplicate submission and show progress |
| Success | Update or refetch the affected data and confirm completion |
## IDs, names, and URLs
Use returned opaque IDs for API variables. Use slugs or names only where the schema or product URL documents them. Do not parse Relay IDs or construct IDs from school acronyms.
## Use Kralis Web alongside your client
Your custom client does not have to reproduce every management screen. Schools can use [Kralis Web](https://kralis.app) for setup and full administration while your client focuses on the experience it is designed to provide.
```mermaid theme={null}
flowchart LR
A[School operator] --> B[Kralis Web]
C[Your users] --> D[Custom client]
B --> E[Kralis API]
D --> E
E --> F[One school data model]
```
# Classroom API Integration
Source: https://docs.kralis.app/developers/classroom-integration
Build a Kralis-branded Classroom client without bypassing event access, admission, attendance, or recording rules.
Kralis Classroom is available through authenticated GraphQL workflows. A custom client works with Kralis event IDs and permissions; it does not create public provider meeting links or require separate meeting accounts.
## Core concepts
| Concept | Meaning for a client |
| ----------------------- | ---------------------------------------------------------------------- |
| Classroom event | The planned or instant classroom with schedule, audience, and settings |
| Classroom session | One live run of the event |
| Participant | A Kralis user associated with the event and effective role |
| Admission | Waiting-room state controlling entry |
| Presence and attendance | Server-calculated evidence from actual room joins and leaves |
| Recording | A session output with processing and publication state |
| Whiteboard | An independently owned board optionally attached to an event |
```mermaid theme={null}
stateDiagram-v2
[*] --> DiscoverEvent
DiscoverEvent --> RequestAdmission: Waiting room applies
DiscoverEvent --> RequestJoin: Bypass or no waiting room
RequestAdmission --> Waiting
Waiting --> RequestJoin: Admitted
Waiting --> Rejected: Rejected
RequestJoin --> LiveRoom: Join credentials issued
LiveRoom --> Review: Leave or event ends
Review --> [*]
```
## Recommended join flow
1. Query an event visible to the signed-in user.
2. Display schedule, access state, media defaults, and recording notice.
3. Request admission when the waiting room requires it.
4. Observe admission state instead of repeatedly submitting requests.
5. Acknowledge the recording notice when required.
6. Request short-lived join credentials through Kralis GraphQL.
7. Connect using only the returned room information and permissions.
8. Return to Kralis event history after leaving.
```mermaid theme={null}
sequenceDiagram
participant C as Custom client
participant K as Kralis API
participant R as Realtime room
C->>K: Query visible event
C->>K: Request admission if required
K-->>C: Pending, admitted, or rejected
C->>K: Request join credentials
K-->>C: Short-lived scoped credentials
C->>R: Connect
R-->>K: Authoritative join/leave evidence
C->>K: Query attendance, sessions, and published recordings
```
## Roles and moderation
Render actions from the effective event role and current settings. A host or moderator may receive management actions; an ordinary participant does not. Always handle a rejected mutation because roles or live permissions can change after the screen was loaded.
## Chat, hand state, and presentation
Use documented Classroom GraphQL operations for application state. Do not invent a parallel chat, admission, or attendance system and expect it to appear in Kralis history.
## Recordings
Ordinary participants should see only recordings the API exposes to them. Managers can receive processing, failed, ready, published, and deleted states according to authorization. Never expose a playback URL beyond its intended user or assume it is permanent.
## Whiteboards
Whiteboards can exist without an event. A client may list boards available to the user and attach or open them through documented operations. Editing access and live-view behavior remain subject to current Kralis permissions.
Do not embed infrastructure credentials, construct realtime room names, or bypass Kralis admission with arbitrary meeting links. Always request access and room credentials through authenticated Kralis operations.
Use [GraphiQL](https://api.kralis.app/graphiql/) to inspect the current `classroom` queries, mutations, inputs, connection fields, and responses.
# Errors, Pagination, and Reliability
Source: https://docs.kralis.app/developers/errors-and-pagination
Handle GraphQL and REST failures, cursor connections, retries, and changing school data.
## GraphQL errors
A GraphQL HTTP response can contain `errors` even when the transport request completed. Check both `data` and `errors`; do not treat HTTP `200` alone as application success.
| Error class | Client response |
| ----------------------------- | --------------------------------------------------------------------- |
| Authentication | Refresh once when appropriate, otherwise sign out |
| Authorization | Stop the action and update the UI to reflect unavailable access |
| Validation | Preserve inputs and show the server message near the action or field |
| Not found | Remove stale selection and return to an available list |
| Rate limit | Disable repeated submission and retry only after the indicated window |
| Provider or temporary failure | Keep persisted Kralis state authoritative and offer a safe retry |
## REST errors
Use HTTP status and the documented response body. Handle invalid credentials, expired tokens, forbidden access, validation errors, rate limits, and server failures separately.
## Cursor pagination
Kralis GraphQL lists commonly use Relay-style connections.
```graphql theme={null}
query ListBroadcasts($first: Int!, $after: String) {
broadCasts(first: $first, after: $after) {
edges {
node {
pk
title
}
}
pageInfo {
hasNextPage
endCursor
}
totalCount
}
}
```
```mermaid theme={null}
flowchart LR
A[Fetch first page] --> B[Render edges]
B --> C{hasNextPage?}
C -->|Yes| D[Fetch with endCursor]
D --> E[Merge by stable node ID]
E --> C
C -->|No| F[Complete list]
```
Never silently assume a fixed first page contains the whole school. Search selectors, event lists, students, recordings, and other growing datasets must support pagination.
## Retry safety
Queries are generally safe to retry. Mutations may not be. Disable duplicate submission, retain operation state, and refetch after an uncertain response before repeating a create, payment, result, promotion, or recording action.
## Changing data
Another Kralis Web user or custom client can change the same school data. Refetch after important mutations, use realtime or polling only where the product contract supports it, and avoid assuming cached permissions remain valid forever.
# Exploring GraphQL with GraphiQL
Source: https://docs.kralis.app/developers/exploring-graphiql
Browse every Kralis query and mutation, run operations, and authenticate with Kralis SimpleJWT.
[Kralis GraphiQL](https://api.kralis.app/graphiql/) is the interactive explorer for the same GraphQL schema and SimpleJWT authentication used by `/graphql/`.
| Area | What you can inspect |
| --------- | --------------------------------------------------------------------- |
| Query | Root queries, arguments, filters, connections, and return types |
| Mutation | Root mutations, input objects, arguments, responses, and descriptions |
| Types | Fields, nullability, enums, interfaces, and Relay connections |
| Variables | JSON values kept separate from operation text |
| Headers | The Bearer access token used for authenticated operations |
```mermaid theme={null}
flowchart LR
A[Open GraphiQL] --> B[Inspect schema]
B --> C[Run login]
C --> D[Add Bearer access token]
D --> E[Run school-scoped operations]
```
## Log in
```graphql theme={null}
mutation Login($input: LoginInput!) {
login(input: $input) {
access
refresh
yearId
termId
user {
id
pk
username
fullName
role
}
school {
id
pk
schoolName
schoolAcronym
isActive
}
}
}
```
Variables:
```json theme={null}
{
"input": {
"username": "YOUR_USERNAME",
"password": "YOUR_PASSWORD_OR_ACCESS_PIN"
}
}
```
Add the returned access token in the **Headers** panel:
```json theme={null}
{
"Authorization": "Bearer YOUR_ACCESS_TOKEN"
}
```
## Verify, refresh, and revoke
```graphql theme={null}
mutation Verify($input: VerifyLoginTokenInput!) {
verifyLoginToken(input: $input) {
valid
}
}
```
```graphql theme={null}
mutation Refresh($input: RefreshLoginTokenInput!) {
refreshLoginToken(input: $input) {
access
refresh
}
}
```
```graphql theme={null}
mutation Revoke($input: RevokeLoginTokenInput!) {
revokeLoginToken(input: $input) {
revoked
}
}
```
Use `{ "input": { "token": "..." } }` for verification and `{ "input": { "refresh": "..." } }` for refresh or revocation. Refresh rotation invalidates the previous refresh token.
## Routes
| Route | Intended use |
| ------------ | -------------------------------------------- |
| `/graphiql/` | Interactive schema discovery and development |
| `/graphql/` | Application and integration requests |
Both routes accept the same access token and expose the same schema. Production clients should normally send operations to `/graphql/`.
Use temporary test accounts in the browser explorer. Never put passwords or tokens in source control, screenshots, shared requests, URLs, or issue trackers.
# Developer Quickstart
Source: https://docs.kralis.app/developers/getting-started
Onboard a school, authenticate, explore the schema, and make an authenticated Kralis API call.
## 1. Onboard and configure the school
Create the school at [kralis.app/onboard](https://kralis.app/onboard), then use [Kralis Web](https://kralis.app) to configure its current year and term, classes, sections, subjects, users, roles, and enabled modules.
```mermaid theme={null}
flowchart LR
A[Onboard school] --> B[Configure school]
B --> C[Authenticate account]
C --> D[Call GraphQL]
D --> E[Build client workflow]
```
## 2. Authenticate with GraphQL
Send `login` to `/graphql/`. The same operation can be explored interactively at `/graphiql/`.
```bash theme={null}
curl https://api.kralis.app/graphql/ \
-H "Content-Type: application/json" \
-d '{"query":"mutation Login($input: LoginInput!) { login(input: $input) { access refresh user { pk username fullName role } school { pk schoolName } } }","variables":{"input":{"username":"YOUR_USERNAME","password":"YOUR_PASSWORD"}}}'
```
Keep the returned access and refresh tokens private.
## 3. Call GraphQL
```bash theme={null}
curl https://api.kralis.app/graphql/ \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"query":"query { userBroadCasts { pk title message } }"}'
```
Use [GraphiQL](https://api.kralis.app/graphiql/) to inspect current queries, mutations, inputs, filters, and return types. Its **Headers** panel accepts the same Bearer token.
## 4. Refresh when required
Call `refreshLoginToken` once after an access token expires. Store both newly returned tokens before retrying the original operation.
```mermaid theme={null}
sequenceDiagram
participant U as School user
participant C as Your client
participant G as Kralis GraphQL API
U->>C: Sign in
C->>G: login
G-->>C: Access + refresh + limited session context
C->>G: Product operation with Bearer access token
G-->>C: School-scoped result
C->>G: refreshLoginToken when access expires
G-->>C: Rotated access + refresh tokens
```
## Before production
| Check | Expected outcome |
| -------------- | ------------------------------------------------------------------------- |
| Credentials | No secret or token is committed to source control |
| Token storage | Appropriate for a browser, server, or mobile threat model |
| Rotation | Both tokens are replaced after every successful refresh |
| School scoping | The UI uses authenticated school context rather than arbitrary school IDs |
| Roles | Unauthorized actions are hidden and API permission errors are handled |
| Pagination | Growing connections load beyond the first page |
| References | Operations are generated or verified against the live schema |
See [Authentication](/developers/authentication) and [API Access, Templates, and Support](/developers/access-and-support) before production rollout.
# GraphQL and REST
Source: https://docs.kralis.app/developers/graphql-and-rest
Choose the correct Kralis API surface and discover its live contract.
GraphQL is the main Kralis product API. It provides authentication, queries, mutations, schema discovery, filters, pagination, and typed responses. REST remains available for Kralis Web and compatible authentication clients.
## Choose an API
| Need | Recommended surface |
| --------------------------------------------------- | --------------------------------------------- |
| Sign in, refresh, verify, or revoke through GraphQL | Auth mutations on `/graphql/` |
| Use interactive GraphQL documentation | `/graphiql/` |
| Query or update application data | `/graphql/` with a Kralis access token |
| Use REST authentication | `/auth/` with the same SimpleJWT token family |
| Inspect GraphQL types and operations | GraphiQL `/graphiql/` |
| Inspect REST request and response schemas | Swagger, ReDoc, or OpenAPI |
```mermaid theme={null}
flowchart TD
A[Client operation] --> B{Authentication?}
B -->|REST| C[REST auth then /graphql/]
B -->|GraphQL| E[login then /graphql/]
B -->|No| F[GraphQL query or mutation]
```
## GraphQL requests
Send a JSON body containing `query`, optional `variables`, and optionally `operationName`.
```json theme={null}
{
"operationName": "FetchAuthUserBroadcasts",
"query": "query FetchAuthUserBroadcasts { userBroadCasts { pk title message } }",
"variables": {}
}
```
Prefer variables over interpolating user input into query strings. Request only fields your client uses, give operations meaningful names, and generate types from the live schema where your toolchain supports it.
## REST authentication requests
Use the method, path, body, and response documented for `/auth/` in the live OpenAPI surfaces. Do not infer that a GraphQL product mutation has an equivalent REST endpoint.
## Response differences
| Surface | Success | Failure to handle |
| ------- | ----------------------------------- | ------------------------------------------------------------------------------ |
| GraphQL | `data` for requested fields | Top-level `errors`, nullable partial data, authentication or transport failure |
| REST | Documented status and response body | `4xx`, `5xx`, validation body, authentication failure |
GraphQL and REST authentication issue the same SimpleJWT token family. Use one lifecycle consistently and send product operations to `/graphql/`.
# Integration Patterns
Source: https://docs.kralis.app/developers/integration-patterns
Choose a practical boundary between Kralis Web, a custom client, and external school systems.
## Common patterns
| Pattern | Description | Good fit |
| -------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------- |
| Focused student app | Custom client for learner results, courses, tests, fees, or Classroom | Schools wanting a branded learner experience |
| Staff portal | Selected teacher or operator workflows | Teams prepared to model permissions and complex forms |
| School website integration | Public-facing school content plus authenticated Kralis areas | School websites that need a connected portal |
| Companion client | Custom high-value screens while Kralis Web handles administration | Fastest integration with the least duplicated UI |
| Enterprise school instance | Separately operated Kralis instance maintained by Kralis | Contracted enterprise requirements |
## Recommended boundary
```mermaid theme={null}
flowchart TB
A[Public school website] --> D[Your client]
B[Student or parent experience] --> D
C[Focused staff workflow] --> D
D --> E[Kralis API]
F[Full school administration] --> G[Kralis Web]
G --> E
```
Start with a companion client. Rebuild only the workflows your users need, and leave complex or infrequent administration in Kralis Web until there is a clear reason to reproduce it.
## Cross-module operations
Treat server workflows as authoritative. Examples include CBT-to-SRMS score synchronization, LMS test attachment, and Classroom event access. Do not join unrelated API responses locally and assume the result equals a supported server operation.
## Integration checklist
* onboard and configure the school through Kralis Web;
* use a permitted account and least necessary role;
* choose GraphQL authentication mutations or REST `/auth/`; both issue the same SimpleJWT token family for `/graphql/`;
* use GraphQL for product queries and mutations;
* paginate every growing connection;
* display API validation and permission messages;
* keep credentials and tokens out of source control;
* verify destructive and financial actions; and
* coordinate contract questions through Kralis support.
The live schema and OpenAPI documents are the current contracts. Do not depend on internal model names, repository layouts, infrastructure providers, or undocumented endpoints.
# Kralis for Developers
Source: https://docs.kralis.app/developers/overview
Build web and mobile clients with the Kralis API while schools continue managing their data through Kralis Web.
The Kralis Developer Guide is for teams building a frontend, mobile app, school website, portal, or integration against the hosted Kralis API.
You do not need access to the Kralis source code, servers, databases, or deployment configuration. Kralis operates the platform; your client uses supported API contracts.
```mermaid theme={null}
flowchart LR
A[Onboard school at kralis.app] --> B[Configure school in Kralis Web]
B --> C[Authenticate an authorized account]
C --> D[Build your web or mobile client]
D --> E[Call the Kralis GraphQL schema]
E --> F[School uses Kralis Web and your client]
```
## The integration model
| Part | Who owns it | Purpose |
| --------------------- | --------------------------- | --------------------------------------------------------------------- |
| Kralis GraphQL API | Kralis | Main product queries, mutations, business rules, and school data |
| Kralis authentication | Kralis | One SimpleJWT family available through GraphQL or REST authentication |
| Kralis Web | Kralis | A complete interface schools can use for setup and everyday work |
| Your client | Your development team | A custom experience built for the school or its users |
| School configuration | Authorized school operators | Years, terms, classes, users, roles, modules, and operational data |
Your client and Kralis Web work with the same school data. A school can keep using `kralis.app` even when it also has a custom frontend.
## Start here
| Goal | Guide |
| ------------------------------------------------ | -------------------------------------------------------------------- |
| Onboard a school and make the first API call | [Developer Quickstart](/developers/getting-started) |
| Sign in and manage tokens safely | [Authentication](/developers/authentication) |
| Browse every operation and test GraphQL auth | [Exploring GraphQL with GraphiQL](/developers/exploring-graphiql) |
| Keep every operation inside the correct school | [School Scoping and Authorization](/developers/auth-and-scoping) |
| Choose between the two API surfaces | [GraphQL and REST](/developers/graphql-and-rest) |
| Structure a dependable frontend or mobile client | [Building a Client](/developers/building-clients) |
| Handle errors, pagination, and changing data | [Errors and Pagination](/developers/errors-and-pagination) |
| Integrate supported Classroom workflows | [Classroom API Integration](/developers/classroom-integration) |
| Open the live schema and API references | [API Reference Links](/developers/reference-links) |
| Review the developer offering and support path | [API Access, Templates, and Support](/developers/access-and-support) |
## What is not required
* cloning or running Kralis repositories;
* connecting directly to the Kralis database;
* managing Kralis infrastructure; or
* recreating server-side permissions in place of API authorization.
Enterprise arrangements can provide a separately operated school instance, but Kralis still handles its infrastructure and maintenance. Integration remains API-based.
# API Reference Links
Source: https://docs.kralis.app/developers/reference-links
Open the live Kralis authentication, GraphQL, REST, support, and platform references.
## Live API surfaces
| Reference | URL | Use |
| ---------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Interactive GraphQL explorer | [GraphiQL](https://api.kralis.app/graphiql/) | Inspect the complete schema, test GraphQL authentication, and run product operations |
| REST-authenticated GraphQL | [GraphQL](https://api.kralis.app/graphql/) | Send product operations with a REST JWT |
| REST auth | [Auth index](https://api.kralis.app/auth/) | Login and manage the JWT used by Kralis Web and `/graphql/` |
| OpenAPI document | [Schema](https://api.kralis.app/schema/) | Consume the generated REST contract |
| Swagger UI | [Swagger](https://api.kralis.app/schema/swagger/) | Explore and try REST operations |
| ReDoc | [ReDoc](https://api.kralis.app/schema/redoc/) | Read the REST contract |
## Product and support
| Resource | Use |
| ------------------------------------------------------- | ------------------------------------------------- |
| [Kralis Developer Hub](https://kralis.app/developers) | Developer offering, onboarding, pricing, and FAQs |
| [School onboarding](https://kralis.app/onboard) | Register a school and its initial account |
| [Kralis Web](https://kralis.app) | Configure and operate the school |
| [Support](https://kralis.app/support) | Integration support and product questions |
| [Terms of Service](https://kralis.app/terms-of-service) | Platform terms |
| [Privacy Policy](https://kralis.app/privacy-policy) | Platform privacy information |
## Which reference wins?
```mermaid theme={null}
flowchart TD
A[Need current field or endpoint?] --> B{GraphQL?}
B -->|Yes| C[GraphiQL schema]
B -->|No| D[OpenAPI / Swagger / ReDoc]
C --> E{Contract unclear?}
D --> E
E -->|Yes| F[Contact Kralis support]
E -->|No| G[Implement against documented contract]
```
The live schema is authoritative for operation names, arguments, input types, response fields, and deprecations. Public guides explain recommended workflows; they do not replace schema validation.
# Assigning Fees
Source: https://docs.kralis.app/fees/assigning-fees
Target the correct population and generate fee assignments without duplicates.
A fee assignment is the user's invoice for a fee.
## Choose targets
Open an existing fee and use its **Groups**, **Users**, and **Classes** tabs.
| Target | Use it for |
| ------ | ------------------------------------- |
| Group | A defined category of eligible users |
| User | One specifically selected person |
| Class | Active students in the selected class |
Target only the people who owe the fee. Review the displayed total and selections before generating assignments.
## Assignment behavior
Active targeted users can receive invoice assignments from the fee. Inactive accounts and exceptional cases may require manual invoice handling through the invoice interface.
## Review generated invoices
After assignment, open **Invoices** or the fee's invoice action. Confirm:
* invoice user;
* academic year and term;
* amount, paid amount, and outstanding amount;
* due date; and
* last payment information.
## Avoid duplicate or incorrect invoices
* Search for an existing invoice first.
* Confirm target users after changing target criteria.
* Do not use both broad and individual targeting without checking overlap.
* Correct the fee definition before assigning it widely.
Changing a fee's targets can affect who receives invoices. It does not safely erase payments already recorded against existing invoices.
# Managing Student Invoices
Source: https://docs.kralis.app/fees/managing-invoices
Review invoice balances, create exceptions, and keep assignment records accurate.
Open **Fees → Invoices** to search by invoice ID or user details and review fee assignments.
## Invoice columns
| Column | Meaning |
| ------------ | --------------------------------------------------- |
| Amount | Original amount assigned |
| Paid | Payments recorded against the invoice |
| Outstanding | Amount that remains according to current records |
| Last payment | Most recent recorded payment date |
| Due date | Expected payment deadline |
| Paid status | Whether the invoice is currently considered settled |
## Manage an invoice
Open the invoice action to inspect its fee and user. Authorized operators can create an exceptional assignment, update permitted invoice fields, record a payment, or delete an invalid invoice.
## Delete safely
Do not delete an invoice merely because it is unpaid. Delete only an invoice created for the wrong person or in error, and inspect its payment history first.
An invoice with payments is part of the financial trail. Correct or reverse the payment record first where appropriate, then reassess whether the invoice should be removed.
# Fees
Source: https://docs.kralis.app/fees/overview
Configure receiving accounts, assign fees, manage invoices, and record payments.
Kralis Fees connects school fee definitions to targeted users or classes, creates invoice assignments, and records payments against those invoices.
```mermaid theme={null}
flowchart LR
A[Create receiving account] --> B[Create category]
B --> C[Create fee]
C --> D[Target users or classes]
D --> E[Generate assignments]
E --> F[Student invoice]
F --> G[Record payment]
G --> H[Review and reconcile]
```
## Guides
| Goal | Guide |
| ------------------------------------------------- | -------------------------------------------------------------- |
| Prepare accounts, categories, and fee definitions | [Setting Up Fees and Accounts](/fees/setup) |
| Target users or classes and generate invoices | [Assigning Fees](/fees/assigning-fees) |
| Review and manage student invoices | [Managing Student Invoices](/fees/managing-invoices) |
| Record, correct, and reconcile payments | [Recording and Reconciling Payments](/fees/recording-payments) |
| Understand the learner's fees view | [Viewing Fees as a Student](/fees/student-guide) |
## Who can do what?
| Role | Typical capabilities |
| ----------------------------------- | ------------------------------------------------------------------------ |
| Student | View their own invoices, amounts, due dates, payment history, and status |
| Finance operator or permitted staff | Manage fee definitions, invoices, and payment records |
| Dean or administrator | Configure accounts and categories and oversee school-wide fee operations |
Fee records affect the school's financial ledger. Confirm the user, invoice, amount, receiving account, and payment status before saving or deleting anything.
# Recording and Reconciling Payments
Source: https://docs.kralis.app/fees/recording-payments
Record money against the correct invoice and correct mistakes safely.
## Record a payment
1. Open the intended invoice.
2. Choose the payment action.
3. Confirm the read-only invoice identifier.
4. Enter the payment amount, date, status, reference, receiving information, and other fields shown.
5. Save and confirm the invoice's paid and outstanding summaries update.
## Reconciliation workflow
```mermaid theme={null}
flowchart LR
A[Receive payment evidence] --> B[Find invoice]
B --> C[Record payment]
C --> D[Compare amount and reference]
D --> E{Correct?}
E -->|Yes| F[Confirm or retain status]
E -->|No| G[Edit or remove incorrect payment]
G --> D
```
The **Payments** page provides search and filters for reviewing recorded payments. Compare the record with the school's receiving account or payment evidence before treating it as confirmed.
## Correct a mistake
Update the payment when the transaction remains valid but a permitted detail is wrong. Delete it only when the payment record itself should not exist. After correction, recheck the related invoice balance.
Never create another payment merely to cancel a mistaken one unless that is the school's documented accounting method. Use the edit or delete action provided to authorized operators.
# Setting Up Fees and Accounts
Source: https://docs.kralis.app/fees/setup
Create receiving accounts and categories before defining school fees.
## Recommended setup order
```mermaid theme={null}
flowchart LR
A[Bank or receiving account] --> B[Fee category]
B --> C[Fee definition]
C --> D[Targets]
```
## Receiving accounts
Open **Fees Manager → Bank accounts** to create an account. Record the account identity, bank, branch, account type, status, and whether it should be the default where those fields apply.
A fee can point to a receiving account so operators and families know where it is expected to be paid.
## Fee categories
Open **Fee categories** to create reusable classifications such as tuition, transport, examination, or another school-defined category. Keep category names distinct and descriptions clear.
## Create a fee
Open **Fees Manager → New fee**, then complete:
* category and receiving account;
* title or description;
* amount and due information;
* academic year and optional term scope; and
* the other status or behavior fields shown by the form.
After the fee exists, configure its target groups, users, or classes.
## Safe deletion
Before deleting an account, category, or fee, check whether fees, invoices, or payments already refer to it. Historical financial records should remain understandable. If deletion is blocked, update or stop using the setup record instead of trying to remove its history.
# Viewing Fees as a Student
Source: https://docs.kralis.app/fees/student-guide
Understand your invoices, balances, due dates, and recorded payments.
Open **Fees** to view invoices assigned to your account.
## Read an invoice
| Value | What it tells you |
| ----------------- | ----------------------------------------------- |
| Fee | What the charge is for |
| Amount | Total amount assigned |
| Paid | Amount currently recorded as paid |
| Outstanding | Amount still due in Kralis |
| Due date | When payment is expected |
| Receiving account | Where the school expects payment, when provided |
## Payment records
An amount handed over or transferred may not appear immediately if the school still needs to record or confirm it. Keep the school's payment evidence and contact its finance office when a valid payment is missing or incorrect.
## Privacy
Students see their own fee information according to account permissions. A copied Kralis page link does not grant another person access to the invoice.
Kralis displays the financial records entered or confirmed by the school. Questions about policy, waivers, deadlines, or accepted payment methods should go to the school.
# Dashboard and Navigation
Source: https://docs.kralis.app/getting-started/dashboard-navigation
Move between Kralis modules and understand role-dependent shortcuts.
The dashboard is the signed-in starting point for school work. It shows module tabs and shortcuts allowed by the user's role and the school's enabled products.
| Area | Purpose |
| ------------------- | ------------------------------------------------------------- |
| Module tabs | Move among SRMS, CBT, LMS, Classroom, and other enabled areas |
| Page navigation | Return to the current module's home or open its related pages |
| Bottom navigation | Reach common destinations on supported screen sizes |
| Dashboard shortcuts | Open high-frequency actions for the signed-in role |
## Role-dependent visibility
Two users in the same school can see different actions. Students receive learner workflows; teachers see assigned teaching tools; deans and administrators see broader management areas.
```mermaid theme={null}
flowchart LR
A[Sign in] --> B[Load role and school]
B --> C[Dashboard shortcuts]
B --> D[Enabled module tabs]
C --> E[Role-permitted page]
D --> E
E --> F[Page-level authorization]
```
| Symptom | Likely explanation |
| ----------------------------------- | ------------------------------------------------- |
| Entire module missing | Product is unavailable to the school or role |
| Module exists but action is missing | Role or object-level permission does not allow it |
| Page opens but list is empty | Filters, school setup, eligibility, or pagination |
| Direct link shows forbidden | The URL does not grant permission |
If a module or action is unavailable:
1. Confirm you are signed into the intended school account.
2. Return to the dashboard and reopen the module.
3. Check whether the school has enabled the product.
4. Ask an administrator to verify your role and relationships.
A direct URL does not bypass module availability or permissions. Kralis still checks the signed-in user and school.
# Get Help
Source: https://docs.kralis.app/getting-started/get-help
How to use Kralis guides, when to contact support, and what details make a support request actionable.
Kralis support works best when schools use the right channel for the right kind of need.
## Capabilities
The help flow supports:
* self-service guide usage
* support escalation when needed
* better issue reporting
* faster operator-to-support handoff
## Start with self-service guidance
Use product guides first when the need is:
* setup sequencing
* normal workflow clarification
* a reminder of where a feature lives
* best-practice usage guidance
## Contact support when needed
Escalate to support when the issue is:
* blocking school operations
* related to access or account problems
* likely a bug
* dependent on school-specific configuration
* unclear after checking the guides
```mermaid theme={null}
flowchart TD
A[Something did not work] --> B{Normal workflow question?}
B -->|Yes| C[Use product guide]
B -->|No| D{Access, data, or configuration?}
D -->|Yes| E[Ask school administrator]
D -->|No| F{Bug, outage, or API issue?}
F -->|Yes| G[Contact Kralis support]
F -->|No| H[Collect details and reproduce once]
H --> G
```
## What to include in a support request
A strong request includes:
* your school or organization name
* the Kralis area involved, such as SRMS, CBT, LMS, Classroom, Fees, AI, or accounts
* the affected user or role, without sharing passwords
* what you expected to happen
* what happened instead
* screenshots, dates, error messages, or reference IDs when available
| Include | Never include |
| -------------------------------------------- | -------------------------------------------------- |
| School name and affected role | Password or Access PIN |
| Page and action | Access or refresh token |
| Filters and academic context | Full payment credentials |
| Time, timezone, and error message | Unnecessary personal or medical information |
| Safe screenshot with sensitive values hidden | Private recording or document link shared publicly |
## Keep requests specific
Vague requests slow support down.
Instead of saying:
* "results are not working"
Prefer something like:
* "In SRMS Results, after filtering JSS 2 and 2026/2027 First Term, opening one student's result fails after generation"
## Operational support rule
When reporting a problem, always include the filters or selections that were in use at the time. Many Kralis workflows are scoped by year, term, class, section, subject, or user.
## Feature links
* [Quickstart](/quickstart)
* [Roles and Daily Use](/roles/overview)
* [Kralis Classroom](/classroom/overview)
* [Reference](/reference/overview)
# Install Kralis
Source: https://docs.kralis.app/getting-started/install-kralis
How users can install Kralis on Android, iOS, or as a web app using the same install options exposed in Kralis Web.
Kralis is offered through multiple access paths depending on the user's device and preferred workflow.
## Supported access paths
* Android
* iOS
* web app or progressive web app
| Access path | Best fit | Installation source |
| ------------- | --------------------------------------------------- | ---------------------- |
| Android app | Common school phones and app-style access | Google Play Store |
| iOS app | iPhone and iPad users | Apple App Store |
| Web app | Shared devices, desktops, and any supported browser | `kralis.app` |
| Installed PWA | Browser-based access with an app-like launcher | Browser install action |
```mermaid theme={null}
flowchart TD
A[Choose device] --> B{Mobile store app preferred?}
B -->|Android| C[Google Play]
B -->|iPhone or iPad| D[App Store]
B -->|No| E[Open Kralis Web]
E --> F{Browser offers Install?}
F -->|Yes| G[Install PWA]
F -->|No| H[Use browser or Add to Home Screen]
```
![Kralis install experience]()
## Android
Android is appropriate when the school wants mobile access for daily operational work on common Android devices.
Install link:
* [Google Play Store](https://play.google.com/store/apps/details?id=dev.netrobase.kralis)
Use Android when:
* staff rely heavily on phones
* the school wants a more app-like mobile experience
* operators need quick access to attendance, results, communication, or fees
## iOS
iOS is appropriate for Apple-device users who want the same school access on iPhone or iPad.
Install link:
* [Apple App Store](https://apps.apple.com/us/app/kralis/id6748902735)
## Web app and PWA
The web app or installable progressive web app is the most universal path.
The install page in Kralis Web does not point to a fixed external PWA URL. It uses the browser's install capability when available and otherwise guides the user through manual browser installation.
Use it when:
* the school works mainly from desktops or laptops
* the team wants browser-based access without a store install
* a device is managed in a shared or low-friction environment
## PWA install behavior
If the browser supports app installation, Kralis can prompt the user to install the web app directly.
If that browser-level prompt is not available, the expected fallback is manual installation guidance such as:
* Chrome or Edge: use the browser menu and choose the Kralis install option
* Safari: use the share action and choose `Add to Home Screen`
* Firefox: use the browser menu and choose the install option where supported
## Recommendation
Choose the access method based on the school's device reality rather than trying to force a single pattern for everyone.
Many schools will use a mix:
* admins and finance staff on desktop web
* teachers on mobile or desktop
* students on mobile web or installed app flows
## Classroom device guidance
Live Classroom access requires a current browser or installed app that supports camera and audio access over a secure connection.
* grant camera and microphone permission only when needed;
* headphones reduce echo in shared spaces;
* screen sharing depends on browser and operating-system support and is usually easiest on desktop;
* a user without camera or microphone can still join in listen-only mode;
* lower-end devices should keep camera off and use Classroom low-bandwidth mode when the network is constrained;
* test one representative school device before a large scheduled class.
See [Joining and the Live Room](/classroom/joining-and-live-room) for the complete media workflow.
## Related support contacts from the install page
* email: [info@netrobase.dev](mailto:info@netrobase.dev)
* phone: [+2349028366697](tel:+2349028366697)
* WhatsApp: [wa.me/2349028366697](https://wa.me/2349028366697)
# Onboard a School
Source: https://docs.kralis.app/getting-started/onboard-a-school
How the Kralis onboarding flow works, what information is collected, and what to prepare before creating a new school account.
Kralis provides a guided onboarding flow for registering a school and creating its first administrative access.
This flow is designed for a school operator, not for a technical installer.
## Capabilities
The onboarding flow supports:
* new school registration
* first-admin creation
* school identity setup
* rollout and plan selection
## What the onboarding flow collects
The app onboarding flow is organized around five steps:
1. school profile
2. admin access
3. contact details
4. location
5. plan and channel
```mermaid theme={null}
flowchart LR
A[School profile] --> B[Admin access]
B --> C[Contact details]
C --> D[Location]
D --> E[Plan and channel]
E --> F[Review and create]
```
| Step | Review before continuing |
| ---------------- | ---------------------------------------------------------- |
| School profile | Official name, stable acronym, and identifying information |
| Admin access | Intended first administrator and private credential |
| Contact details | Reachable school email and phone |
| Location | Correct country, region, city, and address |
| Plan and channel | Appropriate rollout size and commercial path |
![Kralis onboarding flow]()
## Information to prepare
Before starting, have these ready:
* official school name
* preferred school acronym
* primary admin PIN or password policy decision
* school email and phone
* school address, city, country, and state/region
* expected rollout size or plan
## Acronym and admin identity
The school acronym matters operationally because it becomes part of the school identity and user credential patterns.
The onboarding flow also derives the first administrative identity from that acronym, so choose it carefully and keep it short, readable, and stable.
## Practical guidance
* treat onboarding as the creation of a live school workspace
* keep the first admin access secure
* verify contact and location details before submission
* choose the intended rollout size honestly so the school starts on the right path
## After onboarding
The next recommended order is:
1. review school settings
2. create the academic year and terms
3. create classes, sections, and subjects
4. create staff and student accounts
5. begin module-specific work such as results, CBT, LMS, Classroom, attendance, or fees
Developers building a custom client use the same onboarding flow. The school can be configured through Kralis Web before the custom client calls its API data.
## Feature links
* [Quickstart](/quickstart)
* [School Setup](/school-setup/overview)
* [Install Kralis](/getting-started/install-kralis)
* [Kralis Classroom](/classroom/overview)
# Kralis Docs
Source: https://docs.kralis.app/index
Public user guides and developer documentation for Kralis.
![Kralis dashboard preview]()
Kralis is a school management platform for student records, academic results, computer-based testing, learning content, live classrooms, collaborative whiteboards, attendance, and fees.
This documentation is the public product guide. It explains how schools should use Kralis in practice.
Use these starting points:
* [Quickstart](/quickstart) for the fastest path from a new school account to daily use.
* [Onboard a School](/getting-started/onboard-a-school) for the school creation flow.
* [Install Kralis](/getting-started/install-kralis) for device access options.
* [Dashboard and Navigation](/getting-started/dashboard-navigation) for module tabs and role-dependent shortcuts.
* [School Setup](/school-setup/overview) for academic structure, users, and Access PINs.
* [Roles and Daily Use](/roles/overview) for admin, dean, teacher, and student workflows.
* [Students](/students/overview) for creating, importing, moving, and reviewing students.
* [Promotions](/students/promotions) for year-end class promotion history and execution.
* [Get Help](/getting-started/get-help) for support guidance.
* [Reference](/reference/overview) for API surfaces and terminology.
* [Developer Guide](/developers/overview) for architecture, API, and release expectations.
## Capabilities
Kralis supports:
* school setup and academic structure
* role-based school operations
* student records and imports
* academic results and reports
* attendance workflows
* CBT workflows
* LMS workflows
* live Classroom events, video meetings, recordings, and whiteboards
* fees and payment workflows
* API-driven integrations
## Product areas
* School setup: years, terms, classes, sections, subjects, users, permissions
* Students: create, import, update, archive, and move between classes
* Results: annual records, scores, reports, promotions
* Attendance: daily attendance and summaries
* CBT: question banks, tests, attempts, and results
* LMS: courses, content, enrollment, and progress
* Classroom: live media, scheduling, access, attendance, recordings, whiteboards, and collaboration groups
* Fees: fee structures, assignments, and payments
## Documentation audiences
* school operators who need product guidance
* implementation teams who need workflow and terminology clarity
* developers working on Kralis or integrating against its APIs
## Feature links
* [Onboard a School](/getting-started/onboard-a-school)
* [Install Kralis](/getting-started/install-kralis)
* [School Setup](/school-setup/overview)
* [Students](/students/overview)
* [Results](/results/overview)
* [Attendance](/attendance/overview)
* [CBT](/cbt/overview)
* [LMS](/lms/overview)
* [Classroom](/classroom/overview)
* [Fees](/fees/overview)
* [School Broadcasts](/broadcasts/overview)
* [Kralis AI](/ai/overview)
* [User Management](/user-management/overview)
* [Profile and Account](/account/profile-and-security)
* [School Billing](/billing/overview)
* [Developer Guide](/developers/overview)
# Building Modules, Lessons, and Units
Source: https://docs.kralis.app/lms/building-course-content
Create, edit, remove, and reorder each level of an LMS course.
## Content hierarchy
```mermaid theme={null}
flowchart TD
A[Course] --> B[Module]
B --> C[Lesson]
C --> D[Unit]
D --> E[Content]
D --> F[Optional assessment]
```
| Level | Use it for |
| ------ | -------------------------------------------------- |
| Course | The complete learning experience |
| Module | A major topic or stage |
| Lesson | A focused part of a module |
| Unit | The page or activity a learner opens and completes |
## Build in order
1. Create the course.
2. Add a module to the course.
3. Add a lesson inside that module.
4. Add units inside the lesson.
5. Edit each unit's content.
6. Reorder each level to match the teaching sequence.
7. Preview the course.
## Unit content
Write for the learner who will see the unit without the editor around it. Use clear headings, short sections, useful examples, and an explicit completion goal.
## Attach CBT assessments
Use **Choose a test** in the editor to attach an existing eligible CBT test. Confirm the assessment matches the unit and course context. Editing the LMS connection does not rewrite the CBT questions.
## Reordering and deletion
Reordering changes navigation order. Deleting a parent can affect the content beneath it, so check child modules, lessons, or units and active enrollments before confirming.
Do not delete published content merely to hide it temporarily. Use the available visibility or publication controls when the content may be needed again.
# Using LMS as a Course Author
Source: https://docs.kralis.app/lms/course-author-guide
Create a course, build its content, preview it, and prepare it for learners.
## Find courses
Open **LMS → Courses**. Search by title and use the year, term, class, subject, and teacher filters to narrow the list. Empty and loading states reflect the current filters, so clear a restrictive filter before assuming a course is missing.
## Create a course
1. Open the LMS editor.
2. Choose **Course** and create a course.
3. Enter the title, description, academic context, author, and visibility details offered by the form.
4. Save before adding child content.
5. Add modules, lessons, and units.
6. Preview the learner experience.
7. Make the course available according to its publication and visibility settings.
## Editor areas
| Area | Purpose |
| ------- | -------------------------------------------------- |
| Course | Edit the course record and content structure |
| Preview | Review how the course reads before learners use it |
| Tests | Connect eligible CBT assessments to course content |
## Publication and visibility
Keep unfinished content unavailable to learners. Before changing visibility or publication state, check the course title, content order, unit text, assessments, and enrollment audience.
## Preview and share
Use course preview to inspect the complete structure. The course page also provides a course link that can be copied or shared. Recipients must still sign in and have access; the link does not bypass enrollment or school permissions.
## Author checklist
* [ ] Course details are complete
* [ ] Modules, lessons, and units are in order
* [ ] Every learner-facing unit has usable content
* [ ] Connected tests are correct
* [ ] Preview has been checked on desktop and a smaller screen
* [ ] Intended students are enrolled
# Managing Enrollments
Source: https://docs.kralis.app/lms/managing-enrollments
Give learners course access and manage enrollment status safely.
An enrollment connects one learner to one course and carries that learner's course status and progress.
## Enrollment workflow
```mermaid theme={null}
flowchart LR
A[Choose course] --> B[Choose learner]
B --> C[Create enrollment]
C --> D[Student opens course]
D --> E[Progress is recorded]
E --> F[Update status or review]
```
## Create an enrollment
Open **LMS → Enrollments**, choose the course and learner, complete the status fields, and save. Search first to avoid creating an unnecessary duplicate.
## Statuses
Use the status displayed by the enrollment interface to understand whether access is active and where the learner is in the course lifecycle. Status names may include states such as active, completed, or otherwise unavailable according to the current school workflow.
## Enrollment details
Open an enrollment to review course navigation, content preview, test preview, and recorded progress. Update the enrollment when its access state should change.
## Delete safely
Deleting an enrollment can remove the learner's connection to their course history. Confirm the learner, course, completion state, and any assessment activity before deletion.
Removing an enrollment does not delete the course or the student's school account.
# Learning Management System
Source: https://docs.kralis.app/lms/overview
Build structured courses, enroll learners, deliver units, and review progress.
Kralis LMS organizes learning as **Course → Module → Lesson → Unit**. Authors build and preview content; enrolled students move through units and assessments while Kralis records progress.
```mermaid theme={null}
flowchart LR
A[Create course] --> B[Add modules]
B --> C[Add lessons]
C --> D[Add units and assessments]
D --> E[Preview course]
E --> F[Enroll students]
F --> G[Students complete units]
G --> H[Review progress]
```
## Guides
| Goal | Guide |
| ---------------------------------------------- | -------------------------------------------------------------------- |
| Create, configure, preview, and share a course | [Using LMS as a Course Author](/lms/course-author-guide) |
| Build and arrange the content hierarchy | [Building Modules, Lessons, and Units](/lms/building-course-content) |
| Add, update, and remove enrollment records | [Managing Enrollments](/lms/managing-enrollments) |
| Navigate and complete a course | [Taking a Course as a Student](/lms/student-guide) |
| Understand completion and connected CBT tests | [Course Progress and Assessments](/lms/progress-and-assessments) |
## Capabilities by role
| Role | Typical capabilities |
| ------------------------ | --------------------------------------------------------------------------------------------------- |
| Student | View enrolled courses, open units, complete available content and assessments, and monitor progress |
| Course author or teacher | Create and edit courses, build content, attach tests, preview, and manage permitted enrollments |
| Dean or administrator | Manage school-wide courses and enrollments according to assigned permissions |
Kralis Classroom is independent from LMS. A future course attachment can connect a requested live classroom to a course without making either module depend on the other.
# Course Progress and Assessments
Source: https://docs.kralis.app/lms/progress-and-assessments
Understand unit completion, course progress, and CBT assessment connections.
## How progress works
Course progress is calculated from the learner's recorded unit activity and completion within the enrollment. Opening a course does not by itself mean the course is complete.
| Level | What to review |
| ------ | -------------------------------------------------------------- |
| Unit | Whether the learner completed the individual learning activity |
| Lesson | Progress across its units |
| Module | Progress across its lessons |
| Course | Overall completion across the course structure |
If an author adds or removes units, the course structure—and therefore the meaning of overall progress—can change.
## Assessments
Authors can connect eligible CBT tests to LMS content. The LMS provides the learning context; CBT owns the questions, session, attempt, and score workflow.
```mermaid theme={null}
flowchart LR
A[LMS unit] --> B[Connected CBT test]
B --> C[Eligible session]
C --> D[Student attempt]
D --> E[CBT performance review]
```
## Review progress
Open the learner's enrollment to inspect their content and assessment progress. Distinguish between:
* a unit that is available but not completed;
* a completed unit;
* an assessment that has not been attempted; and
* an attempt that has been submitted but still needs review.
Future Classroom-to-course attachment will be documented when that interface is implemented. Classroom events are currently managed independently.
# Taking a Course as a Student
Source: https://docs.kralis.app/lms/student-guide
Find an enrollment, navigate course content, and complete units and assessments.
## Learning journey
```mermaid theme={null}
flowchart LR
A[Open LMS] --> B[Choose enrolled course]
B --> C[Open module]
C --> D[Open lesson]
D --> E[Study unit]
E --> F[Complete activity or test]
F --> G[Continue to next unit]
G --> H[Review progress]
```
## Navigate a course
Open an enrolled course and use its module and lesson structure to find a unit. Within a unit, use the previous and next controls to continue in sequence.
## Complete units
Read the full unit and perform any requested activity. Use the completion action shown by the course when the work is finished. Progress is based on recorded unit completion, not merely opening a page.
## Take an assessment
When a unit includes a CBT test, open it from the course, read its session instructions, and submit through the CBT experience. Assessment availability may differ from the rest of the unit.
## If content is unavailable
Check that you are signed into the correct school account and that the enrollment is active. Some units or tests may also depend on publication, sequence, or timing. Contact the course teacher if the expected content remains unavailable.
# Quickstart
Source: https://docs.kralis.app/quickstart
The fastest safe order for setting up a school and starting normal academic operations in Kralis.
This is the shortest recommended order for setting up a school in Kralis.
```mermaid theme={null}
flowchart LR
A[Academic structure] --> B[Staff accounts]
B --> C[Students]
C --> D[Access setup]
D --> E[Daily modules]
E --> F[Review and reporting]
F --> G[Year-end promotion]
```
| Stage | Ready when |
| ------------------ | ------------------------------------------------------------------ |
| Academic structure | Current year, terms, ordered classes, sections, and subjects exist |
| Staff accounts | Roles and teaching relationships are correct |
| Students | Active learners have compatible class and section placement |
| Access setup | Sign-in credentials or Access PINs are safely distributed |
| Daily modules | Module-specific settings and audiences have been reviewed |
| Year end | Results are complete and the next academic year exists |
## 1. Create the academic structure
Start with:
* current academic year
* terms
* classes
* sections
* subjects
Sections can either be general school sections or be tied to a single class. If a section is tied to a class, it can only be used with students and records for that class.
## 2. Add users
Create the staff accounts that will manage school operations.
Typical roles are:
* admin
* dean
* teacher
Use permissions deliberately. Kralis operations are scoped to the signed-in user's school.
## 3. Add students
Students can be created one by one or imported in bulk.
When adding a student, set:
* the current class
* the current section, if one applies
* the contact information required by your school
Kralis records who created a student when that creation path supplies an authenticated user context.
## 4. Issue Access PINs
Use Access PINs to provision student sign-in credentials in schools that use PIN-based account distribution.
## 5. Begin academic operations
After setup, proceed with daily work such as:
* score entry and result generation
* attendance
* CBT setup
* LMS enrollment
* Classroom events and whiteboards
* fee assignment
Classroom works independently of LMS. Before running a scheduled class, review the event audience, media defaults, waiting room, recording notice, attendance thresholds, and the school limits under [Classroom Settings](/classroom/school-settings-and-operations).
## 6. Run promotions at the right time
Promotions should be treated as a deliberate academic operation, usually after the current year is complete and the next year already exists.
Related pages:
* [Dashboard and Navigation](/getting-started/dashboard-navigation)
* [Create the Next Year](/school-setup/create-next-year)
* [Import Students](/students/import-students)
* [Run Promotion](/students/run-promotion)
* [Kralis Classroom](/classroom/overview)
* [Using Classroom as a Teacher](/classroom/teacher-guide)
* [Using SRMS as a Teacher](/results/teacher-guide)
* [Creating CBT Tests](/cbt/creating-tests)
* [Using LMS as a Course Author](/lms/course-author-guide)
* [Setting Up Fees and Accounts](/fees/setup)
# Glossary
Source: https://docs.kralis.app/reference/glossary
Shared Kralis terminology for operators, implementers, and developers.
## Core terms
* school: the tenant boundary for almost all Kralis data
* year: the academic year for a school, stored in strict sequence
* term: a period inside an academic year
* class: the academic level in the school hierarchy
* section: a student grouping that may be global or tied to a single class
* Access PIN: a PIN inventory record used for student access workflows
## Classroom
* Classroom event: the durable scheduled or instant live-class definition
* Classroom session: one live run of an event
* event audience: invite-only, class with optional section, or school-wide
* event role: host, moderator, presenter, participant, or observer
* admission: a persistent waiting-room request and decision
* participant: a Kralis user’s event-level role and participation summary
* presence interval: one verified join-to-leave interval used for attendance
* expected attendee: a user frozen into a scheduled event’s attendance roster
* attendance override: an audited manager status that preserves calculated evidence
* recording segment: one independently numbered MP4 operation for a session
* presentation source: native whiteboard, shared screen, or none
* Classroom whiteboard: a standalone persistent Excalidraw board
* whiteboard revision: an immutable saved board document
* editor lease: the renewable right held by the board's current active editor
* collaboration group: a reusable Classroom cohort, separate from global Kralis authorization groups
* operational issue: a persistent Classroom incident available for manager review and resolution
## Student operations
* promotion: the school-scoped operation that moves students to the next class
* annual record: the year-level academic record tied to a student and class
* created by: the user context captured when a student is created through a supported path
## Interfaces
* GraphQL: the main application API used by Kralis Web
* GraphiQL: the browser-based GraphQL explorer
* Swagger UI: interactive REST reference
* ReDoc: REST reference presentation
# Reference
Source: https://docs.kralis.app/reference/overview
Main Kralis API surfaces and product reference entry points.
This section points to the main Kralis API and product reference surfaces.
## Capabilities
The reference area supports:
* live API discovery
* REST and GraphQL entry-point lookup
* terminology alignment
* role and permission lookup
* supported Classroom client workflow reference
## API surfaces
| Surface | Purpose |
| ---------------------------------------------------- | ------------------------------------------------------------------------------ |
| [GraphiQL](https://api.kralis.app/graphiql/) | Interactive access to the complete GraphQL schema and authentication mutations |
| [GraphQL API](https://api.kralis.app/graphql/) | GraphQL authentication and product operations for custom clients |
| [REST authentication](https://api.kralis.app/auth/) | Compatible SimpleJWT login and token lifecycle used by Kralis Web |
| [REST schema](https://api.kralis.app/schema/) | Machine-readable REST authentication contract |
| [Swagger UI](https://api.kralis.app/schema/swagger/) | Interactive REST authentication reference |
| [ReDoc](https://api.kralis.app/schema/redoc/) | Readable REST authentication reference |
```mermaid theme={null}
flowchart LR
A[Product user] --> B[User guides]
C[School operator] --> D[Role and workflow reference]
E[Client developer] --> F[Developer Guide]
F --> G[GraphiQL and OpenAPI]
```
## Notes
* GraphQL is the primary product API.
* Developers authenticate with `login`, explore through `/graphiql/`, and send application operations to `/graphql/`.
* Kralis Web authenticates through REST and sends product operations to `/graphql/`.
* School scoping is part of the authorization model. A valid ID from another school must not grant access.
## Glossary
* school: the tenant boundary
* year: the academic year record for a school
* term: a term within a year
* class: the academic level, such as JSS 1 or SS 2
* section: a student grouping that may be global or class-bound
* Access PIN: a PIN inventory record used for student access workflows
Developer entry point:
* [Developer Guide](/developers/overview)
* [Classroom API Integration](/developers/classroom-integration)
## Feature links
* [Glossary](/reference/glossary)
* [Roles and Permissions](/reference/roles-and-permissions)
* [Classroom](/classroom/overview)
* [Developer Guide](/developers/overview)
# Roles and Permissions
Source: https://docs.kralis.app/reference/roles-and-permissions
A public summary of the main Kralis roles and how permissions shape what users see.
Kralis combines role-driven product behavior with permission-aware operations.
## Main user-facing roles
* admin
* dean
* teacher
* student
| Role | Default product focus |
| ------- | --------------------------------------------------------------------- |
| Admin | School setup, accounts, policies, billing, and broad operations |
| Dean | Academic and operational management |
| Teacher | Assigned teaching, assessment, course, Classroom, and attendance work |
| Student | Personal learning, tests, Classroom, results, attendance, and fees |
## Practical meaning
Roles affect:
* which sections appear in navigation
* which workflows can be initiated
* which school data can be viewed or changed
## Important rule
Do not infer access only from the presence of a screen in a screenshot or guide. Actual behavior still depends on the signed-in user and the school's configured permissions.
## Classroom roles are event-specific
Classroom adds host, moderator, presenter, participant, and observer roles for one event. These do not replace the user’s global admin, dean, teacher, or student role.
* the event creator is its host;
* school administrators and deans can manage school events as moderators;
* a teacher or other user may be a host, moderator, or presenter through an event grant;
* a student may be a participant or observer through audience matching or a grant;
* when several access sources apply, Kralis uses the strongest event role.
```mermaid theme={null}
flowchart LR
A[Global school role] --> C[Effective action]
B[Object-specific relationship] --> C
D[Current school and object state] --> C
C --> E[Visible and authorized workflow]
```
| Permission layer | Example |
| -------------------- | ---------------------------------------------------------------------- |
| Global school role | Teacher, student, dean, or admin |
| Relationship | Assigned subject, LMS enrollment, CBT eligibility, or class membership |
| Object-specific role | Classroom host, moderator, presenter, participant, or observer |
| Object state | Draft, published, live, ended, archived, or unavailable |
See [Classroom Access and Roles](/classroom/access-and-roles).
# Generating and Reviewing Results
Source: https://docs.kralis.app/results/generating-and-reviewing-results
Use Result Manager to create, inspect, update, and safely remove results.
## Open Result Manager
Choose the academic year, result period, class, and optional section. Use the search and selection controls to narrow the learners shown.
| Filter | Effect |
| ----------------- | -------------------------------------------- |
| Result period | Switches between termly and annual results |
| Year and term | Selects the academic window |
| Class and section | Narrows the learner cohort |
| Search | Finds a learner in the current filtered list |
## Generate results
Result generation uses the saved scores for the chosen period. Confirm that scoresheets are complete before generating. If a result already exists, use the available update or regeneration action instead of creating an accidental duplicate.
## Read a result
| Value | Interpretation |
| ------------- | -------------------------------------------------------------------------------- |
| Subject total | Combined score components for that subject |
| Grade | Grade produced by the school's grading rules |
| Average | Mean performance across the included subjects or learners, depending on the view |
| Position | Relative placement within the selected result cohort |
| Remark | Comment generated or entered for the result |
Open the individual result page to see one learner's full subject breakdown and available actions.
## Update or delete
Update a result after correcting its underlying entries or when the displayed result needs regeneration. Delete only when the result was created in error and should no longer exist.
Removing a result is not the same as correcting a score. If the scoresheet data is wrong, correct it first, then update or regenerate the result.
## Review checklist
* correct learner and period;
* expected subjects are present;
* totals and grades are plausible;
* averages and positions use the intended cohort;
* remarks are suitable; and
* the printable report matches the reviewed result.
# Managing Scoresheets
Source: https://docs.kralis.app/results/managing-scoresheets
Select a scoresheet, manage its learners, and enter termly or annual marks.
## Scoresheet context
Every scoresheet is identified by a combination of academic fields.
| Field | Purpose |
| ------------- | -------------------------------------------- |
| Academic year | Keeps entries within the correct school year |
| Term | Selects the term for termly work |
| Class | Selects the learner cohort |
| Class section | Optionally narrows the selected class |
| Subject | Selects the subject being assessed |
A section is compatible when it is general or belongs to the selected class. If the section list looks wrong, reselect the class first.
## Manage enrollment
1. Select the scoresheet context.
2. Open **Scoresheet Enrollments**.
3. Compare the enrolled list with the learners expected for the subject.
4. Add or remove learners as needed.
5. Return to the scoresheet and confirm the list.
## Individual and bulk work
Use row or card actions to create and update one entry. Use the table and available bulk controls when many learners need the same operation. Bulk work is faster, but the selected learners and context should be reviewed before confirmation.
## Score components
The exact fields come from the school's assessment setup. A school may use components such as **Kickoff**, **Classwork**, **Assignment**, **Project**, **Test**, and **Exam**. Calculated fields such as total and grade are displayed for review and are not ordinary score inputs.
## Termly and annual entries
* **Termly entries** belong to a selected term.
* **Annual entries** summarize the academic year and may depend on completed termly information.
Do not use an annual entry as a substitute for missing termly scores. Correct the underlying term data first where appropriate.
## Safe editing rules
* Search by learner when the list is long.
* Verify the context after changing a filter.
* Save before leaving the page.
* Treat zero and “not entered” as different when the form distinguishes them.
* Delete only when the entry itself should not exist.
# Results and SRMS
Source: https://docs.kralis.app/results/overview
Enter scores, generate results, compile performance, and prepare school reports.
Kralis SRMS turns subject scores into reviewed termly or annual results. It preserves the academic context—year, term, class, section, and subject—through every stage.
```mermaid theme={null}
flowchart LR
A[Select academic context] --> B[Manage scoresheet enrollment]
B --> C[Enter scores]
C --> D[Review totals and grades]
D --> E[Generate results]
E --> F[Generate remarks]
F --> G[Compile performance]
G --> H[Print or export reports]
```
## Where to begin
| Goal | Guide |
| ---------------------------------------------------- | ------------------------------------------------------------------------------- |
| Understand the full teacher workflow | [Using SRMS as a Teacher](/results/teacher-guide) |
| Select context, enroll learners, and enter scores | [Managing Scoresheets](/results/managing-scoresheets) |
| Generate, review, update, or remove results | [Generating and Reviewing Results](/results/generating-and-reviewing-results) |
| Prepare remarks, compilations, and printable reports | [Remarks, Compilations, and Reports](/results/remarks-compilations-and-reports) |
## Result periods
| Period | Meaning |
| ------ | --------------------------------------------------------------------- |
| Termly | A learner's result for one term in an academic year |
| Annual | A combined view of the learner's performance across the academic year |
Scores, grades, positions, averages, and remarks depend on the school's configured subjects, grading rules, and academic context. Review the context shown on screen before saving or generating anything.
## Who does what?
| Role | Typical actions |
| -------------------- | -------------------------------------------------------------------------------------------------------------- |
| Teacher | Manage assigned scoresheets, enroll learners, and enter or update scores |
| Dean | Review broader academic data, generate results and remarks, compile performance, and prepare reports |
| School administrator | Configure supporting school data and perform the same school-wide result operations permitted by their account |
| Student | View result information made available through the student experience |
# Remarks, Compilations, and Reports
Source: https://docs.kralis.app/results/remarks-compilations-and-reports
Generate comments, interpret performance compilations, and prepare result reports.
## Generate remarks
Open **Remarks**, select the academic year, result period, class, and optional section, then generate remarks for the intended results. Existing remarks can be regenerated when the underlying results have changed.
Regenerating can replace earlier generated text. Review the affected learners before confirming and read the new remarks afterward.
## Compile performance
Compilation brings results together for comparison and review.
```mermaid theme={null}
flowchart LR
A[Choose period] --> B[Choose class and section]
B --> C[Load completed results]
C --> D[Review totals and averages]
D --> E[Interpret positions and distribution]
E --> F[Prepare report]
```
Interpret every compilation within its selected filters. A class compilation and a section compilation can contain different learners and therefore different averages and positions.
## Prepare reports
1. Open **Report**.
2. Select the required academic period and learner cohort.
3. Preview the report data.
4. Check names, subjects, grades, averages, positions, and remarks.
5. Print or export using the available report controls.
## Before distribution
| Check | Why it matters |
| ------------------- | -------------------------------------------------------------------- |
| Academic context | Prevents distributing a report for the wrong term or year |
| Result completeness | Avoids incomplete subject rows and misleading averages |
| Remarks | Ensures comments are appropriate for the learner |
| Cohort | Confirms positions and comparisons use the intended class or section |
| Print preview | Catches layout or page-break problems before printing |
## Related guides
* [Managing Scoresheets](/results/managing-scoresheets)
* [Generating and Reviewing Results](/results/generating-and-reviewing-results)
# Using SRMS as a Teacher
Source: https://docs.kralis.app/results/teacher-guide
A practical workflow from scoresheet selection to reviewed results.
## Complete workflow
```mermaid theme={null}
flowchart LR
A[Open Scoresheet] --> B[Choose context]
B --> C[Confirm enrollment]
C --> D[Enter scores]
D --> E[Review totals and grades]
E --> F[Open Result Manager]
F --> G[Review generated results]
```
## 1. Select the correct context
Open **SRMS → Scoresheet** and select the academic year, term, class, optional class section, and subject. Select the class before the section so Kralis can show only compatible sections.
Check the context summary before editing. A score entered under the wrong term or subject belongs to that wrong context until corrected.
## 2. Confirm scoresheet enrollment
Open **Scoresheet Enrollments** to check which learners belong to the selected scoresheet. Add missing eligible learners or remove an incorrect enrollment before entering marks.
Enrollment controls who appears in that subject's scoresheet; it does not create or move the student's school enrollment.
## 3. Choose a working view
| View | Best for |
| ---------- | -------------------------------------------------------------------- |
| Cards View | Working carefully with one learner at a time and using row actions |
| Table View | Comparing many learners and entering or reviewing scores efficiently |
Switching views does not create another scoresheet or discard saved entries.
## 4. Enter and review scores
Use the score fields configured by the school, such as classwork, assignment, project, test, or examination. Kralis calculates derived values such as total and grade where configured.
Before moving on:
* confirm every score is attached to the intended learner;
* check totals against the permitted maximums;
* review missing or unusual values; and
* save completed changes.
## 5. Review results
Open **Result Manager**, select the same academic context, and review termly or annual results. Use an individual result page when one learner needs closer inspection or correction.
Deleting a score entry or result removes academic information. Read the confirmation, verify the learner and period, and prefer correcting an incorrect value when the record should continue to exist.
## Teacher checklist
* [ ] Correct year and term
* [ ] Correct class, section, and subject
* [ ] Enrollment list confirmed
* [ ] All required score components entered
* [ ] Totals and grades reviewed
* [ ] Generated results checked
# Admin and Dean Workflows
Source: https://docs.kralis.app/roles/admin-and-dean
The main day-to-day workflows typically available to admin and dean users in Kralis.
Admin and dean users drive most school-wide setup and operations.
## Capabilities
Admin and dean access commonly supports:
* school setup and configuration
* academic structure management
* student and staff management
* school-wide academic workflows
* attendance review and management
* fee and communication workflows
## Core areas commonly available
* school profile and structure
* students and archives
* teachers and board-member records
* classes, sections, and subjects
* fees manager
* broadcasts
* SRMS
* CBT
* LMS
* Classroom events, recordings, attendance, and whiteboards
* attendance review and management
Admins additionally tend to have the broadest access to school settings and user management.
## Typical operating order
```mermaid theme={null}
flowchart LR
A[Review school context] --> B[Maintain people and structure]
B --> C[Run academic operations]
C --> D[Review attendance and finance]
D --> E[Communicate and monitor]
E --> F[Audit outcomes]
```
1. confirm the current school setup is correct
2. confirm users, classes, sections, and subjects exist
3. create or review student records
4. run academic workflows such as SRMS, CBT, LMS, or Classroom
5. configure Classroom operational limits and recording notices
6. manage attendance, communication, and fees as needed
## Common admin-only concerns
* school settings
* Access PIN inventory
* broader user management
## Common dean concerns
* academic oversight
* fee workflows
* broadcasts
* operational review of attendance and student records
## Responsibility matrix
| Area | Admin emphasis | Dean emphasis |
| --------------------- | ---------------------------- | ---------------------------------------------- |
| School configuration | Primary ownership | Review or delegated management |
| Users and permissions | Broad account administration | Operational staff oversight |
| Academic structure | Configure and protect | Validate for academic workflows |
| SRMS, CBT, and LMS | Enable and oversee | Generate, review, and coordinate |
| Classroom | Policy and school limits | Events, attendance, recordings, and moderation |
| Fees and billing | School billing and access | Fee operations when authorized |
| Broadcasts | School-wide control | Targeted operational communication |
## Frequent mistakes to avoid
* entering scores before the academic structure is stable
* promoting students before the next year exists
* using class-bound sections with the wrong class
* assuming a student-facing issue is unrelated to class, section, or year setup
## Feature links
* [School Settings](https://kralis.app/school)
* [Access PINs](https://kralis.app/access-pins)
* [Students](https://kralis.app/dashboard)
* [Teachers](https://kralis.app/teacher)
* [Board Members](https://kralis.app/dean)
* [Users](https://kralis.app/user)
* [SRMS](https://kralis.app/srms)
* [Generating and Reviewing Results](/results/generating-and-reviewing-results)
* [CBT](https://kralis.app/cbt)
* [Running a CBT Session](/cbt/running-sessions)
* [LMS](https://kralis.app/lms)
* [Managing LMS Enrollments](/lms/managing-enrollments)
* [Classroom](https://kralis.app/classroom)
* [Using Classroom as a Teacher](/classroom/teacher-guide)
* [Classroom School Settings](https://kralis.app/school/classroom)
* [Fees](https://kralis.app/fees)
* [Setting Up Fees and Accounts](/fees/setup)
* [Attendance](https://kralis.app/attendance)
* [Managing and Correcting Attendance](/attendance/managing-and-correcting)
* [School Broadcasts](/broadcasts/overview)
* [User Management](/user-management/overview)
* [School Billing](/billing/overview)
# Roles and Daily Use
Source: https://docs.kralis.app/roles/overview
How the Kralis experience changes by role and which workflows are typically available to admins, deans, teachers, and students.
Kralis is strongly role-aware. The app does not present every workflow to every user in the same way.
The most important public roles are:
* admin
* dean
* teacher
* student
## Capabilities
Role-aware access in Kralis supports:
* different navigation by user role
* different workflow access by user role
* school-setup dependence for daily operations
* student-facing self-service where enabled
## Why role documentation matters
Many support and onboarding issues are not product failures at all. They are the result of:
* expecting a workflow that belongs to another role
* missing school setup
* missing class, section, or subject assignment
* missing permissions or incorrect current school context
## Role summary
* admins usually manage school settings, structure, access PINs, users, and the broadest operational workflows
* deans usually share many academic and school-operations workflows with admins
* teachers typically work in teaching-facing modules such as results, tests, LMS, Classroom, and attendance
* students mainly consume their own results, tests, courses, attendance context, live classes, and fee information
Use the role pages in this section to understand the expected daily experience.
| Workflow | Student | Teacher | Dean / administrator |
| ------------------------------ | ------------- | ------------------------------- | ----------------------------------- |
| View own profile and account | Yes | Yes | Yes |
| Enter subject scores | No | When assigned | When permitted |
| Take a CBT test | Yes | Only when eligible as a learner | Only when eligible as a learner |
| Author CBT or LMS content | No | When permitted | When permitted |
| Join Classroom | When eligible | When eligible | When eligible |
| Moderate Classroom | No by default | When host or moderator | When host or moderator |
| Manage users and school setup | No | No by default | According to management permissions |
| View own fees | Yes | When assigned | When assigned |
| Manage school fees and billing | No | No by default | When authorized |
## Feature links
* [Admin and Dean Workflows](/roles/admin-and-dean)
* [Teacher Workflows](/roles/teacher)
* [Student Workflows](/roles/student)
* [Dashboard and Navigation](/getting-started/dashboard-navigation)
# Student Workflows
Source: https://docs.kralis.app/roles/student
The student-facing experience in Kralis, including results, tests, courses, fees, and profile-related access.
Students interact with a narrower, self-service version of Kralis.
```mermaid theme={null}
flowchart TD
A[Student dashboard] --> B[Results]
A --> C[CBT]
A --> D[LMS]
A --> E[Classroom]
A --> F[Attendance]
A --> G[Fees]
```
## Capabilities
Student access commonly supports:
* profile self-service
* result viewing
* test taking and performance review
* course access
* live class participation and personal Classroom attendance
* personal fee review
## Typical student areas
* profile
* current and archived results
* CBT tests
* CBT performance
* LMS courses and enrollments
* visible Classroom events, published recordings, and shared whiteboards
* personal fee view
## What students depend on
Student access often depends on correct setup behind the scenes:
* current class
* current section
* active academic year and term
* readiness of results or tests
* assigned enrollments or fee records
## When students say something is missing
Common causes include:
* the result is not ready yet
* the student is in the wrong class or section
* the selected year or term is wrong
* the student has not been enrolled or assigned correctly
* the Classroom event is still a draft, targets another class or section, or has not granted the student access
| Missing item | First checks |
| --------------- | ------------------------------------------------------------------ |
| Result | Year, term, class/section, and generation/publication readiness |
| CBT session | Eligibility, availability window, and previous attempt state |
| LMS course | Enrollment status and course visibility |
| Classroom event | Publication, audience, schedule, direct access, and archived state |
| Whiteboard | Board visibility, user/class/group grant, and archive state |
| Fee invoice | Fee target, assignment generation, and signed-in account |
## Student support rule
Before escalating a student complaint, confirm the student's class, section, year, term, and role context first.
## Feature links
* [Profile](https://kralis.app/profile)
* [SRMS](https://kralis.app/srms)
* [CBT](https://kralis.app/cbt)
* [CBT Tests](https://kralis.app/cbt/tests)
* [Taking a Test as a Student](/cbt/student-guide)
* [LMS](https://kralis.app/lms)
* [My Enrollments](https://kralis.app/lms/enrollments)
* [Taking a Course as a Student](/lms/student-guide)
* [Classroom](https://kralis.app/classroom)
* [Using Classroom as a Student](/classroom/student-guide)
* [My Fees](https://kralis.app/fees/invoices)
* [Viewing Fees as a Student](/fees/student-guide)
* [Checking Daily Attendance](/attendance/checking-daily-attendance)
# Teacher Workflows
Source: https://docs.kralis.app/roles/teacher
The main learning, results, testing, and attendance workflows teachers typically use in Kralis.
Teachers usually work inside teaching and academic-delivery workflows rather than full-school setup.
## Capabilities
Teacher access commonly supports:
* profile management
* class and subject-based academic work
* result-entry and review workflows
* CBT participation as an operator
* LMS teaching workflows
* live Classroom teaching, presentation, and whiteboard workflows
* classroom attendance workflows
## Typical teacher areas
* profile
* assigned classes and subjects
* SRMS workflows such as scoresheets and results
* CBT tests and questions, where allowed
* LMS courses and teaching content
* Classroom events, waiting rooms, participants, recordings, and whiteboards
* attendance workflows relevant to classroom operations
## What teachers depend on
Teacher success in Kralis depends on the school having already configured:
* the academic year and terms
* classes and sections
* subjects
* the teacher's class or subject relationship where required
## Good daily pattern
```mermaid theme={null}
flowchart LR
A[Confirm year and term] --> B[Choose class, section, subject]
B --> C[Complete teaching workflow]
C --> D[Review saved state]
D --> E[Publish, submit, or report]
```
1. open the relevant academic period
2. filter to the intended class, section, and subject
3. perform the workflow
4. review before export, publish, or print
## Teacher caution
When a list or result seems wrong, check the filter context first. Many pages in Kralis are filter-driven and may appear empty or incomplete until the class, subject, year, or term is narrowed correctly.
## Typical capability boundaries
| Workflow | Typical teacher position |
| ------------------------ | ------------------------------------------------------------------------- |
| Scoresheets | Enter and review assigned subject marks |
| Results | Review or generate when permitted |
| CBT | Author content and run assigned sessions |
| LMS | Build or manage courses they are permitted to author |
| Classroom | Create when permitted; host, present, or moderate according to event role |
| Attendance | Use the daily or management actions allowed by school role |
| School setup and billing | Usually read-only or unavailable |
## Feature links
* [Profile](https://kralis.app/profile)
* [SRMS](https://kralis.app/srms)
* [Scoresheet](https://kralis.app/srms/entry/)
* [Using SRMS as a Teacher](/results/teacher-guide)
* [CBT](https://kralis.app/cbt)
* [CBT Tests](https://kralis.app/cbt/tests)
* [CBT Questions](https://kralis.app/cbt/questions)
* [Creating CBT Tests](/cbt/creating-tests)
* [LMS](https://kralis.app/lms)
* [Using LMS as a Course Author](/lms/course-author-guide)
* [Classroom](https://kralis.app/classroom)
* [Using Classroom as a Teacher](/classroom/teacher-guide)
* [Attendance](https://kralis.app/attendance)
# Access PINs
Source: https://docs.kralis.app/school-setup/access-pins
How Kralis uses Access PIN inventory records for student access workflows.
Access PINs are the inventory records used for student access workflows in schools that distribute PIN-based sign-in details.
## Capabilities
The Access PIN area supports:
* credential inventory management
* student access preparation
* PIN assignment workflows
* secure handling of distributed PIN data
## What an Access PIN is
An Access PIN is not just a label in the UI. It is a backend record used to provision and track student access credentials.
An unassigned Access PIN can exist before it is tied to a student.
## Operational guidance
* keep unused PIN inventory under control
* assign PINs deliberately
* treat exported or shared PIN lists as sensitive student access data
## Working with the page
1. Open **Access PINs** and search or filter the current inventory.
2. Review whether each PIN is available or already associated with a learner.
3. Use the populate action when the school needs additional inventory.
4. Assign or distribute only the intended records.
5. Reopen the list and confirm the assignment state.
| Situation | Safe response |
| -------------------------- | --------------------------------------------------------------------------- |
| Learner already has access | Do not issue another PIN without investigating |
| PIN appears assigned | Confirm the associated learner before changing it |
| Export is required | Limit access to the file and remove extra copies after use |
| Populate action fails | Refresh the inventory before retrying to avoid assuming nothing was created |
An Access PIN is a credential. Do not place it in broadcasts, Classroom chat, Kralis AI, or public documents.
## Naming
Kralis uses the `Access PIN` terminology in the product because that is the language schools already use in the UI.
## Feature links
* [Access PINs page](https://kralis.app/access-pins)
* [Profile and Account Security](/account/profile-and-security)
# Classes and Sections
Source: https://docs.kralis.app/school-setup/classes-and-sections
How classes and sections are modeled in Kralis and how section-class validation works.
Classes and sections define where students belong academically and operationally.
## Capabilities
This area supports:
* academic-level structure
* section grouping
* class-bound section rules
* downstream validation for student and annual records
## Classes
Classes represent academic levels such as:
* Primary 1
* JSS 1
* SS 2
Promotion behavior depends on class hierarchy, so class ordering is not just a display detail.
## Sections
Sections are grouping labels inside a school.
Kralis supports two section patterns:
* global sections that can be reused across classes
* class-bound sections that can only be used with one class
This matches a common school pattern where many students stay in the same broad section over time, while some sections exist only for a specific class setup.
## Validation
If a section is tied to a class, Kralis will reject using that section with any other class.
This applies in student updates, annual records, and bulk operations.
## Practical guidance
* use global sections when the school wants flexible grouping
* use class-bound sections when the section only makes sense inside one class
* keep section naming simple and operator-friendly
## Create and update
Create classes in their academic progression order, then create sections. When a section belongs only to one class, select that class on the section record. Leave it general only when the same section should be reusable across classes.
Before deleting a class or section, search for students, teachers, academic entries, events, and other records that still use it. Correct or move those relationships first.
```mermaid theme={null}
flowchart LR
A[Create class] --> B[Set hierarchy]
B --> C[Create section]
C --> D{Class-specific?}
D -->|Yes| E[Attach class]
D -->|No| F[Keep section general]
E --> G[Use compatible placements]
F --> G
```
## Feature links
* [Classes page](https://kralis.app/classe)
* [Class Sections page](https://kralis.app/classe-section)
# Create the Next Year
Source: https://docs.kralis.app/school-setup/create-next-year
How to create the next academic year in sequence and what Kralis will enforce automatically.
Kralis treats year creation as a controlled academic operation.
## Capabilities
This year-creation task supports:
* strict academic-year progression
* next-year creation without gaps
* downstream readiness for terms and promotion
## What Kralis enforces
* year names must follow the `YYYY/YYYY+1` pattern
* the next year must continue the existing sequence without gaps
* the normal client mutation creates the next valid year rather than accepting an arbitrary year name
## Recommended operator flow
1. Confirm the current year is correct.
2. Confirm the school is actually ready to move forward academically.
3. Create the next year through the normal client workflow.
4. Create the terms for that year.
5. Review any downstream setup before promotions begin.
## What not to do
* do not try to skip ahead several academic years
* do not use year names as free-form labels
* do not rely on manual deletion to correct poor year planning
## Feature links
* [School Settings](https://kralis.app/school)
* [Years and Terms](/school-setup/years-and-terms)
# School Setup
Source: https://docs.kralis.app/school-setup/overview
The recommended order for configuring a school before students, results, fees, or promotions begin.
School setup establishes the academic structure and operational permissions that all later work depends on.
## Capabilities
The school setup area supports:
* academic year and term setup
* class and section structure
* subject definition
* role and permission groundwork
* access-PIN preparation
## Recommended order
```mermaid theme={null}
flowchart LR
A[School profile] --> B[Year and terms]
B --> C[Classes and sections]
C --> D[Subjects]
D --> E[Staff and roles]
E --> F[Students and Access PINs]
F --> G[Module settings]
G --> H[Daily operations]
```
1. Create the current academic year.
2. Create the terms for that year.
3. Create classes in the intended hierarchy.
4. Create sections.
5. Create subjects.
6. Create staff users and assign permissions.
7. Prepare Access PIN inventory if students will sign in with PINs.
8. Review Classroom room, recording, storage, retention, and consent policy before the first live class.
## What depends on setup?
| Setup record | Used by |
| --------------------- | ---------------------------------------------------------------------------------------- |
| Current year and term | SRMS, CBT, LMS, Fees, Attendance, Classroom context, and reports |
| Classes and sections | Student placement, result filters, tests, courses, events, broadcasts, and fee targeting |
| Subjects | Scoresheets, results, CBT, LMS, Classroom context, and broadcasts |
| Users and roles | Every permission-controlled workflow |
| Access PINs | Schools distributing PIN-based student access |
| Module policies | Module-specific limits, notices, publication, and operational behavior |
Task pages:
* [Create the Next Year](/school-setup/create-next-year)
## Years
Kralis enforces a strict year sequence. A year name must follow the `YYYY/YYYY+1` pattern, and new years are expected to continue the sequence without gaps.
Example:
* `2025/2026`
* `2026/2027`
* `2027/2028`
## Sections
Sections support two patterns:
* global sections that can be used across classes
* class-bound sections that are restricted to one class
If a section is class-bound, Kralis will reject using it with another class.
## Access PINs
Access PINs are PIN inventory records that can later be assigned to students. An unassigned Access PIN is not yet tied to a school account holder.
## Permissions
Use the minimum permissions needed for each role. The common operational roles are admin, dean, and teacher.
Changing or deleting setup records after operational data exists can change filters and historical interpretation. Prefer preserving used records and changing the school's current context.
## Feature links
* [Years and Terms](/school-setup/years-and-terms)
* [Create the Next Year](/school-setup/create-next-year)
* [Classes and Sections](/school-setup/classes-and-sections)
* [Subjects and Users](/school-setup/subjects-and-users)
* [Access PINs](/school-setup/access-pins)
* [Classroom School Settings](/classroom/school-settings-and-operations)
# Subjects and Users
Source: https://docs.kralis.app/school-setup/subjects-and-users
How to define subjects, operational roles, and basic permission expectations in Kralis.
After the academic structure exists, define what is taught and who is allowed to operate each part of the school.
## Capabilities
This area supports:
* subject catalog setup
* role-aware user preparation
* permission groundwork
* creator accountability for student records where available
## Subjects
Subjects should be created clearly and consistently so score entry, reports, and CBT setup remain understandable.
Keep names stable. Changing a subject naming style repeatedly creates operator confusion even when the system still accepts the data.
## Users
The main operational roles are:
* admin
* dean
* teacher
These are all school-scoped in normal use. Operators should only see and manage their own school's records through the application.
## Permission guidance
* give the smallest permission set that still lets the person do the work
* use admin accounts carefully
* keep role boundaries clear where the school wants accountability
## Student records and creators
Student creation can capture which signed-in user created the student record. This helps answer who added a student when the system has that request context.
## Practical setup workflow
```mermaid theme={null}
flowchart LR
A[Create subjects] --> B[Create staff accounts]
B --> C[Assign teacher classes]
C --> D[Assign teacher subjects]
D --> E[Test role navigation]
```
Search active and inactive account lists before creating a duplicate. For teachers, review the **Classes** and **Subjects** tabs after saving their personal details. Deactivate an established account when its history should remain, and delete only after reading the confirmation and checking linked records.
## Feature links
* [Subjects page](https://kralis.app/subject)
* [Teachers page](https://kralis.app/teacher)
* [Board Members page](https://kralis.app/dean)
* [Users page](https://kralis.app/user)
* [Managing Users, Teachers, and Deans](/user-management/users-teachers-and-deans)
# Years and Terms
Source: https://docs.kralis.app/school-setup/years-and-terms
Strict academic year sequencing and term setup expectations in Kralis.
The academic year structure should be established before results, attendance, promotion, and most reporting workflows.
## Years
Kralis expects years to be sequential and strictly named in the `YYYY/YYYY+1` format.
Valid examples:
* `2025/2026`
* `2026/2027`
Invalid patterns include:
* a single year like `2026`
* a descriptive label like `2026 Session`
* gaps such as creating `2028/2029` when `2027/2028` does not exist
## Operational guidance
* create the next year only when the school is ready to move forward
* keep one current working year in focus
* avoid trying to repair academic history through repeated year creation and deletion
## Create the next year
1. Open **School Settings → Years**.
2. Review the latest existing year.
3. Enter the immediately following `YYYY/YYYY+1` value.
4. Save, then create its terms.
5. Set the current academic context only when the school is ready to use it.
Kralis shows validation when the format is invalid, the year already exists, or the sequence skips the expected next year. Correct the value instead of creating an artificial intermediate history.
## Terms
Terms belong to a year. Create the terms needed by the school after the year is created.
Use a consistent naming pattern across the school so score entry, reports, and attendance stay predictable.
Deleting a year or term that already carries scores, results, fees, courses, sessions, or attendance can damage the meaning of historical records. Keep used academic periods and change the current selection instead.
# Class and Section Changes
Source: https://docs.kralis.app/students/class-and-section-changes
How student class changes should work and why section-class validation matters.
Student movement between classes should be explicit and validated.
## Capabilities
This workflow supports:
* student class updates
* section reassignment
* class-section validation
* downstream academic consistency
## Change rules
When updating a student's current class and section:
* a global section can stay attached
* a class-bound section must match the selected class
If the section does not match, the operation should be corrected before save.
## Why this matters
Allowing mismatched class and section data creates downstream problems in:
* annual academic records
* filtered views
* promotions
* any UI that assumes section context is valid for the class
## UI guidance
Where possible, show section options with class context so operators can see when a section is bound to a specific class.
## Change a placement
1. Find the student in the active or inactive list.
2. Open **Change Student Class**.
3. Select the destination class.
4. Select a general section or one belonging to that class.
5. Save and verify the student's row and academic context.
If the current section becomes incompatible after changing the class, choose a valid replacement or leave the section empty. Do not preserve a mismatched section merely to retain its label.
## Feature links
* [Students area](https://kralis.app/dashboard)
* [Classes and Sections](/school-setup/classes-and-sections)
# Import Students
Source: https://docs.kralis.app/students/import-students
How to approach bulk student import safely when names and identities are not perfectly deduplicable.
Bulk student import is efficient, but it is also one of the easiest places to introduce bad identity data.
## Capabilities
This import workflow supports:
* bulk student onboarding
* operator review before commit
* duplicate-signal review
* class and section placement verification
## Import principles
* treat the import file as proposed data, not guaranteed truth
* review class and section assignments carefully
* use duplicate signals as support for the operator, not as an automatic final answer
## Why duplicate detection is hard
* the same student may appear under multiple valid name arrangements
* two different students may share the same or very similar names
* schools may have inconsistent historical naming quality
## Recommended workflow
1. prepare a clean file
2. run the import
3. review likely duplicates or related students surfaced by the client
4. decide whether each row should create a new student or map to an existing one
5. verify the resulting class and section placement
## Before upload
| Check | Reason |
| --------------------- | ----------------------------------------------------- |
| Required columns | Prevents avoidable row failures |
| Names and identifiers | Makes later search and duplicate review dependable |
| Class names | Must match the intended school structure |
| Sections | Must be general or compatible with the selected class |
| Existing learners | Prevents recreating a student already in Kralis |
## Validation and confirmation
Treat every validation message as a row-level instruction. Correct the source file when the same problem affects several rows; use the operator review when a potential duplicate needs human judgment.
After submission, keep the success and failure summary until failed rows have been corrected. Reimport only the records that still need creation.
## Follow-up checks
After a major import, verify:
* student counts
* class counts
* section placement
* access credential expectations if the school uses Access PINs
* failed-row count and error reasons
* inactive or duplicate-looking accounts
## Feature links
* [Students area](https://kralis.app/dashboard)
* [Students overview](/students/overview)
# Imports and Creation
Source: https://docs.kralis.app/students/imports-and-creation
Student creation paths, import guidance, and why duplicate detection must stay operator-assisted.
Task page:
* [Import Students](/students/import-students)
Kralis supports creating students individually and in bulk.
## Individual creation
Use individual creation when:
* the school is adding a small number of students
* an operator needs to carefully review each field
* the student has special placement details
Complete the student's identity and contact fields, then choose the current class and a compatible section. Review the generated or assigned access details before closing the form.
## Bulk imports
Bulk import is the better path when a school is onboarding or moving large student sets.
## Duplicate caution
Student identity cannot be guaranteed from name matching alone.
Two different students may legitimately share similar or identical names, while a single student may appear in multiple naming arrangements.
That means duplicate handling should be treated as operator assistance, not as automatic truth.
## Suggested operating rule
* use fuzzy matching to surface likely related students
* let the operator decide whether the row is new or existing
* avoid hard-blocking imports based only on names
## After either method
Confirm the learner appears in the intended active or inactive list, can be found by search, has the correct class and section, and has the expected access method. Use [Student Archive](/user-management/student-archive) when the learner belongs to historical rather than current records.
# Students
Source: https://docs.kralis.app/students/overview
Student creation, imports, class-section rules, and creation tracking in Kralis.
Kralis supports both one-by-one student creation and bulk import workflows.
```mermaid theme={null}
stateDiagram-v2
[*] --> Proposed
Proposed --> Active: Create or import
Active --> Active: Update class or section
Active --> Promoted: Run promotion
Promoted --> Active: Continue in destination year
Active --> Archived: Leave or complete school
Archived --> Active: Restore with valid placement
```
## Capabilities
The student area supports:
* student creation
* bulk import
* class and section placement
* archive review
* creator tracking where supported
## Core student data
A student record usually includes:
* name
* current class
* current section when applicable
* admission and identification details
* contact details
## Choose the right operation
| Need | Operation |
| --------------------------------- | --------------------------------------- |
| Add one learner carefully | Individual student creation |
| Add a prepared cohort | Bulk import with duplicate review |
| Move one current learner | Change Student Class |
| Move a cohort into the next year | Promotion workflow |
| Retain a former learner's history | Archive |
| Return an archived learner | Restore from Student Archive |
| Remove a record created in error | Delete only after linked-history review |
## Class and section rules
When assigning a student section:
* a global section can be used with any class
* a class-bound section must match the selected class
The same validation also applies to related annual academic records.
## Creation tracking
Kralis stores `created_by` on student records when the creation path provides a signed-in user context. This answers who created the student record.
Older records and some import/system-created records may not have this value.
## Imports
Bulk imports should be reviewed carefully before commit because student identity is not something a system can deduplicate perfectly from names alone.
Use duplicate checks and operator review as support, not as a guarantee.
Task pages:
* [Import Students](/students/import-students)
* [Run Promotion](/students/run-promotion)
## Feature links
* [Imports and Creation](/students/imports-and-creation)
* [Import Students](/students/import-students)
* [Class and Section Changes](/students/class-and-section-changes)
* [Promotions](/students/promotions)
* [Run Promotion](/students/run-promotion)
# Promotions
Source: https://docs.kralis.app/students/promotions
Promotion rules, section behavior, and how to review school promotion history.
Promotions are a school-scoped academic operation that move students from one class to the next for a target year.
## Capabilities
The promotion workflow supports:
* controlled year-end student movement
* immutable promotion history
* year and class filtering
* school-wide atomic execution
## Operational rules
* promotions should be run intentionally, not as a side effect of school edits
* the operation is all-or-nothing for a school
* promotion history is read-only through the normal client API
* exceptional cleanup belongs in the Django admin only
## Ordering
Promotion relies on the configured class hierarchy so students are processed in a safe order.
## Sections during promotion
If a student's current section is tied to a different class than the promoted class, that section cannot remain attached after the move.
Client workflows should make this outcome explicit so operators understand when a section will become empty.
## Viewing history
Use the promotions page to:
* review promotion history
* filter by year
* filter by class
* paginate through results
This is the recommended place to run and verify school promotions.
## Confirmation and recovery
The promotion confirmation is the final opportunity to verify the destination year and scope. Do not refresh or start another run while the operation is processing.
Promotion history is the audit record of what moved. It is not an ordinary editable list and should not be deleted to hide a mistake. If a completed promotion has an exceptional problem, stop further academic work and have an administrator review the affected students and history.
Task page:
* [Run Promotion](/students/run-promotion)
## Feature links
* [Run Promotion](/students/run-promotion)
* [School Settings](https://kralis.app/school)
# Run Promotion
Source: https://docs.kralis.app/students/run-promotion
How to run school promotions safely, what happens to sections, and how to review the result.
Promotion should be run as a deliberate academic event, not as a side effect of editing a school record.
## Capabilities
This promotion task supports:
* controlled promotion execution
* class-hierarchy progression
* section cleanup where needed
* post-promotion verification
## Preconditions
Before running promotion:
1. the current year's work should be complete enough for the school
2. the next academic year should already exist
3. class hierarchy should be correct
4. operators should understand the section behavior for class-bound sections
Use the promotion page's year and class filters to review the intended scope before starting. Read the final confirmation as an academic operation, not a routine form save.
## What the operation does
* promotes students by class hierarchy order
* records immutable promotion history
* runs atomically for the school
## Section behavior
Global sections can remain attached.
Class-bound sections only remain valid when they still match the promoted class. If they no longer match, they are cleared rather than preserved incorrectly.
## After promotion
Review:
* promotion history
* student counts in destination classes
* section placement for affected students
* promotion history, destination year, and operator-visible counts
Refresh the destination student list and inspect a sample from every affected class. If the operation reports an error, do not start another promotion until the displayed outcome and history have been checked.
## Feature links
* [School Settings](https://kralis.app/school)
* [Promotions overview](/students/promotions)
# User Management
Source: https://docs.kralis.app/user-management/overview
Create and manage general users, teachers, deans, and archived student records.
Kralis separates general users, teachers, board members or deans, and students so each account can carry the correct school information and permissions.
| Area | Purpose |
| ------------------ | ----------------------------------------------------------------- |
| User Management | Search and manage general school user accounts |
| Teachers & Faculty | Manage teacher profiles, classes, and subjects |
| Board Members | Manage dean or school leadership profiles |
| Students | Manage active and inactive learner records |
| Student Archive | Find historical learner records and restore them when appropriate |
See [Managing Users, Teachers, and Deans](/user-management/users-teachers-and-deans) and [Student Archive](/user-management/student-archive).
```mermaid theme={null}
flowchart TD
A[School person] --> B{Primary school role}
B -->|General| C[User account]
B -->|Teaching staff| D[Teacher profile]
B -->|Leadership| E[Dean or board profile]
B -->|Learner| F[Student profile]
F --> G{Current learner?}
G -->|Yes| H[Active or inactive students]
G -->|No| I[Student Archive]
```
| Change | Preferred operation |
| --------------------------------------------------------- | ---------------------------------- |
| Temporary loss of access | Deactivate the account |
| Teacher assignment change | Update Classes and Subjects |
| Student leaves school | Archive when history should remain |
| Archived student returns | Restore with compatible placement |
| Record was created by mistake and has no required history | Delete after confirmation |
# Student Archive
Source: https://docs.kralis.app/user-management/student-archive
Find historical student records, export archive results, and restore a learner safely.
Student Archive preserves learners who are no longer in the active student list while keeping their school history findable.
## Find an archived learner
1. Open **Students → Student Archive**.
2. Use **Archive Filter** to choose the relevant academic context.
3. Search within the returned archive.
4. Review the student's class, section, status, and archive information.
Use **Export Archive** when a permitted operator needs a copy of the filtered archive.
## Restore
Open the archived student's action and follow the restore or class-change workflow shown. Choose a compatible current class and section and review the restored student's active record.
```mermaid theme={null}
flowchart LR
A[Filter archive] --> B[Find learner]
B --> C[Review historical record]
C --> D[Choose restore]
D --> E[Select current placement]
E --> F[Confirm active student]
```
Archiving retains a historical learner record. Deletion removes a record and can break the continuity of linked school history. Use archive for ordinary departures or completed cohorts unless the school has a valid reason and permission to delete.
# Managing Users, Teachers, and Deans
Source: https://docs.kralis.app/user-management/users-teachers-and-deans
Create, search, update, activate, and safely remove school accounts.
## Shared workflow
1. Open the appropriate account page.
2. Filter active or inactive records and search for the person.
3. Open an existing row to edit it, or choose the add action.
4. Complete **Details** and **Extra Details**.
5. For teachers, also review **Classes** and **Subjects**.
6. Save and confirm the user appears in the correct list.
## Choose the right account type
| Type | Use it for |
| ------------------- | -------------------------------------------------------------------- |
| General user | A school member without a teacher, dean, or student-specific profile |
| Teacher | Teaching staff who need class or subject relationships |
| Dean / board member | School leadership with broader management responsibilities |
| Student | A learner attached to school academic records |
Use account status to control normal availability while retaining the record. Check both active and inactive filters before creating a person who appears to be missing.
## Deletion
Deleting an account can affect related academic, attendance, financial, LMS, CBT, or Classroom records. Prefer deactivation when the person has historical activity that should remain attributable.
Permissions follow the account's role and school relationships. Review them after changing a general user into a specialized role or changing a teacher's classes and subjects.