How to extract the Entity Value from the Virtual Agent Search Text

[jpeterson2]

Does anyone know how to extract the below value in the Virtual Agent Designer? I found that I can use "vaSystem.getSearchText()" to get the entire search text which in this example was "What is the status of INC0462117" and then I could write a script to parse out the ticket number but does anyone know if there's a way to grab it similar to how I grabbed the search text? For example, if there was a vaSystem.getEntityValue() it would return INC0462117.

[Chris D]

Good question. Not sure if there's a simple method to grab an entity's value.
Quick check on 50+ (Un)documented Virtual Agent variables (vaInputs, vaVars, vaContext, vaSystem) and looks like you could use vaVars._topic_current, but you'd have to parse its json:

vaVars._topic_current

Same as vaVars._topic_results. Provides details of the current Topic the conversation is in, in JSON format. Details like the Sys ID of the current Topic, Sys ID of the Conversation Task, name of the current Topic. Example output: "{"sys_id":"5e85248c2f50a050b0c2d5ea2799b6b4", "task":"f327e4802f90a050b0c2d5ea2799b63d", "entities":null, "modelId":null, "name":"Test Topic", "prediction":null, "title":"Test Topic", "type":"normal", "utterance":"test topic"}"

(Note, I've never really thought about it, but that does imply that there could be multiple - comma-separated? - entities in one utterance so just something to be aware of when scripting.)

What's the use case? I'm not saying there absolutely isn't a simpler way, but at the same time, I wouldn't be entirely unsurprised if there wasn't a simpler way since ServiceNow includes the simple way to map an entity to a input with no code necessary. Your question makes it seem like you want to do something besides mapping this entity to an input, but if all you're trying to do is grab the ticket number to use it to search for a ticket, then you just need a simple text input with the following settings:

[jpeterson2]

Thank you, I will look into the parsing.

My use case is that I want a user to type something like "What's the status of INC123456" and the VA will show the details of the INC. They are able to ask for an INC/REQ/or another type of ticket we have AUT. The problem I was seeing with the example you showed of mapping an entity to an input is exactly that, it's an input. The way our status currently works is like so:

1. The user asks for the status of their ticket

2. Currently, the flow won't care if they put a number in their question and it will use their name to check for any open INC/REQ/AUT tickets and display all of them to the user and ask them to pick which ticket they want the status before showing it to them.

Updated flow:

A. User doesn't put a ticket number, it will do the above functionality and show them all open tickets and let them choose.

B. User does include a number, we want the flow to skip to showing them the status without having to confirm which ticket because they already typed the number.

Unless I'm thinking about it wrong, the issue with using an input is that it will work perfectly IF they included a ticket number and will bypass actually asking them a question but if they don't include a ticket number the flow will be something like:

1. User asks, can I get a status update of my ticket?

2. The Input won't see an entity value and then prompt the user something like "What's the ticket number"

The issue there is that they might not know the number and since I'm in the input now I can't just lookup all their tickets and ask them to pick which one they are asking about. I hope all that made sense... Let me know if I'm thinking about it wrong and there's an easy way to do this which also accounts for the possibility of needing to query from different tables based on INC/REQ/AUT/Etc...

[Chris D · Accepted solution]

I get what you're saying and agreed that does sound like a good, user-friendly design.

To give you a slightly different perspective, here's what our Ticket Status topic does: we have Ticket as a pattern entity and at the top of the topic, we do a simple regex check on the user's utterance - vaSystem.getSearchText().match(/(ritm|inc|ims)[0-9]{7,12}/i (note: this regex exactly matches the entity's regex) -  and if there's no match, we ask the user how they'd like to search for a ticket: search by number, show all open tickets, show all closed tickets, etc. And if there is a match, then we bypass that first question and assume they want to search by number, in which case the topic points to the text input ("Enter your ticket number") which is mapped to the entity, skip confirmation if matched, and voila - that's it, the user is shown the status of that ticket without having to type it in or provide any other input. Plus it works for users that know their ticket number but don't input it as an utterance.

If there was a more ootb way to get the entity in the topic, I would certainly prefer to use it, but luckily for now, ticket number being a pattern entity makes it easy enough to run the same regex on the utterance.

And so my recommendation would be to not overthink the entity extraction part - use the ootb entity input mapping - and do something similar to what I did: regex at the beginning of the topic to bypass the normal flow for users that provided a ticket number and send them to a text input mapped to your ticket entity and check the "Enable NLU at Input Node" and "Skip confirmation for recognized entity" boxes. If you keep your topic design as described, it will be as if that text input doesn't exist - no user will ever see it because the only time it'll be reached is when there's an entity match and it'll just auto-fill for the user.

[jpeterson2]

Thank you! I will just use the regex to get the ticket number then and follow a flow similar to what you shared.