{"id":24846,"date":"2020-10-30T12:29:54","date_gmt":"2020-10-30T12:29:54","guid":{"rendered":"https:\/\/developer.kore.ai\/v10-1\/?p=24846"},"modified":"2023-12-20T06:31:32","modified_gmt":"2023-12-20T06:31:32","slug":"entity-rules","status":"publish","type":"post","link":"https:\/\/developer.kore.ai\/v10-1\/docs\/bots\/how-tos\/entity-rules\/","title":{"rendered":"Entity Rules"},"content":{"rendered":"
\r\n\t
\r\n\t\t
\r\n\t\t\t

Validating user input before processing 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<\/strong> can be used for additional processing hints and validations.<\/p>\n

Entity rules can be added from the Entity Rules<\/strong> section under\u00a0Instance Properties<\/strong> of the corresponding entity. Add the rule in the JSON editor provided, see here for how<\/a>.<\/p>\n

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:<\/p>\n

context.entityRules.<entityName> = {\r\n      \"ruleName\": \"value\"\r\n   }<\/pre>\n
Subentity rules can be part of the composite entity rules:<\/p>\n
context.entityRules.<compositeEntityName> = {\r\n    <subentityName> : { \r\n      \"ruleName\": \"value\"\r\n     }\r\n   }<\/pre>\n
Below are the entity rules that can be entered in the JSON editor for the required entity or included as ruleName<\/code> in the above script. We are continuously improving and updating this list. Any feedback or suggestions, kindly post in the community forum<\/a> and our developers will accommodate it, if feasible.<\/p>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
<\/div><\/div>\r\n\t
\r\n\t\t
\r\n\t\t\t
Generic rules<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ruleName<\/strong><\/th>\nValue<\/strong><\/th>\nDescription<\/strong><\/th>\n<\/tr>\n<\/thead>\n
allowConfirmation<\/strong><\/td>\ntrue\/false<\/td>\nThe 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.<\/td>\n<\/tr>\n
Example<\/p>\n
{\r\n\"allowConfirmation\": <true\/false>\r\n}<\/pre>\n<\/td>\n<\/tr>\n
confirmYesSynonyms<\/strong><\/td>\n<concept names><\/td>\nAdditional words\/phrases to be used to confirm an entity value.
\nUsed in conjunction with allowConfirmation rule mentioned above.<\/td>\n<\/tr>\n
Example<\/p>\n
{\r\n\"confirmYesSynonyms\": [\"~concept1\", \"~concept2\"]\r\n}<\/pre>\n
where concept1: ok;
\nconcept2: affirmative<\/td>\n<\/tr>\n
confirmNoSynonyms<\/strong><\/td>\n<concept names><\/td>\nAdditional words\/phrases to be used to cancel a confirmation entity. If selected\/uttered, the entity value will be set to null
\nUsed in conjunction with allowConfirmation\u00a0rule mentioned above.<\/td>\n<\/tr>\n
Example<\/p>\n
{\r\n\"confirmNoSynonyms\": [\"~concept2\", \"~concept3\"]\r\n}<\/pre>\n
where concept1: nope;
\nconcept2: wrong<\/td>\n<\/tr>\n
processLatestSentence<\/strong><\/td>\ntrue\/false<\/td>\nTo restrict checking to the sentences only from the current volley.<\/td>\n<\/tr>\n
Example<\/p>\n
{\r\n \"processLatestSentence\": <true\/false>\r\n}<\/pre>\n<\/td>\n<\/tr>\n
patternsOnly<\/strong><\/td>\ntrue\/false<\/td>\nTo 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.<\/td>\n<\/tr>\n
Example<\/p>\n
{\r\n\"patternsOnly\": <true\/false>\r\n}<\/pre>\n<\/td>\n<\/tr>\n
preConditions<\/strong><\/td>\nuser defined preconditions<\/td>\nTo define preconditions for all entity types to process entity extraction if one of the conditions is true. If the condition is invalid the entity extraction is skipped entirely.<\/p>\n
Use Case Examples:<\/strong><\/p>\n
    \n
  • Example1<\/strong>: A composite entity matches with a set of identification numbers, such as membership ID, provider ID, and RX number. You can set the precondition rule as \"preConditions\" : [\"checkMemberID\"]<\/code>.<\/li>\n
  • Example 2<\/strong>: A VA has two static list of values (LOV) in a composite entity, you can add precondition to customer specific LOV to enable it.<\/li>\n
  • Example 3<\/strong>: If you don\u2019t want to extract entity values for simple utterances, then add preconditions to skip the extraction entirely.<\/li>\n
  • Example 4<\/strong>: Add a precondition for each car make type to simplify the extraction of valid car models based on the car make. The car make can be a custom concept entity with an output tag based on the extracted entity value followed by a composite of individual LoVs for each model. Each list has a pre-condition corresponding to the make.<\/li>\n<\/ul>\n
    The pre-condition can be expressed as a context tag or trait (like an intent\u2019s pre-condition) or when enclosed in parentheses, as a pattern. For example:<\/p>\n
    \"entityRules\" : {\r\n    \"preConditions\" : [\"checkMemberID\"]\r\n}\r\n<\/pre>\n
    This will only extract an entity value when the current context has a checkMemberID context tag set or a trait with that name has been found.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{ \r\n\"preConditions\": \r\n[ \u201cisCustomerX\u201d ]\r\n}\r\n<\/pre>\n<\/td>\n
Entity type<\/strong>: LoV Entity with Premium as one of the choices. But the list is only appropriate for Customer X.<\/p>\n
A previous script node has set the \u201cisCustomerX\u201d context tag.<\/p>\n
User Utterance<\/strong> “check my premium account<\/em>”
\nExtracted Value<\/strong> \u201cPremium\u201d<\/p>\n
A previous script node has not set the \u201cisCustomerX\u201d context tag.<\/p>\n
User Utterance<\/strong> “check my premium account<\/em>”
\nExtracted Value<\/strong> \u201cnone\u201d<\/td>\n<\/tr>\n
JSON<\/p>\n
{ \r\n\"preConditions\u201d : \r\n[ \u201c( buy )\u201d ]\r\n}\r\n<\/pre>\n<\/td>\n
Entity type<\/strong>: Number Entity<\/p>\n
User Utterance<\/strong> “buy 10 apples<\/em>”
\nExtracted Value<\/strong> \u201c10\u201d<\/p>\n
User Utterance<\/strong> “search for 10 apples<\/em>”
\nExtracted Value<\/strong> \u201cnone\u201d<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
<\/div><\/div>\r\n\t
\r\n\t\t
\r\n\t\t\t
String type entity<\/span><\/h3>\n
Description entity type<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
discardAsCommand<\/strong><\/td>\nConcept Name:<\/strong> ~bot_commands_override_discard<\/p>\n
Synonyms:<\/strong> abort, abort_all, cancel, clear_screen, discard, discard all, exit, exit_all, quit, quit_all, restart, start_over, startover, stop, stop_all<\/td>\n
If the rule is set to true, then the discard commands entered at a string entity node are not considered as valid string inputs, and the task gets discarded.<\/td>\n<\/tr>\n
stripLeading<\/strong><\/td>\n<concept name><\/td>\nTo remove the words given in the concept from the start of the extracted string.<\/p>\n
The concept can be a single concept name or a space-separated list of concepts or an array of concept names.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{ \"stripLeading\": [ \r\n      \"~stringConcept\" \r\n    ]\r\n}<\/pre>\n<\/td>\n
stringConcept:\u00a0<\/strong> city<\/p>\n
Entity Pattern:<\/strong> I like *<\/p>\n
User Utterance<\/strong> “I like city New York<\/em>”
\nExtracted Value<\/strong> New York<\/td>\n<\/tr>\n
stripTrailing<\/strong><\/td>\n<concept name><\/td>\nTo remove words in a concept from the end of the extracted string.<\/p>\n
The value can be a single concept name or a space-separated list of concepts or an array of concept names.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{ \"stripTrailing\":\r\n    \"~stringConcept ~stringConcept1\"\r\n }<\/pre>\n<\/td>\n
stringConcept:\u00a0<\/strong> city; stringConcept1:\u00a0<\/strong> airport<\/p>\n
Entity Pattern:<\/strong> I like *<\/p>\n
User Utterance<\/strong> “I like New York city<\/em>” or “I like New York airport<\/em>”
\nExtracted Value<\/strong> New York<\/td>\n<\/tr>\n
avoidSingleWord<\/strong><\/td>\n<concept name><\/td>\nTo ignore any value that is a member of the concept, unless it is the entire input.<\/p>\n
The value can be a single concept name or a space-separated list of concepts or an array of concept names.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n  \"avoidSingleWord\": \r\n      \"~stringConcept\"\r\n}<\/pre>\n<\/td>\n
stringConcept:\u00a0<\/strong> chess, cricket<\/p>\n
Entity Pattern:<\/strong> like to watch * tournament<\/p>\n
User Utterance<\/strong> “I like to watch chess tournament<\/em>”
\nExtracted Value<\/strong> prompt for entity value<\/p>\n
User Utterance <\/strong>“I like to watch golf tournament<\/em>”
\nExtracted Value<\/strong> golf<\/p>\n
User Utterance<\/strong> “cricket<\/em>”
\nExtracted Value<\/strong> cricket, since it is the entire input<\/td>\n<\/tr>\n
avoidSingleVerb<\/strong><\/td>\ntrue<\/td>\nIf set to true, then any value that is just a verb is ignored, unless it is the entire input.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n\"avoidSingleVerb\": true\r\n}<\/pre>\n<\/td>\n
Entity Pattern:<\/strong> I like * music<\/p>\n
User Utterance<\/strong> “I like playing music<\/em>”
\nExtracted Value<\/strong> prompt for entity value<\/p>\n
User Utterance<\/strong> “I like rap music<\/em>”
\nExtracted Value<\/strong> rap<\/p>\n
User Utterance<\/strong> “play<\/em>”
\nExtracted Value<\/strong> play, since it is the entire input<\/td>\n<\/tr>\n
extractOnlyNumbers<\/strong><\/td>\ntrue<\/td>\nif true, the entity will extract only numbers present in the string and set it as the entity value<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n\"extractOnlyNumbers\": true\r\n}<\/pre>\n<\/td>\n
<\/td>\n<\/tr>\n
letters<\/strong><\/td>\nnumber
\nOr
\nrange<\/td>\n		To extract a word of a specific length, or a sequence of individual characters that meet the length criteria.
\nThe rule value is either:<\/p>\n
    \n
  • A single number, letters=3<\/code>, where the word(s) matched is composed of that many alphabetic (a-z) letters.<\/li>\n
  • A range, letters=5-8<\/code>, indicates that 5, 6, 7, and 8 letters are valid.<\/li>\n<\/ul>\n
    Words or sequences of letters having only alphabets are matched. The words containing punctuation or numbers are not considered. Also, the return value is converted to all caps.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{ \r\n\"letters\": 2 \r\n}\r\n<\/pre>\n<\/td>\n
Entity Pattern<\/strong> – \u201cletters = 2″<\/em><\/p>\n
User Utterance<\/strong> 234 XY
\nExtracted Value<\/strong> “XY<\/em><\/p>\n
User Utterance<\/strong> 234 x y
\nExtracted Value<\/strong> “XY<\/em><\/p>\n
User Utterance<\/strong> 234 alpha bravo
\nExtracted Value<\/strong> “AB<\/em>
\nThis value is extracted as part of a phonetic alphabet.
\nUser Utterance<\/strong> 234 X Y Z
\nExtracted Value<\/strong> “Nothing<\/em>
\nNo alphabet matches with letters value defined.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{ \r\n\"letters\": 5-8 \r\n}\r\n<\/pre>\n<\/td>\n
Entity Pattern<\/strong> – \u201cletters = 5-8″<\/em><\/p>\n
User Utterance<\/strong> Kore.ai is the best platform in artificial intelligence of recent times.
\nExtracted Value<\/strong> “platform, recent, times<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
<\/div><\/div>\r\n\t
\r\n\t\t
\r\n\t\t\t
Number <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n
ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
asString<\/strong><\/td>\ntrue<\/td>\nTo capture a number as a string, preserving leading zeros<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n  \"asString\": true\r\n}<\/pre>\n<\/td>\n
Entity Pattern<\/strong> – by default numeric entries<\/p>\n
User Utterance<\/strong> “OTP is 009944<\/em>”
\nExtracted Value<\/strong> “009944″<\/em>
\nwithout the rule, it would have been “9944”<\/em><\/td>\n<\/tr>\n<\/tbody>\n
digits<\/strong><\/td>\nsingle number
\nOr
\na range of values<\/td>\n		To enforce a number of digits to match in a Number entity. This rule will not ignore leading zeros. The word(s) matched are composed of that many digits after NL processing. When a range is provided for the rule, it passes only if the utterance value matches within that valid range<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n  \"digits\": \"3\"\r\n}<\/pre>\n<\/td>\n
Entity Pattern<\/strong> – Numeric or string entries<\/p>\n
User Utterance<\/strong> “CVV is 034<\/em>”
\nExtracted Value<\/strong> “034″<\/em>
\nThe value is a match as the digits = 3. If the value of the digits is 2, then it would be a no match in this example.<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n  \"digits\": \"13-17\"\r\n}<\/pre>\n<\/td>\n
Entity Pattern<\/strong> – Numeric or string entries<\/p>\n
User Utterance<\/strong> \u201cMy credit card number is 4012 8888 8888 1881″
\nExtracted Value<\/strong> “4012 8888 8888 1881″<\/em>
\nIt is a match as the number of digits in the credit card number is 16, and within the range.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n
Note:<\/strong> The presence of the digits rule is an implicit asString=true<\/code> and integerOnly=true<\/code>, which means the entity value is always returned as a string even if the number is short and does not have a leading zero. Floating point\/decimal numbers and ordinals (For example, \u201cfirst\u201d, \u201ctwenty-third\u201d) are not matched.<\/p>\n
The rule does not split a word or number. For example, if the utterance is \u201ctwo thousand and twenty three\u201d and the rule is \"digits\": 3<\/code>, then it is a no match. The utterance “twenty twenty three” would also be a no match. The rule should be \"digits\": 4<\/code> for all the inputs to match.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
<\/div><\/div>\r\n\t
\r\n\t\t
\r\n\t\t\t
Currency\u00a0<\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
defaultCode<\/strong><\/td>\n<currency code>
\nor
\n<country code><\/td>\n		If no code is mentioned in user input, this value will be picked as code.
\nThe value needs to be a 3 letter currency code or two-letter country alpha-2 codes.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n  \"defaultCode\": \"NZD\"\r\n}<\/pre>\n<\/td>\n
Entity Pattern\u00a0<\/strong>pay *<\/p>\n
User Utterance <\/strong>“Pay 30<\/em>”
\nExtracted Value<\/strong> “NZD30<\/em>”<\/p>\n
User Utterance <\/strong>“Pay USD30<\/em>”
\nExtracted Value<\/strong> “USD30<\/em>“<\/td>\n<\/tr>\n
maxDigits<\/strong><\/td>\n<number><\/td>\nTo restrict the amount length. If the amount length exceeds the value it will be discarded.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{   \r\n    \"maxDigits\": 3 \r\n}<\/pre>\n<\/td>\n
Entity Pattern\u00a0<\/strong>pay *<\/p>\n
User Utterance <\/strong>“Pay USD30<\/em>”
\nExtracted Value<\/strong> “USD30<\/em>”<\/p>\n
User Utterance <\/strong>“Pay USD3000<\/em>”
\nExtracted Value<\/strong> prompt for value<\/td>\n<\/tr>\n
currencyCodes<\/strong><\/td>\n[<currency code>,<currency code>]
\nor
\n[<country code>,<country code>]<\/td>\n		To restrict the currency codes. If the user entered code is not in the given list then the value will be discarded.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n  \"currencyCodes\": [\r\n    \"USD\",\r\n    \"INR\",\r\n    \"NZD\"\r\n  ]\r\n}<\/pre>\n<\/td>\n
Entity Pattern\u00a0<\/strong>pay *<\/p>\n
User Utterance <\/strong>“Pay USD30<\/em>”
\nExtracted Value<\/strong> “USD30<\/em>”<\/p>\n
User Utterance <\/strong>“Pay AUD30<\/em>”
\nExtracted Value<\/strong> prompt for a value<\/td>\n<\/tr>\n
ignoreOnlyCode<\/strong><\/td>\n<true\/false><\/td>\nIf the value is true, the currency entity requires both the currency code\/symbol AND the amount. Otherwise, the entered value is unaccepted, resulting in an error message displayed to the user.<\/p>\n
If the value is false, the currency entity accepts the currency code or symbol even without the amount.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n  \"ignoreOnlyCode\": true  \r\n}<\/pre>\n<\/td>\n
In a scenario where the rule is set to true:<\/p>\n
Entity Pattern\u00a0<\/strong>pay *<\/p>\n
User Utterance <\/strong>“Pay USD30<\/em>”
\nExtracted Value<\/strong> “USD30<\/em>”<\/p>\n
User Utterance <\/strong>“Pay AUD<\/em>”
\nVA Response<\/strong>: I apologize, I did not recognize the currency you entered. Please enter the currency you would like to use. An example of currency is $ 100.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
<\/div><\/div>\r\n\t
\r\n\t\t
\r\n\t\t\t
Model Number for Composite entity type<\/span><\/span><\/h3>\n\n\n\n\n\n\n\n\n
ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
modelNumber<\/strong><\/td>\n<true>
\nor
\n<a character><\/td>\n		To capture a model number that is composed of letters and numbers such as membership number, social security number, country of origin code, and other ticket numbers.
\nThe rule is especially useful to capture structured data on a voice channel where a custom regex pattern is not flexible or is too cumbersome to account for every variation.
\nFor example:<\/p>\n
    \n
  • \u201cMy id is six twenty seven dash forty four eighty nine<\/li>\n
  • \u201cMy seat is 20 3 sea\u201d<\/li>\n
  • \u201cThe account number is alpha bravo slash six two one oh seven\u201d<\/li>\n
  • \u201cI was in row 35 seat d\u201d<\/li>\n<\/ul>\n
    Each part of the structured data is a subentity, and the composite entity patterns define the order of those elements. The modelNumber rule means that the value stored in context.entities will be a concatenated string of the matched subentities instead of a JSON object.<\/td>\n<\/tr>\n
Example<\/td>\n<\/tr>\n
JSON<\/p>\n
{\r\n  \"modelNumber\": true\r\n}\r\n<\/pre>\n<\/td>\n
Entity Pattern\u00a0<\/strong>\u2013 @AccountNumbers @AccountSuffix
\n@AccountNumbers is a Number entity with \u201cdigits\u201d:8 entity rule.
\n@AccountSuffix is a String entity with \u201cletters\u201d:2 entity ruleUser Utterance <\/strong>“\u201cAccount Number is 3 3 1 3 4 2 1 2 X Y”<\/em>
\nExtracted Value<\/strong> “\u201c33 13 42 12 X Y\u201d<\/em>User Utterance <\/strong>“\u201cAccount Number is 33134212 – XY”<\/em>”
\nExtracted Value<\/strong> “\u201c33134212XY\u201d<\/em>“User Utterance <\/strong>“\u201cAccount Number is 33 13 42 12 alpha bravo”
\nExtracted Value<\/strong> “ \u201c33134212AB\u201d<\/em>“<\/em>User Utterance <\/strong>“\u201cAccount Number is thirty three thirteen forty two twelve a like apple b as in boy”
\nExtracted Value<\/strong> “ \u201c33134212AB\u201d<\/em>”
\nComposite Patterns<\/strong> \u2013 {row} @RowNumber {seat} @Seat<\/em>@RowNumber is a Number entity with \u201cdigits\u201d:2 and \u201crange\u201d: (\u201cfrom\u201d:1,\u201dto\u201d,35} entity rules.<\/p>\n
@Seat is a Custom concept entity using a concept ~seatletters ( A B C D E F )<\/p>\n
User Utterance <\/strong>“\u201cI am sitting in 33 A”
\nExtracted Value<\/strong> “ \u201c33A\u201d<\/em>“<\/em><\/p>\n
User Utterance <\/strong>“\u201c\u201cI am in row thirty three seat sea”
\nExtracted Value<\/strong> “ \u201c33C\u201d<\/em>“<\/em><\/td>\n<\/tr>\n
composite number<\/strong><\/td>\n<single number> or <a range of values><\/td>\nTo extract a composite number using the Letters and Number entities. This rule will extract a number composed of subgroups with a specific number of digits and number of letters. For example:<\/p>\n
    \n
  • A provider ID could be 8 digits and 1 or 2 letters<\/li>\n
  • An SSN is 3 digits then 2 digits then 4 digits<\/li>\n
  • A Jira ticket is a project id plus a number.<\/li>\n
  • An airline seat is 1 or 2 digits and 1 letter (though not all 2 digits or all letters).<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n
    Note:<\/strong> Note: A modelNumber<\/code> composite entity is a voice-compatible replacement for a Custom regex entity.
    \nA regex is a strict character-matching expression, the input must be an exact match that generally works on text-based channels though those expressions can become complicated when optional elements like punctuation are involved – users don\u2019t necessarily know if they have to provide them or not.
    \nOn voice channels, an ASR can (mis)transcribe speech, for example \u201cC\u201d becomes \u201csea\u201d or \u201csee\u201d. A user could pause so \u201c23\u201d becomes \u201c20 3\u201d. The Number and String entity types, along with the digits and letters entity rules, can handle all of these variations.
    \nThe example above of ( @AccountNumbers @AccountSuffix ) can replace a regex like \\d{8}\\-?[a-zA-Z]{2}<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    PersonName\u00a0<\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    disablePatterns<\/strong><\/td>\nAn array of person name patterns to ignore – currently supporting only “possessive<\/em>“<\/td>\nTo disable patterns in extracting a person\u2019s name when not applicable in specific scenarios.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"disablePatterns\": [\r\n    \"possessive\"\r\n  ]\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default capitalized words<\/p>\n
    User Utterance <\/strong>“schedule Bob’s review at 9 am”
    \nExtracted Value<\/strong> “Bob<\/em>“<\/td>\n<\/tr>\n
    ignoreWords<\/strong><\/td>\n<concept name><\/td>\nWords in the concept are not to be considered as names even when capitalized.<\/p>\n
    The concept name could be a space-separated list of concepts or an array of concepts.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"ignoreWords\": [\r\n    \"review\",\r\n    \"~prepositionList\"\r\n  ]\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern<\/strong> – by definition capitalized words<\/p>\n
    User Utterance <\/strong>“meeting for Bob Review”
    \nExtracted Value<\/strong> “Bob<\/em>”
    \nwould have been “Bob Review” without the rule<\/td>\n<\/tr>\n
    negativePatterns<\/strong><\/td>\narray of patterns<\/td>\nPerson 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.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"negativePatterns\": [\r\n    \"about *\"\r\n  ]\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern<\/strong> – by definition capitalized words<\/p>\n
    User Utterance <\/strong>“schedule a meeting about Philip with Fred”
    \nExtracted Value<\/strong> “Fred<\/em>”
    \nwould have been “Philip” without the rule<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    Company <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    ignoreWords<\/strong><\/td>\n<concept name><\/td>\nWords in the concept are not to be considered as companies even when capitalized.<\/p>\n
    The concept name could be a space-separated list of concepts or an array of concepts.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"ignoreWords\": [\r\n    \"atm\"\r\n  ]\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern<\/strong> – by definition capitalized words<\/p>\n
    User Utterance <\/strong>“find ATM”
    \nExtracted Value<\/strong> none
    \nwould have been “ATM” (an Italian company) without the rule<\/td>\n<\/tr>\n
    negativePatterns<\/strong><\/td>\nAn array of company name patterns to ignore<\/td>\nTo disable patterns in extracting a company name when not applicable in specific scenarios.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    Date\u00a0<\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    range<\/strong><\/td>\n{ \u201cfrom\u201d : <from-date>, \u201cto\u201d : <to-date> }<\/td>\nTo extract dates only in the specified range. Either endpoint is optional.<\/p>\n
    Values can be a date, YYYY-MM-DD, or a keyword: today, tomorrow, yesterday. The dates are inclusive.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n\"range\": {\r\n   \"from\": \"2020-01-01\",\r\n   \"to\": \"today\"\r\n  }\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“show schedule for 2019-02-03”
    \nExtracted Value<\/strong> prompt for a value<\/p>\n
    User Utterance <\/strong>“show schedule for tomorrow”
    \nExtracted Value<\/strong> prompt for a value<\/p>\n
    User Utterance <\/strong>“show schedule\u00a0 for 2020-02-03”
    \nExtracted Value<\/strong> “2020-02-03”<\/td>\n<\/tr>\n
    referenceDate<\/strong><\/td>\n<date><\/td>\nSets the reference date to <date> and any date calculation to set the current date entity value is based on that date.<\/p>\n
    Values should be a date, YYYY-MM-DD, or a keyword: today, tomorrow, yesterday.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"referenceDate\": \"2020-07-09\"\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“schedule after two days”
    \nExtracted Value<\/strong> “2020-07-11”
    \nwould have been two days from the current date without the reference date<\/td>\n<\/tr>\n
    preferredDateFormat<\/strong><\/td>\n“yyyy-mm-dd”<\/td>\nIn case of ambiguity in date, it uses the preferred date format to resolve ambiguity.
    \nValues can be:<\/p>\n
      \n
    • “yyyy-mm-dd”<\/li>\n
    • “yyyy-dd-mm”<\/li>\n
    • “dd-mm-yyyy”<\/li>\n
    • “mm-dd-yyyy”<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"preferredDateFormat\": \"mm-dd-yyyy\"\r\n}<\/pre>\n<\/td>\n
    		User Utterance <\/strong>“03-04-2021”
    \nExtracted Value<\/strong> “2021-03-04”
    \nNOTE: This rule only applies when there is an ambiguity in the user utterance. If the user\u2019s preference is already set as part of a previous conversation, then the user selected format would take precedence over the defined rule
    \nFor 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”<\/td>\n<\/tr>\n
    returnOnlyMonthYear<\/strong><\/td>\n<true\/false><\/td>\nWhen 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<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"returnOnlyMonthYear\": true\r\n}<\/pre>\n<\/td>\n
    		User Utterance <\/strong>“03-04-2021”
    \nExtracted Value<\/strong> “04-2021”User Utterance <\/strong>“Apr 2021”
    \nExtracted Value<\/strong> “04-2021”<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    Date Period <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    range<\/strong><\/td>\n{ \u201cfrom\u201d : <from-date>, \u201cto\u201d : <to-date> }<\/td>\nTo extract dates in the specified range. Either endpoint is optional.<\/p>\n
    Values can be a date, YYYY-MM-DD, or a keyword: today, tomorrow, yesterday. The dates are inclusive.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n\"range\": {\r\n   \"from\": \"2020-01-01\",\r\n   \"to\": \"today\"\r\n  }\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“show schedule for 2019-02-03”
    \nExtracted Value<\/strong> prompt for a value<\/p>\n
    User Utterance <\/strong>“show schedule for tomorrow”
    \nExtracted Value<\/strong> prompt for a value<\/p>\n
    User Utterance <\/strong>“show schedule\u00a0 for 2020-02-03”
    \nExtracted Value<\/strong> “2020-02-03”<\/td>\n<\/tr>\n
    range<\/strong> with strict<\/strong><\/td>\n{ \u201cfrom\u201d : <from-date>, \u201cto\u201d : <to-date>,
    \n\u201cstrict\u201d: <true\/false> }<\/td>\n    		If the value is true<\/em>, the Date Period entity accepts values that are strictly in the defined date range.
    \nIf the value is false<\/em>, the Date Period entity accepts values that are in the range or overlapping with the range.<\/td>\n    		Examples<\/td>\nJSON<\/p>\n
    {\r\n\"range\": {\r\n   \"from\": \"2022-01-01\",\r\n   \"to\": \"2023-03-05\",\r\n   \"strict\" = \"true\"\r\n  }\r\n}<\/pre>\n<\/td>\n
    		User Utterance<\/strong>: “2022-05-05 – 2022-06-05”
    \nExpected Value<\/strong>: “Selected date range”
    \n(The user utterance is within the defined date range. As strict is true, any value strictly in the defined date range is a valid input and is accepted.)User Utterance<\/strong>: “2021-05-05 – 2022-05-05”
    \nExtracted Value<\/strong>: “I\u2019m sorry, I am unable to recognize the string. Please enter again.”
    \n(The user utterance is not strictly in the defined date range, it\u2019s overlapping. As strict is true, any overlapping input is an invalid input and is rejected with an error.)<\/td>\n    		JSON<\/p>\n
    {\r\n\"range\": {\r\n   \"from\": \"2022-01-01\",\r\n   \"to\": \"2023-03-05\",\r\n   \"strict\" = \"false\"\r\n  }\r\n}<\/pre>\n<\/td>\n
    		User Utterance<\/strong>: “2021-05-05 – 2022-05-05”
    \nExpected Value<\/strong>: “Selected date range”
    \n(The user utterance is overlapping with the defined date range. As strict is false, any overlapping input is a valid input and is accepted.)<\/td>\n    		referenceDate<\/strong><\/td>\n<date><\/td>\nSets the reference date to <date> and any date calculation to set the current date entity value is based on that date.<\/p>\n
    Values should be a date, YYYY-MM-DD, or a keyword: today, tomorrow, yesterday.<\/td>\n
    		Example<\/td>\nJSON<\/p>\n
    {\r\n  \"referenceDate\": \"2020-07-09\"\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“schedule after two days”
    \nExtracted Value<\/strong> “2020-07-11”<\/td>\n
    		tense<\/strong><\/td>\npast\/future<\/td>\nTo adjust the date period based on the tense when the year is not present in the user utterance.<\/p>\n
    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.<\/td>\n
    		Example<\/td>\nJSON<\/p>\n
    {\r\n \"tense\": \"past\"\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“get the statement for Jan”
    \nExtracted Value<\/strong> “2020-01-01” if the current date is “2020-15-12”
    \nwithout the rule, it would have been “2021-01-01”<\/p>\n
    \u00a0<\/strong><\/td>\n
    		preferredDateFormat<\/strong><\/td>\n“yyyy-mm-dd”<\/td>\nIn case of ambiguity in date, it uses the preferred date format to resolve ambiguity.
    \nValues can be:<\/p>\n
      \n
    • “yyyy-mm-dd”<\/li>\n
    • “yyyy-dd-mm”<\/li>\n
    • “ddmmyyyy”<\/li>\n
    • “mmddyyyy”<\/li>\n<\/ul>\n<\/td>\n
    		Example<\/td>\nJSON<\/p>\n
    {\r\n  \"preferredDateFormat\": \"mm-dd-yyyy\"\r\n}<\/pre>\n<\/td>\n
    		User Utterance <\/strong>“03-04-2021”
    \nExtracted Value<\/strong> “2021-03-04”
    \nNOTE: This rule only applies when there is an ambiguity in the user utterance. If the user\u2019s preference is already set as part of a previous conversation, then the user selected format would take precedence over the defined rule
    \nFor 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”<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    DateTime <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    range<\/strong><\/td>\n{ \u201cfrom\u201d : <from-datetime>, \u201cto\u201d : <to-datetime> }<\/td>\nTo extract date-times only in the specified range. Either endpoint is optional.<\/p>\n
    Values can be a date, YYYY-MM-DD, or a DateTime, YYYY-MM-DDTHH:MM:SS (user\u2019s timezone is assumed if none specified) or a keyword: today, tomorrow, yesterday, now. The dates are inclusive.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"range\": {\r\n    \"from\": \"2020-01-01T00:00:00+05:30\",\r\n    \"to\": \"2020-10-01T00:00:00+05:30\"\r\n  }\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date time patterns<\/p>\n
    User Utterance <\/strong>“set alarm for 2019-02-03T10:00:00”
    \nExtracted Value<\/strong> prompt for a value<\/p>\n
    User Utterance <\/strong>“show schedule for 2021-12-20T10:00:00”
    \nExtracted Value<\/strong> prompt for a value<\/p>\n
    User Utterance <\/strong>“show schedule\u00a0 for 2020-02-03 T10:00:00”
    \nExtracted Value<\/strong> “2020-02-03T10:00:00”<\/td>\n<\/tr>\n
    preferredTimes<\/strong><\/td>\n{ \u201cfrom\u201d : <from-time>,
    \n\u201cto\u201d : <to-time> }<\/td>\n    		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.<\/p>\n
    For example, \u201c3\u201d will become \u201c3 pm\u201d if the preferredTimes are 9 am to 6 pm.<\/p>\n
    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 \u201cdaylight\/standard awake\u201d hours will be used. The times should be ISO 8601 format, THH:MM<\/td>\n<\/tr>\n
    { \u201cfrom\u201d : [],
    \n\u201cto\u201d : [] }<\/td>\n    		This option is for setting preferred times different for different days of the week. The \u201cfrom\u201d and \u201cto\u201d 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.<\/td>\n<\/tr>\n
    { \u201cfavor\u201d : <keyword> }<\/td>\nThe \u201cfavor\u201d keyword can be used to set the preference in terms of \u201cfuture\u201d, \u201cpast\u201d, \u201cam\u201d, or \u201cpm\u201d.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
     \"preferredTimes\": {\r\n    \"from\": \"T12:00:00\",\r\n    \"to\": \"T18:00:00\"\r\n  }<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“remind me at 3”
    \nExtracted Value<\/strong> “T15:00:00”<\/td>\n<\/tr>\n
    JSON<\/p>\n
     \"preferredTimes\": {\r\n    \"from\": [\r\n      \"\", \"T09:00\", \r\n      \"T09:00\", \"T21:00\", \r\n      \"T21:00\", \"T07:00\", \"\"\r\n    ],\r\n    \"to\": [\r\n      \"\", \"T18:00\",\r\n      \"T18:00\", \"T06:00\", \r\n      \"T06:00\", \"T16:00\", \"\"\r\n    ]\r\n  }<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“remind me at 3”
    \nExtracted Value<\/strong> “T15:00:00”, if the current day is Monday\/Tuesday\/Friday;
    \n“T03:00:00”, if the current day is Wednesday\/Thursday<\/td>\n<\/tr>\n
    JSON<\/p>\n
     \"preferredTimes\": {\r\n    \"favor\": \"pm\"\r\n  }<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“remind me at 3”
    \nExtracted Value<\/strong> “T15:00:00”<\/td>\n<\/tr>\n
    timeRangePossible<\/strong><\/td>\ntrue\/false<\/td>\nIf true then the dialog will be looking for time range in the user input.<\/p>\n
    Influences how \u201c10 to 4\u201d is interpreted. By default, this will be \u201c3:50\u201d but if there is the possibility of a range then will be decoded as 2 times \u201c10:00\u201d and \u201c16:00\u201d<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n\"timeRangePossible\": \"true\"\r\n}<\/pre>\n<\/td>\n
    		 <\/p>\n
    \u00a0<\/strong><\/td>\n<\/tr>\n
    preferredDateFormat<\/strong><\/td>\n“yyyy-mm-dd”<\/td>\nIn case of ambiguity in date, it uses the preferred date format to resolve ambiguity.
    \nValues can be:<\/p>\n
      \n
    • “yyyy-mm-dd”<\/li>\n
    • “yyyy-dd-mm”<\/li>\n
    • “ddmmyyyy”<\/li>\n
    • “mmddyyyy”<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"preferredDateFormat\": \"mm-dd-yyyy\"\r\n}<\/pre>\n<\/td>\n
    		User Utterance <\/strong>“03-04-2021”
    \nExtracted Value<\/strong> “2021-03-04”
    \nNOTE: This rule only applies when there is an ambiguity in the user utterance. If the user\u2019s preference is already set as part of a previous conversation, then the user selected format would take precedence over the defined rule
    \nFor 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”<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    Time <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    preferredTimes<\/strong><\/td>\n{ \u201cfrom\u201d : <from-time>,
    \n\u201cto\u201d : <to-time> }<\/td>\n    		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.<\/p>\n
    For example, \u201c3\u201d will become \u201c3 pm\u201d if the preferredTimes are 9 am to 6 pm.<\/p>\n
    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 \u201cdaylight\/standard awake\u201d hours will be used. The times should be ISO 8601 format, THH:MM<\/td>\n<\/tr>\n
    { \u201cfrom\u201d : [],
    \n\u201cto\u201d : [] }<\/td>\n    		This option is for setting preferred times different for different days of the week. The \u201cfrom\u201d and \u201cto\u201d 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.<\/td>\n<\/tr>\n
    { \u201cfavor\u201d : <keyword> }<\/td>\nThe \u201cfavor\u201d keyword can be used to set the preference in terms of \u201cfuture\u201d, \u201cpast\u201d, \u201cam\u201d, or \u201cpm\u201d.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
     \"preferredTimes\": {\r\n    \"from\": \"T12:00:00\",\r\n    \"to\": \"T18:00:00\"\r\n  }<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“remind me at 3”
    \nExtracted Value<\/strong> “T15:00:00”<\/td>\n<\/tr>\n
    JSON<\/p>\n
     \"preferredTimes\": {\r\n    \"from\": [\r\n      \"\", \"T09:00\", \r\n      \"T09:00\", \"T21:00\", \r\n      \"T21:00\", \"T07:00\", \"\"\r\n    ],\r\n    \"to\": [\r\n      \"\", \"T18:00\",\r\n      \"T18:00\", \"T06:00\", \r\n      \"T06:00\", \"T16:00\", \"\"\r\n    ]\r\n  }<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“remind me at 3”
    \nExtracted Value<\/strong> “T15:00:00”, if the current day is Monday\/Tuesday\/Friday;
    \n“T03:00:00”, if the current day is Wednesday\/Thursday<\/td>\n<\/tr>\n
    JSON<\/p>\n
     \"preferredTimes\": {\r\n    \"favor\": \"pm\"\r\n  }<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default date patterns<\/p>\n
    User Utterance <\/strong>“remind me at 3”
    \nExtracted Value<\/strong> “T15:00:00”<\/td>\n<\/tr>\n
    timeRangePossible<\/strong><\/td>\ntrue\/false<\/td>\nIf true then the dialog will be looking for time range in the user input.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {
    \n“timeRangePossible”: “true”
    \n}<\/td>\n
    		Influences how utterances like \u201c10 to 4\u201d is interpreted. By default, this will be \u201c3:50\u201d but if there is the possibility of a range then will be decoded as 2 separate time values \u201c10:00\u201d and \u201c16:00\u201d<\/td>\n<\/tr>\n
    range<\/strong><\/td>\n{ \u201cfrom\u201d : “now”,
    \n}
    \nor
    \n{ \u201cto\u201d : “now”
    \n}<\/td>\n    		To extract date-times only in the specified range. Either endpoint is optional.<\/p>\n
    Currently, support is extended to the value “now” alone<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"range\": {\r\n    \"from\": \"now\"\r\n  }\r\n}<\/pre>\n<\/td>\n
    		<\/td>\n<\/tr>\n
    timeOnly<\/b><\/td>\ntrue\/false<\/span><\/td>\nRule to include or exclude the character \u201cT\u201d and the offset value in the time.<\/span><\/p>\n
    Possible values are:<\/span><\/p>\n
      \n
    • True <\/b>– Obtains only the time and excludes the character \u201cT\u201d and the offset value.<\/span><\/li>\n
    • False <\/b>– Obtains the time along with character T and the offset value.<\/span><\/li>\n<\/ul>\n
      Note<\/b>: The timeOnly rule supports multilang excluding English, German, French and Spanish.<\/span><\/p>\n
      For example:<\/span><\/p>\n
        \n
      • User Input: 6 pm<\/span><\/li>\n
      • Result (with “timeOnly” rule): 18:00:00<\/b><\/li>\n
      • Result (without “timeOnly” rule): T18:00:00+5:50<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {<\/span>\r\n\u201ctimeOnly\u201d: \u201ctrue\u201d<\/span>\r\n}<\/span><\/pre>\n<\/td>\n
    		<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    City\u00a0<\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    ignoreWords<\/strong><\/td>\n<concept name><\/td>\nFor the words in the concept not to be considered as cities.<\/p>\n
    The concept name could be a space-separated list of concepts or an array of concepts or space-separated strings.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"ignoreWords\": \"Send\"\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default capitalized words<\/p>\n
    User Utterance <\/strong>“Send destination to my email”
    \nExtracted Value<\/strong> prompt for entity value, without the rule it would have been “Send” since it is a city name<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    Zip Code <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    preferredCountries<\/strong><\/td>\n[<\u201ccountry1\u201d>,<\u201ccountry2\u201d>,..]<\/td>\nTo restrict zip code from the given set of preferred countries along with the user location country and the gleaned countries from the input.<\/p>\n
    Need to add two-letter country alpha-2 codes in place of
    \n<\u201ccountry1\u201d>,<\u201ccountry2\u201d>,…<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"preferredCountries\": [\r\n    \"GB\"\r\n  ]\r\n}<\/pre>\n<\/td>\n
    		Entity Pattern <\/strong>– by default zip code patterns<\/p>\n
    User Utterance <\/strong>“check delivery to PO16 7GZ<\/em>”
    \nExtracted Value<\/strong> “PO16 7GZ<\/em>“, without the rule this might have been ignored if the user is not in the UK region<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    Location <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    preferredCountries<\/strong><\/td>\n[<\u201ccountry1\u201d>,<\u201ccountry2\u201d>,..]<\/td>\nTo restrict location from the given set of preferred countries along with the user location country and the gleaned countries from the input.<\/p>\n
    Need to add two-letter country alpha-2 codes in place of
    \n<\u201ccountry1\u201d>,<\u201ccountry2\u201d>,…<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"preferredCountries\": [\r\n    \"GB\"\r\n  ]\r\n}<\/pre>\n<\/td>\n
    		<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div>\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    List of Values (LoV) <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    ignoreLemmaWords<\/strong><\/td>\ntrue\/
    \nfalse<\/td>\n    		If ignoreLemmaWords<\/code> is true, lemmatization is not performed on the given user input in the LoV lookup entity to predict the output. If it is set to false, lemmatization is performed.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n\"ignoreLemmaWords\": false\r\n}\r\n\r\n{\r\n\"ignoreLemmaWords\": true\r\n}\r\n<\/pre>\n<\/td>\n
    		Input Options<\/strong> – \u201cticket\u201d, \u201ctickets\u201d.”<\/p>\n
    User Utterance<\/strong> \u201cI need a ticket,\u201d \u201cI need tickets.\u201d<\/p>\n
    Extracted Value<\/strong> When ignoreLemmaWords<\/strong><\/code> is set to false, the LoV entity extracts \u201cticket\u201d for both the inputs – \u201cticket\u201d and \u201ctickets\u201d.
    \nWhen it is set to true, the entity extracts \u201cticket\u201d only when the input contains \u201cticket\u201d. For a different input like \u201ctickets\u201d, the bot responds that it is not a valid option.<\/td>\n<\/tr>\n
    ignoreWords<\/strong><\/td>\n<\/td>\nThe rule for the list of values (LOV) entity type to extend support to ignore words defined in the stop words or ignore words list.
    \nThis rule helps to ignore words that are not part of every choice and if a particular word is either causing a specific match or an ambiguity. It assesses the common synonyms (common meaning present in more than one choice) and boost partial match score for same choice.
    \nSyntax<\/strong>
    \n
    \n{
    \n\"ignoreWords\": [
    \n\"\"
    \n]
    \n}
    \n<\/code>
    \nNote<\/strong>: You can enter multiple synonyms as a comma-separated list of words to be ignored.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n\"ignoreWords\": [\r\n\"~size\"\r\n]\r\n}\r\n<\/pre>\n<\/td>\n
    		Input Options<\/strong> \u2013 \u201c~extra large size t-shirt\u201d, \u201c~large size t-shirt\u201d, \u201c~medium size t-shirt\u201d, \u201c~short size t-shirt\u201d. \u201c~child t-shirt, \u201c~ men t-shirt\u201d \u201c~women t-shirt\u201d<\/p>\n
    User Utterance<\/strong> \u2013 \u201cI need extra large size t-shirt\u201d, \u201cI need large size t-shirt.\u201d, \u201cI need medium size t-shirt\u201d \u201cI need t-shirt for men\u201d<\/p>\n
    Extracted Value<\/strong> \u2013 When ignoreWords<\/strong> is set to size<\/em>, the LoV entity ignores the word \u201csize\u201d in the user input.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n\r\n\t
    \r\n\t\t
    \r\n\t\t\t
    List of Items (enum) <\/span>type entity<\/span><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    ruleName<\/th>\nValue<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
    ownership<\/strong><\/td>\ninclude\/
    \nexclude<\/td>\n    		To look for potential \u201cownership\u201d phrasing, e.g. \u201cis mine\u201d to determine if a potential choice should be included or excluded from the entity value.
    \nExamples of ownership phrases are \u201cis mine\u201d, \u201cbelongs to me\u201d, etc.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"ownership\": \"include\"\r\n}<\/pre>\n<\/td>\n
    		Input Options<\/strong> – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap”<\/p>\n
    User Utterance<\/strong> “first two are mine”
    \nExtracted Value<\/strong> [“pen”, “watch”]<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"ownership\": \"exclude\"\r\n}<\/pre>\n<\/td>\n
    		Input Options<\/strong> – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap”<\/p>\n
    User Utterance<\/strong> “first two are mine”
    \nExtracted Value<\/strong> [“bottle”, “book”, “cap”], since the rule is to exclude the ownership values.<\/td>\n<\/tr>\n
    includeWords<\/strong><\/td>\n<concept name> or array of words<\/td>\nThe list of words that supplement to the ownership phrases.
    \nThe value can be an array of strings or a concept.To be used along with ownership: include<\/em> rule<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"ownership\": \"include\",\r\n  \"includeWords\": \"great\"\r\n}<\/pre>\n<\/td>\n
    		Input Options<\/strong> – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap”<\/p>\n
    User Utterance<\/strong> “first two are mine”
    \nExtracted Value<\/strong> [“pen”, “watch”]<\/p>\n
    User Utterance<\/strong> “first two are great”
    \nExtracted Value<\/strong> [“pen”, “watch”]<\/td>\n<\/tr>\n
    excludeWords<\/strong><\/td>\n<concept name> or array of words<\/td>\nThe list of words that can be used as non-ownership phrases.
    \nThe value can be an array of strings or a concept. To be used along with ownership: exclude<\/em> rule<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"ownership\": \"exclude\",\r\n\u00a0 \u00a0\"excludeWords\": \"~lovConcept\"\r\n}<\/pre>\n<\/td>\n
    		Input Options<\/strong> – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap”
    \nlovConcept<\/strong> – dubiousUser Utterance<\/strong> “first two are dubious”
    \nExtracted Value<\/strong> [“bottle”, “book”, “cap”]<\/td>\n<\/tr>\n
    noIndexMatch<\/strong><\/td>\ntrue<\/td>\nTo disable the alphabet and number Index match, would not allow the user to select the items using an index.<\/td>\n<\/tr>\n
    Example<\/td>\n<\/tr>\n
    JSON<\/p>\n
    {\r\n  \"noIndexMatch\": \"true\"\r\n}<\/pre>\n<\/td>\n
    		Input Options<\/strong> – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap”<\/p>\n
    User Utterance<\/strong> a
    \nExtracted Value<\/strong> prompt for input, without the rule it would have been [“pen”]<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n
    <\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>\n","protected":false},"excerpt":{"rendered":"Validating user input before processing 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...","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[74],"tags":[],"class_list":["post-24846","post","type-post","status-publish","format-standard","hentry","category-how-tos"],"_links":{"self":[{"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/posts\/24846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/comments?post=24846"}],"version-history":[{"count":70,"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/posts\/24846\/revisions"}],"predecessor-version":[{"id":60872,"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/posts\/24846\/revisions\/60872"}],"wp:attachment":[{"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/media?parent=24846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/categories?post=24846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/developer.kore.ai\/v10-1\/wp-json\/wp\/v2\/tags?post=24846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}