OVERVIEW
Virtual Assistants
Kore.ai Platform
Key Concepts
Natural Language Processing (NLP)
Accessing Platform
VIRTUAL ASSISTANTS
Virtual Assistant Builder
Virtual Assistant Types
Getting Started
Creating a Simple Bot
SKILLS
Storyboard
Dialog Task
Introduction
Dialog Builder (New)
Dialog Builder (Legacy)
User Intent Node
Dialog Node
Entity Node
Supported Entity Types
Composite Entities
Supported Colors
Supported Company Names
Form Node
Logic Node
Message Nodes
Confirmation Nodes
Bot Action Node
Service Node
Custom Authentication
2-way SSL for Service nodes
Script Node
Agent Transfer Node
WebHook Node
Grouping Nodes
Connections & Transitions
Manage Dialogs
User Prompts
Knowledge Graph
Terminology
Building
Generation
Importing and Exporting
Analysis
Knowledge Extraction
Build
Alert Tasks
Introduction
Ignore Words and Field Memory
How to Schedule a Smart Alert
Small Talk
Digital Views
Overview
Configuring Digital Views
Digital Forms
Overview
How to Configure Digital Forms
NATURAL LANGUAGE
Overview
Machine Learning
Introduction
Model Validation
Fundamental Meaning
Introduction
NLP Guidelines
Knowledge Graph
Traits
Introduction
How to Use Traits
Ranking and Resolver
Advanced NLP Configurations
INTELLIGENCE
Overview
Context Management
Overview
Session and Context Variables
Context Object
How to Manage Context Switching
Manage Interruptions
Dialog Management
Sub-Intents & Follow-up Intents
Amend Entity
Multi-Intent Detection
Sentiment Management
Tone Analysis
Sentiment Management
Event Based Bot Actions
Default Conversations
Default Standard Responses
TEST & DEBUG
Talk to Bot
Utterance Testing
Batch Testing
Record Conversations
CHANNELS
PUBLISH
ANALYZE
Overview
Dashboard
Custom Dashboard
Overview
How to Create Custom Dashboard
Conversation Flows
NLP Metrics
ADVANCED TOPICS
Universal Bots
Overview
Defining
Creating
Training
Customizing
Enabling Languages
Store
Smart Bots
Defining
koreUtil Libraries
SETTINGS
Authorization
Language Management
PII Settings
Variables
Functions
IVR Integration
General Settings
Management
Import & Export
Delete
Versioning
Collaborative Development
Plan Management
API GUIDE
API Overview
API List
API Collection
SDKs
SDK Overview
SDK Security
SDK App Registration
Web SDK Tutorial
Message Formatting and Templates
Mobile SDK Push Notification
Widget SDK Tutorial
Widget SDK – Message Formatting and Templates
Web Socket Connect & RTM
Using the BotKit SDK
Installing
Configuring
Events
Functions
BotKit SDK Tutorial – Agent Transfer
BotKit SDK Tutorial – Flight Search Sample Bot
Using an External NLP Engine
ADMINISTRATION
HOW TOs
Creating a Simple Bot
Creating a Banking Bot
Context Switching
Using Traits
Schedule a Smart Alert
Configure UI Forms
Add Form Data into Data Tables
Configuring Digital Views
Add Data to Data Tables
Update Data in Data Tables
Custom Dashboard
Custom Tags to filter Bot Metrics
Patterns for Intents & Entities
Build Knowledge Graph
Global Variables
Content Variables
Using Bot Functions
Configure Agent Transfer
Update Balance Task
Transfer Funds Task
RELEASE NOTES
  1. Home
  2. Docs
  3. Virtual Assistants
  4. How Tos
  5. Entity Rules

Entity Rules

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;
concept2: affirmative

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;
concept2: wrong

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 UtteranceI like city New York
Extracted Value 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 UtteranceI like New York city” or “I like New York airport
Extracted Value New York

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 UtteranceI like to watch chess tournament
Extracted Value prompt for entity value

User Utterance I like to watch golf tournament
Extracted Value golf

User Utterancecricket
Extracted Value cricket, since it is the entire input

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 UtteranceI like playing music
Extracted Value prompt for entity value

