Quickstart #2: Slots & Resolvers
Learning Objectives
In this Quickstart guide, you'll build on the core concepts covered in Quickstart #1, and we'll build a more complex Task Agent that will enable a user to find and update a feature request. As part of the building process you'll learn how to:
- Build a Data Type to represent a feature request object.
- Create a Resolver Strategy that enables an AI Agent to find feature requests when it needs one
- Set up a Plugin that can use the Data Type & Resolver Strategy to power the process of finding the right feature request that a user wants to update.
Prerequisites
- Access to the "Agent Studio" App.
- Completed Quickstart #1: Basic Task Agent.
What You'll Build
The Plugin you're about to build solves a simple, but real-world problem: enable users to find and update a feature request.
Before starting to build, we always recommend that you first map out the desired end user experience and the overall building blocks of the Conversational Process.
Here is an example of the end-user experience we hope to enable:

To get to this experience, you can set up a Data Type to represent a "feature request" object, and your core Conversational Process should consist of one Activity (powered by an HTTP Action) and two Slots required in order to run the Activity:

Left: Data Type. Right: Conversational Process (does not require any Decision Policies).
You'll build an end-to-end working Plugin via these phases:
- Set up 2 (HTTP) Actions: one to fetch available feature requests, and another to update a feature request.
- Set up a "feature request" Data Type, and attach a default Resolver Strategy to power a feature request object (using the "fetch" Action you created in the previous phase).
- Build the Conversational Process, containing the 1 Activity (using your other "update" Action) and the 2 Slots, as illustrated above.
- Add the Conversational Process to your AI Agent by launching a Plugin.
Let's get started!
Phase 0: Generate a Unique Session ID & Set Up Your Connector
Import building notes if you are using the Moveworks Developer Labs environment
- If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with
<fullname>_<descriptive_name>
- For example:
lucasrollo_Submit_PTO_Action
- When launching your Plugin, make sure to only launch to yourself! You can do this by going to Your Plugin > Launch Configuration > Allow Selected Users > the email on your credential card
You may be able to skip this phase if you've completed another Agent Studio Quickstart guide.
You can skip Phase 0 and move onto Phase 1A if:
- You have already created a
firstname_lastname_moveworks_purple
connector, AND- You already have your unique "Session ID" on hand.
This section will walk you through how to set up your own connector to the Moveworks Purple API (which powers the Actions used in the Quickstart guides), so no need to repeat this step if you've done it before.
In this guide, you'll build a Plugin that will actually fetch from and take action on a store of feature requests that's set up just for you. In preparation for this, follow these steps
- Go to the Moveworks Purple API Tool.
- Click "Create New Session ID". You should see sample feature requests populate below.
- Copy your Session ID to your own notes. You'll to have this on hand in the following phase when we set up your Actions.
Now, you just need to set up a (reusable) connector that will allow you to seamlessly hit the necessary Actions that your Plugin will use.
-
Navigate to the App Picker in the top right corner of Agent Studio.
-
Click on "HTTP Connectors", which will take you to another browser tab.
-
Click "Create" in the top right corner.
-
Fill out the following information for your Connector (be sure to replace "firstname" and "lastname" with your corresponding information).
Field Value to enter (replace "firstname" & "lastname" with your info) Connection Name firstname_lastname_moveworks_purple
Description Moveworks Purple APIs Connector
Base Url https://us-central1-creator-studio-workflows.cloudfunctions.net
Auth Config No Auth
-
Click "Save" on the bottom right corner.
You're now fully ready to start building. On to Phase 1 to set up your Actions!
Before you proceed, make sure you've copied your Session ID somewhere you can access soon.
Phase 1A: Set Up Your "Fetch Feature Requests" Action
Import building notes if you are using the Moveworks Developer Labs environment
- If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with
<fullname>_<descriptive_name>
- For example:
lucasrollo_Submit_PTO_Action
- When launching your Plugin, make sure to only launch to yourself! You can do this by going to Your Plugin > Launch Configuration > Allow Selected Users > the email on your credential card
Let's first set up an HTTP Action that will fetch available feature requests. This Action doesn't require any dynamic inputs, and will just query an external system for a list of feature requests.
-
Navigate to the App Picker in the top right corner. Click on "Agent Studio".
-
Navigate to a new HTTP Action.
-
Set the following title and description for your Action (be sure to replace "firstname" and "lastname" with your corresponding information).
Field Value to enter (replace "firstname" & "lastname" with your info) Title firstname_lastname_fetch_feature_requests
Description Fetches a list of existing feature requests
-
Enter the details of your API:
-
Click on the "Import" icon to the right of the "TEST" button.
-
Find the Session ID that you created & copied from Phase 0 — you'll use it in the next step.
-
Paste (don't click "Import" yet) the following almost-ready cURL command:
curl "https://us-central1-creator-studio-workflows.cloudfunctions.net/getFeatureRequests?sessionId=YOUR_SESSION_ID"
-
Replace
YOUR_SESSION_ID
(at the very end) in the pasted command with your actual Session ID. -
Click "Import" (your Action should now be auto-populated with details).
-
-
Add your Connector:
-
Navigate to the "Connector" tab.
-
Select "Inherit from existing connector".
-
Select the Connector you created in Phase 0 (e.g.
firstname_lastname_moveworks_purple
).
-
-
Test your Action:
-
Click on the "TEST" icon (to the right of the endpoint URL definition).
-
Inspect the Console to verify that you receive a successful response:
You should see: Status Code 200, a list of Feature Request objects, and a response schema of the list.
-
-
Hit "Publish".
Nice! You've just set up 1 Action to fetch feature requests — 1 more Action to go.
In the next section, we'll build the final Action that this Plugin requires: an Action to update the status of the feature request object in the external database.
Phase 1B: Set Up Your "Update Feature Request" Action
Import building notes if you are using the Moveworks Developer Labs environment
- If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with
<fullname>_<descriptive_name>
- For example:
lucasrollo_Submit_PTO_Action
- When launching your Plugin, make sure to only launch to yourself! You can do this by going to Your Plugin > Launch Configuration > Allow Selected Users > the email on your credential card
Now, we'll build an Action that can apply a status update to a single feature request. This Action will require two dynamic inputs (feature_request_id
and new_status
), and should update the feature request record in your session's database.
-
Navigate to a new HTTP Action.
-
Click "Create".
-
Set the following title and description for your Action (be sure to replace "firstname" and "lastname" with your corresponding information).
Field Value to enter (replace "firstname" & "lastname" with your info) Title firstname_lastname_update_feature_request_action
Description Updates the status of an existing feature request
-
Enter the details of your API:
-
Click on the "Import" icon to the right of the "TEST" button.
-
Find the same Session ID that you created & copied from Phase 0 — you'll use it in the next step.
-
Paste (don't click "Import" yet) the following almost-ready cURL command:
curl "https://us-central1-creator-studio-workflows.cloudfunctions.net/updateFeatureRequest?featureRequestId={{feature_request_id}}&newStatus={{new_status}}&sessionId=YOUR_SESSION_ID"
-
Replace
YOUR_SESSION_ID
(at the very end) in the pasted command with your actual Session ID. -
Click "Import" (your Action should now be auto-populated with details).
-
-
Add your Connector:
-
Navigate to the "Connector" tab.
-
Select "Inherit from existing connector".
-
Select the Connector you created in Phase 0 (e.g.
firstname_lastname_moveworks_purple
)
-
-
Define 2 formal input arguments to represent the "feature request id" and "new status" inputs that this Action requires:
-
Click on the "Input Args" button near the top right corner.
-
Click "Create New" in the "Input Arguments" pop up.
-
Fill out the following details for your
feature_request_id
argument:Field label Value to enter/select Argument Name feature_request_id
Data Type Select "string" Example Value Copy/Paste an existing FR-##### ID from your Moveworks Purple API session Description The ID of the feature request to update
Required Check the box -
Hit "Save".
-
Click "Create New" again in the "Input Arguments" pop up.
-
Fill out the following details for your
new_status
argument:Field label Value to enter/select Argument Name new_status
Data Type Select "string" Example Value 7
Description The status to update the given feature request to
Required Check the box -
Hit "Save" and hit the "X" icon to close this "Input Arguments" pop up.
-
-
Test your Action:
-
Click on the "TEST" icon (to the right of the endpoint URL definition).
-
Inspect the Console to verify that you receive a successful response:
You can also go to Moveworks Purple API, fetch your session by Session ID, and see that your status for the feature request you updated is now "On Roadmap" (which is what status 7 represents).
-
-
Click "Publish". Review details, and click "Publish" once again.
All done with Actions!
You're ready to move on — time to create your first Data Type to represent feature request objects.
Phase 2: Create a "Feature Request" Data Type & Resolver Strategy
Import building notes if you are using the Moveworks Developer Labs environment
- If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with
<fullname>_<descriptive_name>
- For example:
lucasrollo_Submit_PTO_Action
- When launching your Plugin, make sure to only launch to yourself! You can do this by going to Your Plugin > Launch Configuration > Allow Selected Users > the email on your credential card
To power the process of updating a feature request, creating a formal Data Type to represent a "feature request" object can help us encapsulate the properties of a feature request. Furthermore, one of the critical properties of this Data Type is that there's a particular way to fetch values for the object: that's what the Resolver Strategy you're also about to build will take care of!
We'll build the "feature request" Data Type with its Resolver Strategy in this phase:
-
Navigate to a new Data Type.
-
Set the following title and description for your Data Type (be sure to replace "firstname" and "lastname" with your corresponding information). Note that the title will autofix itself to the appropriate formal type name (in
u_
prefixed format).Field Value to enter (replace "firstname" & "lastname" with your info) Title firstname_lastname_feature_request
Description A feature request object
-
Provide the schema for an object of this type:
-
Click "Import JSON" near the top right corner of the editor.
-
Paste the following JSON sample object into the popup (this will allow you to auto-generate the schema):
{ "id": "FR-12345", "name": "Add Dark Mode", "current_status": "New", "created_by": "[email protected]", "moderator": "[email protected]", "product_area": "UI/UX" }
-
Click "Generate", and verify that the auto-populated schema looks correct (matches the structure of the sample object).
-
-
Configure your Resolver Strategy. This strategy will contain one Dynamic Resolver Method, which is essentially a resolver that fetches candidate options from a dynamic source (in this case, from the "fetch feature requests" HTTP Action you configured in Phase 1A).
-
Navigate to the "Resolver Strategy" tab.
-
Fill out the following details for your Resolver Strategy Method:
Field label Value to enter/select Method Name choose_from_existing_feature_requests
Method Type Select Dynamic
Action Select the firstname_lastname_fetch_feature_requests
Action that you built in Phase 1AInput mapping Leave blank (no inputs to map to) Output Mapping
(".dot_walk_here" box)Leave blank (output is fine as is) Output Cardinality Select Interpret output as a list of candidate values
-
-
-
Click "Publish". Review details, and click "Publish" once again.
And just like that... you've created a fully-fledged Data Type!
Awesome work. Time to finally put this Data Type and the rest of these Actions to work in a Conversational Process.
Phase 3: Build Your Conversational Process
Import building notes if you are using the Moveworks Developer Labs environment
- If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with
<fullname>_<descriptive_name>
- For example:
lucasrollo_Submit_PTO_Action
- When launching your Plugin, make sure to only launch to yourself! You can do this by going to Your Plugin > Launch Configuration > Allow Selected Users > the email on your credential card
This Conversational Process, like the one in Quickstart #1, will also appear to be a simple single-Activity process. Its added complexity will be in the form of two Slots, where one of these Slots will be powered by the "feature request" Data Type you just created in Phase 2.
Here's a reminder of the bird's eye view for our Process (2 Slots, 1 Action Activity):

To build this Conversational Process:
-
Navigate to a new Conversational Process (navigate to the library and click "Create").
-
Set the following title and description for your Conversational Process (be sure to replace "firstname" and "lastname" with your corresponding information).
Field Value to enter (replace "firstname" & "lastname" with your info) Title firstname_lastname_update_feature_request_process
Description This will help users update the status of an existing feature request.
-
Add TWO new Slots for the Process to interact with. One will represent the
feature_request
to update, and the other will be thetarget_status
to set on the feature request. 📖 Learn more about Slots.-
Click on the "Slots" button near the top right corner of the editor.
-
Click "Create New" in the "Slots" pop up.
-
Fill out the following details for your first
feature_request
Slot:Field label Value to enter/select Name feature_request
Data Type Select the u_FirstnameLastnameFeatureRequest
Data Type that you built in Phase 2Slot Description The feature request that the user wants to update.
Slot Validation Policy Leave blank Slot Validation Description Leave blank Slot Inference Policy Leave as is (Infer slot value if available) -
Hit "Save" (scroll to the bottom of the popup).
-
Click "Create New" again in the "Slots" pop up to build your second Slot.
-
Fill out the following details for your second
target_status
Slot:Field label Value to enter/select Name target_status
Data Type Select "string" Slot Description The target status that the user wants to update the feature request to.
Slot Validation Policy Leave blank Slot Validation Description Leave blank Slot Inference Policy Leave as is (Infer slot value if available) -
Before saving this slot, you'll add an Inline Resolver Strategy to this
target_status
Slot. We want to power this Slot with a **Static Resolver**(aka a resolver which is backed by static multiple choice options).-
Scroll to the very bottom of this Slot creation popup and click "Add Inline Resolver Strategy".
-
Click "+ Add Method".
-
Fill out the following initial details for your Method.
Field label Value to enter/select Method Name choose_from_existing_feature_requests
Method Type Select Static
-
Add the following Static Options for your Static Resolver Method. (Note: the "Raw Value" column contains the actual values that your "update feature request" HTTP Action expects in order to successfully update the status on the feature request).
Display Value Raw Value Existing Functionality/Native Skill
2
Limited Preview
11
Future Consideration
3
Not Enough Info to Make Decision
6
Delivered
8
Duplicate
9
New
1
On Roadmap
7
-
Click the "X" in the top right corner of the "Strategy Definition" pop up.
-
-
Hit "Save" (scroll to the bottom of the popup) and hit the "X" icon to close this "Slots" pop up.
-
-
Build an Action Activity that will post the status update to the feature request. 📖 Learn more about Activities.
-
Click on the "+ Add a block to your process" button in the main section of the editor.
-
Click on "Action Activity".
-
Fill out the following details for your Action Activity, which mostly involves connecting your Slot to the input(s) of the HTTP Action (and mapping the result of the Action back to the Conversational Process):
Field label Value to enter/select Action Select the firstname_lastname_update_feature_request_action
Action that you built in Phase 1BRequired Slots Select 2 slots: feature_request
andtarget_status
Input mapping feature_request_id: data.feature_request.id
new_status: data.target_status.value
Output Mapping
(".dot_walk_here" box)Leave blank (output is fine as is) Output Key feature_request_update_result
Confirmation Policy Leave unchecked
-
-
Click "Validate" (Located in the top right corner. Click on the caret icon next to the Publish button). If everything went well so far, the Console (bottom of the editor) will say "Validation successful".
-
💡Pro-tip: You can also use the following hotkeys to validate without pressing the button:
On a MacOS machine On a Windows machine Cmd + Shift + V Ctrl + Shift + V
-
-
Click "Publish", review details, and Click "Publish" once again.
Awesome! You've just built the main part of this Plugin: the Conversational Process.
We're ready for the last step: now you'll launch a Plugin — this packages the Conversational Process into a tool that your AI Agent can use directly.
Phase 4: Launch a Plugin
Import building notes if you are using the Moveworks Developer Labs environment
- If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with
<fullname>_<descriptive_name>
- For example:
lucasrollo_Submit_PTO_Action
- When launching your Plugin, make sure to only launch to yourself! You can do this by going to Your Plugin > Launch Configuration > Allow Selected Users > the email on your credential card
In our final section, you’ll learn how to add your Conversational Process to a Plugin, and control the Triggering scenarios of your Plugin, and specify which end users are allowed to use your Plugin.
-
Navigate to a new Plugin (navigate to the library and click "Create").
-
Set the following title and description for your Plugin (be sure to replace "firstname" and "lastname" with your corresponding information).
Field Value to enter (replace "firstname" & "lastname" with your info) Title firstname_lastname_update_feature_request
Description This will help users update the status of an existing feature request.
-
Define a Conversational Trigger. 📖 Learn more about Natural Language Triggers.
-
Click on "Define a trigger".
-
In the panel that appears on the right, either:
-
Approve (click "Trigger") 5 of the auto-generated suggested positive examples, or
-
Add the following recommended utterances:
Utterances to add How do I update a feature request?
Can you update a feature request?
Change status of FR-12345 to "Limited Preview"
update feature request
Change feature request status
-
-
-
Choose your Conversational Process (the one you built in Phase 2).
- Click on "Set a process".
- In the panel that appears on the right, search for and select the Conversational Process that you built in Phase 2 (should be named
firstname_lastname_update_feature_request_process
)
-
Define your Launch Configuration.
-
Navigate to the "Launch Configuration" tab.
-
In the Input field under "Allow selected users", enter your email (or multiple emails using commas to separate the email addresses).
-
-
Click "Publish" to launch your Plugin.
And just like that — you've finished building your Plugin, and now it's ready to use!
Use one of your triggering examples (e.g. "update feature request") to access the Plugin in conversation. If all goes well, you'll be greeted with a list of feature requests to choose from.
Try refreshing your sample feature requests in your Moveworks Purple API session to see the updates take effect in real time!
Reflecting On This Plugin
This Plugin involved a good number of core concepts in Agent Studio, with some special focus on the concept of Resolver Strategies. You've created a plugin that:
- Fetches available feature requests from a dynamic external source via an HTTP Action.
- Interactively gathers details from users to choose which feature request to update or status to update to.
- Ensures accurate and API-compatible values are passed to your Actions.
- Executes for the right users at the right moments via Triggering and Launch configurations you've set up.
Way to stick through it, and now your Plugin is ready to enable users to seamlessly keep their feature requests up to date!
Updated 1 day ago
Take a look at our other Quickstart examples!