Why is the Tag Encoded Query Different from a Regular Reference Field in ServiceNow?

[nagaraju15]

I've noticed that the encoded query for tags in ServiceNow is different from the syntax used for regular reference fields. For example, in a regular reference field like assigned-to, the query is assigned-to = sysID, but for tags, it uses

sys-tags.(sysID) = sysID.

Could someone explain why the encoding for tags differs from regular reference fields? And How it will be executed in the backend ?

[Siddhesh Jadhav]

Hello @nagaraju15,

The difference in the encoded query syntax for tags versus regular reference fields in ServiceNow stems from how tags are structured and stored in the database.

1. Tags Structure: Tags are stored in a separate table (the sys_tags table) and can be associated with multiple records. The query sys-tags.(sysID) = sysID is used to match the tag to the associated record through this table. In contrast, regular reference fields, such as assigned-to, directly reference a single record in another table.

2. Execution in the Backend: When you run a query using tags, ServiceNow will internally perform a join between the table containing the main record and the sys_tags table to find records associated with the specified tag. This is more complex than querying a direct reference field, which simply retrieves records based on a direct relationship.

In summary, the difference in syntax reflects the underlying data model and relationship management in ServiceNow.

If this helps to solve your query, please mark it as accepted and helpful!

Thanks and Regards

Siddhesh Jadhav

[nagaraju15]

Hi @Siddhesh Jadhav ,

Thank you for your response.

Could you please explain the backend execution with a detailed example? I am particularly interested in understanding how the join occurs between the Incident, Label, and Label Entry tables.

[Siddhesh Jadhav]

Hi @nagaraju15 ,

Backend execution with an example using the Incident, Label, and Label Entry tables.

1. Incident Table: This holds the primary record, such as incidents or tasks.

2. Label Table (sys_tags): This stores unique tags. Each tag is identified by a sys_id and a label name.

3. Label Entry Table (label_entry): This table serves as a junction between the main records (such as an Incident) and the tags. It references the sys_id of both the record (Incident) and the tag (Label).

Backend Execution:

When you query using a tag, the system performs an internal join between the Incident table, Label table, and Label Entry table.

For example, if you want to retrieve all incidents with a specific tag, the encoded query might look like this:

incident.sys_id IN (SELECT record_id FROM label_entry WHERE label_id = '<sys_id of the tag>')

Here's the breakdown of the join:

The system first finds all label_entry records where the label_id matches the tag's sys_id. It then retrieves the record_id (the sys_id of the Incident). Finally, it fetches the matching incidents.

So, when querying, ServiceNow performs a join like this:

1. Label Entry → Label: Matches the tag based on the label_id.

2. Label Entry → Incident: Matches the incident based on the record_id.

This is more complex than a simple reference field, as multiple tags can be associated with multiple records.

If this helps to solve your query, please mark it as accepted and helpful!

Thanks and Regards,
Siddhesh Jadhav

[Bert_c1]

From the navigation, select "Debug SQL (Detailed)" and go to a list view of incidents, and filter as shown below:

In my Washingtondc Patch 7 instance, there is no table named 'sys_tags'. See below: