What Happens When an Attribute Option Is Removed

A plain-language guide to how the Asset Database handles deactivated dropdown options

Why this article exists

In the Asset Database, many fields use dropdown lists — things like Unit of Measurement (UOM), Brand, Category, Group, Segment, Asset Allocation, and Asset Ownership. The options inside those dropdowns are managed centrally, not by individual users.

That means an option you’ve already used to tag an asset can later be removed from the master list — for example, when the business retires an old brand, consolidates categories, or cleans up legacy data.

When that happens, a fair question comes up: what happens to all the assets that were already using that option?

This article answers that question across every place in the module where it matters: the asset list, the edit page, the global filter, the activity log, and bulk edits in progress.

The core principle

The system follows one simple rule:

Don’t lose history. Don’t allow new mistakes.

In practice, this means:

• Existing data stays visible. If an asset was tagged with a label that has since been removed, the asset keeps showing that label so you can still recognize and audit the record.
• New selections use the current list. The moment anyone tries to change that field, the removed option disappears — you can only pick from options that are currently active.

Everything below is a consequence of that one rule.

What you’ll see in each part of the module

On the Asset List page

The asset still shows the removed label exactly as it was saved. Nothing about the row changes just because the master list changed.

This is intentional. If a brand called “Acme” is removed from the master list, every asset that used to be tagged “Acme” still says “Acme” on the list. You wouldn’t want those assets to suddenly show a blank field — it would make them impossible to recognize, and the historical record would be lost.

When you open the Edit page

When you open an asset whose data includes a removed option, the field shows the removed value as the current value. You can see clearly what was set, and nothing has been silently overwritten.

The moment you open that field’s dropdown to change it, the removed option is no longer in the list. You can only pick from options that are currently active.

If you don’t touch that field, the removed value stays saved on the record. Editing other fields and saving doesn’t force you to update this one — your edit is scoped to what you actually changed.

When you click Save

Before saving, the system checks every value on the form against the current master list. If any of the values you’re trying to save are no longer valid, the save is blocked and the affected field is highlighted so you can fix it.

This is the system’s safety net: it prevents anyone from saving a record that contains an option that was removed during the editing session.

In the Global Filter

Removed options don’t appear in the Global Filter’s selection list. You can’t build a new filter condition that targets a removed label — the option simply isn’t there to pick.

Existing assets that hold the removed value are still visible on the Asset List. You just can’t isolate them using that label as a filter criterion going forward.

In the Activity Log

When an option is removed from the master list, that change is recorded in the database for audit purposes — but it doesn’t show up as an entry in any individual asset’s Activity Log.

Why? Because the asset itself didn’t change. The master list changed. The asset still holds the same value it was given. Cluttering every asset’s history with an event that wasn’t about that asset would make the log harder to read.

If a config change happens while someone is mid-edit

This is the trickiest scenario. Imagine a user opens an asset’s Edit page, starts making changes, and in parallel an admin removes one of the options from the master list before the user clicks Save.

The system handles this gracefully: it uses a snapshot of the attributes and labels taken when the Edit page was opened. The user can finish their work and save, validated against that snapshot. They won’t be blocked mid-task by a change made elsewhere.

Bulk Edits

The same rule applies to bulk imports. If a CSV file contains a removed option, those rows fail back-end validation and appear in the Failed Data sheet of the result file, with the specific reason listed. Rows that don’t touch the affected field go through normally.

Quick reference table

What this means for you

For business and operations teams: You don’t need to worry about historical records being silently wiped. Anything that was tagged in the past stays tagged — until someone deliberately updates it.

For admins managing the master list: Removing an option is safe in the sense that it won’t corrupt existing data, but it does mean those options can no longer be used as filter criteria or applied to new records. Plan removals around reporting cycles where possible.

For users doing day-to-day edits: If you open an asset and see a value that’s no longer in the dropdown when you click into it, that’s expected. Either leave it as-is or pick a current option to replace it.

End of article. Return to “Understanding the Asset Database” for an overview of the module, or continue to “How to View and Edit an Asset” for the standard edit flow.