With the introduction of EmployeeWorks as the AI Enterprise Front Door, the way employees interact with ServiceNow is fundamentally changing. We are shifting away from portals with rigid structures toward a conversational experience. Employees no longer need to navigate complex Knowledge Base structures or Catalog categories. A single conversation with Otto gives them all the information they need, and they can immediately instruct Otto to complete the related tasks.
To make this vision a reality, Otto (in this case, Moveworks) must not only understand the employee's intent but also seamlessly connect to various enterprise systems to execute those tasks.
Moveworks already comes with a robust set of built-in connectors. When setting up the basic integration between Moveworks and ServiceNow, a lot of functionality is already available. You can use Enterprise Search with your Knowledge Base, ingest catalogs to make them searchable and orderable, and expose Incidents and Service Requests directly within Moveworks.
But as a developer, the best way to truly understand a system is to build something yourself. That’s why I decided to extend the Conversational Assistant’s capabilities so it can work with ServiceNow Stories.
In this short series of articles, I will share my experience building the following capabilities:
- Ask questions about my stories
- Create new stories in a conversational way
- Let Moveworks enhance the quality of existing stories
Agent Studio
Moveworks provides Agent Studio to "connect AI assistants to your business systems & content."
Within Agent Studio, we build Plugins to extend the capabilities of our AI Assistants.
The Structure
The following image represents my current mental model of plugins. This is not a complete picture of everything that is possible, but it helped me to have an overview and learn the basics.
For this project, I am building a plugin triggered by a conversation with a user. Therefore, the plugin consists of a Conversational Process and a Trigger built using example utterances. (Note: The other option is an ambient plugin triggered by system events, which I maybe cover in a later post).
Setting up the Trigger
In addition to the positive utterances (what users say to start the process), you can also provide negative examples (what shouldn't trigger the process). For my plugin, ServiceNow Show Stories, the trigger configuration looks like this:
As you can see in the screenshot, the system generates suggested utterances based on your plugin's description. You can use these suggestions or write your own, but you need at least five positive examples. Once triggered, this will execute the Conversational Process servicenow_get_user_assigned_stories.
The Conversational Process
The conversational process contains the different actions that are executed once the plugin is triggered. There are four action types available:
- Built-in Actions
- HTTP Actions
- Script Actions
- Compound Actions
Because I need to fetch data from a different system, in this case my ServiceNow instance, I am using an HTTP Action to execute a simple GET request against the Table API.
The Base URL is automatically populated based on the selected connector I configured during the initial integration setup.
You can define input arguments for your HTTP Actions. To reference a variable inside the action, you wrap its name in double curly brackets {{variable_name}}. For this action, I use a variable for the user ID inside the sysparm_query parameter to fetch the correct stories.
Once the HTTP action is created, I can add it to my conversational process.
During the initial integration setup, I imported ServiceNow users into Moveworks and mapped them by email address. However, the initial integration did not import the sys_ids from the ServiceNow user records. As a result, Moveworks doesn't have direct access to the user's sys_id.
To pass the sys_id into the conversational process, I need to define an input value, which Moveworks calls a Slot. When a slot exists, the AI tries to fill it with a value based on the slot's description and the context of the user's conversation.
This works good for some cases but not when we need the sys_id from the current user. For this case we need a way to tell the AI exactly how to translate the user to a sys_id. This can be done by Resolver Strategies.
Resolver strategies can use dynamic or static actions to do these translations.
For my use case, I built a dynamic resolver strategy that triggers a second HTTP action. This action queries the sys_user table in ServiceNow to find the record matching the current user's email address (which Moveworks already knows via the meta_info.user.email_addr attribute).
This second HTTP Action, servicenow_get_user, is a simple HTTP GET request to the instance, very similar to the one we built to fetch the stories.
Finally, I configured the slot we just created as a required slot for the servicenow_get_stories_assigned_to_user action in the conversational process. This guarantees that the AI always fetches the user record (and the sys_id) before it attempts to query the stories.
The Result
And that’s basically it! Once the process is published, we can test it immediately to see if Otto successfully retrieves and displays the user's assigned stories.
In the next article, we will take this a step further and create a new story using a conversational process. We'll provide some basic details and let the AI formulate a well-structured story for us. Stay tuned!
