What this module is for
Register visitors, manage gate/current visitor records, checkout, cancel, history, categories, types, and settings.
Prerequisites
- Visitor permissions assigned
- Visitor categories/types configured if used
- Front desk process defined by school
Main screens
Step-by-step workflows
Check in a visitor
- Open Visitor Management.
- Create a visitor entry.
- Enter visitor name, purpose, contact, host, and timing details as required.
- Save check-in.
- Confirm the visitor appears in the current/gate register.
Check out or cancel
- Open current visitors.
- Use checkout when the visitor leaves.
- Use cancel only for invalid or mistaken entries.
- Review history for completed visits.
Operational detail
Permission checkpoints
- Visitor register, gate view, checkout, cancel, setup, reports, and settings require visitor permissions.
- Front desk users should have only the entry and checkout permissions they need.
- Visitor reports and history should remain limited to authorized office or admin users.
Field guidance
Record the visitor name, purpose, contact, and host or department according to school policy.
Use the actual arrival time so current visitor and history reports remain reliable.
Select or enter the staff member, department, or student-related purpose being visited.
Current visitors should remain open until checkout. Cancel only invalid or mistaken entries.
Use the gate/current visitor view for operational monitoring during the day.
Use history to review completed visits and audit front desk activity.
Validation and system feedback
- Visitor entries must be scoped to the authenticated school.
- Checkout is allowed only for currently checked-in visitors.
- Cancel actions should be blocked for states where cancellation no longer makes sense.
- Required purpose/contact fields should follow the school visitor settings.
Common mistakes to avoid
- Leaving visitors open after they have left campus.
- Cancelling a real completed visit instead of checking it out.
- Recording unclear purpose text that is not useful later.
- Sharing visitor logs with users who do not need them.
Recommended next steps
Screenshot plan
Final public screenshots will use synthetic QA data only. Sensitive values such as names, phone numbers, emails, admission numbers, document numbers, credentials, cookies, tokens, and internal IDs must be removed or redacted.
Important safety notes
Use normal Schoolixa workflows
Public docs explain user workflows only. They do not expose internal IDs, direct database operations, credentials, provider prompts, or private system configuration. Permission visibility in the interface does not replace server-side permission checks.