Organize records with clear, consistent tags

Understand what a tag does

A Lexoh tag is a label used to organize supported records and, where available, find or filter those records. In this guide, tag means a data label, not an RFID or UHF credential presented to a reader. Available fields, record types and actions depend on your installation and permissions.

A label such as VIP, Active or Maintenance required describes the team’s classification. Its name or color alone does not establish a customer’s status, grant access, reserve a parking space or stop equipment. Verify any explicit rule that uses a tag before changing its associations.

If parent tags are offered, use them to organize related labels. A parent-child relationship does not by itself prove property inheritance, permission inheritance or inclusion of every child in a parent filter. Check those behaviors independently.

Find a tag and check its scope

1. Open the tag-management area available to your operator account. Check the current site or organization scope and clear unrelated filters before looking for a label.
2. Search for the name and inspect similar spellings, accents, language variants and parent labels. A missing search result does not prove that the tag does not exist outside the current scope.
3. Open the intended tag and record its stable reference if shown. Compare the name, color, parent and description that are actually available; a display name is not a reliable substitute for a stable reference.
4. If a usage count appears, determine whether it counts records, associations, direct assignments or descendants, and which record types and permissions it covers. A visible zero is not a complete dependency check.
5. Use the sorting and filters supported by that list, then inspect representative associated records. Distinguish the tag’s update time from the time it was assigned to a particular record.

Create a label with a defined purpose

1. Define the classification and the records it should describe. For example, Inspection due could identify equipment awaiting review where device tagging is supported; it should not be treated as a command to disable that equipment.
2. Look for an existing label with the same meaning before creating one. Decide how the team handles French and English names without assuming that two translated labels are the same tag.
3. Use the available creation control and enter a concise, descriptive name. Follow the form’s actual required fields, length and validation messages; do not assume a universal character limit or uniqueness rule.
4. Choose a readable color if offered, while keeping the meaning in the text. If a parent field is offered, select the intended parent and avoid circular relationships. Confirm the supported hierarchy rather than assuming automatic inheritance.
5. Add the purpose and owner in a description if available, or in the team’s tag reference. Review the values, save once and wait for the result before retrying.
6. Reopen the saved tag and confirm its identity and values. Apply it to one suitable test or agreed sample record, save that record, and verify both the association and the relevant filter before wider use.

Change a tag without changing its meaning accidentally

Locate the tag by its reference and current name, then review associated records and any saved filters, reports or configured rules that use it. Record the previous values and the reason for the change.

Rename, recolor or reparent only through the controls available in your installation. Use the edit form’s save action, then reopen the record. Renaming a label does not necessarily merge it with another tag, change its identifier or update external references that use the old name.

Check representative records and dependent filters after the change. A historical report may show current labels or labels captured at the event time; confirm which interpretation applies before comparing exports.

For a batch assignment, verify the exact selected population and whether the action adds tags, replaces the full tag set or removes selected associations. Test on a small sample and preserve unrelated labels. Do not assume every list offers the same bulk operation.

Review dependencies before removing a tag

Removing a tag from one record and deleting the tag from the catalogue are different operations. Before deleting, confirm what the control affects, whether the action can be reversed and what happens to existing associations. Do not infer those effects from an icon or a displayed usage count.

1. Identify the exact tag and inspect its assignments, descendants where supported, saved filters, reports and configured rules. Include relevant record types and scopes beyond the current list.
2. If the team is consolidating labels, agree on the replacement meaning first. Reassign a small sample, verify the result, then complete the planned reassignment. A rename is not proof of a merge.
3. Confirm the actual handling of child tags: the system may restrict deletion or require a specific reassignment procedure. Do not assume it offers delete-all-children and keep-children choices.
4. Read the confirmation and proceed only when its scope matches the intended change and the site’s procedure. Preserve the references and associations needed for recovery before removing them.
5. Check affected records, filters and rules after the operation. Recreating a tag with the same name may produce a different reference and does not prove that old associations or history have been restored.

Apply tags and verify filter matching

Open a supported record, select the intended existing tag, save and reopen it to verify the association. Availability must be checked for each record type; a tag field on a device does not establish the same feature on transactions, reports, users or parking spaces.

For multiple selected tags, determine whether the filter means any selected tag or all selected tags. The illustrative set below contains four records and two labels: A means North site and B means Inspection due. These are explanatory labels, not a claim about a particular Lexoh filter.

Compare the actual result

For this set, any returns three records and all returns one. Compare known records with the actual filter and check how it combines with dates, sites and other criteria. Selecting no tag may clear the filter rather than mean records without tags.

Check parents and counts separately

A filter on a parent may or may not include descendants. A record carrying both A and B still represents one distinct record in this example. Adding separate tag usage counts can double-count shared records.

Verify actions that use tags

A filter selects records; it does not itself prove a change to access, billing or equipment behavior. If a configured automation uses tag membership, verify the rule, affected population and expected result before changing membership.

Maintain a shared tag vocabulary

Name the meaning and the owner

Keep a short reference with each label’s purpose, applicable record types, owner and examples. Use language and capitalization conventions the team understands. Do not repurpose an old label for a different meaning without reviewing existing records.

Keep text meaningful without color

Use readable text and consistent colors where supported. Color should reinforce the name, not be the only way to distinguish a maintenance item from an approved one. Check the label on the actual backgrounds and devices operators use.

Keep private details out of labels

Tags can appear in lists, search results and exports. Use them for the classification needed by the workflow rather than passwords, access codes or unnecessary personal details. A tag is not a privacy boundary.

Review usage and dependencies together

Revisit labels when processes, sites or responsibilities change. Check duplicates, ambiguous names, stale assignments and dependency references. A low count alone is not a reason to delete a tag. Record what changed and verify a known filtered result afterward.