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 the Slot Resolvers documentation to understand how resolver strategies fit into the big picture.
Looking for a complete worked example? Quickstart #2: Slots & Resolvers walks through building a feature_request Data Type with a dynamic resolver end-to-end, including the HTTP action, the resolver configuration, output mapping, cardinality, and using the resolved object in a conversation process.
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
Resolver strategies are made up of multiple “methods.” Each method provides a list of possible values that matches the data type.
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 support@moveworks.ai!
You can build two types of methods:
JiraIssue, you might specify a few status options
id=4)id=8)id=10)
The AI agent will offer these options as part of how slot resolvers work.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.
Dynamic resolver methods do not support pagination. The action must return the complete list of candidates in a single response. If your source system returns large datasets, apply filtering at the HTTP action level (query parameters, request body filters) before the data reaches the resolver.
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
JiraIssue 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
If you always retrieve a single object in your output and want the entire object select the below setting: Interpret output as the exact value.
JiraIssue 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).
If you always retrieve a list in your output and want the user to make a selection from the list choose the below setting:Interpret output as a list of candidate values.
During the conversation, the AI agent picks the best method to use based on the conversation. For example, if you the following methods
JiraIssue by IDJiraIssue assigned to userJiraIssue by status & projectThen the AI agent will choose the right method based on the conversation
You can attach resolver strategies in two places:
Configure the resolver strategy directly on a custom data type. Every slot that uses that data type automatically inherits the resolver. This is ideal when multiple plugins need to resolve the same business object (e.g., a JiraIssue or SalesforceAccount).
A single data type can have multiple resolver strategies — for example, a JiraIssue type might have:
The AI agent selects the best method based on conversation context.
Configure the resolver strategy directly on a specific slot. This is useful for one-off resolvers that are specific to a single plugin and don’t need to be reused.
If a slot has an inline resolver AND its data type has a resolver, the inline resolver takes precedence for that slot.
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.
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).
Dynamic Resolvers require you to select an Action in order to dynamically lookup slot values.
It’s recommended to only use HTTP Actions for Dynamic Resolvers; Compound Actions are currently not supported. Script and Built-in actions are also available but HTTP Actions are preferred.
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. These will be collected from the user whenever the resolver slot is collected.
The names of these are important as that is how the reasoning engine infers what it is collecting from the user similarly to slots in a conversational process. Do not create additional slots in your conversational process for resolvers input variables, treat the input variables as if they are slots contained within the resolver itself.
Learn more about how to write JSON schemas at the official JSON schema docs.
In most cases, your resolver methods will collect their inputs from users (i.e. ask the user for the resolver input argument).
However, in some cases, you may want to set input args based on the rest of your plugin. For example,
TimeOffType records for a given User – requires one slot (the user) into the resolver for another slot (the time off type)To use context passing:
Attach a resolver strategy to the slot you want to receive context. This can be via a data type, or inline.
Select the View Strategy Mapping button.
Pass context from slots or activities in the conversation process to the slot resolver.
Warning
Slots & activities must be collected / completed before their contents are passed to a resolver. Else you may receive null / empty values.
Use your context-passed values in your resolver method.
data.<key_name> in the data bank (e.g. data.start_date above)This represents the output structure of your resolver method. 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 the http action in the resolver is stored as response when referencing it in the output mapper
Clicking “Switch to data mapper” will take you to a Data Mapper editor where you have more controls to fully define a custom output object.
Note: the output mapper must always point to an array if the output cardinality is set to interpret as a list of candidate values. This is how we build the list of option the user can select from
For example given an action with an output like
The output mapping would be response.results
See the Output Cardinality reference for guidance on which option to choose.
data.<input_arg>You can reference the input arguments of your resolver method with the notation data.<input_arg>
Important Note:
You can not reference the data bank of the conversational process. Only keys that have been explicitly context passed via the strategy mapper on the slot become part of the resolvers data bank in addition to input arguments defined on the resolver for collection.
meta_info.userYou 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.
Once the user selects one of the presented static options you can reference the output in the conversational process in 2 ways.
To reference the display value of the user’s static resolver choice use:
data.<slot_name>.display_name
To reference the raw value of the user’s static resolver choice use:
data.<slot_name>.value
Once the user selects one of the presented dynamic options, the entire object is bound to the slot. Reference it directly — there is no .value. indirection like there is on static resolvers.
To reference the whole selected object:
data.<slot_name>
To reference a field on the selected object:
data.<slot_name>.<field_name>
For example, given a slot named feature_request resolved by a dynamic resolver whose action returns objects with id, name, and current_status fields:
Do not write data.feature_request.value.current_status for dynamic resolvers — that pattern only applies to static resolvers (see above). On a dynamic resolver, fields hang directly off the slot name.
For how resolver strategies fit into slot configuration, see Slots.
For a complete end-to-end walkthrough — creating a custom Data Type, configuring a dynamic resolver against an HTTP action, mapping the output, and using the resolved object in a conversation process — see Quickstart #2: Slots & Resolvers.