A composite bag is a grouping of related entities that can be treated as a whole within a conversation. Using composite bags enables a skill to extract values for multiple entities in one user utterance, which allows a conversation to flow more naturally. Early on in the designing of your skill, you should identify these groups of related entities, which often reflect clear business domains, and build composite bags for them.

For example, a composite bag for a pizza might include entities for type, size, crust, and extra toppings. If a user enters "I'd like a large pepperoni pizza with a gluten-free crust", the skill could extract "large", "pepperoni", and "gluten-free" from that input and not need to prompt the user for those values individually.

You can configure the composite bag entity to resolve its constituent items in different ways: it can prompt for individual entity values when they're missing from the user input, for example, or it can use the value extracted by one if its entities to resolve a second entity.

Composite bags can also include other types of items, such as those that store location and accept free text and attachments.

Composite bag entities allow you to write much shorter, more compact dialog flow definitions because they can be resolved using just one component. See Configure Composite Bag Entities for details on creating and configuring composite bags.

Because anticipating the format or wording of user messages is challenging, especially for multi-lingual skills, you may want to use an ML entity in place of the less flexible Value List and Regular Expression entities. Despite fuzzy matching, Value List entities (both static and dynamic) can often detect entity values only when they match their values or synonyms. "Computer engineer" might not match "computer engineering", for example. Regular Expression entities restrict the user input to matching a predetermined pattern or the wording that proceeds or follows an entity value. ML entities, on the other hand, are adaptable and can be made more so through robust training data.

An entity based on a list of predetermined values, like menu items that are output by a Common Response component. You can optimize the entity’s ability to extract user input by defining synonyms. These can include abbreviations, slang terms, and common misspellings. Synonym values are not case-sensitive: USA and usa, for example, are considered the same value.

Resolves an entity using a regular expression (regex), such as (?<=one\s).*(?=\sthree). Regular expressions allow your skill to identify pre-defined patterns in user input, like ticket numbers. Unlike the other entity types, regex-based entities don’t use NLP because the matching is strictly pattern-based.

A super set of entities. Using a travel skill as an example, you could fold the entities that you’ve already defined that extract values like airport codes, cities, and airport names into a single entity called Destination. By doing so, you would enable your skill to respond to user input that uses airport codes, airport names, and cities interchangeably. So when a user enters “I want to go to from JFK to San Francisco,” the Destination entity detects the departure point using the airport code entities and the destination using the cities entity.

A derived entity is the child of a built-in entity or another entity that you define. You base this relationship on prepositional phrases (the "to" and "from" in utterances like I want to go from Boston to Dallas or Transfer money from checking to savings). Derived entities can’t be parent entities. And because the NLU Engine detects derived entities only after it detects all of the other types of entities, you can’t add derived entities as members of an entities list.