GETTING STARTED
Kore.ai XO Platform
Virtual Assistants Overview
Natural Language Processing (NLP)
Concepts and Terminology
Quick Start Guide
Accessing the Platform
Navigating the Kore.ai XO Platform
Building a Virtual Assistant
Help & Learning Resources
Release Notes
Current Version
Recent Updates
Previous Versions
Deprecations
Request a Feature
CONCEPTS
Design
Storyboard
Overview
FAQs
Conversation Designer
Overview
Dialog Tasks
Mock Scenes
Dialog Tasks
Overview
Navigate Dialog Tasks
Build Dialog Tasks
Node Types
Overview
Intent Node
Dialog Node
Dynamic Intent Node
GenAI Node
GenAI Prompt
Entity Node
Form Node
Confirmation Node
Message Nodes
Logic Node
Bot Action Node
Service Node
Webhook Node
Script Node
Process Node
Agent Transfer
Node Connections
Node Connections Setup
Sub-Intent Scoping
Entity Types
Entity Rules
User Prompts or Messages
Voice Call Properties
Knowledge AI
Introduction
Knowledge Graph
Introduction
Terminology
Build a Knowledge Graph
Manage FAQs
Knowledge Extraction
Import or Export Knowledge Graph
Prepare Data for Import
Importing Knowledge Graph
Exporting Knowledge Graph
Auto-Generate Knowledge Graph
Knowledge Graph Analysis
Answer from Documents
Alert Tasks
Small Talk
Digital Skills
Overview
Digital Forms
Digital Views
Introduction
Widgets
Panels
Session and Context Variables
Context Object
Intent Discovery
Train
NLP Optimization
ML Engine
Overview
Model Validation
FM Engine
KG Engine
Traits Engine
Ranking and Resolver
Training Validations
NLP Configurations
NLP Guidelines
LLM and Generative AI
Introduction
LLM Integration
Prompts & Requests Library
Co-Pilot Features
Dynamic Conversations Features
Kore.ai XO GPT Model
Intelligence
Introduction
Event Handlers
Contextual Memory
Contextual Intents
Interruption Management
Multi-intent Detection
Amending Entities
Default Conversations
Conversation Driven Dialog Builder
Sentinment Management
Tone Analysis
Default Standard Responses
Ignore Words & Field Memory
Test & Debug
Overview
Talk to Bot
Utterance Testing
Batch Testing
Conversation Testing
Conversation Testing Overview
Create a Test Suite
Test Editor
Test Case Assertion
Test Case Execution Summary
Glossary
Health and Monitoring
NLP Health
Flow Health
Integrations
Actions
Actions Overview
Asana
Configure
Templates
Azure OpenAI
Configure
Templates
BambooHR
Configure
Templates
Bitly
Configure
Templates
Confluence
Configure
Templates
DHL
Configure
Templates
Freshdesk
Configure
Templates
Freshservice
Configure
Templates
Google Maps
Configure
Templates
Here
Configure
Templates
HubSpot
Configure
Templates
JIRA
Configure
Templates
Microsoft Graph
Configure
Templates
Open AI
Configure
Templates
Salesforce
Configure
Templates
ServiceNow
Configure
Templates
Stripe
Configure
Templates
Shopify
Configure
Templates
Twilio
Configure
Templates
Zendesk
Configure
Templates
Agents
Agent Transfer Overview
Custom (BotKit)
Drift
Genesys
Intercom
NiceInContact
NiceInContact(User Hub)
Salesforce
ServiceNow
Configure Tokyo and Lower versions
Configure Utah and Higher versions
Unblu
External NLU Adapters
Overview
Dialogflow Engine
Test and Debug
Deploy
Channels
Publishing
Versioning
Analyze
Introduction
Dashboard Filters
Overview Dashboard
Conversations Dashboard
Users Dashboard
Performance Dashboard
Custom Dashboards
Introduction
Custom Meta Tags
Create Custom Dashboard
Create Custom Dashboard Filters
NLP Insights
Task Execution Logs
Conversations History
Conversation Flows
Conversation Insights
Feedback Analytics
Usage Metrics
Containment Metrics
Universal Bots
Introduction
Universal Bot Definition
Universal Bot Creation
Training a Universal Bot
Universal Bot Customizations
Enabling Languages
Store
Manage Assistant
Team Collaboration
Plan & Usage
Overview
Usage Plans
Templates
Support Plans
Invoices
Authorization
Conversation Sessions
Multilingual Virtual Assistants
Get Started
Supported Components & Features
Manage Languages
Manage Translation Services
Multiingual Virtual Assistant Behavior
Feedback Survey
Masking PII Details
Variables
Collections
IVR Settings
General Settings
Assistant Management
Manage Namespace
Data
Overview
Data Table
Table Views
App Definitions
Data as Service
HOW TOs
Build a Travel Planning Assistant
Travel Assistant Overview
Create a Travel Virtual Assistant
Design Conversation Skills
Create an ‘Update Booking’ Task
Create a Change Flight Task
Build a Knowledge Graph
Schedule a Smart Alert
Design Digital Skills
Configure Digital Forms
Configure Digital Views
Train the Assistant
Use Traits
Use Patterns
Manage Context Switching
Deploy the Assistant
Use Bot Functions
Use Content Variables
Use Global Variables
Use Web SDK
Build a Banking Assistant
Design Conversation Skills
Create a Sample Banking Assistant
Create a Transfer Funds Task
Create a Update Balance Task
Create a Knowledge Graph
Set Up a Smart Alert
Design Digital Skills
Configure Digital Forms
Configure Digital Views
Add Data to Data Tables
Update Data in Data Tables
Add Data from Digital Forms
Train the Assistant
Composite Entities
Use Traits
Use Patterns for Intents & Entities
Manage Context Switching
Deploy the Assistant
Configure an Agent Transfer
Use Assistant Functions
Use Content Variables
Use Global Variables
Intent Scoping using Group Node
Analyze the Assistant
Create a Custom Dashboard
Use Custom Meta Tags in Filters
Migrate External Bots
Google Dialogflow Bot
APIs & SDKs
API Reference
API Introduction
Rate Limits
API List
koreUtil Libraries
SDK Reference
SDK Introduction
SDK Security
SDK Registration
Web Socket Connect and RTM
Installing the BotKit SDK
Using the BotKit SDK
SDK Events
SDK Functions
SDK Tutorials
BotKit - Blue Prism
BotKit - Flight Search Sample VA
BotKit - Agent Transfer
Widget SDK Tutorial
Web SDK Tutorial
ADMINISTRATION
Introduction to Admin Console
Administration Dashboard
User Management
Add Users
Manage Groups
Manage Roles
Data Tables and Views
Assistant Management
Enrollment
Invite Users
Send Bulk Invites
Import User Data
Synchronize Users from AD
Security & Control
Using Single-Sign On (SSO)
Two-Factor Authentication (2FA)
Security Settings
Cloud Connector
Analytics
Billing
  1. Home
  2. Docs
  3. Virtual Assistants
  4. How Tos
  5. Entity Rules

