Validating Slot Values

Suppose that the user asked Alexa to plan a trip, but rather than ask for a trip to one of the planets in our solar system, the user asked for a trip to Chicago. Such a conversation in the simulator might look like this:

As you can see, even though the destination slot is typed as PLANETS, it didn’t stop the user from asking for and scheduling a trip to Chicago. Alexa did stop and ask the user which planet that they’d like to visit, but that was only because “Chicago” isn’t one of the planets defined in PLANETS, so she wasn’t sure if she should put “Chicago” into that slot. But once she prompted the user for a planet and the user again said “Chicago,” she went ahead and used that value as the destination.

To stop the user from offering values that aren’t valid, we can define validation rules on the slot. For example, consider the following declaration of the destination slot, with an “isInSet” validation rule to ensure that the given value is one of the planets in our solar system:

The validations property defines one or more validation rules to be applied to the slot. The one validation rule defined here has a type of “isInSet”, If the value given by the user for the “destination” slot isn’t one of the values listed in the values property, then the “Slot.Validation.UnknownDestination” prompt will be returned to the user to ask them to supply a different value.

This should do the trick. But doesn’t it seem a bit odd to duplicate the list of planet names, when we’ve already defined all planets as part of the PLANETS type? We can get rid of that duplication by replacing the “isInSet” rule with a new “hasEntityResolutionMatch” rule, as shown here:

The “hasEntityResolutionMatch” rules considers the slot’s type and ensures that whatever value the user specifies matches one of the values in the type. If the user were to ask for a trip to anywhere that isn’t a member of the PLANETS type, then validation fails and Alexa will present the user with one of the variations of the “Slot.Validation.UnknownDestination” prompt.

Speaking of that prompt, here’s how “Slot.Validation.UnknownDestination” may be defined:

With this validation rule in place and a corresponding prompt at the ready, we’re ready to try out validation on the “destination” slot. Because we’re still using automatic dialog delegation, we can’t test the dialog with the BST testing tool or the Alexa Skill Testing Framework. But we can deploy it and try it out in the developer console simulator. The conversation might look something like this:

As before, after the user asked for a trip to Chicago, Alexa wasn’t sure that “Chicago” should be used for the slot value, so she asked where the user wants to go. But when the user said “Chicago” in response to the elicitation prompt, the validation rule kicked in. Since “Chicago” isn’t one of the planets defined in PLANETS, she explained that Chicago isn’t one of the destinations served and asked for another destination.

Now, let’s say that it doesn’t make sense to leave Earth only to travel to Earth. Therefore, while Earth is one of the planets in our solar system, it may not be a valid destination. Fortunately, we can specify more than one validation rule for a slot. To account for that case, let’s configure another rule to exclude Earth as a destination:

The “isNotInSet” validation rule is the opposite of “isInSet”. In this case, “earth” will pass the first validation check, because Earth is one of the planets contained within the PLANETS type. But it will fail this new validation rule, because “earth” is an entry in the “isNotInSet” rule. Therefore, if the user asks for a trip to Earth, Alexa will stop them and prompt them for another choice using the “Slot.Validation.NoStaycations” prompt. That prompt is defined like this:

With this new validation and its associated prompts declared, let’s give it a try. First, we’ll need to deploy the skill (using git commit/git push for Alexa-hosted skills or ask deploy if the skill is AWS Lambda-hosted). Then, in the developer console’s simulator, we can test out the validation by planning a trip to Earth as shown in the screenshot.

Nice! Although the skill recognizes Earth as a valid planet, it also prohibits it from being chosen as a destination, because traveling from Earth to Earth doesn’t make sense for the Star Port 75 Travel skill.

Aside from validating slots whose types are lists, as is the case with the PLANETS type, Alexa also supports many other kinds of validation,^[16] including date and number validation to ensure that values fall within a specific range. With that in mind, it might make sense to add validation to the departure and return dates, at very least enforcing that the return date falls after the departure date. But that kind of validation is a bit trickier than it sounds, so let’s defer it until section ​Explicitly Handling Dialog Delegation​. Instead, let’s look at the third kind of dialog rule: confirmation.