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

1. Access to the “Agent Studio” App.
2. 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:

You’ll build an end-to-end working Plugin via these phases:

1. Set up 2 (HTTP)Actions: one to fetch available feature requests, and another to update a feature request.
2. Set up a “feature request”Data Type, and attach a defaultResolver Strategy to power a feature request object (using the “fetch” Action you created in the previous phase).
3. Build the Conversational Process, containing the 1 Activity (using your other “update” Action) and the 2 Slots, as illustrated above.
4. 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

1. If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with <fullname>_<descriptive_name>
   1. For example: lucasrollo_Submit_PTO_Action
2. 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 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

1. Go to the Moveworks Purple API Tool.
2. Click “Create New Session ID”. You should see sample feature requests populate below.
3. 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.

1. Navigate to the App Picker in the top right corner of Agent Studio.

2. Click on “HTTP Connectors”, which will take you to another browser tab.

3. Click “Create” in the top right corner.

4. 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://marketplace.moveworks.com
   Auth Config	No Auth

5. 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

1. If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with <fullname>_<descriptive_name>
   1. For example: lucasrollo_Submit_PTO_Action
2. 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.

1. Navigate to the App Picker in the top right corner. Click on “Agent Studio”.

   

2. Navigate to a new HTTP Action.

   

3. 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

4. Enter the details of your API:

   1. Click on the “Import” icon to the right of the “TEST” button.

      

   2. Find the Session ID that you created & copied from Phase 0 — you’ll use it in the next step.

   3. Paste (don’t click “Import” yet) the following almost-ready cURL command:

      cURL

      curl "https://marketplace.moveworks.com/api/purple-suite/community/feature-requests?sessionId=YOUR_SESSION_ID"

   4. Replace YOUR_SESSION_ID (at the very end) in the pasted command with your actual Session ID.

   5. Click “Import” (your Action should now be auto-populated with details).

5. Add your Connector:

   1. Navigate to the “Connector” tab.

   2. Select “Inherit from existing connector”.

   3. Select the Connector you created in Phase 0 (e.g. firstname_lastname_moveworks_purple).

      

6. Test your Action:

   1. Click on the “TEST” icon (to the right of the endpoint URL definition).

   2. Inspect the Console to verify that you receive a successful response:

      

7. 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

1. If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with <fullname>_<descriptive_name>
   1. For example: lucasrollo_Submit_PTO_Action
2. 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.

1. Navigate to a new HTTP Action.

2. Click “Create”.

   

3. 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

4. Enter the details of your API:

   1. Click on the “Import” icon to the right of the “TEST” button.

      

   2. Find the same Session ID that you created & copied from Phase 0 — you’ll use it in the next step.

   3. Paste (don’t click “Import” yet) the following almost-ready cURL command:

      cURL

      curl -X PATCH "https://marketplace.moveworks.com/api/purple-suite/community/feature-requests/{{feature_request_id}}?sessionId=YOUR_SESSION_ID" \
      -H "Content-Type: application/json" \
      -d '{"newStatusNumber": "{{new_status}}"}'

   4. Replace YOUR_SESSION_ID (at the very end) in the pasted command with your actual Session ID.

   5. Click “Import” (your Action should now be auto-populated with details).

5. Add your Connector:

   1. Navigate to the “Connector” tab.

   2. Select “Inherit from existing connector”.

   3. Select the Connector you created in Phase 0 (e.g. firstname_lastname_moveworks_purple)

      

6. Define 2 formal input arguments to represent the “feature request id” and “new status” inputs that this Action requires:

   1. Click on the “Input Args” button near the top right corner.

      

   2. Click “Create New” in the “Input Arguments” pop up.

   3. 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 existingFR-##### ID from your Moveworks Purple API session
      Description	The ID of the feature request to update
      Required	Check the box

   4. Hit “Save”.

   5. Click “Create New” again in the “Input Arguments” pop up.

   6. 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

   7. Hit “Save” and hit the “X” icon to close this “Input Arguments” pop up.