Entity Rules

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

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>
}
preConditions user defined preconditions To 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.

Use Case Examples:

  • Example1: 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"].
  • Example 2: A VA has two static list of values (LOV) in a composite entity, you can add precondition to customer specific LOV to enable it.
  • Example 3: If you don’t want to extract entity values for simple utterances, then add preconditions to skip the extraction entirely.
  • Example 4: 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.

The pre-condition can be expressed as a context tag or trait (like an intent’s pre-condition) or when enclosed in parentheses, as a pattern. For example:

"entityRules" : {
    "preConditions" : ["checkMemberID"]
}

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.

Example
JSON

{ 
"preConditions": 
[ “isCustomerX” ]
}
Entity type: LoV Entity with Premium as one of the choices. But the list is only appropriate for Customer X.

A previous script node has set the “isCustomerX” context tag.

User Utterancecheck my premium account
Extracted Value “Premium”

A previous script node has not set the “isCustomerX” context tag.

User Utterancecheck my premium account
Extracted Value “none”

JSON

{ 
"preConditions” : 
[ “( buy )” ]
}
Entity type: Number Entity

User Utterancebuy 10 apples
Extracted Value “10”

User Utterancesearch for 10 apples
Extracted Value “none”

String type entity

Description entity type

ruleName Value Description
discardAsCommand Concept Name: ~bot_commands_override_discard

