INTENT In order for the chatbot to recognise an input, we'll need to create an intent It starts with sign # After you click Create intent, you'll be able to add user examples that user can say. These are sample texts of what a user could say to mean the same thing this example is known as phrase ENTITY Entities allow a user to include extra information about their request Entities allow us to capture specific information in the user in put Entity values can have synonyms and patterns They do not have to match complete sentence to get reply like intent It starts with sign @ O nly they have to match some keywords What's the weather like in Seattle tomorrow? Here keyword is seattle Also add some synonyms to cover what users may enter instead of the value with the same intent For example user can say seatle instead of seattle so to check this type of keywords we use synonyms @city:seattle here city is entity and seattle is value for this enti ty In this way we can set multiple values of entity city WEBHOOK Webhook is a way using this IBM chatbot can communicate with other services We'll create a webhook that queries for some documents using API stored somewhere and optionally filters by the assignee entity we created earlier Head back to the Dialog page and add a new node with a descriptive name. We want the node to trigger when the chatbot recognizes the intent we created earlier Click the Customize button next to the node name and toggle Webhooks to On , then click apply it automatically enabled multiple conditional responses One for response that we get from API get request other for if any error comes then what to reply Here key and value pairs store value that we send as a parameter during API call for GET request and response that comes is save in webhook_result_1 variable The webhook response stored in the variable is accessible like any other object, with the exception of using SpEL expressions to show the results (simply put, you'll need to wrap variables wi th <? ?> tags) By setting Response variations to multiline , you can split your response over multiple lines by adding more variations. This can be useful for making your responses more readable If you want to do more complicated transforms of your data before displaying it to the user, it's recommended to use IBM Cloud Functions (or another cloud function provider) as the target for your webhook and perform the fetch to an external service manual ly then we have to configure cloud function in webhook We add child node s that are triggered by the @menu entity types CHILD NODE A child - node allows you to set if conditions within a dialog flow For example: You can make the Assistant provide user with options for resetting a password or unlocking an account. And you can create separate child nodes for resetting a password and as well as for unlocking an account First create intent account Add account intent in if bot recognize section to the node w hich is parent Create entity named account create two values resetting and unlocking for this entity And create child nodes for both entity @account:resetting and @account:unlocking and give response which you like in both child nodes response section CONTEXT VARIABLE T o avoid asking for the same Question again we use context variable to save value in this variable A context variable is a variable that you define in a node, and optionally specify a default value for. Other nodes or application logic c an subsequently set or change the value of the context variable For example Your application can set a $time_of_day context variable, and pass it to the dialog which can use the information to tailor the greeting it displays to the user In this example, the dialog knows that the application sets the variable to one of these values: morning, afternoon, or evening . It can check for each value, and depending on which value is present, return the appropriate greeting. If the variable is not passed or has a value that does not match one of the expected values, then a more generic greeting is displayed to the user The dialo g can also add context variables to pass information from one node to another or to update the values of context variables. As the dialog asks for and gets information from the user, it can keep track of the information and reference it later in the conver sation. For example, in one node you might ask users for their name, and in a later node address them by name. In this example, the system entity @sys - person is used to extract the user’s name from the input if the user provides one. In the JSON editor, the username context variable is defined and set to the @sys - person value. In a subsequent node, the $username context variable is included in the response to address the user by name "username": "@sys - person.literal" Whenever a name is encountered, @sys - person entity automatically recognises it and assigns it to the username context variable. You can use it by calling $username anywhere in your dialog. Other example, the @sys - number system entity matches any numerical value, including wh ole numbers, decimal fractions, or even numbers written out as words if you use context variable somewhere in any node to save it then it automatically saved in this variable SLOTS It tell in which variable to save that input and what question to ask if that data was not provided yet. Optional slots, i.e., optional data, can be enabled Slots allows us to co llect inform ation from the user and store it in context variable s MULTIPLE CONDITION Multiple conditioned responses allow you to provide different answers based on conditions related to the intent — all in one dialog node. The scenario below provides a greeting based on the time of day. The conditions here are looking to match to give different response in different time • Time of day which is after 5:59pm and before 11:59pm • Time of day which is before 12pm (noon) • Time of day which is before 6pm • True condition (default/catch - all value) A conditioned response is different to a standard response as the customer will see a different answer based on: • Their previous interactions with the assistant • External criteria, such as the time of day The system processes the conditions from top to bottom, will one condition block another and final and the default (true) condition as the last item in the list T he final c ondition, the default (true) condition, is triggered if the previous conditions haven’t been triggered Typically, a default (true) response indicates to the customer that the assistant has understood the question. The customer may not receive any response if a default (true) response is not added. The assistant appears to be completely lost in its answer, or worse, that it has broken down DIGRESSION Digressions are a feature that enables nodes to pass control to a different node while they are processing a slot. What this means is that they allow the dialog to respond to a user's side question, while they are in the middle of answering a slot For example T he user might be ordering a new phone, but switches topics to ask about tablets. Your dial og can answer the question about tablets, and then bring the user back to where they exited the customer journey for ordering a phone Every root node in your dialog is configured to allow digressions to target them by default. Child nodes cannot be the target of a digression Nodes with slots are configured to prevent digressions away from it All other nodes are configured to allow digressions awa y However, the conversation cannot digress away from a node under the following circumstances: • If any of the ch ild nodes of the current node contain the anything_else or true condition These conditions are special in that they always evaluate to true. Because of their known behavior , they are often used in dialogs to force a parent node to evaluate a specific chil d node in succession To prevent breaking existing dialog flow logic, digression are not allowed in this case. Before you can enable digressions away from such a node, you must change the child node’s condition to something else • If the node is configured to jump to another node or skip user input after it is processed The final step section of a node specifies what should happen after the node is processed. When the dialog is configured to jump directly to another node, it is often to ensure that a spec ific sequence is followed And when the node is configured to skip user input, it is equivalent to forcing the dialog to process the first child node after the current node in succession To prevent breaking existing dialog flow logic, digressions are no t allowed in either of these cases. Before you can enable digressions away from this node, you must change what is specified in the final step section The last thing you would want, is an instance where the user gets caught in a leg of the conversation. So most legs have a default message if a user does not exercise any input or if there is a “ no matc h ”. Users cannot digress away from dialog flows that u se this approach If the user’s input does not match anything you anticipated, it might find a match against an entirely different dialog flow in your tree. Rather than responding with a generic message, you can effectively put the rest of the dialog to work to try to address the user’s input Digression Control You do not define the start and end of a digression, the user is in complete control of digression at run time. You only specify how each node should or should not participate in a user - led digr ession. For each node, you configure whether • a digression can start from and leave the node • a digression that starts elsewhere can target and enter the node For Example With out D igression W ith D igression