7. Test your Action:

   1. Click on the “TEST” icon (to the right of the endpoint URL definition).

   2. Inspect the Console to verify that you receive a successful response:

      

8. 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

1. If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with <fullname>_<descriptive_name>
   1. For example: lucasrollo_Submit_PTO_Action
2. 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:

1. Navigate to a new Data Type.

   

2. 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

3. Provide the schema for an object of this type:

   1. Click “Import JSON” near the top right corner of the editor.

      

   2. Paste the following JSON sample object into the popup (this will allow you to auto-generate the schema):

      JSON

      {
        "id": "FR-12345",
        "name": "Add Dark Mode",
        "current_status": "New",
        "created_by": "user@example.com",
        "moderator": "abc@example.com",
        "product_area": "UI/UX"
      }

   3. Click “Generate”, and verify that the auto-populated schema looks correct (matches the structure of the sample object).

4. 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).

   1. Navigate to the “Resolver Strategy” tab.

      

      1. 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	SelectDynamic
         Action	Select thefirstname_lastname_fetch_feature_requests Action that you built in Phase 1A
         Input mapping	{}
         Output Mapping (“.dot_walk_here” box)	Leave blank (output is fine as is)
         Output Cardinality	SelectInterpret output as a list of candidate values

5. 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

1. If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with <fullname>_<descriptive_name>
   1. For example: lucasrollo_Submit_PTO_Action
2. 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:

1. Navigate to a new Conversational Process (navigate to the library and click “Create”).

2. 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.

3. Add TWO new Slots for the Process to interact with. One will represent the feature_request to update, and the other will be the target_status to set on the feature request. 📖Learn more about Slots.

   1. Click on the “Slots” button near the top right corner of the editor.

      

   2. Click “Create New” in the “Slots” pop up.

   3. Fill out the following details for your first feature_request Slot:

      Field label	Value to enter/select
      Name	feature_request
      Data Type	Select theu_FirstnameLastnameFeatureRequest Data Type that you built in Phase 2
      Slot 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)

   4. Hit “Save” (scroll to the bottom of the popup).

   5. Click “Create New” again in the “Slots” pop up to build your second Slot.

   6. 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)

   7. 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).

      1. Scroll to the very bottom of this Slot creation popup and click “Add Inline Resolver Strategy”.

      2. Click ”+ Add Method”.

      3. Fill out the following initial details for your Method.

         Field label	Value to enter/select
         Method Name	choose_from_existing_feature_requests
         Method Type	SelectStatic

      4. 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

      5. Click the “X” in the top right corner of the “Strategy Definition” pop up.

   8. Hit “Save” (scroll to the bottom of the popup) and hit the “X” icon to close this “Slots” pop up.

4. Build an Action Activity that will post the status update to the feature request. 📖 Learn more about Activities.

   1. Click on the ”+ Add a block to your process” button in the main section of the editor.

   2. Click on “Action Activity”.

      

   3. 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 thefirstname_lastname_update_feature_request_action Action that you built in Phase 1B *
      Required Slots	Select 2 slots:feature_request and target_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

5. 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”.

   1. 💡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

6. 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

1. If you are working in a Moveworks lab environment, name anything you save (Plugin, Action, Data Type, etc.) with <fullname>_<descriptive_name>
   1. For example: lucasrollo_Submit_PTO_Action
2. 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.

1. Navigate to a new Plugin (navigate to the library and click “Create”).

2. 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.

3. Define a Conversational Trigger. 📖 Learn more about Natural Language Triggers.

   1. Click on “Define a trigger”.

   2. In the panel that appears on the right, either:

      1. Approve (click “Trigger”) 5 of the auto-generated suggested positive examples, or

      2. 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

4. Choose your Conversational Process (the one you built in Phase 2).

   1. Click on “Set a process”.
   2. 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)

5. Define your Launch Configuration.

   1. Navigate to the “Launch Configuration” tab.

      

   2. In the Input field under “Allow selected users”, enter your email (or multiple emails using commas to separate the email addresses).

      

6. 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!