Skip to main contentSchylvaRequest a demo

School ERP access and login management

See how Schylva manages school access and login.

Follow the product paths your school can inspect: administrator-managed accounts, role-aware workspaces, configured login verification, selected audit visibility and controlled file routes.

Request a security reviewSee product evidence

Request a review without sharing student records, login credentials, OTPs, payment details or confidential documents.

  • Four school roles

    Administrator, teacher, parent and student experiences

  • Login verification

    Configured code step; SMS delivery is not currently available

  • Real product evidence

    Account and file workflows shown with sample school data

Start with something inspectable

The account controls.
The limits of a screenshot.

Review the real web interface using sample school data, then request a representative demonstration. A product screenshot is not a security test, infrastructure proof or an assurance report.

Account interface evidence

Review school accounts by role.

The administrator workspace groups administrator, teacher, parent or guardian and student login records by role.

Sample Schylva web login summary with Teacher, Student, School Administrator and Parent or Guardian account categories
Role-account overview · static product screenshotEnlarge screenshot: Role-account overview

Role-account overview

Reviewed sample school data. Static image—product controls are not interactive.

The totals are fictional account values, not adoption metrics or a uniform active-user count. This static overview does not demonstrate account changes, deactivation enforcement or verification delivery.

What this does not prove

This screen demonstrates a product workflow; it is not evidence of infrastructure isolation or a breach-prevention guarantee.

Review user and access management

Account interface evidence

Examine available administrator permissions.

The account preparation screen shows the administrator context and permissions available in the current product workflow.

Eight named administrator permission groups in a reviewed Schylva web screenshot, with sample checked boxes
Administrator permission groups · static product screenshotEnlarge screenshot: Administrator permission groups

Administrator permission groups

Reviewed sample school data. Static image—product controls are not interactive.

These checked boxes are pixels, not live controls, defaults or a recommended permission set. Interface descriptions are not an independent feature checklist or evidence that authorization checks were tested.

What this does not prove

Available permissions do not imply arbitrary custom RBAC, unlimited role creation or enterprise identity administration.

Understand available permissions

These independent static examples do not establish a matched account lifecycle. File preparation and recipient examples appear in the audit-and-files section below.

Access follows a relationship

A school. An account.
A relevant record.

Review the school context, account, role workspace and record together. Test representative users before activation; the presence of a menu or permission checkbox is not proof that a boundary has been enforced.

Four layers to inspect

What it does.
What your school should check.

All four descriptions and limits stay visible while you review.

School context

Begin inside the configured school context.

Product behaviour
Each school works in its configured Schylva environment, which provides the context for its accounts and workflows.
School review
Use representative users to check that they remain in the expected school experience.
Current boundary
This does not imply absolute isolation or a breach-prevention guarantee.

Account

Connect an account to the right school relationship.

Product behaviour
Administrators can create and maintain administrator, teacher, parent and student accounts and work with their account status.
School review
Review account creation, status changes and the expected relationship between the account and the school’s people records.
Current boundary
Schylva is not presented as a universal identity-management platform.

Role workspace

Move into the experience appropriate to the school role.

Product behaviour
Administrators, teachers, parents and students receive focused experiences shaped by their role and the available permissions.
School review
Check the menus, records and available work for representative users in each required role.
Current boundary
This does not imply arbitrary custom roles, unlimited permission design or unrestricted access.

Relevant record

Reach the relevant class, child, person, workflow or file.

Product behaviour
The role experience connects the user to the records and workflows relevant to that school relationship.
School review
Demonstrate representative role-to-record paths using privacy-safe sample school data.
Current boundary
A relevant path does not give a user visibility into every school record.

Account lifecycle

Prepare the account.
Verify the full path.

Confirm the people, relationships, status and permissions before the user enters a role workspace.

  1. Prepare people and relationships

    Confirm who needs an account and how they relate to the school.

    Prepare administrator, teacher, parent and student records, including the relevant class, guardian and child relationships.

  2. Create or maintain the account

    Keep the school account connected to that context.

    Administrators can create and maintain role accounts within the configured school environment.

  3. Apply status and permissions

    Use account status and available administrator permissions.

    The administrator can work with account status and the permissions currently available in Schylva.

  4. Complete configured verification

    Use the current configured code step.

    The current verified web flow accepts a configured six-digit code. It does not generate or send that code by SMS.

  5. Enter the role workspace

    Continue in the appropriate administrator, teacher, parent or student experience.

    The account reaches its role-aware experience and the records relevant to that school relationship.

