Its possible to add a few conditions to your slot for scenarios like this, but its not perfect. In general, slots are meant to collect any and/or all information given in a single input when the user might supply it.
ie when ordering a pizza, someone might say:
1. "I want a pizza" (no info)
2. "I want a pepperoni pizza" (toppings given)
3. "I want a large pizza" (size given)
4. "I want a large pepperoni pizza" (all info given)
In your scenario, do you think people will give the special instructions along with the initial input? I find it a bit odd, albeit possible. That, coupled with the complexity to configure, I'd recommend just using two different dialog nodes. One to collect the explicit info, and a second one to capture the open input for special instructions. Its going to lead to less effort on your part, and likely a higher rate of completion for your users because it will be more straight forward.
Less dialog nodes does not necessarily mean better design, so there's no need to try to squish things together unless its best for the conversation.
If you absolutely need to do it all in one slots node (again, for your user's benefit), there are a few options.
1. The "correct" way to do this would be using a contextual entity for things that look like special instructions. Its a pretty complicated type of data so I'd guess its going to take a decent number of annotations, maybe 30 or so to start?
2. you can add `&& slot_in_focus' to the `check_for` section of the slot. This tells the system NOT to collect this info until this slot is specifically the one being asked for. It basically goes against slots design principles in that it effectively turns it into a separate question. IMO its easier to just make it a stand alone dialog node for longer term maintainence and tracing.
3. I think, but you'd want to validate, that if you add a check_for `<? input.text ?>, it won't actually save the input if slots above this one are being filled. So if someone just says "my zip is 95123" it won't save the <? input.text ?> until nothing else is being saved. There's a lot of risk here, in that if someone digresses away, or raelly anything not answering the question, it will save it anyway because there's not other controls on it.
------------------------------
Mitch Mason
------------------------------
Original Message:
Sent: Thu September 24, 2020 06:26 PM
From: Daniel Toczala
Subject: Free form fields for slots?
Posting this for a friend (honest!!!):
I know Slots work great when the expected answers can be tied to existing @Entities, or even system entities like @sys-number, etc...
Is it possible to capture free-form text (i.e. input.text) via a Watson Assistant Slots?
For example, if there are 4 pieces of information that must be gathered - can there be a single dialog node with 4 Slots to do this (2 being free-form text entries)?
What is your street address? <input.text>
What state do you live in? @US_State
What is your zip code? @US_Zip
Are there any special directions or instructions (gate code etc)? <input.text>
------------------------------
Daniel Toczala
Community Leader and Customer Success Manager - Watson
dtoczala@us.ibm.com
------------------------------
#WatsonAssistant