User UtteranceI like rap music
Extracted Value rap

User Utteranceplay
Extracted Value play, since it is the entire input

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
Extracted Value009944″
without the rule, it would have been “9944”

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
Extracted ValueNZD30

User Utterance Pay USD30
Extracted ValueUSD30

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
Extracted ValueUSD30

User Utterance Pay USD3000
Extracted Value prompt for value

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
Extracted ValueUSD30

User Utterance Pay AUD30
Extracted Value prompt for a value

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”
Extracted ValueBob

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”
Extracted ValueBob
would have been “Bob Review” without the rule

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”
Extracted ValueFred
would have been “Philip” without the rule

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”
Extracted Value none
would have been “ATM” (an Italian company) without the rule

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”
Extracted Value prompt for a value

User Utterance “show schedule for tomorrow”
Extracted Value prompt for a value

User Utterance “show schedule  for 2020-02-03”
Extracted Value “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”
Extracted Value “2020-07-11”
would have been two days from the current date without the reference date

preferredDateFormat “yyyy-mm-dd” In case of ambiguity in date, it uses the preferred date format to resolve ambiguity.
Values can be:

  • “yyyy-mm-dd”
  • “yyyy-dd-mm”
  • “ddmmyyyy”
  • “mmddyyyy”
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”
Extracted Value prompt for a value

User Utterance “show schedule for tomorrow”
Extracted Value prompt for a value

User Utterance “show schedule  for 2020-02-03”
Extracted Value “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”
Extracted Value “2020-07-11”

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”
Extracted Value “2020-01-01” if the current date is “2020-15-12”
without the rule, it would have been “2021-01-01”

 

preferredDateFormat “yyyy-mm-dd” In case of ambiguity in date, it uses the preferred date format to resolve ambiguity.
Values can be:

  • “yyyy-mm-dd”
  • “yyyy-dd-mm”
  • “ddmmyyyy”
  • “mmddyyyy”
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”
Extracted Value prompt for a value

User Utterance “show schedule for 2021-12-20T10:00:00”
Extracted Value prompt for a value

User Utterance “show schedule  for 2020-02-03 T10:00:00”
Extracted Value “2020-02-03T10: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”
Extracted Value “T15:00:00”

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”
Extracted Value “T15:00:00”, if the current day is Monday/Tuesday/Friday;
“T03:00:00”, if the current day is Wednesday/Thursday

JSON

 "preferredTimes": {
    "favor": "pm"
  }
Entity Pattern – by default date patterns

User Utterance “remind me at 3”
Extracted Value “T15:00:00”

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:

  • “yyyy-mm-dd”
  • “yyyy-dd-mm”
  • “ddmmyyyy”
  • “mmddyyyy”
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”
Extracted Value “T15:00:00”

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”
Extracted Value “T15:00:00”, if the current day is Monday/Tuesday/Friday;
“T03:00:00”, if the current day is Wednesday/Thursday

JSON

 "preferredTimes": {
    "favor": "pm"
  }
Entity Pattern – by default date patterns

User Utterance “remind me at 3”
Extracted Value “T15:00:00”

timeRangePossible true/false If true then the dialog will be looking for time range in the user input.
Example
JSON

{
“timeRangePossible”: “true”
}

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”
Extracted Value prompt for entity value, without the rule it would have been “Send” since it is a city name

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
<“country1”>,<“country2”>,…

Example
JSON

{
  "preferredCountries": [
    "GB"
  ]
}
Entity Pattern – by default zip code patterns

User Utterance “check delivery to PO16 7GZ
Extracted ValuePO16 7GZ“, without the rule this might have been ignored if the user is not in the UK region

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
<“country1”>,<“country2”>,…

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”
Extracted Value [“pen”, “watch”]

JSON

{
  "ownership": "exclude"
}
Input Options – Pick your item: “pen”, “watch”, “bottle”, “book”, “cap”

User Utterance “first two are mine”
Extracted Value [“bottle”, “book”, “cap”], since the rule is to exclude the ownership values.

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”
Extracted Value [“pen”, “watch”]

User Utterance “first two are great”
Extracted Value [“pen”, “watch”]

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
Extracted Value prompt for input, without the rule it would have been [“pen”]

Menu