Cannot access slot original value

[mig82]

When a slot is filled, I'd like to use it's resolved value under the hood but still refer to it by what the user said. For example, if a slot called country_slot is for the user to choose a country, and they say "Venezuela", the slot resolves this to ISO code VEN but I still need to tell the user Ok, you've chosen $session.params.country_slot.original. It seems this is not possible. The prompt is completely omitted from the conversation. I assume because the evaluation of this expression fails.

This would be consistent with the way to address an intent's parameter original and resolved values as intent.params.['param_name'].original and intent.params.['param_name'].resolved.

Looing at the flow of the conversation in the Actions Console, I can see that there's a slotMatch object with this information, but I can't seem to access this either.

{
  "slotMatch": {
    "nluParameters": [
      {
        "key": "country_slot",
        "value": {
          "original": "Spain",
          "resolved": "ESP"
        }
      }
    ]
  },
  "responses": []
}

[Fleker]

Can you access it through conv.body.intent.params[country_slot].original?

[mig82]

I had tried that. I'm afraid it won't work.

What happens is that the prompt for the condition fails to be evaluated and I just get "Sorry, I didn't get that" instead.

[Fleker]

Can you try using a webhook instead?

[mig82]

How would I go about solving this with a webhook?. This would require calling the webhook in between the slot being filled and it being resolved, so I can capture the original answer.

What I'm doing now to get around this is that on the slots being finalised I'm calling a service that given the country code returns the country name. This covers the use case.

However, I would still point out that having access to the original value for intents and not for slots seems awfully asymmetric. Maybe this should be fixed in later iterations.

[Fleker]

If you use a webhook, you should be able to capture the original value in the response like conv.body.intent.params[country_slot].original as it should be part of the webhook request. But it is good that you have found a workaround.

[mig82]

I see. But then does that mean that what's available in the prompt templates using $ is not the same as what's available to a webhook in the conv object? Is this intended? I think it would be ideal for the behaviour to be consistent. Maybe that's something to look into.

[Fleker]

I agree we should look into the available variables in the templates. I'm not as sure about the full scope of what is available, where it does appear in the webhook request body, available through the conv object.