Identify the account’s purpose
A Lexoh operator account identifies someone who uses the management application. Its sign-in settings establish how that person authenticates; its roles and restrictions determine the actions and records available to them.
Keep operator accounts distinct from customer profiles, vehicles and physical access credentials. A person may have more than one of these records. Linking a vehicle or badge to a record does not by itself establish permission to manage the application or enter a site.
Use an individual account for each operator and assign access for their actual duties. A receptionist who needs to inspect visitor records does not automatically need full administration rights. Review the installed modules and current account form before following a configuration procedure.
Find and verify the correct account
Open user management from the configuration navigation available to your account. Search by the identifiers supported in the list, then open the record and compare its username, contact details and stable reference. A matching display name alone may identify the wrong person.
Review the saved status, sign-in method, role assignment and relevant scope. If a field is absent, check the detail view and your viewing permissions. List columns, search coverage, sorting and pagination can differ by installation.
Check active filters before concluding that an account does not exist. Search for duplicates before creating another record, particularly when a person’s name, email address or organization has changed.
Create and verify an operator account
- Confirm the person, job, sites and records they need to use, together with the administrator responsible for approving their access. Check for an existing account.
- Open the supported account-creation control. Enter the identifying and contact information required by the current form. Check the username format and uniqueness rules; do not assume an email address is always the sign-in identifier.
- Select the intended sign-in method. For a managed directory or single sign-on connection, confirm the identity mapping and provisioning process with its administrator before assigning a local password.
- Assign the approved role and record restrictions. Review sensitive actions such as equipment commands, exports and account administration separately from ordinary viewing.
- Complete the available activation or invitation procedure. Follow the installation’s password policy and secure delivery process if an initial password is required. Do not send a reusable password in an ordinary support request.
- Save, reopen and compare the account with the approved details. Have the designated operator verify sign-in, a required action and an excluded action. Check any invitation’s status separately: creating the account does not prove that its email reached the recipient.
Use the configured sign-in and recovery method
Local sign-in
For a local account, use the accepted username and password procedure. Follow the requirements displayed by the installed application and the organization’s policy. This guide does not specify a universal minimum length or establish the application’s password-storage implementation.
Directory and single sign-on
LDAP is the Lightweight Directory Access Protocol. An LDAP connection and a browser single sign-on flow are different integration arrangements. Confirm which one applies, the identity format and where passwords are changed. Enabling a directory option alone does not establish automatic provisioning, single sign-on or removal of all local credentials.
Multifactor authentication
Where the installation or identity provider offers multifactor authentication, follow its enrollment and recovery procedure. Confirm the supported factors and complete a test sign-in before relying on enrollment. Keep recovery material private; do not put an authenticator secret or enrollment QR code in a shared screenshot.
A failed sign-in
Record the error and time, then check the account reference, status, selected sign-in route and identity-provider availability. Use the approved identity-verification and recovery process. Reset the credential in the system that manages it; repeatedly changing a local password will not resolve every directory or session problem.
Assign permissions for the operator’s job
Review the role’s actual permissions and scope before assigning it. Administrator, Manager, Operator and Viewer are descriptive names, not a verified list of fixed Lexoh roles or guaranteed permission sets. Use the roles available in the current installation.
Check whether assignments are managed locally or through directory mappings. After saving a change, verify the stored assignment and effective access in both an existing session and a new sign-in. Record the expected and actual results using designated test records.
An available menu is only part of the check. Verify the intended record scope and sensitive actions, including commands and exports where applicable. Coordinate any equipment test with site operations. The related role guide provides a worked acceptance checklist.
Review status, notifications and time display
Account status
Use the supported activation or suspension control for the intended account. Verify its effect on new sign-ins and existing sessions. An Active label does not prove successful authentication; an Inactive label alone does not prove that every session or physical credential has been revoked.
Notifications
Review the recipient address, available notification preferences and applicable alert rules. Send an approved test where appropriate and inspect delivery separately from the preference itself. Enabling a notification setting does not guarantee receipt or an operator response.
Time zone
Select the intended named time zone where supported. Compare a known event in the account view and relevant report, including the zone or UTC offset shown. Confirm how each view handles daylight-saving changes before adding a manual offset; avoid applying the adjustment twice.
Understand the account’s linked records
Use the tabs present in the account detail view to inspect related information. Availability can depend on the installed modules, permissions and record relationships. A missing tab or empty result does not by itself prove that no related activity exists.
| View or relationship | Interpretation to check |
|---|---|
| Account information | Confirm identity, sign-in settings, status and saved role assignment for this record. |
| Vehicles | Confirm whether the record represents ownership, association or another relationship; inspect physical access separately. |
| Access credentials | Review the credential reference, state, dates and permitted devices or zones in its own record. |
| Events | Distinguish the operator who performed an action from the person or record affected by it. |
| Entries and exits | Check recorded timestamps, location and matching rules before interpreting a visit, duration or charge. |
Exports and visibility
Use only the permitted export controls and review the resulting fields, filters and time zone before sharing a file. The visible page count does not establish that an export contains all records or only the current page.
Inspect vehicle associations before changing them
Open the available vehicle view and compare the vehicle reference and identifying details with the intended person. Check the relationship shown in the record rather than assuming every linked vehicle is owned by that operator.
When adding or editing an association, use the supported controls and reopen the records to verify the result. If a plate is used for access recognition, review the applicable camera, recognition configuration and authorization rules separately.
Removing a relationship, deleting a vehicle and withdrawing site access are different operations. Inspect the proposed action and its dependencies before saving, then verify the relevant records and access result.
Check physical credentials separately
For each linked credential, inspect its identifier, status, validity dates and assigned access rules. Reader compatibility depends on the credential technology and installed equipment; an RFID card, UHF tag or QR code is not interchangeable with every reader.
Review device or zone permissions, schedules and any other applicable restrictions in the credential configuration. A displayed first entry, last exit or inside status is recorded system information; confirm its definition and freshness before treating it as a person’s physical location.
For a lost credential or a departing user, follow the supported revocation procedure and verify the affected readers or controllers, including synchronization and offline behavior. Disabling the application account is not sufficient evidence that the credential can no longer open an entrance.
Read account activity in context
Use the event view to inspect the available recorded activity within the selected period and filters. Compare the event reference, time zone, source, action and result. Determine whether the account is the actor, the subject or merely associated with another record.
An entry or exit event does not always prove completed physical passage. A command record does not by itself establish equipment movement, and a payment-related event does not establish bank settlement. Consult the related equipment or transaction record for the outcome required by the investigation.
Keep useful references when escalating an issue. Missing results can reflect filters, permissions, retention or collection gaps; avoid describing the view as a complete audit trail without checking its actual coverage.
Verify visits, durations and associated charges
Inspect the available entry and exit records for the intended account or related customer. Check the site, timestamps and time zone, and whether the session has a matching exit. Open or unmatched records may not support a completed visit duration.
For a paired session, confirm the matching and duration rules before comparing results across reports. If a charge or payment status is shown, inspect the underlying transaction and its state; an entry record alone is not evidence of a settled payment.
Before exporting, verify the selected range, filters, included fields and record coverage. Handle the file according to the organization’s access and retention rules. Use transaction records and the appropriate financial reconciliation for accounting decisions.
Review and retire accounts with a recorded checklist
- Review accounts when responsibilities change and at the organization’s chosen intervals. Record the owner, current job, approved permissions and relevant sites. Preserve an authorized administrative recovery path during changes.
- For a departure or suspected compromise, identify the local account, external identity, active sessions and separately managed physical credentials. Coordinate the required changes with their responsible administrators.
- Use the supported suspension and session-revocation procedures. Verify blocked sign-in and loss of access in existing sessions through an approved test; close out linked badges, vehicle access and other entitlements separately.
- Check ownership of operational records, scheduled work and integrations before deleting or archiving the account. Follow the installation’s supported procedure and the organization’s retention requirements. Recreating the same name may produce a different record reference.
- Retain a dated change record with the account references, actions taken and verified outcomes. Review unresolved access or missing audit evidence before treating the departure as complete.
Password and recovery practices
Use a long, unique password and an approved password manager for password-based accounts. OWASP provides general guidance on password strength, recovery and multifactor authentication. Apply it with the responsible administrator; these references do not establish which controls a particular Lexoh installation implements.
General guidance reviewed September 30, 2026: OWASP authentication guidance. OWASP multifactor authentication guidance.