What are resolver strategies?

Resolver strategies instruct AI agents how to convert the user’s provided value (e.g. “this week's most important bug”) to a Data Type the system wants (e.g. <JiraIssue>_BUG-732).

Please read theSlot Resolvers documentation to understand how resolver strategies fit into the big picture.

One Strategy, One Data Type

Each resolver strategy produces one data type. For example, if I have a resolver strategy that is bound to the JiraIssue data type, then it can NOT also return an AsanaTask

Methods

Resolver strategies are made up of multiple “methods.” Each method provides a list of possible values that matches the data type.

🚧

Resolver Strategy Limitation

A Resolver Strategy can only have 1 Static Method or multiple Dynamic Methods.

It is not possible to have multiple Static Methods or a mix of Static & Dynamic Methods. If this something you think you need, reach out to your CSE or [email protected]!

Type of Methods

You can build two types of methods:

1. Static methods - preconfigure a multiple choice list of possible values. For example, if you're changing the status of a JiraIssue, you might specify a few status options
   • Not Started (id=4)
   • In Progress (id=8)
   • Done (id=10) The AI agent will offer these options as part of how slot resolvers work.
2. Dynamic methods - use an action to retrieve possible values. For example, if you're trying to get a list of JiraIssue records that are assigned to the user, you can fetch them from the Jira Issues API and offer them to the user. You can send data from your

   🚧

   Warning

   You can not currently use compound actions, but other action types are valid.

Output Cardinality

For a given resolver, the action, after output mappings are applied, should return an instance of your data type.

For example, a resolver strategy for JiraIssue might return

• A singleJiraIssue record - for example, if the user specified the issue by it's ID (e.g. "I want to close BUG-732"), then you can return the content as
  JSON

  {
    "id": "BUG-732",
    "title": "Set HTTP Status code correctly on custom REST API",
    ...
  }

• A list ofJiraIssue records, for example, if the user said "Show me my tasks," you would return a list of records. (Note: you can return 0, or 1 records, but it must be a list).
  JSON

  [
    {
      "id": "BUG-732",
      "title": "Set HTTP Status code correctly on custom REST API",
      ...
    },
    {
      "id": "BUG-733",
      "title": "Envelope response under 'data' keyword",
      ...
    },
    ...
  ]

Method Selection

During the conversation, the AI agent picks the best method to use based on the conversation. For example, if you the following methods

• Get JiraIssue by ID
• Get JiraIssue assigned to user
• Get JiraIssue by status & project

Then the AI agent will choose the right method based on the conversation

How do I configure Resolver Strategies?

The 2 ways to author Resolver Strategies

First, it's worth mentioning that there are 2 ways to author a resolver strategy:

1. As part of a Data Type. This will make your Resolver Strategy reusable wherever your data type is used.

2. As part of a Slot. This will tie your Resolver Strategy to a specific slot making it non-reusable.

Resolver Basic Info

It's important to provide a detailed Method Name as this helps the AI Assistant choose which Method is best for each conversation with the user. The Method Name must be in snake_case format.

Configuring a Static Resolver

Static Resolvers allow you to configure a list of options to show the user every time. Each option has a Display Value (what the end user will see) and a Raw Value (what will be used in your Activities).

Configuring a Dynamic Resolver

Dynamic Resolvers require you to select an Action in order to dynamically lookup slot values.

Setting

Selecting an Action

Its recommend to only use HTTP Actions for Dynamic Resolvers; Compound Actions, Scripts, and Built-in Actions will not work reliably if at all.

Input Arguments & Input Mapping

You can configure input arguments for your resolver method using a JSON schema. Inputs are added to the resolver method's data bank. For example, the following schema would provide a single feature_request_id string as data.feature_request_id.

{
  "type": "object",
  "properties": {
    "feature_request_id": {
      "type": "string"
    },
    "feature_request_name":{
      "type": "string"
    }
  }
}

Learn more about how to write JSON schemas at the official JSON schema docs.

Output Mapping

This represents the output object of your Activity. By default, it will capture all of the data that the action you selected returns. However, you can "dot walk" into the object if you want to limit the data returned.

The output value from your resolver method is stored as response

Clicking "Switch to advanced bender" will take you to a JSON Bender editor where you have more controls to fully define a custom output object.

Output Cardinality

See the Output Cardinality reference for guidance on which option to choose.

Data Bank

data.<input_arg>

You can reference the input arguments of your resolver method with the notation data.<input_arg>

meta_info.user

You can reference user attributes about the current user (ie. the user that triggered the plugin) with the notation meta_info.user

See User Attributes Reference for examples.