After many hours of tail chasing while trying to prepare our code for a migration from Voxeo to Plum, I found out that the 'value' attribute of the <option> tag and built in grammar does not re-assign the field variable value properly if the parent <field> element is of type 'digits'. To illustrate I have updated the example in your <option> tag documentation to specify the field type as digits, and if you run this you'll hear "You chose 3" instead of "You chose chicken" when you hit 3:
<?xml version="1.0"?>
<vxml version="2.0">
<form>
<field name="maincourse" type="digits?minlength=1;maxlength=10">
<prompt>
Please select an entree. Today, we're featuring:
<enumerate/>
</prompt>
<option dtmf="1" value="fish"> swordfish </option>
<option dtmf="2" value="beef"> roast beef </option>
<!-- Notice that, while this third option specifies -->
<!-- "frog legs" as the option text, if the caller -->
<!-- chooses this option, the "maincourse" field will be -->
<!-- set to the value "chicken". -->
<option dtmf="3" value="chicken"> frog legs </option>
<filled>
You chose <value expr="maincourse"/>.
</filled>
</field>
</form>
</vxml>
We've Moved! Please visit our new and improved forum over at our new portal: https://portal.plumvoice.com/hc/en-us/community/topics
<option> 'value' doesn't work when <field> type=
Plum IVR platform processes grammars in the following order:
The built-in digits type is taking precedence over the auto-generated options grammar. The Plum IVR platform processes IVR grammars in the following order: inline grammars first, then built-ins, then option-based grammars.
My best suggestion, if you want to continue to use the digits type, is to change minlength to 2 to avoid IVR grammar overlap.
My best suggestion, if you want to continue to use the digits type, is to change minlength to 2 to avoid IVR grammar overlap.