Attachment Tags – Can existing tags be displayed as a dropdown instead of only after typing?

[santhoshini2]

Hi everyone,

We're using the OOTB Attachment Tags (Tags) feature and have encountered a usability issue.

Currently, existing tags are not displayed when the user clicks the tag field. Suggestions only appear after the user starts typing. Because of this, users often don't realize that a tag already exists and end up creating new tags with spelling mistakes or slight variations, resulting in duplicate tags.

We're looking for a way to improve this experience.

Questions are:

1. Is there any OOTB configuration to display existing attachment tags as a dropdown when the field receives focus?

2. Has anyone customized this behavior?

3. Can we reuse the existing attachment tag table and replace the OOTB tag input with a reference/dropdown field, while still preserving the OOTB attachment tagging functionality?

4. Are there any recommended best practices to prevent duplicate attachment tags?

Any suggestions or implementation examples would be greatly appreciated.

Thanks in advance!

[Shiny-Syslabo]

Regarding the ServiceNow Community topic on attachment tags, there is no Out-of-the-Box (OOTB) configuration to display existing tags as a dropdown on focus.

Customizing the core attachment UI is highly discouraged due to upgrade risks.

Here are the compact, best-practice solutions to prevent duplicate tags:

1. Restrict New Tag Creation via ACL (Highly Recommended)

• What to do: Modify the Create ACL on the Tag (label) table so regular users cannot create new tags.

• Why: This forces users to use predefined tags. When they type in the attachment field, only existing valid tags will appear as suggestions, completely preventing typos and duplicates.

2. Block Duplicates with a Business Rule

• What to do: Create a Before / Insert Business Rule on the label table.

• Script Logic: Check if a tag with the same name (case-insensitive) already exists. If found, abort the insert and display an error message:

  JavaScript

  var labelGR = new GlideRecord('label');
  labelGR.addQuery('name', current.name);
  labelGR.query();
  if (labelGR.hasNext()) {
      gs.addErrorMessage('This tag already exists.');
      current.setAbortAction(true);
  }

3. Merge Existing Duplicates via Scheduled Job

• What to do: Set up a periodic Scheduled Script Execution to clean up existing data.

• Why: It scans for similar tags, reparents the records in the tag entry (label_entry) table to a single master tag, and deletes the duplicate tag records.

•  

Alternative Option: Build a Fully Custom Solution (Bold Move)

If customization is permitted in your environment, a bold alternative is to create a custom attachment field and build a feature to input tag data directly there. This allows you to design your ideal user experience from scratch.

[MaheshG95462175]

Building on what's already been shared here a couple of additions/refinements:
On the duplicate-prevention approach worth flagging one risk with the "Restrict Create ACL on the label table" suggestion — that ACL is global, so locking down tag creation there would block users from creating new tags anywhere in the instance (incidents, changes, KB articles, etc.), not just on attachments. If attachment tags are the only place you're seeing the duplicate problem, a case insensitive duplicate check Business Rule (like the one shared above) is the safer, more targeted fix it stops junk duplicates without taking away tag creation everywhere else.

Point 2 : has anyone customized this exact behavior?
Nothing documented for this specific "show dropdown on focus" tweak that I could verify it's a narrow ask. What does exist in the community is people working around the tag input entirely rather than patching it (see point 3 below), which tells you the OOTB widget itself isn't commonly touched probably for the upgrade-risk reason already mentioned.

Point 3- reuse the tag table with a real reference/dropdown field:
Yes, and here's how it actually maps to the data model: tags live in two tables label (the tag itself) and label_entry (the join table: table + table_key + label reference). You can add a custom reference field pointing at label so users get a real dropdown of existing tags, then use a Business Rule to write the matching label_entry row (running with elevated privileges, since those two fields require the maint role by default via ACL).


End result: the tag still shows up natively on the record, you've just replaced the input experience.