This is the second article in my mini-series exploring Moveworks' capabilities by teaching it to manage stories in ServiceNow.
Here is the full list of articles in the series:
- Part 1: Create Moveworks Plugins for Story Management
- Part 2: Let Otto write the Story.
Goal
Our goal is that Otto can manage stories in ServiceNow. Specifically, we want to improve the quality of our stories while reducing the time it takes to manage them through their entire lifecycle.
In part one, we asked Otto to simply retrieve and show us our stories. This time, we want Otto to take action and "turn intent into completed work", exactly what it was built for. We want Otto to create stories in ServiceNow, but not just by copy-pasting what the user writes. Instead, Otto should act as our guide: improving the story’s quality by aligning it with our best practices or even drafting parts of the story completely from scratch.
Let’s see how far we can push this. (Maybe in a later iteration, we’ll let Otto jump directly into the implementation, who knows.)
To start, Otto will focus on the following story attributes:
- Description: The provided description will be checked against story-writing best practices.
- Short Description: We will generate this based on the description. The maximum length should be 100 characters.
- Acceptance Criteria: If provided, we'll validate it against best practices. If the user prefers, the AI will draft the acceptance criteria itself. We'll also ensure the AI uses HTML formatting for this field.
Of course we could also do things like predicting the Theme, Epic, or other attributes, but let's take it one step at a time.
The Plugin
The development begins by defining the utterances that will trigger the plugin, followed by creating the conversational process that executes once it is triggered.
This time, the conversational process consists of four actions and two Slots: one Slot for the Description and one for the Acceptance Criteria.
mw.generate_text_action
In the previous article, we only used custom HTTP actions that we defined ourselves. However, Moveworks also provides built-in actions. One of these is mw.generate_text_action. (For the documentation, see: Moveworks LLM Actions)
This action generates text using an LLM. It's essentially the same as using ChatGPT, Claude, or Gemini in the background.
Description
Instead of copying the user's description verbatim, we want to see if the LLM can suggest improvements. To do this, we pass the text provided by the reasoning engine into the mw.generate_text_action as user_input.
We then use the system_prompt input parameter to instruct the LLM on how to process that input. This is where we tell the LLM exactly how the description should be formatted, allowing us to enforce our specific best practices. For the purpose of this article, I used the best practices from ServiceNow's Story Creation Guidance.
This action also lets us choose which model to use. In this case, I used gpt-5.5. (You can find the list of available models here: Model Reference)
Here is what the first action looks like:
Acceptance Criteria
The setup for the Acceptance Criteria is essentially the same. We mark the Slot for the Acceptance Criteria as required and map it to user_input. We select our generation model and provide a system prompt for guidance.
Because the out-of-the-box Acceptance Criteria field in ServiceNow is an HTML field, we also specifically instruct the model in our system prompt to format its output using HTML tags.
Short Description
The Short Description will be generated based on the description we just created in the first step. It needs to provide a high-level overview of the story and stay under a 100-character limit.
We map the newly generated description to user_input, and our instructions for how a short description should look to the system_prompt.
Creating the Story
Now that we have the content for the story, we need an action to actually create it in ServiceNow.
Therefore, we'll create a new HTTP action called ServiceNow_Create_story, which uses the Table API to insert a record into the rm_story table.
We set the HTTP Method to POST, and we define an input argument for each attribute we just generated.
These input arguments build the body of our request. We can build this body using either Raw JSON or the Data Mapper. If you use Raw JSON, you can access your variables by wrapping the variable name in double curly brackets (e.g., {{variable_name}}).
If you use the Data Mapper, you can access variables directly and even use DSL expressions to manipulate the values before sending them.
That’s it. Let’s test it and see how it works.