Synonyms: abort, abort_all, cancel, clear_screen, discard, discard all, exit, exit_all, quit, quit_all, restart, start_over, startover, stop, stop_all

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.
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
}
letters number
Or
range
To extract a word of a specific length, or a sequence of individual characters that meet the length criteria.
The rule value is either:

  • A single number, letters=3, where the word(s) matched is composed of that many alphabetic (a-z) letters.
  • A range, letters=5-8, indicates that 5, 6, 7, and 8 letters are valid.

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.

Example
JSON

{ 
"letters": 2 
}
Entity Pattern“letters = 2″

User Utterance 234 XY
Extracted ValueXY

User Utterance 234 x y
Extracted ValueXY

User Utterance 234 alpha bravo
Extracted ValueAB
This value is extracted as part of a phonetic alphabet.
User Utterance 234 X Y Z
Extracted ValueNothing
No alphabet matches with letters value defined.

Example
JSON

{ 
"letters": 5-8 
}
Entity Pattern“letters = 5-8″

User Utterance Kore.ai is the best platform in artificial intelligence of recent times.
Extracted Valueplatform, recent, times

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”

digits single number
Or
a range of values
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
Example
JSON

{
  "digits": "3"
}
Entity Pattern – Numeric or string entries

User Utterance “CVV is 034
Extracted Value034″
The 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.

JSON

{
  "digits": "13-17"
}
Entity Pattern – Numeric or string entries

User Utterance “My credit card number is 4012 8888 8888 1881″
Extracted Value4012 8888 8888 1881″
It is a match as the number of digits in the credit card number is 16, and within the range.

Note: The presence of the digits rule is an implicit asString=true and integerOnly=true, 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, “first”, “twenty-third”) are not matched.

The rule does not split a word or number. For example, if the utterance is “two thousand and twenty three” and the rule is "digits": 3, then it is a no match. The utterance “twenty twenty three” would also be a no match. The rule should be "digits": 4 for all the inputs to match.

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

ignoreOnlyCode <true/false> If 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.

If the value is false, the currency entity accepts the currency code or symbol even without the amount.

Example
JSON

{
  "ignoreOnlyCode": true  
}
In a scenario where the rule is set to true:

Entity Pattern pay *

User Utterance Pay USD30
Extracted ValueUSD30

User Utterance Pay AUD
VA Response: 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.

Model Number for Composite entity type

ruleName Value Description
modelNumber <true>
or
<a character>
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.
The 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.
For example:

  • “My id is six twenty seven dash forty four eighty nine
  • “My seat is 20 3 sea”
  • “The account number is alpha bravo slash six two one oh seven”
  • “I was in row 35 seat d”

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.

Example
JSON

{
  "modelNumber": true
}
Entity Pattern – @AccountNumbers @AccountSuffix
@AccountNumbers is a Number entity with “digits”:8 entity rule.
@AccountSuffix is a String entity with “letters”:2 entity ruleUser Utterance “Account Number is 3 3 1 3 4 2 1 2 X Y”
Extracted Value“33 13 42 12 X Y”User Utterance “Account Number is 33134212 – XY”
Extracted Value“33134212XY”User Utterance “Account Number is 33 13 42 12 alpha bravo”
Extracted Value “33134212AB”
User Utterance “Account Number is thirty three thirteen forty two twelve a like apple b as in boy”
Extracted Value “33134212AB”
Composite Patterns – {row} @RowNumber {seat} @Seat
@RowNumber is a Number entity with “digits”:2 and “range”: (“from”:1,”to”,35} entity rules.

@Seat is a Custom concept entity using a concept ~seatletters ( A B C D E F )

User Utterance “I am sitting in 33 A”
Extracted Value “33A”

User Utterance ““I am in row thirty three seat sea”
Extracted Value “33C”

composite number <single number> or <a range of values> To 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:

  • A provider ID could be 8 digits and 1 or 2 letters
  • An SSN is 3 digits then 2 digits then 4 digits
  • A Jira ticket is a project id plus a number.
  • An airline seat is 1 or 2 digits and 1 letter (though not all 2 digits or all letters).
Note: Note: A modelNumber composite entity is a voice-compatible replacement for a Custom regex entity.
A 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’t necessarily know if they have to provide them or not.
On voice channels, an ASR can (mis)transcribe speech, for example “C” becomes “sea” or “see”. A user could pause so “23” becomes “20 3”. The Number and String entity types, along with the digits and letters entity rules, can handle all of these variations.
The example above of ( @AccountNumbers @AccountSuffix ) can replace a regex like \d{8}\-?[a-zA-Z]{2}

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”
  • “dd-mm-yyyy”
  • “mm-dd-yyyy”
