Search and investigate recorded Lexoh events

Understand the purpose of event history

Lexoh event history helps operators investigate activity reported by connected equipment and software workflows. Use it to locate a record, identify its source and follow related access, parking or transaction activity. Available event types, detail fields, filters and retained periods depend on the version, configuration and account scope.

The list is a record of reported activity, not a guarantee that every physical action or software change was captured. One operation can generate several events, and a missing record can have several causes. Check the relevant source before drawing conclusions from counts or absence.

Use this guide for general event investigation. Recorded alerts focus on reported conditions needing follow-up, while camera review covers video and detection evidence. A related record can support an investigation without proving the final outcome on its own.

Establish the viewing scope

1. Open the event-history view with an authorized account. Confirm the site or organization and the records your role can inspect.
2. Identify the search field, available filters, result list, refresh control and export action. Use the labels shown by your version; their position can differ between desktop and mobile.
3. Record the active period, filters, sort order and displayed total, where available. Check whether the results have finished loading.
4. Check for a loading failure, access message or stale list before interpreting an empty result. Refresh through the available control when a current snapshot is needed.
5. Keep the question being investigated explicit, such as a reported access refusal at a particular reader and time. This makes the search and follow-up easier to reproduce.

Search using a known record

Start with a stable device or event reference, or a distinctive part of the message. Confirm which fields the search actually covers. Text matching, partial matches and case handling can vary; test the search against a known record before relying on it.

Apply one constraint at a time. Searching for the word “error” is different from selecting an error severity or outcome. A device name may appear in a message without being the event’s source device.

Where a filter offers suggestions, select the intended record and verify the saved selection. Typed text is not always an applied filter. Use the reference and site to distinguish people, cards or devices with similar names.

If the expected record disappears, clear the newest constraint and check again. Record the effective filters, including any hidden in a closed panel. Reopen a saved or shared URL to verify its scope before assuming it reproduces the search.

Separate category, action, outcome and severity

Read the labels and definitions used in your event view. A category describes the area involved, an action describes an operation, an outcome describes its reported result, and severity indicates a level of attention. They are different dimensions even when a screen groups them together.

The examples below are interpretation checks, not an exhaustive Lexoh event catalogue. Check the exact source message and linked record for the installed integration.

Multiple categories

Where multiple selections are available, check how they combine. Do not assume category choices use the same logic as separate device, date or person filters.

Severity and service impact

Interpret warnings or errors with the affected operation and site procedure. A warning need not become an error, and the absence of an error label does not establish successful service.

Identify the actor and the affected record

An event can involve an operator account, customer, guest, credential, device or another linked record. Distinguish who initiated an action from the record it affected. A displayed customer name does not necessarily identify the person who performed the action.

Confirm the meaning of customer, user and guest in your version. Do not assume that every guest is anonymous or that every customer has an active subscription. Use stable references when available; names and associations can change.

Open related details only within your authorized scope. Determine whether the link shows historical values or the current record. A current card owner, zone or company association may differ from the one at the event time.

If the actor or related reference is missing, leave that part unresolved. Do not attribute an action to a person solely from the nearest timestamp, a similar name or a device’s usual operator.

Combine filters and define the period

A date picker’s earliest selectable date does not establish how much history was retained. Verify retention and access with the administrator when investigating older activity. This guide does not assume a two-character search minimum, a fixed suggestion count or a universal device-list limit.

1. Select an explicit start and end, then record the time zone and the meaning of the event timestamp. Source occurrence and processing or recording time may differ.
2. Confirm the date format and boundary behavior. Check known records near the start and end rather than assuming that both dates include a complete day.
3. Add the exact device, credential, person, company, zone or tag available for the investigation. Verify each selected reference and whether it describes the source or an associated record.
4. Apply the filters and compare a known result. Confirm whether separate filter groups require all conditions and whether multiple selections within a group match any or all selected values.
5. If a suggestion or device is missing, refine the term and check scope, permissions and archived records. A short suggestion list does not establish that no other matches exist.
6. Record the final combination and the retrieval time. If the list remains too broad, narrow the period or source based on the question rather than excluding records needed to test it.

Review the sequence without inventing missing steps

For each relevant row or card, retain the event reference, time, source, message, reported result and available actor or related references. Expand details where your version supports it. An icon or color is a viewing aid, not a substitute for the message and result.

Check the sort direction and timestamp precision. Two records with the same displayed second may not have a proven internal order. Records arriving late can also appear after a refresh. Keep those limits with the investigation.

For an access issue, compare the validation result, any command record, available device feedback and the related visit or observation. These are possible stages to investigate, not a promise that every integration logs each stage.

A blank field means the displayed record does not supply that value. An empty result set may reflect filters, retention, access or reporting gaps. Describe the observed evidence and the checks still needed rather than filling gaps with an assumed successful or failed action.

Check what the export contains

If export is available, use the format offered by your account and record the intended scope. Verify whether the export includes the visible page, selected rows or all matching results. Do not infer its contents from the button label.

An event export is a dataset for review. It does not by itself constitute a complete system backup, an invoice or a verified compliance record. Use the appropriate operational and retention procedures.

1. Keep the site, account scope, period, time zone, filters and export time alongside the file.
2. Open the file and check its actual columns, row count and a sample of known event references. Compare the first and last relevant timestamps with the intended period.
3. Preserve identifiers, leading zeros and timestamp meaning when opening the file in a spreadsheet or analysis tool. Distinguish missing values from zero.
4. Keep the original file unchanged and perform grouping or calculations in a copy. Document duplicate handling, excluded rows and transformations.
5. Check linked transaction or visit records before using event data for reconciliation or traffic analysis. Keep unresolved differences explicit.
6. Share only the required records through the approved route and retain them according to the site’s procedure. State any unverified export limitation in the follow-up.

Distinguish list positions from event references

The visible rows, total matching results and page size are different quantities. Use the pagination controls available in your version and check how a filter or sort change affects the current page.

For example, with 61 matching records and 25 rows per page, there are three pages: 1–25, 26–50 and 51–61. The last page contains 11 rows. These are illustrative counts, not Lexoh defaults or setting limits.

New records or a changed order can shift row positions between pages. Use stable references and a defined cutoff for a repeatable review. A page number alone is not an event identifier, and the number of displayed events is not the number of unique visits or incidents.

Turn findings into a traceable follow-up

1. State the reported problem, site, device or person reference, relevant period and expected result.
2. List the event references that support each observation and distinguish them from assumptions or missing evidence.
3. Use the source records to verify outcomes. Entry/exit ratios alone do not prove gate operation or occupancy; those checks need the relevant counts, starting state and physical or operational evidence.
4. Assign the next check and responsible person through the site’s service process. Verify the present condition before acting on an old event.
5. For a recurring issue, compare equivalent periods and reporting conditions. Separate repeated messages from separate incidents before discussing trends.
6. Give support the exact message, references, active filters, time zone and steps already completed. Include the expected result and what appeared instead.