Operational evidence

Trace the action.
Follow the file.

Use representative actions and files to evaluate coverage, ownership and the intended recipient. Record additional requirements instead of assuming every event or file is covered.

Selected audit visibility

Identify the actions your school needs to review.

Selected school and platform actions can be recorded for audit and review. Coverage and retention depend on the release and school agreement.

  • Confirm which actions matter to the school’s approval process
  • Identify who needs to review the available records
  • Record the applicable coverage and retention
Current boundary

Schylva does not publicly claim that every action is recorded, immutable or retained forever.

Ask in the demo: Which actions matter to our approval, and who needs to review them?

Review user and access management

File routes

Evaluate the path from teacher publication to the relevant role.

Study materials and other supported files use controlled product routes. Demonstrate the teacher-to-recipient path with a representative file.

  • Confirm the file types needed for the school’s launch scope
  • Follow the publication and recipient-access path
  • Record any required access or usage terms
Current boundary

Schylva does not publicly claim every file type, unlimited storage, end-to-end encryption or unrestricted offline access.

Ask in the demo: Can we follow one representative file from publication to the intended recipient?

Review homework and study materials

File-workflow interface evidence

Follow a teacher material path.

The teacher workflow shows how study material can be prepared for the relevant school audience.

Teacher web material form with class selection, Mathematics subject, title and description fields, with no file selected
Teacher material preparation · static product screenshotEnlarge screenshot: Teacher material preparation

Teacher material preparation

Reviewed sample school data. Static image—product controls are not interactive.

A preparation state with no class or file selected—not a completed upload, a published material or evidence of recipient authorization.

What this does not prove

This screen does not prove encryption, a storage quota, unlimited storage or support for every file type.

Review homework and study materials

File-workflow interface evidence

Review the linked-family material path.

The parent experience shows study materials in the context of the relevant linked child.

Parent web study-material workspace showing no new materials and no older matching materials
Parent material workspace · static product screenshotEnlarge screenshot: Parent material workspace

Parent material workspace

Reviewed sample school data. Static image—product controls are not interactive.

An empty historical Parent material view. It does not prove file retrieval, denied access, a matched publication or offline availability.

What this does not prove

This screen does not imply unrestricted or offline access, synchronisation of every resource or support for every file type.

Review the parent experience

The disclosure register

Three answer states.
No implied guarantees.

Separate public product behaviour, school agreement terms and technical details that remain unpublished. These labels describe the source of an answer—not a certification.

Described publicly now

Product behaviour schools can inspect

School context, roles and account controls
Each school works in its configured Schylva environment. Administrators, teachers, parents and students receive focused experiences, while account status and available administrator permissions help shape access.
Configured login verification
The current verified web flow accepts a configured six-digit code. Product-managed SMS delivery is not currently available.
Selected audit and file workflows
Selected school and platform actions can be recorded for review, while files use controlled product routes such as the available paths for study materials.

Confirmed in the school agreement

Product-data terms recorded for the school

Export, retention and deletion
Applicable data-export, product-data retention and deletion terms are addressed in the school’s agreement.

Not publicly stated yet

Topics to bring into the security review

Hosting region and encryption scope
A product-data hosting country or region and encryption scope in transit or at rest are not currently published. Product-data location cannot be inferred from the marketing website’s hosting.
Backup, recovery, uptime and service levels
Backup frequency, retention, restore testing, recovery targets, uptime percentages and service-level guarantees are not currently published.
Incident commitments
A public incident-response process, reporting contact or notification commitment is not currently published.
Certifications and blanket DPDP compliance
No security certification, certification logo or blanket Digital Personal Data Protection Act compliance claim is made on this website.

Security decision gate

Six questions.
A useful review brief.

