Entities

/* Title: About Entities Sort: 1 */

Understanding a user intent can depend on the ability to classify the important elements of the conversation. This could apply to the everyday elements that end-users may employ (location, days, time etc.) but also industry, sector or brand specific ones. These are stored as entities.

You can use entities to store information to be used later in the conversation, in Flows, or to pass to Integrations that reference external services.

Entities are prefixed with the @ symbol.

One or more variables can be assigned to an entity, and will inherit that entity's properties. These can be used in a Flow, for instance, to capture multiple instances of the same entity.

Humley Studio allows you to build your own Custom Entities, and to create them from a list of pre-configured System Entities.

Entity values

You must give a Custom Entity a number of values and/or patterns in order to recognise and group key inputs.

Text values

Text values can recognise text matches and, in Flow, enforce them as acceptable inputs, e.g. you may want to restrict values for the entity @PhoneOS to either “iOS” or “Android”.

You can also give each text value a number of alternative inputs that will be accepted as if they were that value.

e.g. the @SalesCountry custom entity has a number of text values, one of which is “US”. This value can have alternatives of “USA”,“United States of America”, "America" etc. If any of those alternatives are uttered, the input will recognised as belonging to this entity. However, it will be normalised and stored as the base value name “US”.

All user utterances are interrogated at the point of entry for the existence of values and/or patterns that match your entity library, and the latest entry is stored against that entity.

If the entity is used in a Gather module in a Flow, any user input that doesn't conform to these values will be 'rejected', triggering the module's Fail Response.

Pattern values

Pattern values are used when you want to allow for a wider range of inputs, but still restrict them to a pattern. This is achieved using regular expressions (regex).

e.g. you could create an entity called @PositiveInteger and give it a regex of ^[0-9]\d*$

If the entity was used in a Gather module in a Flow, any user input that didn't conform to this regex pattern would be 'rejected', triggering that module's Fail Response.

Further help

Custom Entities System Entities Add a Text Value Add a Pattern Value