5 minute read
Virtual Agent
Virtual Agent is a new feature in the London version of ServiceNow. I have dived deep into this new feature to share with you. Virtual Agent is a form of chatbot which helps guide users with conversation style interactions to get them the information they need or aid them to input a request to your ServiceNow instance. The guided interaction can result in delivering the user a knowledge article, helping them fill out and submit a request, or get them to the right human support queue.
Let’s take a look at what this interaction looks like. It starts with a user invoking an interaction. This can be done in many different ways. It can be done via a service portal widget, stand-alone HTML client, integrations with slack or teams, or via iOS or Android applications. Each of these different interaction methods must be set up and configured instructions can be found in the Docs Site. Most of my screenshots will be from the standalone HTML client.
As you can see above you have the bot interacting with the user in human language as a conversation. We will follow the example topic flow for requesting a change for most of this post. Users are prompted for the type of change and the details required to get a change request ready for submission all within the conversation. The logic that drives this interaction is built in the Virtual Agent Designer.
Virtual Agent Designer
Each Agent workflow is called a Topic. To build the topics you utilize the Virtual Agent Designer. The designer is a visual workflow editor that is built from activities through a drag and drop interface. You can filter access via roles and scope to any topic. The keywords are words that will cause this topic to be invoked in a conversation. Let’s take a look at the components of the designer. First up on the left-hand side are the activities you will use to build your logic. They are broken up into User Inputs, Bot Responses, Utilities, and Script Variables.
These components are how the interactions are put together. Take special note of the script variables. These are how activities pass information. The activities use vainputs.variablename to read and write to those variables. The other variables are just for workflow logic and are referenced with vavars.variable name. The main window of the designer is where the logic is built. These variables can be scripted and respect the scope in which the scope the script is run in.
When you select one of the activities it is configured via the properties pane on the right. Any of the scripting you do inside of the activities is done with JavaScript. Utilizing gs.message for your interactions is important if you want to use internationalization for delivering multiple languages. Those messages are stored in sys_ui_message table. You can use conditions to control when and if a given activity is invoked.
The preview button in the top right is very important while building your Topic. Saving and previewing is important to do as you are building your topic. Getting a topic interaction to be easy for the end user is a very iterative process. I highly suggest building and testing as you go. The topics are stored on the sys_cb_topic table. Even the layout and position of the workflow is stored as a JSON object. When you preview a topic, it is placed temporarily in the runtime topic table: sys_cs_topic. These are cleaned up after 12 hours.
The conclusion of your topic might be transferring to a live agent, creating a record, or delivering information like from a knowledge base. To transfer to a live agent you can use vaSystem.connectToAgent() in a scripted action or the user selecting that option from the menu. Either of these methods results in the transition to the appropriate connect support queue.
Technical Details
When you are ready to deploy your Topic you utilize the normal development methods to promote from your development instance to deploy it up to production. You can also export a topic to XML for sharing with others. Delegated development and domain separation are both supported.
When previewing a Topic you can enable the logs, which are quite extensive. You can use the logs to really dig deep into what is going on and what might be causing issues during your build process.
Tables of note
sys_cb_topic: Where topics are stored
sys_cs_topic: Where runtime topics are stored
sys_ui_message: Message storage table, important for translations
sys_cs_live_agent_setup: How you setup agents
Performance & Integrations
Agent conversations have their own worker threads that you can see in your stats and diagnostic pages. 2 threads have been added and dedicated to just handling these conversations to ensure the responsiveness of your bots. Scripts are scope aware and need to use scoped APIs.
Integrations with systems like slack support one to one user to agent interactions. This means the agents don’t work for engaging users in a group channel. Another note for integrations is many systems don’t support HTML rendering and thus they get images from the conversation instead of text.
Future
Virtual Agents are all about driving improved user experience with your system. This first release is definitely worth looking at if you wish to improve your customers experience interacting with your system. Check out the example topics provided and get inspired on how you can make life easier. We will have blog and example Topics in the future.
Share this post
Twitter
Facebook
Reddit
LinkedIn
Email