Wondering why ^NQ in an encoded query on a Query Business Rule does not work right?

[TrenaFritsche]

In trying to prevent visibility of REQ, RITM & Incidents that are generated from a Service Catalog Request, I created a filter on the respective tables to filter out tickets based on text in the short description and not belonging to a certain group OR keeping the tickets displaying that have that same text that I filtered out if it was opened by the user.  This created an encoded query with an ^NQ in it, but the end result when using it in a business rule had some unexpected results.  On the surface, the list for the table that the BR was written for looked correct, but opening any ticket in the list seemed to open the wrong ticket.  With this Query Business Rule in place, it is almost like the platform query didn't pay attention to the ticket that I clicked on.  In order for my query business rule with an encoded query to work, and select the correct ticket that I clicked on, I had to use ^OR. in place of ^NQ.  

I wanted to post this in the community to help others get past this issue that I spent hours upon hours trying to get something to work correctly and finally settled on using the ^OR and also hoping that this may get looked at by the platform engineers to see if they can recreate this and come up with a fix. 🙂

[MrMuhammad · Accepted solution]

Hi,

I just found a KB article that discuss the same and seems like this known error is there since very beginning, starting from the Berlin release. 

Refer below

https://hi.service-now.com/kb_view.do?sysparm_article=KB0564887

Thanks,

Sharjeel

[sbh]

@inderpal found a brilliant way around this - see the community post Encoded Query & Add Or Condition query.