Example
JSON

{
  "preferredDateFormat": "mm-dd-yyyy"
}
User Utterance “03-04-2021”
Extracted Value “2021-03-04”
NOTE: This rule only applies 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 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”

range with strict { “from” : <from-date>, “to” : <to-date>,
“strict”: <true/false> }
If the value is true, the Date Period entity accepts values that are strictly in the defined date range.
If the value is false, the Date Period entity accepts values that are in the range or overlapping with the range.
Examples JSON

{
"range": {
   "from": "2022-01-01",
   "to": "2023-03-05",
   "strict" = "true"
  }
}
User Utterance: “2022-05-05 – 2022-06-05”
Expected Value: “Selected date range”
(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: “2021-05-05 – 2022-05-05”
Extracted Value: “I’m sorry, I am unable to recognize the string. Please enter again.”
(The user utterance is not strictly in the defined date range, it’s overlapping. As strict is true, any overlapping input is an invalid input and is rejected with an error.)
JSON

{
"range": {
   "from": "2022-01-01",
   "to": "2023-03-05",
   "strict" = "false"
  }
}
User Utterance: “2021-05-05 – 2022-05-05”
Expected Value: “Selected date range”
(The user utterance is overlapping with the defined date range. As strict is false, any overlapping input is a valid input and is accepted.)
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 only applies 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 only applies 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"
  }
}
timeOnly true/false Rule to include or exclude the character “T” and the offset value in the time.

Possible values are:

  • True – Obtains only the time and excludes the character “T” and the offset value.
  • False – Obtains the time along with character T and the offset value.

Note: The timeOnly rule supports multilang excluding English, German, French and Spanish.

For example:

  • User Input: 6 pm
  • Result (with “timeOnly” rule): 18:00:00
  • Result (without “timeOnly” rule): T18:00:00+5:50
Example
JSON

{
“timeOnly”: “true”
}

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 Values (LoV) type entity

ruleName Value Description
ignoreLemmaWords true/
false
If ignoreLemmaWords 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.
Example
JSON

{
"ignoreLemmaWords": false
}

{
"ignoreLemmaWords": true
}
Input Options – “ticket”, “tickets”.”

User Utterance “I need a ticket,” “I need tickets.”

Extracted Value When ignoreLemmaWords is set to false, the LoV entity extracts “ticket” for both the inputs – “ticket” and “tickets”.
When it is set to true, the entity extracts “ticket” only when the input contains “ticket”. For a different input like “tickets”, the bot responds that it is not a valid option.

ignoreWords The rule for the list of values (LOV) entity type to extend support to ignore words defined in the stop words or ignore words list.
This 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.
Syntax

{
"ignoreWords": [
""
]
}

Note: You can enter multiple synonyms as a comma-separated list of words to be ignored.
Example
JSON

{
"ignoreWords": [
"~size"
]
}
Input Options – “~extra large size t-shirt”, “~large size t-shirt”, “~medium size t-shirt”, “~short size t-shirt”. “~child t-shirt, “~ men t-shirt” “~women t-shirt”

User Utterance – “I need extra large size t-shirt”, “I need large size t-shirt.”, “I need medium size t-shirt” “I need t-shirt for men”

Extracted Value – When ignoreWords is set to size, the LoV entity ignores the word “size” in the user input.

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”]

Entity Rules

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

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>
}
preConditions user defined preconditions To 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.

Use Case Examples:

  • Example1: 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"].
  • Example 2: A VA has two static list of values (LOV) in a composite entity, you can add precondition to customer specific LOV to enable it.
  • Example 3: If you don’t want to extract entity values for simple utterances, then add preconditions to skip the extraction entirely.
  • Example 4: 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.

The pre-condition can be expressed as a context tag or trait (like an intent’s pre-condition) or when enclosed in parentheses, as a pattern. For example:

"entityRules" : {
    "preConditions" : ["checkMemberID"]
}

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.

Example
JSON

{ 
"preConditions": 
[ “isCustomerX” ]
}
Entity type: LoV Entity with Premium as one of the choices. But the list is only appropriate for Customer X.

