For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Logo
DeveloperAcademyCommunityStatus
ReferenceGuides
ReferenceGuides
  • Agent Studio
    • Overview
    • Quickstart Guides
      • Purple Suite Setup
      • Quickstart #1: Build Your First Plugin
      • Quickstart #2: Slots & Resolvers
      • Quickstart #3: Build a Plugin That Follows a Process
      • Quickstart #4: Structured Data Analysis (SDA)
      • Quickstart #5: Notification Ambient Agent
      • Quickstart #6: Expense Approval Ambient Agent
      • Quickstart #7: Scheduled Trigger Ambient Agent
      • Purple API Tool
    • Core Concepts
    • Conversation Process
    • Actions
    • Connectors
    • System Triggers
    • Agent Architect
    • Cookbooks
    • Development and Testing
    • AI Agent Marketplace
    • Developer Tools
  • Agentic AI
    • LLM Fundamentals
    • The Agentic Reasoning Engine
    • Memory Constructs
    • Conversational Context
    • Guardrails
    • Grounding and Hallucinations
    • Continuous Learning
    • LLMs & SLMs
    • Steerability Tools
    • Multilingual Support
  • Core Platform
    • User Identity
    • Moveworks Agent (On-Prem)
    • Approvals Engine
    • Entity Catalog
    • Moveworks Data Objects
    • Security Information and Event Management (SIEM) Logs Overview
DeveloperAcademyCommunityStatus
On this page
  • Learning Objectives
  • Prerequisites
  • What You’ll Build
  • Phase 0: Set Up the Purple Suite
  • Phase 1A: Set Up Your “Fetch Feature Requests” Action
  • Phase 1B: Set Up Your “Update Feature Request” Action
  • Phase 2: Create a “Feature Request” Data Type & Resolver Strategy
  • Phase 3: Build Your Conversational Process
  • Phase 4: Launch a Plugin
  • Reflecting On This Plugin
Agent StudioQuickstart Guides

Quickstart #2: Slots & Resolvers

||View as Markdown|
Was this page helpful?
Edit this page
Previous

Quickstart #3: Build a Plugin That Follows a Process

Build a purchase-request submission plugin with multiple slots, activities, and a decision policy.

Next
Built with

Learning Objectives

In this Quickstart guide, you’ll build on the core concepts covered in Quickstart #1 by building a more complex plugin that enables 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 the AI Assistant 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: Build Your First Plugin.

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 Assistant by launching a Plugin.

Let’s get started!

Phase 0: Set Up the Purple Suite

Already set up?

If you’ve already completed the Purple Suite Setup and have your connector configured, skip to Phase 1A.

Follow the Purple Suite Setup guide to:

  1. Create a Purple Suite instance at marketplace.moveworks.com/purple-suite
  2. Get your Instance ID and API Token (PAT)
  3. Set up a connector in Agent Studio with API Key auth

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 Agent Studio

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

2

Create a new HTTP Action

Navigate to a new HTTP Action.

3

Set the title and description

Set the following title and description for your Action (be sure to replace “firstname” and “lastname” with your corresponding information).

FieldValue to enter (replace “firstname” & “lastname” with your info)
Titlefirstname_lastname_fetch_feature_requests
DescriptionFetches a list of existing feature requests
4

Import the API details

Enter the details of your API:

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

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

    $curl -X GET "https://marketplace.moveworks.com/api/purple-suite/community/feature_requests" \
    >  -H "Authorization: Bearer YOUR_PAT" \
    >  -H "X-Instance-ID: YOUR_INSTANCE_ID"

  3. Replace YOUR_PAT and YOUR_INSTANCE_ID in the pasted command with your actual API Token (PAT) and Instance ID from the Purple Suite setup.

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

5

Add your connector

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

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

Publish

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 instance’s database.

1

Create a new HTTP Action

Navigate to a new HTTP Action. Click “Create”.

2

Set the title and description

Set the following title and description for your Action (be sure to replace “firstname” and “lastname” with your corresponding information).

FieldValue to enter (replace “firstname” & “lastname” with your info)
Titlefirstname_lastname_update_feature_request_action
DescriptionUpdates the status of an existing feature request
3

Import the API details

Enter the details of your API:

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

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

    $curl -X PATCH "https://marketplace.moveworks.com/api/purple-suite/community/feature_requests/{{feature_request_id}}" \
    >  -H "Authorization: Bearer YOUR_PAT" \
    >  -H "X-Instance-ID: YOUR_INSTANCE_ID" \
    >  -H "Content-Type: application/json" \
    >  -d '{"currentStatus": "{{new_status}}"}'

  3. Replace YOUR_PAT and YOUR_INSTANCE_ID in the pasted command with your actual API Token (PAT) and Instance ID from the Purple Suite setup.

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

4

Add your connector

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)

5

Define input arguments

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 of the editor.

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

  3. Fill out the following details for your feature_request_id argument:

    Field labelValue to enter/select
    Argument Namefeature_request_id
    Data TypeSelect “string”
    Example ValueCopy/Paste an existing FR-##### ID from your Purple Suite instance
    DescriptionThe ID of the feature request to update
    RequiredCheck 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 labelValue to enter/select
    Argument Namenew_status
    Data TypeSelect “string”
    Example Value7
    DescriptionThe status to update the given feature request to
    RequiredCheck the box

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

6

Test your action

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

Publish

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

Navigate to a new Data Type.

2

Set the title and description

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

FieldValue to enter (replace “firstname” & “lastname” with your info)
Titlefirstname_lastname_feature_request
DescriptionA feature request object
3

Provide the schema

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 the Resolver Strategy

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

Publish

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

Create a new Conversational Process

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

2

Set the title and description

Set the following title and description for your Conversational Process (be sure to replace “firstname” and “lastname” with your corresponding information).

FieldValue to enter (replace “firstname” & “lastname” with your info)
Titlefirstname_lastname_update_feature_request_process
DescriptionThis will help users update the status of an existing feature request.
3

Add Slots

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 labelValue to enter/select
    Namefeature_request
    Data TypeSelect theu_FirstnameLastnameFeatureRequest Data Type that you built in Phase 2
    Slot DescriptionThe feature request that the user wants to update.
    Slot Validation PolicyLeave blank
    Slot Validation DescriptionLeave blank
    Slot Inference PolicyLeave 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 labelValue to enter/select
    Nametarget_status
    Data TypeSelect “string”
    Slot DescriptionThe target status that the user wants to update the feature request to.
    Slot Validation PolicyLeave blank
    Slot Validation DescriptionLeave blank
    Slot Inference PolicyLeave 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 labelValue to enter/select
      Method Namechoose_from_existing_feature_requests
      Method TypeSelectStatic

    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 ValueRaw Value
      Existing Functionality/Native Skill2
      Limited Preview11
      Future Consideration3
      Not Enough Info to Make Decision6
      Delivered8
      Duplicate9
      New1
      On Roadmap7

    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

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

Validate

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 machineOn a Windows machine
    Cmd + Shift + VCtrl + Shift + V
6

Publish

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

Create a new Plugin

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

2

Set the title and description

Set the following title and description for your Plugin (be sure to replace “firstname” and “lastname” with your corresponding information).

FieldValue to enter (replace “firstname” & “lastname” with your info)
Titlefirstname_lastname_update_feature_request
DescriptionThis will help users update the status of an existing feature request.
3

Define a Conversational Trigger

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

  1. Click on “No triggers configured”.

  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

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

  1. Click on “No body configured”.
  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

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

Publish

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 Purple Suite instance 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!

Next step: Test your plugin. See our Testing & Error Handling guide for how to test, debug, and handle errors in production.