Use these six questions to test the product and record every requirement that still needs an approved answer. Each question links to the relevant evidence or disclosure above.

Demonstrate in the product

Use representative, privacy-safe school data to follow these paths.

  1. Account lifecycleWho creates, reviews, changes and deactivates each required school account type?
  2. Roles, relationships and loginWhich permissions and school relationships must be validated, and what verified login-delivery method do the intended account holders require?
  3. Audit and file evidenceWhich actions, review periods, file types and recipient paths should the product demonstration cover?

Confirm before approval

Record the terms and unanswered requirements that need written confirmation.

  1. Additional identity needsDoes the school require SSO, SCIM, arbitrary custom roles, MFA or product-managed verification delivery?
  2. Agreement termsWhich export, retention and deletion terms must be confirmed in the school agreement?
  3. Unresolved security questionsWhich hosting, encryption, backup, recovery or incident terms still need an approved answer?
Take these questions into your school’s review.

Copies all six questions. Nothing is submitted or stored. You can also select the text manually.

JavaScript is needed for the copy button. You can select the six questions above manually.

How open questions are resolved

Record the requirement.
Resolve the next step.

The Remonthub product team reviews requirements that are not answered by the product evidence or school agreement.

Review owner
Remonthub product team
Source content reviewed
August 2026

The source review date is retained. This website redesign is not a fresh product-security assessment.

  1. Send the requirement

    Use the security-review request to describe the decision your school needs to make.

  2. Review evidence and scope

    The product team separates demonstrable behaviour, agreement terms and technical details that are not yet published.

  3. Record the next step

    The school receives the available answer, the evidence to inspect or the confirmation needed before approval.

Request a security review

We respond to demo and quote enquiries within two working days, excluding weekends and public holidays. This sales response is not a security-incident response time.

School security FAQs

Straight answers.
Clear boundaries.

Review the current product scope and note what your school still needs to confirm.

Does every user see the same information?

No. Each school works in its configured Schylva environment, and administrators, teachers, parents and students receive role-appropriate experiences. Test representative users against the records and workflows your school needs.

How do users sign in to Schylva?

The current verified web flow accepts a configured six-digit code before the account enters its school and role experience. Schylva does not currently generate or send that code by SMS.

Is SMS used for school updates?

No. WhatsApp and non-login SMS are not product channels. Login verification SMS delivery is not currently available; school updates use Schylva’s in-app and push notification experience at launch.

Does Schylva support SSO, SCIM or arbitrary custom roles?

Schylva does not currently claim SSO, SCIM, arbitrary custom roles, MFA or product-managed verification delivery. Administrators can work with the four school-role accounts, account status and available permissions.

What audit information is available?

Selected school and platform actions can be recorded for audit and review. Confirm the actions covered and applicable retention for your release and agreement; not every action is claimed to be immutable or retained forever.

Where is school product data hosted and how is it encrypted?

The website does not currently publish a product-data hosting country or region or encryption scope in transit or at rest. Do not infer product-data location from the marketing website’s hosting; bring the requirement into the security review.

Are backup and disaster-recovery guarantees published?

Not yet. Backup frequency, retention, restore testing and disaster-recovery targets remain unpublished. Bring any required terms into the security review.

Is Schylva certified under a security standard?

No current security certification or certification logo is claimed on this website. Evaluate a certification only with its verified scope, issuer, validity and supporting record.

How are data export, retention and deletion handled?

Applicable data-export, retention and deletion terms are addressed in the school’s agreement. Formats, self-service workflows and timelines are not currently published.

Does Schylva claim DPDP Act compliance?

No blanket Digital Personal Data Protection Act compliance claim is made on this website. Review the applicable responsibilities, notices and agreement terms for your school’s context.

What should a school confirm before activation?

Confirm account ownership, roles and relationships, permissions, login verification and delivery requirements, audit and file needs, plus any required export, retention, deletion, hosting, encryption, backup or incident terms.

Security review

Your school’s requirements.
An evidence-led conversation.

Bring the roles, login path, audit needs, file workflows and agreement terms your school wants to confirm.

Request a security reviewGet a custom quote

Request a review without sharing student records, login credentials, OTPs, payment details or confidential documents.