A previous script node has set the “isCustomerX” context tag.

User Utterancecheck my premium account
Extracted Value “Premium”

A previous script node has not set the “isCustomerX” context tag.

User Utterancecheck my premium account
Extracted Value “none”

JSON

{ 
"preConditions” : 
[ “( buy )” ]
}
Entity type: Number Entity

User Utterancebuy 10 apples
Extracted Value “10”

User Utterancesearch for 10 apples
Extracted Value “none”

String type entity

Description entity type

ruleName Value Description
discardAsCommand Concept Name: ~bot_commands_override_discard

Synonyms: abort, abort_all, cancel, clear_screen, discard, discard all, exit, exit_all, quit, quit_all, restart, start_over, startover, stop, stop_all

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.
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
}
letters number
Or
range
To extract a word of a specific length, or a sequence of individual characters that meet the length criteria.
The rule value is either:

  • A single number, letters=3, where the word(s) matched is composed of that many alphabetic (a-z) letters.
  • A range, letters=5-8, indicates that 5, 6, 7, and 8 letters are valid.

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.

Example
JSON

{ 
"letters": 2 
}
Entity Pattern“letters = 2″

User Utterance 234 XY
Extracted ValueXY

User Utterance 234 x y
Extracted ValueXY

User Utterance 234 alpha bravo
Extracted ValueAB
This value is extracted as part of a phonetic alphabet.
User Utterance 234 X Y Z
Extracted ValueNothing
No alphabet matches with letters value defined.

Example
JSON

{ 
"letters": 5-8 
}
Entity Pattern“letters = 5-8″

User Utterance Kore.ai is the best platform in artificial intelligence of recent times.
Extracted Valueplatform, recent, times

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”

digits single number
Or
a range of values
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
Example
JSON

{
  "digits": "3"
}
Entity Pattern – Numeric or string entries

User Utterance “CVV is 034
Extracted Value034″
The 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.

JSON

{
  "digits": "13-17"
}
Entity Pattern – Numeric or string entries

User Utterance “My credit card number is 4012 8888 8888 1881″
Extracted Value4012 8888 8888 1881″
It is a match as the number of digits in the credit card number is 16, and within the range.

Note: The presence of the digits rule is an implicit asString=true and integerOnly=true, 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, “first”, “twenty-third”) are not matched.

The rule does not split a word or number. For example, if the utterance is “two thousand and twenty three” and the rule is "digits": 3, then it is a no match. The utterance “twenty twenty three” would also be a no match. The rule should be "digits": 4 for all the inputs to match.

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

ignoreOnlyCode <true/false> If 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.

If the value is false, the currency entity accepts the currency code or symbol even without the amount.

Example
JSON

{
  "ignoreOnlyCode": true  
}
In a scenario where the rule is set to true:

Entity Pattern pay *

User Utterance Pay USD30
Extracted ValueUSD30

User Utterance Pay AUD
VA Response: 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.

Model Number for Composite entity type

ruleName Value Description
modelNumber <true>
or
<a character>
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.
The 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.
For example:

  • “My id is six twenty seven dash forty four eighty nine
  • “My seat is 20 3 sea”
  • “The account number is alpha bravo slash six two one oh seven”
  • “I was in row 35 seat d”

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.

Example
JSON

{
  "modelNumber": true
}
Entity Pattern – @AccountNumbers @AccountSuffix
@AccountNumbers is a Number entity with “digits”:8 entity rule.
@AccountSuffix is a String entity with “letters”:2 entity ruleUser Utterance “Account Number is 3 3 1 3 4 2 1 2 X Y”
Extracted Value“33 13 42 12 X Y”User Utterance “Account Number is 33134212 – XY”
Extracted Value“33134212XY”User Utterance “Account Number is 33 13 42 12 alpha bravo”
Extracted Value “33134212AB”
User Utterance “Account Number is thirty three thirteen forty two twelve a like apple b as in boy”
Extracted Value “33134212AB”
Composite Patterns – {row} @RowNumber {seat} @Seat
@RowNumber is a Number entity with “digits”:2 and “range”: (“from”:1,”to”,35} entity rules.

@Seat is a Custom concept entity using a concept ~seatletters ( A B C D E F )

User Utterance “I am sitting in 33 A”
Extracted Value “33A”

