Organize and maintain company records in Lexoh

Define what a company represents

A company record in Lexoh groups customer, vehicle or access-card records associated with an organization. Use a consistent meaning across your installation: for example, a tenant organization or an internal department. Confirm which associations and settings your version supports before designing the structure.

A company is not automatically a physical site, an operator account or a billing account. Grouping records does not by itself prove that one organization cannot see another organization’s data, that access is authorized or that a separate invoice will be produced. Permissions, access rules and billing workflows need their own configuration and checks.

This guide covers company-record administration. Keep the organization’s identity separate from the doors, barriers, schedules and credentials that determine physical access.

Find the right company record

1. Open Companies in the administration area with an account authorized for the site and task. Menu names and available actions depend on your version and role.
2. Check the current site, filters and loading state. An empty list can result from access restrictions or filters; it does not establish that no companies exist.
3. Search for the expected name or stable company reference. Check a known record to establish which fields the search covers, including whether descriptions are searchable.
4. Open the matching record and compare its reference, description and linked customers. Similar names can identify different organizations; a renamed company can keep the same identity.
5. Review the status as text and note the available actions. Read the actual account scope rather than assuming the list includes every active or inactive company.

Create a company without duplicating it

Before adding a record, decide what it represents and who maintains it. Search existing names, abbreviations and references. Use the same company for a rename when appropriate; do not create a second record simply to change its displayed name.

1. Choose the available add-company action. Read the fields marked required in your version rather than relying on a default status or a fixed form layout.
2. Enter a recognizable organization name and concise operational context. Use a separate site or zone record for a location when that is the intended data model.
3. Review the proposed status and any operational settings before saving. Leave unfamiliar limits unchanged until their units, scope and effect are confirmed.
4. Save once and check the result. If the response is unclear, search and refresh before submitting again so that a delayed response does not lead to a duplicate.
5. Reopen the saved company and compare its values with the intended setup. Record its stable reference where available.
6. Associate the intended customers or credentials through their supported controls. Check the association from both records and complete an approved access test when access behavior is affected.

Separate descriptive fields from operating rules

Use the name for recognition and the stable reference for reconciliation. A description supplies context; text such as “20 spaces” or “monthly billing” does not configure a capacity limit or a billing rule. Keep credentials, payment-card details and unnecessary personal information out of free-text notes.

Active or inactive status describes a company setting. Confirm its effect on linked customers, credentials, operator visibility and reports before using it for offboarding. Do not assume that reactivation restores every expired or independently disabled record.

Entry limits and cycle settings

If your version exposes “Max Entrance” or “Bad Cycles,” confirm the definition with the administrator or Lexoh support. Establish whether a value concerns simultaneous presence, entries over a period, validation failures or another condition; identify the reset rule and any linked action. The field name alone is insufficient to choose a value.

Changes that cross organizational boundaries

When a customer moves between companies, check which credentials, vehicles and reports follow the new association. Verify whether historical reports use the association at the time of the event or the current company. Do not assume a move transfers every related record.

Verify edits, deactivation and deletion

1. Identify the exact company by reference and review affected linked records. Record the starting values and the intended result.
2. Make the authorized change, save it and reopen the record. A successful save confirms the stored change; test any operational effect separately.
3. For a status change, check a representative linked customer and credential, the relevant operator’s view and a known report. Follow the site’s access-test procedure.
4. Before deleting or merging records, establish the impact on associations and historical records with the administrator. Do not assume a confirmation dialog explains every consequence or that deletion can be undone.
5. For a batch operation, check whether the selection covers the visible page or all matching records. Review the exact references and compare results with the intended set.
6. If an export is available, verify its scope, columns and record count. A company list export is not a complete backup of customers, credentials, rules or historical relationships.

When an edit is unavailable

Check the account’s role, current scope and any integration that manages the record. A missing action can reflect permissions or configuration. Give support the reference and exact message rather than creating a replacement record to bypass the problem.

Test a tenant setup from end to end

Illustrative setup: two tenant organizations share a parking facility. Each organization has its own company record and intended customer associations. They use the same physical entrance, while their access schedules and operator permissions are configured separately.

The checks below validate the intended arrangement. They are not a claim that every Lexoh installation uses the same permissions, billing model or company fields. Use test records approved for your site.

Buildings and departments

For a campus or residential property, first decide whether the grouping describes an organization, a location or a reporting label. A company per building is one possible model, not a universal setup rule. Confirm the required reports and access relationships before creating the records.

Keep the structure understandable

1. Document what each company represents, its stable reference and the person responsible for maintaining it.
2. Use consistent names and review possible duplicates before onboarding or reorganizing customers. A similar name is a reason to investigate, not automatic evidence of a duplicate.
3. Review associations after a move, rename or service change. Keep the expected outcome and observed result together.
4. Check inactive records against the site’s retention and offboarding procedure. Do not delete records solely because a calendar interval has elapsed.
5. When reporting by company, record the period, time zone and association rule used. Reconcile a sample with the underlying records before using totals for billing.
6. Send unresolved issues to support with the company reference and exact steps. Separate a stored setting from the access, visibility or reporting outcome still to be verified.