You are accountable for who gets onto your site and for what the records say afterwards. In practice that is three jobs: you decide the requests that are waiting (approve, send for review, or decline with a reason), you keep the rules the system enforces up to date (what has to be captured, how long a pass lasts, who is screened), and you answer for the history when somebody asks who was here last Tuesday. Day-to-day check-ins belong to reception; policy and accountability belong to you.
Start here
Your first week, in this order:
- Clear the queue once, by hand. Work through the pending requests in Visitor Registration so you know what an approval actually asks you to decide.
- Decline one request deliberately and read the message the visitor receives, so your reason wording is yours and not the shipped default. Reasons come from the cancellation reason templates.
- Look at yesterday. Open the Visitors Dashboard and the Logbook described in Check-in and Check-out, then generate one report from Reports.
- Check what a pass grants and how long it lasts in Visit Pass - the single setting page with the largest effect on security.
- Check who is screened: Watchlist.
- Then, and only then, change settings. Everything below the approvals section is policy, and policy is easier to change once you have seen a week of real traffic.
Deciding who comes in
Work through today’s requests
Every self-registration, group registration and pre-registration lands in the Registration list with a status. Open a request to see the captured details, the visit reason, the location and the validity window, then approve it (which registers the visitor and issues the pass), or route it onward for review. The list has a filter so you can look at only what is waiting for you, including the manager review and compliance queues.
Full walkthroughs: Visitor Registration for the list and the link, and Group Pre-Registration for the processor screen and an approval end to end.
Decline a request and say why
A refusal is a message to a person, so it carries three deliberate choices: the reason (picked from your prepared list), who is told (the host, the visitor, or both), and a free-text message that goes with it. Write the message as if the visitor will read it out loud, because they will. Keep the reason list short and unambiguous so two managers refuse the same case the same way.
Where the reasons come from: Cancellation. Where the request itself lives: Visitor Registration.
Clear a long queue in one action
When a queue has built up (a Monday after a shutdown, a delayed group), requests can be approved or declined in bulk from the Registration list instead of one at a time. A bulk decline still requires a message and a notification choice, so the people affected are told. Read the summary the system gives you afterwards: it reports how many were processed and how many were skipped, and skipped requests still need you.
The list and its actions: Visitor Registration.
Approve arrivals for the site you manage
A location can require its own manager’s approval on top of the normal flow. When it does, the request shows a notice naming who it will be sent to (the site manager, or a delegate standing in while they are away), and it waits in the Manager Review state until one of them approves it. If you manage a building, this queue is yours: watch it, and appoint a delegate before you take leave rather than after.
Where the requests appear: Visitor Registration.
Add a compliance review step
In regulated environments a nominated compliance officer reviews registrations before the visitor is approved at all. You choose whether the step exists, who the officers are, and the wording of a rejection.
Full walkthrough: Compliance.
Require the host to approve arrivals
For walk-ins and kiosk check-ins, the person being visited can be made to approve before access is granted, with a fallback address and a time limit for when they do not answer. This moves a decision you cannot make (is this person expected?) to the only person who knows.
The settings: Host Approval. What hosts and visitors experience: Host Approval.
Answering for what happened
Review the day and the history
The Visitors Dashboard is the live picture; the Logbook is the permanent one, holding every status change with the operator, the timestamp and the visit details. Go to the Logbook for “who was on site”, “when did they leave” and “who processed this”.
Full walkthrough: Check-in and Check-out.
Generate the reports your organisation asks for
Reports turn that history into something you can send: visitor movement, events, vehicles, area occupancy and time on site. Pick the report type, the date range and the format, and generate it.
Full walkthrough: Reports. The rules that turn entry and exit events into worked hours are set under Reports settings.
Decide how long records are kept
Retention determines how far back you can report, because it decides how long events, visits and expired credentials survive. Set it to what your policy requires and be aware that shortening it destroys reporting history.
Full walkthrough: Privacy.
Keep the watchlist current
Banned contractors, barred former staff, security alerts. Entries are screened across the system, and a match raises a warning on the record an operator is working on. Review the lists regularly, because a watchlist nobody prunes is one that gets ignored.
Full walkthrough: Watchlist.
Setting the rules
Decide what a visit pass grants and how long it lasts
This is the security decision that matters most: the type of credential issued, the validity window applied by default, and the access control lists a visitor pass carries. Change it deliberately, and remember that changing a default does not rewrite passes already in circulation.
Full walkthroughs: Visit Pass for the defaults and Visit Pass Permit for the printable permit. Which doors a list actually opens: Access Control Lists.
Decide what has to be captured
Required fields decide what an operator or a visitor must supply before a visit can be created, visit reasons record why each person is on site and can carry their own access rules, and agreements make a visitor respond to a safety induction or a non-disclosure statement before they are admitted. These three settings shape every form in the product, so change them together and tell reception before you do.
Full walkthroughs: Required Fields, Visit Reasons, Agreements.
Decide how visits end
Automatic check-out of visitors who never checked out, whether their credential is deactivated when they leave, and whether a checked-out visitor can come back in on the same visit.
Full walkthrough: Check-out.
Decide who is told, and how it is worded
Hosts can be notified on arrival, on departure or both. The invitation email that carries the pass has its own subject, welcome message and safety instructions.
Full walkthroughs: Host Notifications for the notification rules, Host Notifications for what a host actually receives, and the Invitation Email Guide for the wording and attachments.
Choose the badge your site prints
Badge printing decides the layout and logo used for visitor and personnel badges, and you can design your own layout when none of the built-in ones matches your badge stock.
Full walkthroughs: Badge Printing and Custom SVG Badge Templates.
Set up a location and the settings that hang off it
A location is a building or a site, and a surprising amount is decided per location rather than centrally: its own self-registration link and the fields that link asks for, whether group registration is allowed there, whether it requires manager approval, its own invitation email wording and branding, and the site paperwork stored against it. Work through the location’s own tabs whenever you open a new building.
Related chapters: Self-Registration covers the per-location registration links, Visitor Emails covers the per-location invitation overrides, and Documents on Records covers site maps, evacuation plans and permits stored on the location.
Looking after your people
Set up the people who work for you
Personnel are the people who work at your sites and host visitors; users are the people who log in to EvTrack. Create them, keep their validity windows accurate so credentials expire when employment does, and remove accounts when people leave.
Full walkthroughs: Personnel and Add Personnel; Add a User, Edit a User, Delete a User, and User Validity and Credential Expiry.
Get a new team onto the system quickly
A new site or a new contractor crew is a bulk import, not an afternoon of typing. Download the template, fill it, upload, review, run. New users can be sent an onboarding email that walks them through logging in.
Full walkthroughs: Importing Data and User Onboarding Emails.
What you do NOT need
Unless you are also the system administrator, leave these alone:
- Server, email, SMS and WhatsApp plumbing. Delivery channels are configured once by whoever runs the server.
- Devices, readers, kiosks and the guard app hardware. You care that a checkpoint works; pairing and wiring belong to the administrator who set the site up.
- Access control points, schedules, elevator floors and areas. You choose which list a visitor pass carries; you do not have to build the lists.
- Integrations and the web service API. Connecting another system is a project, not a management task.
- Single sign-on and security configuration. Login policy is set by IT.
The people you manage have their own pages: For Hosts for staff who receive visitors and For Reception for the counter.