Pass Data to Dynamic Resolvers with Strategy Mapping

A dynamic resolver cannot read the conversation process data bank. To pass an earlier value to its action, copy the value into the resolver with Strategy Mapping, then bind the resolver-local value to the action argument with Resolver Input Mapping.

In this walkthrough, an earlier activity returns a list of eligible building IDs. The resolver uses that list to populate a building slot. The configuration is the same whether the resolver strategy is attached to a custom data type or defined inline on the slot.

How the Data Moves

Both mappings use destination: source. Strategy Mapping creates the resolver-local building_sys_ids key from data.eligible_building_sys_ids. Resolver Input Mapping passes data.building_sys_ids to the action argument named building_sys_ids.

Before You Start

This walkthrough assumes you already have:

• A conversation process where an earlier activity produces a list at data.eligible_building_sys_ids
• A building slot with a dynamic resolver strategy, either inherited from its custom data type or defined inline
• A building lookup action with a required building_sys_ids argument

Step 1: Confirm the Source Value Is Available

Run the conversation through the activity that produces the eligible building IDs. In the logs, confirm that data.eligible_building_sys_ids contains the IDs before the process reaches the building slot. Strategy Mapping cannot copy a value that has not been produced yet.

Step 2: Map the Value into the Resolver

Open the building slot in the conversation process editor. Under Resolver Strategy, select View Strategy Mapping.

Add this mapping:

1
building_sys_ids: data.eligible_building_sys_ids

After this mapping runs, the resolver reads the value as data.building_sys_ids. The original data.eligible_building_sys_ids path remains in the conversation process data bank.

Step 3: Bind the Resolver Key to the Action Argument

Open the dynamic resolver method and select the building lookup action. In Input Mapping, add:

1
building_sys_ids: data.building_sys_ids

The left side names the action argument. The right side reads the resolver-local value created in Step 2. This mapping is required; leaving it blank or setting it to {} leaves the action argument unset.

Leave building_sys_ids out of Input Variables. Use Input Variables when the assistant should collect or infer a value during resolution.

Step 4: Finish the Resolver Output

Configure the Output Mapping and Output Cardinality for the building lookup action. If the action returns multiple eligible buildings, the output mapping must point to the array of building objects and the cardinality must interpret that array as a list of candidate values.

Step 5: Test the Full Conversation

Test through the AI assistant so the earlier activity and the resolver run in the same conversation:

1. Trigger the plugin and complete the inputs needed by the earlier activity.
2. Reach the building slot.
3. Open the action log for the building lookup.
4. Confirm the action received a non-empty building_sys_ids argument.
5. Select a building and confirm the chosen object is stored at data.building.

Choose the Input Source

A dynamic resolver can get action inputs from three places:

Resolver Input Mapping binds the selected source to the action argument.

Troubleshooting

Pattern Gallery

Apply the same two mappings to other resolver dependencies: