Confirming Slots
Confirmation can be thought of as reverse validation. When validating slot values, the skill verifies that the values given by the user meet certain criteria. Confirmation, on the other hand, is checking with the user to make sure that what the skill is about to do meets the user’s expectations.
When scheduling a trip, for example, it would be helpful if Alexa repeated the trip details back to the user to make sure that she heard everything correctly before booking the trip. To enable such confirmation for the ScheduleTripIntent, we can simply set the confirmationRequired property on the intent to true and specify the prompt Alexa should use to confirm the trip details:
| | { "name": "ScheduleTripIntent", |
| » | "confirmationRequired": true, |
| | "prompts": { |
| » | "confirmation": "Confirmation.ScheduleTrip" |
| | }, "slots": [ ... ] } |
When the confirmationRequired property is set to true, Alexa will automatically ask for confirmation before submitting the request to the intent handler. As declared here, she will prompt the user for confirmation using the prompt named “Confirmation.ScheduleTrip”, which is declared like this:
| | { "id": "Confirmation.ScheduleTrip", "variations": [ { "type": "PlainText", "value": "I've got you down for a trip to {destination} leaving on {departureDate} and returning {returnDate}. Is that correct?" }, { "type": "PlainText", "value": "You want to visit {destination} between {departureDate} and {returnDate}. Is that right?" } ] } |
Just as with other prompts we’ve defined, the “Confirmation.ScheduleTrip” prompt has a couple of variations (although it’s generally a good idea to have as many variations as you can come up with to make the interaction feel natural). In both variations, the prompt’s text has placeholders for the destination and travel dates so that Alexa can present those values to the user to confirm. These placeholders are automatically bound to their corresponding slot values.
Giving this a spin in the developer console’s simulator, we can see the confirmation in action as shown in the screenshot.
You may have noticed that the final message has changed to “You’re all set. Enjoy your trip to Mars.” Before we added confirmation, it seemed appropriate to repeat all of the trip details in the final message. But if the confirmation message echoes those details, then it’s redundant to repeat them again in the final message. Therefore, the intent handler has changed slightly to speak a friendlier message:
| | const Alexa = require('ask-sdk-core'); |
| | const getResolvedSlotValue = require('./Helpers'); |
| | |
| | const ScheduleTripIntentHandler = { |
| | canHandle(handlerInput) { |
| | const request = handlerInput.requestEnvelope.request; |
| | return Alexa.getRequestType( |
| | handlerInput.requestEnvelope) === 'IntentRequest' |
| | && Alexa.getIntentName( |
| | handlerInput.requestEnvelope) === 'ScheduleTripIntent' |
| » | && Alexa.getRequest(handlerInput.requestEnvelope) |
| » | .intent.confirmationStatus === 'CONFIRMED'; |
| | }, |
| | handle(handlerInput) { |
| | const destination = |
| | getResolvedSlotValue(handlerInput.requestEnvelope, 'destination'); |
| | const departureDate = |
| | Alexa.getSlotValue(handlerInput.requestEnvelope, 'departureDate'); |
| | const returnDate = |
| | Alexa.getSlotValue(handlerInput.requestEnvelope, 'returnDate'); |
| | |
| » | const speakOutput = handlerInput.t('SCHEDULED_MSG', |
| » | { destination: destination }); |
| | |
| | return handlerInput.responseBuilder |
| | .speak(speakOutput) |
| | .withShouldEndSession(true) |
| | .getResponse(); |
| | }, |
| | }; |
| | |
| | module.exports=ScheduleTripIntentHandler; |
What’s more, notice that the canHandle() function checks that the confirmation status is “CONFIRMED”. That’s so that this request handler will only handle the request if the user said “Yes” or otherwise affirmed the dialog.
On the other hand, if the user says “No” or otherwise denies the dialog, then the confirmation status will be “DENIED”. This situation should also be handled, as shown here:
| | const Alexa = require('ask-sdk-core'); |
| | |
| | const ScheduleTripIntentHandler_DENIED = { |
| | canHandle(handlerInput) { |
| | const request = handlerInput.requestEnvelope.request; |
| | return Alexa.getRequestType( |
| | handlerInput.requestEnvelope) === 'IntentRequest' |
| | && Alexa.getIntentName( |
| | handlerInput.requestEnvelope) === 'ScheduleTripIntent' |
| » | && Alexa.getRequest(handlerInput.requestEnvelope) |
| » | .intent.confirmationStatus === 'DENIED'; |
| | }, |
| | handle(handlerInput) { |
| | const destinationSlot = |
| | Alexa.getSlot(handlerInput.requestEnvelope, 'destination'); |
| | const destinationSlotJSON = JSON.stringify(destinationSlot); |
| | |
| » | const speakOutput = |
| » | "Okay, I'll cancel your trip. What can I do for you now?"; |
| | |
| | return handlerInput.responseBuilder |
| | .speak(speakOutput) |
| | .reprompt("How can I help you?") |
| | .getResponse(); |
| | }, |
| | }; |
| | |
| | module.exports=ScheduleTripIntentHandler_DENIED; |
If the user issues a denial, then the dialog will conclude and Alexa will ask the user what she should do next.
Whether it be elicitation, validation, or confirmation, automatically delegated dialogs are great for adding natural conversation around slot gathering. But sometimes your skill’s dialog needs are more advanced than what automatic delegation can offer. For those situations, let’s have a look at how to write code that steps in during dialog delegation.