Validating user input before processing these values goes a long way in improving the bot’s efficiency and user experience. While the entity type does impose some basic restrictions, these are not always sufficient and does not cater to the specific business requirements. Entity rules can be used for additional processing hints and validations.
Entity rules can be added from the Entity Rules section under Instance Properties of the corresponding entity. Add the rule in the JSON editor provided, see here for how.
These rules can also be set in the script for an entity, in such cases, the rule needs to be set before the entity prompt in the dialog flow. Add a script node at the beginning of the dialog or just before the concerned entity node with the following script:
context.entityRules.<entityName> = { "ruleName": "value" }
Subentity rules can be part of the composite entity rules:
context.entityRules.<compositeEntityName> = { <subentityName> : { "ruleName": "value" } }
Below are the entity rules that can be entered in the JSON editor for the required entity or included as ruleName
in the above script. We are continuously improving and updating this list. Any feedback or suggestions, kindly post in the community forum and our developers will accommodate it, if feasible.
Generic rules
ruleName | Value | Description |
---|---|---|
processLatestSentence | true/false | To restrict checking to the sentences only from the current volley. |
Example { "processLatestSentence": <true/false> } |
||
patternsOnly | true/false | To restrict matching to an entity pattern alone. By default, if the given entity patterns do not result in the extraction of entity value, the platform tries to find a value from user utterance. Setting this rule to true will disable that default processing. |
Example { "patternsOnly": <true/false> } |
||
allowConfirmation | true/false | The extracted entity value is presented to the user after each input and the flow would continue only after confirmation from the user. Currently, this rule is applicable only for LoV enumerated entity types. |
Example { "allowConfirmation": <true/false> } |
||
confirmYesSynonyms | <concept names> | Additional words/phrases to be used to confirm an entity value. Used in conjunction with allowConfirmation rule mentioned above. |
Example { "confirmYesSynonyms": ["~concept1", "~concept2"] } where concept1: ok; |
||
confirmNoSynonyms | <concept names> | Additional words/phrases to be used to cancel a confirmation entity. If selected/uttered, the entity value will be set to null Used in conjunction with allowConfirmation rule mentioned above. |
Example { "confirmNoSynonyms": ["~concept2", "~concept3"] } where concept1: nope; |
String type entity
Description entity type
ruleName | Value | Description |
---|---|---|
stripLeading | <concept name> |
To remove the words given in the concept from the start of the extracted string. The concept can be a single concept name or a space-separated list of concepts or an array of concept names. |
Example | ||
JSON { "stripLeading": [ "~stringConcept" ] } |
stringConcept: city Entity Pattern: I like * User Utterance “I like city New York“ |
|
stripTrailing | <concept name> |
To remove words in a concept from the end of the extracted string. The value can be a single concept name or a space-separated list of concepts or an array of concept names. |
Example | ||
JSON { "stripTrailing": "~stringConcept ~stringConcept1" } |
stringConcept: city; stringConcept1: airport Entity Pattern: I like * User Utterance “I like New York city” or “I like New York airport“ |
|
avoidSingleWord | <concept name> |
To ignore any value that is a member of the concept, unless it is the entire input. The value can be a single concept name or a space-separated list of concepts or an array of concept names. |
Example | ||
JSON { "avoidSingleWord": "~stringConcept" } |
stringConcept: chess, cricket Entity Pattern: like to watch * tournament User Utterance “I like to watch chess tournament“ User Utterance “I like to watch golf tournament“ User Utterance “cricket“ |
|
avoidSingleVerb | true | If set to true, then any value that is just a verb is ignored, unless it is the entire input. |
Example | ||
JSON { "avoidSingleVerb": true } |
Entity Pattern: I like * music User Utterance “I like playing music“ User Utterance “I like rap music“ User Utterance “play“ |
|
extractOnlyNumbers | true | if true, the entity will extract only numbers present in the string and set it as the entity value |
Example | ||
JSON { "extractOnlyNumbers": true } |
Number type entity
ruleName | Value | Description |
---|---|---|
asString | true | To capture a number as a string, preserving leading zeros |
Example | ||
JSON { "asString": true } |
Entity Pattern – by default numeric entries User Utterance “OTP is 009944“ |
Currency type entity
ruleName | Value | Description |
---|---|---|
defaultCode | <currency code> or <country code> |
If no code is mentioned in user input, this value will be picked as code. The value needs to be a 3 letter currency code or two-letter country alpha-2 codes. |
Example | ||
JSON { "defaultCode": "NZD" } |
Entity Pattern pay * User Utterance “Pay 30“ User Utterance “Pay USD30“ |
|
maxDigits | <number> | To restrict the amount length. If the amount length exceeds the value it will be discarded. |
Example | ||
JSON { "maxDigits":[ "3" ] } |
Entity Pattern pay * User Utterance “Pay USD30“ User Utterance “Pay USD3000“ |
|
currencyCodes | [<currency code>,<currency code>] or [<country code>,<country code>] |
To restrict the currency codes. If the user entered code is not in the given list then the value will be discarded. |
Example | ||
JSON { "currencyCodes": [ "USD", "INR", "NZD" ] } |
Entity Pattern pay * User Utterance “Pay USD30“ User Utterance “Pay AUD30“ |
PersonName type entity
ruleName | Value | Description |
---|---|---|
disablePatterns | An array of person name patterns to ignore – currently supporting only “possessive“ | To disable patterns in extracting a person’s name when not applicable in specific scenarios. |
Example | ||
JSON { "disablePatterns": [ "possessive" ] } |
Entity Pattern – by default capitalized words User Utterance “schedule Bob’s review at 9 am” |
|
ignoreWords | <concept name> |
Words in the concept are not to be considered as names even when capitalized. The concept name could be a space-separated list of concepts or an array of concepts. |
Example | ||
JSON { "ignoreWords": [ "review", "~prepositionList" ] } |
Entity Pattern – by definition capitalized words User Utterance “meeting for Bob Review” |
|
negativePatterns | array of patterns | Person names can be general capitalized words, or a name can be used in a sense where it is not meant to be taken as a person. |
Example | ||
JSON { "negativePatterns": [ "about *" ] } |
Entity Pattern – by definition capitalized words User Utterance “schedule a meeting about Philip with Fred” |
Company type entity
ruleName | Value | Description |
---|---|---|
ignoreWords | <concept name> |
Words in the concept are not to be considered as companies even when capitalized. The concept name could be a space-separated list of concepts or an array of concepts. |
Example | ||
JSON { "ignoreWords": [ "atm" ] } |
Entity Pattern – by definition capitalized words User Utterance “find ATM” |
|
negativePatterns | An array of company name patterns to ignore | To disable patterns in extracting a company name when not applicable in specific scenarios. |
Date type entity
ruleName | Value | Description |
---|---|---|
range | { “from” : <from-date>, “to” : <to-date> } |
To extract dates only in the specified range. Either endpoint is optional. Values can be a date, YYYY-MM-DD, or a keyword: today, tomorrow, yesterday. The dates are inclusive. |
Example | ||
JSON { "range": { "from": "2020-01-01", "to": "today" } } |
Entity Pattern – by default date patterns User Utterance “show schedule for 2019-02-03” User Utterance “show schedule for tomorrow” User Utterance “show schedule for 2020-02-03” |
|
referenceDate | <date> |
Sets the reference date to <date> and any date calculation to set the current date entity value is based on that date. Values should be a date, YYYY-MM-DD, or a keyword: today, tomorrow, yesterday. |
Example | ||
JSON { "referenceDate": "2020-07-09" } |
Entity Pattern – by default date patterns User Utterance “schedule after two days” |
|
preferredDateFormat | “yyyy-mm-dd” |
In case of ambiguity in date, it uses the preferred date format to resolve ambiguity.
|
Example | ||
JSON { "preferredDateFormat": "mm-dd-yyyy" } |
User Utterance “03-04-2021” Extracted Value “2021-03-04” NOTE: This rule comes into the picture only when there is an ambiguity in the user utterance. If the user’s preference is already set as part of a previous conversation, then the user selected format would take precedence over the defined rule For example, a per the previous use case, if the user had selected the preferred format to be “dd-mm-yyy” previously in the conversation then the date would be taken as “2021-04-03” |
|
returnOnlyMonthYear | <true/false> | When set to true, the platform would capture the month and year alone from the user input and update the context object accordingly. Even if the user gives a full input (like 20 Oct 2019), the system would only take Oct 2019 from that input. The user will not be prompted for the date if not provided |
Example | ||
JSON { "returnOnlyMonthYear": true } |
User Utterance “03-04-2021” Extracted Value “04-2021”User Utterance “Apr 2021” Extracted Value “04-2021” |
Date Period type entity
ruleName | Value | Description |
---|---|---|
range | { “from” : <from-date>, “to” : <to-date> } |
To extract dates only in the specified range. Either endpoint is optional. Values can be a date, YYYY-MM-DD, or a keyword: today, tomorrow, yesterday. The dates are inclusive. |
Example | ||
JSON { "range": { "from": "2020-01-01", "to": "today" } } |
Entity Pattern – by default date patterns User Utterance “show schedule for 2019-02-03” User Utterance “show schedule for tomorrow” User Utterance “show schedule for 2020-02-03” |
|
referenceDate | <date> |
Sets the reference date to <date> and any date calculation to set the current date entity value is based on that date. Values should be a date, YYYY-MM-DD, or a keyword: today, tomorrow, yesterday. |
Example | ||
JSON { "referenceDate": "2020-07-09" } |
Entity Pattern – by default date patterns User Utterance “schedule after two days” |
|
tense | past/future |
To adjust the date period based on the tense when the year is not present in the user utterance. Without this rule, the year is set as the current year if the month/day falls within 90 days from the current date else it would be set to the previous year. With this rule, you can force the year to current or past. |
Example | ||
JSON { "tense": "past" } |
Entity Pattern – by default date patterns User Utterance “get the statement for Jan”
|
|
preferredDateFormat | “yyyy-mm-dd” | In case of ambiguity in date, it uses the preferred date format to resolve ambiguity. Values can be:
|
Example | ||
JSON { "preferredDateFormat": "mm-dd-yyyy" } |
User Utterance “03-04-2021” Extracted Value “2021-03-04” NOTE: This rule comes into the picture only when there is an ambiguity in the user utterance. If the user’s preference is already set as part of a previous conversation, then the user selected format would take precedence over the defined rule For example, a per the previous use case, if the user had selected the preferred format to be “dd-mm-yyy” previously in the conversation then the date would be taken as “2021-04-03” |
DateTime type entity
ruleName | Value | Description |
---|---|---|
range | { “from” : <from-datetime>, “to” : <to-datetime> } |
To extract date-times only in the specified range. Either endpoint is optional. Values can be a date, YYYY-MM-DD, or a DateTime, YYYY-MM-DDTHH:MM:SS (user’s timezone is assumed if none specified) or a keyword: today, tomorrow, yesterday, now. The dates are inclusive. |
Example | ||
JSON { "range": { "from": "2020-01-01T00:00:00+05:30", "to": "2020-10-01T00:00:00+05:30" } } |
Entity Pattern – by default date time patterns User Utterance “set alarm for 2019-02-03T10:00:00” User Utterance “show schedule for 2021-12-20T10:00:00” User Utterance “show schedule for 2020-02-03 T10:00:00” |
|
preferredTimes | { “from” : <from-time>, “to” : <to-time> } |
To set the preferred time which can be used to interpret times when they are ambiguous. These times would be applicable to all days of the week. For example, “3” will become “3 pm” if the preferredTimes are 9 am to 6 pm. If the time cannot be placed inside the range then it will pick am/pm based on which is closest. If there are two possibilities or equal distance then the “daylight/standard awake” hours will be used. The times should be ISO 8601 format, THH:MM |
{ “from” : [], “to” : [] } |
This option is for setting preferred times different for different days of the week. The “from” and “to” keys can be arrays with 7 members representing the time for each day, from Sunday to Saturday. Each value should be in the in Thh:MM format or an empty string to indicate there is no preference. | |
{ “favor” : <keyword> } | The “favor” keyword can be used to set the preference in terms of “future”, “past”, “am”, or “pm”. | |
Example | ||
JSON "preferredTimes": { "from": "T12:00:00", "to": "T18:00:00" } |
Entity Pattern – by default date patterns User Utterance “remind me at 3” |
|
JSON "preferredTimes": { "from": [ "", "T09:00", "T09:00", "T21:00", "T21:00", "T07:00", "" ], "to": [ "", "T18:00", "T18:00", "T06:00", "T06:00", "T16:00", "" ] } |
Entity Pattern – by default date patterns User Utterance “remind me at 3” |
|
JSON "preferredTimes": { "favor": "pm" } |
Entity Pattern – by default date patterns User Utterance “remind me at 3” |
|
timeRangePossible | true/false |
If true then the dialog will be looking for time range in the user input. Influences how “10 to 4” is interpreted. By default, this will be “3:50” but if there is the possibility of a range then will be decoded as 2 times “10:00” and “16:00” |
Example | ||
JSON { "timeRangePossible": "true" } |
|
|
preferredDateFormat | “yyyy-mm-dd” | In case of ambiguity in date, it uses the preferred date format to resolve ambiguity. Values can be:
|
Example | ||
JSON { "preferredDateFormat": "mm-dd-yyyy" } |
User Utterance “03-04-2021” Extracted Value “2021-03-04” NOTE: This rule comes into the picture only when there is an ambiguity in the user utterance. If the user’s preference is already set as part of a previous conversation, then the user selected format would take precedence over the defined rule For example, a per the previous use case, if the user had selected the preferred format to be “dd-mm-yyy” previously in the conversation then the date would be taken as “2021-04-03” |
Time type entity
ruleName | Value | Description |
---|---|---|
preferredTimes | { “from” : <from-time>, “to” : <to-time> } |
To set the preferred time which can be used to interpret times when they are ambiguous. These times would be applicable to all days of the week. For example, “3” will become “3 pm” if the preferredTimes are 9 am to 6 pm. If the time cannot be placed inside the range then it will pick am/pm based on which is closest. If there are two possibilities or equal distance then the “daylight/standard awake” hours will be used. The times should be ISO 8601 format, THH:MM |
{ “from” : [], “to” : [] } |
This option is for setting preferred times different for different days of the week. The “from” and “to” keys can be arrays with 7 members representing the time for each day, from Sunday to Saturday. Each value should be in the in Thh:MM format or an empty string to indicate there is no preference. | |
{ “favor” : <keyword> } | The “favor” keyword can be used to set the preference in terms of “future”, “past”, “am”, or “pm”. | |
Example | ||
JSON "preferredTimes": { "from": "T12:00:00", "to": "T18:00:00" } |
Entity Pattern – by default date patterns User Utterance “remind me at 3” |
|
JSON "preferredTimes": { "from": [ "", "T09:00", "T09:00", "T21:00", "T21:00", "T07:00", "" ], "to": [ "", "T18:00", "T18:00", "T06:00", "T06:00", "T16:00", "" ] } |
Entity Pattern – by default date patterns User Utterance “remind me at 3” |
|
JSON "preferredTimes": { "favor": "pm" } |
Entity Pattern – by default date patterns User Utterance “remind me at 3” |
|
timeRangePossible | true/false | If true then the dialog will be looking for time range in the user input. |
Example | ||
JSON { |
Influences how utterances like “10 to 4” is interpreted. By default, this will be “3:50” but if there is the possibility of a range then will be decoded as 2 separate time values “10:00” and “16:00” | |
range | { “from” : now, } or { “to” : now } |
To extract date-times only in the specified range. Either endpoint is optional. Currently, support is extended to the value “now” alone |
Example | ||
JSON { "range": { "from": now } } |
City type entity
ruleName | Value | Description |
---|---|---|
ignoreWords | <concept name> |
For the words in the concept not to be considered as cities. The concept name could be a space-separated list of concepts or an array of concepts or space-separated strings. |
Example | ||
JSON { "ignoreWords": "Send" } |
Entity Pattern – by default capitalized words User Utterance “Send destination to my email” |
Zip Code type entity
ruleName | Value | Description |
---|---|---|
preferredCountries | [<“country1”>,<“country2”>,..] |
To restrict zip code from the given set of preferred countries along with the user location country and the gleaned countries from the input. Need to add two-letter country alpha-2 codes in place of |
Example | ||
JSON { "preferredCountries": [ "GB" ] } |
Entity Pattern – by default zip code patterns User Utterance “check delivery to PO16 7GZ“ |
Location type entity
ruleName | Value | Description |
---|---|---|
preferredCountries | [<“country1”>,<“country2”>,..] |
To restrict location from the given set of preferred countries along with the user location country and the gleaned countries from the input. Need to add two-letter country alpha-2 codes in place of |
Example | ||
JSON { "preferredCountries": [ "GB" ] } |
List of Items (enum) type entity
ruleName | Value | Description |
---|---|---|
ownership | include/ exclude |
To look for potential “ownership” phrasing, e.g. “is mine” to determine if a potential choice should be included or excluded from the entity value. Examples of ownership phrases are “is mine”, “belongs to me”, etc. |
Example | ||
JSON { "ownership": "include" } |
Input Options – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap” User Utterance “first two are mine” |
|
JSON { "ownership": "exclude" } |
Input Options – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap” User Utterance “first two are mine” |
|
includeWords | <concept name> or array of words | The list of words that supplement to the ownership phrases. The value can be an array of strings or a concept.To be used along with ownership: include rule |
Example | ||
JSON { "ownership": "include", "includeWords": "great" } |
Input Options – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap” User Utterance “first two are mine” User Utterance “first two are great” |
|
excludeWords | <concept name> or array of words | The list of words that can be used as non-ownership phrases. The value can be an array of strings or a concept. To be used along with ownership: exclude rule |
Example | ||
JSON { "ownership": "exclude", "excludeWords": "~lovConcept" } |
Input Options – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap” lovConcept – dubiousUser Utterance “first two are dubious” Extracted Value [“bottle”, “book”, “cap”] |
|
noIndexMatch | true | To disable the alphabet and number Index match, would not allow the user to select the items using an index. |
Example | ||
JSON { "noIndexMatch": "true" } |
Input Options – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap” User Utterance a |