School
Person context
- Start with
- Person + school
- Decision
- Confirm holder
- Next context
- Choose category
Responsibility and limits
Confirm school.
Use the account record and school relationship.
People records do not create or activate logins.
School user account management
Keep school accounts, status and administrator access clear.
School Administrators need Users & Login Management access to maintain four school account categories, status and permissions.
Align ownership. The verified release does not include SMS delivery, SSO, SCIM or a custom-role builder.
People, accounts and access
Related decisions.
Different responsibilities.
- Who needs access?
- Account contextStart with their record.
- What is available?
- Access decisionSet status and permissions.
- Where do they enter?
- Role entryOpen the resolved workspace.
The access decision map
Who they are.
What they can enter.
Six stages show setup, access and verification boundaries. Account category, status and administrator permissions are separate decisions—not interchangeable labels.
Account context
Category
Account type
- Start with
- Person
- Decision
- Select category
- Next context
- Account fields
Responsibility and limits
Select one.
Use the Administrator, Teacher, Parent/Guardian or Student path.
Categories select experiences—not custom roles.
Access control
Availability
Account status
- Start with
- Account
- Decision
- Choose status
- Next context
- Availability
Responsibility and limits
Choose status.
Use supported active, inactive or blocked states.
Invited/alumni states are category-specific.
School Administrator
Admin permissions
- Start with
- School Administrator account
- Decision
- Select groups
- Next context
- Mapped access
Responsibility and limits
Choose permissions.
Choose from Dashboard & Analytics, Users & Login Management, Attendance, Fees, Exams & Results, Timetable, Communication & Documents, and Settings.
Eight named interface permission groups; effective access follows the mapped permission checks—not custom roles.
Verification and entry
Verification
Verify account
- Start with
- Account + mobile
- Decision
- Validate code
- Next context
- Signed-session context
Responsibility and limits
Check the code.
The verified release does not provide a public delivery mechanism for the mobile-number/six-digit-code interface.
Approve delivery; do not assume resend or expiry.
Session
Role entry
- Start with
- School + role + account
- Decision
- Check access
- Next context
- Workspace
Responsibility and limits
Enter workspace.
Representative protected requests resolve school, role and account.
Other roles receive no User Access administration controls.
A guide to the supported decisions, not an account-creation form or an automated provisioning sequence. Expand a decision for its responsibilities and limits.
School Administrator accounts
Eight named groups.
Not a custom-role builder.
Choose from the named interface permission groups. Effective access follows mapped permission checks. Administrator designations are labels, not separate authorization roles.
Current Schylva web workflow · fictional school data
Focused fictional example. On smaller screens, expand to inspect all eight groups; selections are not defaults or recommendations.
One owner, four account paths
Manage access.
Keep role boundaries.
School Administrators maintain supported account controls; other roles use their own context.
Administers supported controls
School Administrators
Maintain accounts and access.
Users & Login Management access is required to maintain accounts and permissions.
Uses assigned or linked context
Teachers
Enter assigned work.
Teachers use assigned work; they do not assign access.
Uses assigned or linked context
Parents/Guardians
Use linked-Student context.
Parents/Guardians see linked active Students—not User Access controls.
Uses assigned or linked context
Students
Enter school context.
Students use their context; they do not manage access.
Relationship evidence
Linked to a student.
Not linked by assumption.
Fictional school data proves only visible states. The account overview is in the hero and the permission grid is above. This third capture shows a configured family relationship.
Parent/Guardian · Linked-Student context
Current Schylva web workflow · fictional school data
Linked Student—not automatic matching, creation or activation.
Controls with clear limits
Supported access.
No implied identity suite.
Review scope, rollout decisions and boundaries.
Supported today
- Four categories: School Administrator, Teacher, Parent/Guardian and Student
- Overview and category lists
- Role-specific paths and statuses
- Eight named interface permission groups
- Representative requests resolve school, role and account
Current boundaries
- No SMS delivery, resend or server-backed expiry claim
- No SSO, SCIM, TOTP, passkeys, WebAuthn or MFA claim
- No arbitrary custom roles, user-defined RBAC or policy engine
- Visible administrator designations are not separate authorization roles
- No automated provisioning, directory sync or access reviews
- No universal revocation or complete account-change audit claim
Ownership before onboarding
Walk in with questions.
Leave with agreed scope.
Trace controls without production identities. Use fictional or redacted examples; do not share real identities, credentials, login codes or student records.
Who should maintain school accounts?
Confirm ownership and access.
How will accounts be offboarded?
Confirm statuses, ownership and session limits.
Which administrator modules should be available?
Map work to groups, not designations.
What verification delivery is required?
The current verified release does not provide SMS delivery.
Validate before rollout
- Account ownership and statuses
- Administrator permissions
- Assignments and family relationships
- Verification delivery
- Migration and deprovisioning
Questions schools ask
Access, without
the assumptions.
Answers reflect the verified release.
Which school account categories are supported?
School Administrator, Teacher, Parent/Guardian and Student each have a path.
Can module access differ by School Administrator?
Yes. Select eight named interface groups per School Administrator; effective access follows mapped checks—not custom roles.
Are the administrator designation choices security roles?
No. Designations are labels; supported permission checks determine effective access.
Does Schylva currently send a login code by SMS?
No public SMS delivery is verified. Approve delivery for the code interface before rollout.
Does creating a Parent/Guardian account link a Student automatically?
No. Account creation does not prove automatic family matching or Student linking; maintain the relationship separately.
Does User Access Management include SSO, SCIM or custom RBAC?
No. SSO, SCIM, directory sync, custom roles, user-defined RBAC and policy engines are outside scope.
An access-focused demonstration
Your roles.
A clearer access plan.
Review categories, status, permissions and verification with fictional examples.
- Fictional School Administrator account
- Administrator permission set
- Other role contexts
- Verification and offboarding approach
We will confirm scope and identity requirements separately. Use fictional examples, not production identities or login codes.