User Utterance ““I am in row thirty three seat sea”
Extracted Value “33C”

composite number <single number> or <a range of values> To 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:

  • A provider ID could be 8 digits and 1 or 2 letters
  • An SSN is 3 digits then 2 digits then 4 digits
  • A Jira ticket is a project id plus a number.
  • An airline seat is 1 or 2 digits and 1 letter (though not all 2 digits or all letters).
Note: Note: A modelNumber composite entity is a voice-compatible replacement for a Custom regex entity.
A 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’t necessarily know if they have to provide them or not.
On voice channels, an ASR can (mis)transcribe speech, for example “C” becomes “sea” or “see”. A user could pause so “23” becomes “20 3”. The Number and String entity types, along with the digits and letters entity rules, can handle all of these variations.
The example above of ( @AccountNumbers @AccountSuffix ) can replace a regex like \d{8}\-?[a-zA-Z]{2}

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”
  • “dd-mm-yyyy”
  • “mm-dd-yyyy”
Example
JSON

{
  "preferredDateFormat": "mm-dd-yyyy"
}
User Utterance “03-04-2021”
Extracted Value “2021-03-04”
NOTE: This rule only applies 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 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”

range with strict { “from” : <from-date>, “to” : <to-date>,
“strict”: <true/false> }
If the value is true, the Date Period entity accepts values that are strictly in the defined date range.
If the value is false, the Date Period entity accepts values that are in the range or overlapping with the range.
Examples JSON

{
"range": {
   "from": "2022-01-01",
   "to": "2023-03-05",
   "strict" = "true"
  }
}
User Utterance: “2022-05-05 – 2022-06-05”
Expected Value: “Selected date range”
(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: “2021-05-05 – 2022-05-05”
Extracted Value: “I’m sorry, I am unable to recognize the string. Please enter again.”
(The user utterance is not strictly in the defined date range, it’s overlapping. As strict is true, any overlapping input is an invalid input and is rejected with an error.)
JSON

{
"range": {
   "from": "2022-01-01",
   "to": "2023-03-05",
   "strict" = "false"
  }
}
User Utterance: “2021-05-05 – 2022-05-05”
Expected Value: “Selected date range”
(The user utterance is overlapping with the defined date range. As strict is false, any overlapping input is a valid input and is accepted.)
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 only applies 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 only applies 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"
  }
}
timeOnly true/false Rule to include or exclude the character “T” and the offset value in the time.

Possible values are:

  • True – Obtains only the time and excludes the character “T” and the offset value.
  • False – Obtains the time along with character T and the offset value.

Note: The timeOnly rule supports multilang excluding English, German, French and Spanish.

For example:

  • User Input: 6 pm
  • Result (with “timeOnly” rule): 18:00:00
  • Result (without “timeOnly” rule): T18:00:00+5:50
Example
JSON

{
“timeOnly”: “true”
}

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 Values (LoV) type entity

ruleName Value Description
ignoreLemmaWords true/
false
If ignoreLemmaWords 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.
Example
JSON

{
"ignoreLemmaWords": false
}

{
"ignoreLemmaWords": true
}
Input Options – “ticket”, “tickets”.”

User Utterance “I need a ticket,” “I need tickets.”

Extracted Value When ignoreLemmaWords is set to false, the LoV entity extracts “ticket” for both the inputs – “ticket” and “tickets”.
When it is set to true, the entity extracts “ticket” only when the input contains “ticket”. For a different input like “tickets”, the bot responds that it is not a valid option.

ignoreWords The rule for the list of values (LOV) entity type to extend support to ignore words defined in the stop words or ignore words list.
This 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.
Syntax

{
"ignoreWords": [
""
]
}

Note: You can enter multiple synonyms as a comma-separated list of words to be ignored.
Example
JSON

{
"ignoreWords": [
"~size"
]
}
Input Options – “~extra large size t-shirt”, “~large size t-shirt”, “~medium size t-shirt”, “~short size t-shirt”. “~child t-shirt, “~ men t-shirt” “~women t-shirt”

User Utterance – “I need extra large size t-shirt”, “I need large size t-shirt.”, “I need medium size t-shirt” “I need t-shirt for men”

Extracted Value – When ignoreWords is set to size, the LoV entity ignores the word “size” in the user input.

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