Using Virtual Agent vaVars through the data pill

Mark Roethof · ‎07-26-2020

Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

Hi there,

Between the London release and Madrid release, ServiceNow enhanced the Virtual Agent designer with amongst others, the Data pill. A nice addition, like we already knew it in Flow Designer. While working on the Virtual Agent designer and the Data pill, I stumbled on one annoying little thing… Why can't I select my vaVars Script Variables?!

vaVars Script variables

Let's first set up a basic Virtual Agent topic through the Virtual Agent Designer. Just using a Script Action Utility which contains a vaVars variable, which we would like to use in another utility in our Virtual Agent topic.

Data pill [introduced in Madrid]

We've set up the vaVars variable. Though how come we can't use this on the data pill which is available?

vaVars and the Data pill

Defined vaVars during your Virtual Agent topic design, are not automatically recognized. There's a small workaround for this. Adding the variables in the Script Variables section. Ones added, the vaVars variables are directly available in the data pill.

Note there is a downside of this workaround: all defined variables this way, are already available on your first step in your topic design. So already before you are actually doing anything with these variables.

Note: This will also work when working in the Virtual Agent Designer within script. When typing vaVars., all of your vaVars defined will be recognized and available with the auto-complete.

---

And that's it. Hope you like it. If any questions or remarks, let me know!

C	If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful. Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? - Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

Kind regards,

Mark Roethof

ServiceNow Technical Consultant @ Quint Technology
1x ServiceNow Developer MVP

1x ServiceNow Community MVP

---

Andre16 · ‎08-03-2020

Interesting

Alessandro D_ · ‎05-25-2022

Hi Mark,

I wanted to open a new discussion but I thought that my issue is very related to this discussion, so I wanted to check with you if you could help me.

I'm configuring the Virtual Agent for a client, where they have multiple departments and the number of topics are meant to increase a lot.
For this reason we thought we could add an initial question, in the customised greetings setup topic, where we basically ask the users the type of support they are looking for (IT, Legal, HR, Facility, etc.).

When they select the department we would then set a variable somewhere (and here begins my issue), so that we can use it in the condition of the various topics, to decide whether they should be discovered or not.

I've tried with a vaVars, vaContext, vaInputs, and I also tried adding a parameter in the session (gs.getSession().putParameter), but it seems that when we try to look for this variable in the scripted condition of our topics, none of those objects are available.

I get errors like:

com.glide.script.RhinoEcmaError: "vaVars" is not defined.
Topic.7b6e9abe1bdf0910b6ec337a9b4bcb0e : Line(2) column(0)

Strange is that this issue only happens when the Va is trying to discover a topic with a search from the user. However, in the "Show me everything" selector, the topics are correctly filtered out, or shown when the condition is true.

I'm really struggling with this issue, as I'm not able to narrow down the number of Topics to the users.

Any suggestion on what I'm doing wrong? I've already raised a ticket in ServiceNow and they said it is out of standard support. And professional services, plus other ServiceNow employees, told me the approach is correct i.e. using an initial question to filter out not relevant topics, but I haven't received any feedback on how to achieve that.

Thanks
Alessandro

Mark Roethof · ‎05-26-2022

Hi there,

Can you create a new community question for this? That would be more suitable than posting this as a reply to an article.

Kind regards,
Mark