Cognigy.AI Flow Developer Training

Hello and welcome to the Flow Developer course. The goal of this course is to teach you more advanced Flow Development topics. In the Foundation's course, we covered the basic building blocks for conversations, but there were many real-world scenarios that we still can't build without learning more. It's fair to say that this course will take your Flow Development skills to a whole other level, and you should leave confident that you can tackle many common scenarios.

For the most part, this course does not require writing code, but I do introduce more technical concepts. The ideal audience is anyone from a courageous business user with an analytical mindset to a skilled developer. To start things off, in this session we will pull back the curtain and learn about the Input and the Context. These concepts are important, they are fundamental to building real-world Flows, so you'll want to pay particularly close attention to these topics. To start learning about the Input and the Context, I need to give you a proper introduction to the Interaction Panel.

So far we've used the Interaction Panel to test out our Flows. We turned on expert mode to see feedback like Intents and Slots matches, and we used our favorite shortcut, Control-B or Command-B to clear the chat window. But there's much more to the Interaction Panel. I'll show you a few features we haven't looked at yet in the Chat view. At the top, we can select a Snapshot. We'll cover Snapshots later in this course. For now, know that it's like a versioning mechanism for your Agent, so you could test your conversations using a version of your Agent from last week versus this week. A real-world example would be testing a conversation on the production version of your Agent versus a work in progress version of your Agent. Below the Snapshot field, there's a field that lets us choose the starting Flow for our conversation. We haven't talked about working with different Flows yet, but the more Flows you have, the more you may want to test out different Flows without having to leave the view of the current Flow. So I can start the conversation here in my main Flow, or I could point the Interaction Panel to any other Flow in this Agent. Next to the dropdown is a vertical ellipsis that gives you the option to clear the chat, the same as pressing Control-B or Command-B. You'll also see the option to create a Playbook. A topic that we'll cover later in this course. Below this dropdown, you'll see Chat, Info, and Settings. I'll refer to these as tabs, i.e. the Chat tab, the Info tab, or the Setting tab.

Let's go over to the Settings tab. We've seen the expert mode toggle already that gives feedback on Intent matches and Slots matches among other things. Beneath that, you can choose the channel you want to display. This is helpful if you've configured channel-specific output, but for testing purposes, you only want to see the default channel in the Interaction Panel. It doesn't affect the Flow functionality. It can just make the Interaction Panel easier to read if you have multiple channels configured. The other options here relate to features that we'll learn about later. But for now, I'll just note that you can configure how the Interaction Panel runs Playbooks and change the Input mode to let you select a Playbook.

Things get exciting when you go to the Info tab. This reveals four subtabs for the Input, State, Context, and Profile. You may be wondering what am I looking at and how technical do I have to be to make sense of it? Don't worry, we'll take it one step at a time and I'll share some useful tools so that both coders and non-coders can feel comfortable.

To get started, I'll create a new Flow, I'll call it Interaction Panel. I'll add a couple of Question Nodes.

Did you enjoy your flight? This is a Yes/No question. I'll save the answer to the Cognigy Context and make the Context Key be something descriptive, like satisfied.

I'll add another question and make it a Text question.

What was your flight number? I'll save this to the Context as flight.

Now, I'll add a Say Node to output the flight number.

Your flight number is Last Question Result.

Now, let's run through it.

The questions worked fine, but Cognigy did not put the Last Question Result. We'll learn why that is in detail. But for now, that's because we're storing the answer in the Context rather than in the Input. Where can you see the Context? I'll go to the Info tab and then click on Context. There I see two values ''satisfied'' and ''flight''. Those reflect the Keys I specified in the Question Nodes. For the first question ''satisfied'', I said yes. Cognigy stores the Yes/No answers as true or false. For the flight, you'll see the flight number I entered in quotes. This particular structure with the open curly brace at the top and closing curly brace at the bottom is called JSON or JavaScript Object Notation. But you don't need to know JavaScript to work with it. You can just think of it as an outline, a hierarchical list with each element separated by a comma. I can access these values in my Say Node. I'll delete Last Question Result and replace it with opening and closing double curly braces like this. These curly braces just tell Cognigy that I want to insert some dynamic content. Between the braces, I'll put Context.flight, this tells Cognigy to look in the Context object and output the value for flight. Now, if I go through my Flow, I see the flight number output at the end. I also want to tell the user if they were satisfied or not. Under my Say Node, I'll add an If in my condition, I'll switch over to the advanced editor and enter context.satisfied. This just means if context.satisfied is true, then do something. I'll add Say Nodes to reflect whether the user was satisfied or unsatisfied.

In the Say Node, I use context.flight to output the flight number. In my If Node, I check if context.satisfied is true and if so, let the user know that they are satisfied. Let's try the no scenario. Here context.satisfied is not true. So it goes down the Else branch. This is really important to understand. So if it's not clear, take a moment and try it out yourself. I'll open my If Node and look at it again. Cognigy checks the satisfied value in the Context. If it's true, Cognigy follows the Then branch, if it's false, Cognigy Flows the Else branch. And if I look at the Context, I see those values. Now, let's make it one step more interesting. In my Question Nodes, I'll go under advanced and select ''Stored detailed results''.

I'll go through the Flow again.

Now it says your flight number is [object Object], that's not what we're looking for. So let's examine the Cognigy Context to figure out what happened. The Context now has much more information. On line two, you'll see satisfied and on line ten, you still see flight. But there's other stuff here that we need to understand. To help visualize this more easily, I'm going to use a tool called JSON Path Finder. You can find it at jsonpathfinder.com or just search for it online. There are other similar tools that you can find if you search for JSON formatter, for example. Many tools do the same thing, but this is the best one for our training. I'm going to copy the JSON from the context into the left side of the JSON Path Finder. Now look what we see on the right, we see our answer keys satisfied and flight with some arrows next to them. If I click on the arrow next to satisfied, I see some additional information. I see the value is true, I see the timestamp when the user responded and I see that their actual answer was yes.

If I click on the arrow next to the question, I see the actual question. Did you enjoy your flight? Again, think of this as an outline with categories, subcategories, and so on. Let's collapse satisfied and look at flight. There I see the same fields, value, question, timestamp, and answer. So if I want to output the value that the user entered, I need to use that field called value. And here's why I like this tool so much. If you click on value, you'll see the path to that value in the path bar. Take a moment to think about this. The path describes the hierarchy to reach the value. So it starts with x, which in this case is just the top level, and then it goes to flight, and then it goes to value. So the path represents the hierarchy of our outline. I'll click copy. Now I'll go to my Say Node and replace context.flight with x.flight.value. I'll change the x to Context because that's where the value lives.

So I have your flight number is within double curly braces context.flight.value. Now, if I go through the Flow again, it outputs the flight number correctly.

We need to make this change to our If Node as well. I'll go back to my JSON Path Finder tool and find the value in the tree on the right. I'll click on the value under satisfied and then click copy. Again, I'll change the x to context, and now we're all set.

Two questions come to mind: One, is it necessary to enable stored detailed results? It's not. That setting could be helpful if you want to use those values later in the conversation. But it's really just an example of a more complex JSON structure that we could examine. Two, why store things in the Context. The idea behind the Context is that you often want to collect information from a user and make it available later in the conversation. So if the user asks for the status of flight UA277, we should remember that. Later in the conversation, If they ask us what baggage carousel they should go to, we shouldn't have to ask for their flight number again because it's already in the Context. Let me give you an example of that. I'll add a Question Node to the bottom of my Flow that says, ''what was your flight number?'' I'll just copy the question I already asked at the beginning of the Flow.

I'll also copy my Say Node that output's the flight number and put it at the end of my Flow.

If I test it out, I have to answer the question about my flight number a second time. We can imagine that this is at some other point in the conversation where I've triggered a different Intent that requires this information for example. Now I'll make a small change to my Question Node. Under Context, I'll select ''Skip if answer exists in Context''. Now, I'll run through it again.

Now it makes its way to the end of the Flow without asking me the flight number again. That's because I've stored the flight number in the Context and I've told Cognigy to skip the question if we already have the answer. Hopefully, that gives you a basic understanding of how to work with values in the Cognigy Context and how to interpret our work with the Context JSON. Now we'll look at the input JSON, which is longer and much more rich in information. I'll create a new Flow and call it Input.

And I'll upload the Intents that we created in the Foundation's course.

I'll enable my Baggage Lexicon.

And then train.

I'll clear out my Chat and say, can I bring my backpack onboard? I have two of them to start the conversation. If I go to the Info tab in the Input subtab, I see a lot of information. I'll copy that over to JSON Path Finder to make it easier to read. Once you get used to reading the JSON body, you might not need a tool like this, but it's really useful for learning and you might refer to it in the future for Complex JSON bodies. On the right at the top, you see the text the user entered, which was, can I bring my backpack onboard? And you see much more information. Below the text, I see the Intent that was triggered ''Baggage Rules-Carry On'' and I can see the Intent score. If I click on Slots, I can see there was a Number match and a Bag Type match. I can drill all the way down into the number and see the number two because I said I have two bags. I can drill all the way down on the Bag Type Slot and see the Key Phrase match for backpack. There's a lot more here, and we'll look at other branches of this tree later on. Let's look at how we can use this information in our Flow. Let's check the users Intent and let them know we can help them with their bag. If you'll recall from the Foundation's class, we can create a LookUp Node which checks for Intents. I'll create a LookUp Node and set each Case Node to handle an Intent.

For my Carry-On Bag Intent, I'll let the user know we can help them with their bag. I'll create a Say Node that says I can help you with your and then I'll put my double curly braces, two open braces, and two close braces. In between them, I want to put my Slots match. I'll go to my JSON Path Finder and click on the backpack Key Phrase. I'll copy the value and put it into my Say Node. Since we're working with the Input now and not the Context, I'll change the x to Input.

Now, I'll say, can I bring my backpack on board and the bot recognizes my Intent and responds with the correct Slot match. I could also say I need to bring my messenger bag on the flight, and Cognigy finds the Slots match again. A thing to remember about the Input is that it only exists for each Input and then goes away. To persist information, we need to store it in the Context. So that's what I'll do under my Carry On Node, I'll add an If, I want to check to see if there's a Slot match for Bag Type. To do that, I'll go to my JSON Path Finder and click on Bag Type. I'll copy that and paste it into the condition field. I'm looking for the Slot match and what the user just said ''the Input'', so I'll change the x to Input. And then I'll choose exists from the dropdown. So I'm checking to see if there is a Bag Type Slot match of any kind. If there is, I'll move my Say Node to the Then branch and let the user know I can help them with their Bag Type. The other thing I want to do is store the Bag Type in the Context so I don't have to ask them about it again. Under my Say Node, I'll add an Add to Context Node.

For the key, I'll put Bag Type,  for the value, I'll add the full path to the Bag Type. If I go to my JSON Path Finder, I'll drill all the way down to the Bag Type Key Phrase. I'll copy the path and paste it into the value field. Don't forget to put this path between double curly braces because we're getting this information from what the user just said,  I'll change the x to Input and I'll click save. Let's test it out so far. I'll say I need to bring my messenger bag on the flight, Cognigy responds, as I would expect, but did it save Bag Type in the Context? Let's take a look. If I click on Info then Context, I can see that Messenger bag was successfully stored in the Context. If the user didn't specify a Slot type, I want to ask them. In my Else branch I'll add a Question Node that says, what type of bag will you be carrying? I'll make it a Slot question, specify Bag Type as the Key, and I'll store the answer in the Context.

Let's keep using Bag Type as our Key. I'll move my Say Node under the Then and Else branches, so the logic works like this. If the user is mentioned a Bag Type, I'll add it to the Context and say, I can help you with whatever bag you mentioned. If you didn't mention a bag, I'll ask you what type of bag you're bringing and then the same Say Node will execute. Let's try it.

I get my expected confirmation message, and if I look at the Context, I see the Bag Type.

If I say, can I bring my ski bag on board, Cognigy gives me the confirmation message and I can check the Context to confirm the Add to Context Node worked as expected. As one more improvement to the Flow, I want to ask the user about their bag if they asked about checked bag fees. I'll add an If under the checked bag branch. I'll check in the Context to see if the Bag Type exists. Remember, we're getting this out of the Context, not out of the Last User Input. In my condition, I'll put context.bag.type and I'll choose exists as my operator. If there is a Bag Type in the Context, I'll let the user know I can help them. I'll copy the Say Node from the other branch.

Between the double curly braces, I'll just reference the Context value, context.bag.type. Similar to the other path, I'll ask about the Bag Type if they haven't mentioned one. To make it easy, I'll copy my Question from the other branch.

I'll change the text to say what type of bag will you be checking? So at this point, we either remember the Bag Type from a previous question or we ask the user explicitly. Let's imagine we want to give a different response depending on the bag type. If they have a ski bag, it needs to be handled as an oversize bag. If it's a backpack, we'll tell them they could take it as a carry on. If it's anything else, we'll tell them they can check the bag for free. To do this, we'll add a LookUp Node. You may be surprised to see this. Aren't LookUp Node for checking Intents. By default, Yes, but you can actually use LookUp Nodes to check for other things as well. I'll open the LookUp Node and on the Type field, I'll select CognigyScript. For the operator, I need to tell Cognigy which value to look at. In this case, it's going to be the Bag Type. This value should exist at this point in the Context, so I'll just put context.bag.type.

For my first Case Node, I'll put Ski Bag and for my second Case Node, I'll put Backpack.

I'll put a Say Node under the Ski Bag branch. And say ''ski bags are considered oversize and require special handling''.

Under the Backpack branch, I'll say you can check your backpack or just bring it on board. Under the Default branch, I'll put another Say Node and let users know they can check one bag for free.

What's happening here is that Cognigy is going to look the Bag Type value in the Context. If it's a Ski Bag, they will get one message. If it's a Backpack, they'll get another. And if it's neither of those, they'll get the Default message. Don't forget that I can add as many Case Nodes as I like. Let's test it out. Can I bring my ski bag on board? How much does it cost to check a bag? Let's take a step back and think about what we've learned. One, we've learned that Cognigy stores the Input values and the Context values in a hierarchical structure called JSON. Two, we can access those JSON values using the keyword ''Input or Context'' followed by the Path in the JSON. Three, we saw that by storing values in the Context such as Slots matches, we can remember those values across multiple turns in the conversation. Four, and finally we saw that we can use a LookUp Node to give different outputs based on the value of an item in the Context.

Let's look at another example of how we can use the Cognigy input to give intelligent answers to our users. Our goal is this: We know that you can't bring just anything you want on an airplane. Every country has its own rules around how much liquid you can bring, how to handle sharp objects like tweezers or scissors, and how to manage unusual items like musical instruments. I want to create a bot that lets users ask about different things they want to bring and whether or not they're allowed on a plane or in checked baggage. For unique items, I want to give explanations as to how or why they need special handling. If you could connect to a database with this information in it, you could simply query that database and we'll learn how to do that later in this course.

But what about business information that's important and doesn't change frequently but doesn't live in a database? Think of things that you might have in a spreadsheet on your internet or in a list or table on a website, but haven't risen to the level of importance to put them in a system that can be easily queried. This happens more than you might think. In Cognigy, there are different ways you can address this. Cognigy isn't designed to be a replacement for a database system, but for small size datasets, there are some interesting approaches you can take. The goal of the following exercise isn't to persuade you to use Cognigy as a database. It's to show you an additional feature of Lexicon and to get some more practice working with the Cognigy Input and the Cognigy Context. I have downloaded a list of 452 items you might bring on a plane, and their related rules from the US Transportation Security Administration website. I converted the list to a CSV file and uploaded it as a Lexicon in Cognigy.

The other thing I did was to append data elements to the Lexicon. For example, if I search for tweezers on my list, and I click the down arrow on the right, I see some additional information. I see an explanation for what makes tweezers unique, they are potentially sharp objects and I added two values Carry and Check. Carry indicates whether the item is approved as a carry on and check indicates whether the item is approved to be included in checked baggage. Some don't have explanations. If I search for a thermometer, for example, I see that can be a carry on item or a checked item without further discussion. Let's see what happens when I use this Lexicon in a Flow. I'll go back to my Flow and make sure that I've attached the Pack Lexicon.

In the Interaction Panel, I'll just enter tweezers. Let's look at the Cognigy Input. I'll copy it to the JSON Path Finder to make it easier to read.

If I drill down into Slots and then Pack, I'll see the Key Phrase match for tweezers. Now let's drill into data. Here, I see the fields with the explanation and the indicators for Carry and Check. Let's use this in our Flow. The first thing I'll do is create an Intent that uses my Pack Lexicon. I'll call it Baggage Rules-Permitted Items, and I'll add some example sentences and annotate them.

After I'm done annotating, I'll save and build.

In my Chart, I'll add a Case Node and reference my new Intent.

Let's think this through, if the Intent is triggered, I want to see if the user has already asked about a permitted item. If they have, i'll let them know if it's approved for carry on or check in, and I'll provide an explanation if one exists. If they haven't mentioned which item they're concerned about, I'll ask them. In either case, I'll store the item they're asking about in the Cognigy Context. So first, let's check if there's a Slot match for the Pack Slot.

In my condition, I just need to check if the Slot exists. I'll go to my Path Finder and click on Pack and then copy the path. I'll paste it into my condition. Because I'm getting this information from the Input, what the user just said. I'll replace the x with Input. If the Pack Slot exists, I'll share the rules with the user. I'll check to see if Carry is true, and if so, let the user know. I'll repeat that for Check. I'll create an If Node and for the condition, I want to see if Carry is true. In my Path Finder, I'll drill all the way down into my data branch and click Carry. I'll copy that and paste it into my condition.

I'll change the x to Input. For the condition, output is yes. You may recall from an earlier session that Cognigy treats yes as true in this case. So if Carry is true, I'll tell the user they're allowed to bring the item on board. I'll create a Say Node for the Then and the Else branches.

I'll repeat this again with checked baggage. I'll copy my If and make the necessary changes to the If and Say Nodes.

Finally, I'll output the explanation, if there is one. I'll create a Say Node and add my double curly braces. I'll go to the Path Finder to get the path to the explanation.

I'll copy it and paste it between the curly braces. Because this is coming from what the user just said, I'll change x to Input. You'll notice that I didn't add an If here to check to see if there is an explanation. I decided that if there is an explanation, we will output it, and if there's not, Cognigy won't output anything, which is Ok. The last thing I'll do is add the Slot match to the Cognigy Context. I could use and Add the Context Node like we did before. But I have an even easier option, which is to add the Slots match to the Context using the Copy Slots to Context Node and it will do just that.

I don't need to tell it which Slot to copy and which Context Key to use.

Now, if I go all the way to the top, I can see that I first check if the Slot match exists. If it does, then I go through all the logic I just created. If it doesn't, I need to ask the user which item they're concerned about. I'll add a Question Node with a Question Type of Slot.

I'll use Pack as the Slot name to look for, and I'll ask the user, which item are you concerned about? Now, what? Do I need to reproduce all of the logic I have in the Then Node, or is there a way I can make use of everything we just created? There are a couple of ways to handle this. I'll show you a new Node type that can help. Under my Question Node, I'll add a Think Node. Think Nodes let you send an input into the Flow as though it came from a user. So if the user answers my question with Xbox, I want to send an input to the Flow that says, can I bring my Xbox, as though the user set it themselves. This will trigger my Intent and bring a Slot match with it. In my Think Node I'll put ''can I bring my'' and then I'll add my familiar Token Last Question Results. Let's see how it works.

You can see that the bot responds as expected, and if I look in the Context, it copied the Slots match to the Context. Now I'll ask I need to check if an item is permitted on the plane.

Great, everything is working as expected. So what we learn here is how to store additional data in your Lexicons and how to use that data in our responses to users. I want to implement one more scenario as our final practice exercise and working with the Cognigy Context. Thinking back to our Checked Bags Intent, I want to ask a user a question prior to sharing the baggage fees. I want to ask if there are premium gold member or higher in our frequent flier program. I might do this with a Yes/No question. But what if the user isn't sure. I need to implement logic that accepts yes and no, but also maybe or I'm not sure. So if the user gives something other than a yes or no answer, I'll tell them they can log in to find out. As a reminder, here's how our Checked Bag Flow works.

Is there a fee to check a bag?

But before I tell the user they can check one bag for free. I want to ask if they're a premium gold member. So on this Default branch, I'll ask my question. I'll create a Question Node that says, are you a premium gold member?

If I were to make this a Yes/No question, Cognigy would only accept Yes/No as an answer. So I'll make it a Text question that will accept any response. Under the Question Node, I want to respond differently based on the user's response. How can I detect Yes/No, given that this isn't a Yes/No question? We can look in the Input for clues. I'll just enter yes into the Chat. I'll copy the Cognigy Input to my Path Finder.

If you look a few entries down the outline on the left, you'll see an attribute called Type and the value is pAnswer. That stands for positive answer. Now we'll go back to the chat and try the same thing with No.

When I copy the Input back to the Path Finder, I see the answer is now nAnswer. That stands for negative answer. Finally, if I try the same thing with I'm not sure.

I see the Type is Statement. So let's use this information to respond differently to the user based on what they say. I'll go back to the chart and create a LookUp Node. I'm creating a LookUp Node because there are three possible values: positive answer, negative answer, and something else like a statement.

On my LookUp Node, I'll change it to CognigyScript. For my operator, this is the value I want Cognigy to examine. I'll add the type field. I happen to remember that this is just input.type, but you could also get that from the Path Finder. Just remember to change the x to Input, since we're getting the type value from the Input. In my Case Nodes, I'll make one pAnswer and one nAnswer.

If the user is a premium gold member, I'll tell them they can check a bag for free. So I'll just drag my Say Node under the pAnswer Node. Under the nAnswer Node, I'll add a Say Node that says checked bags are an extra 50 dollars each.

And if they say something other than a positive or negative answer, I'll tell them to please log on to the portal to check your membership status.

Alright, let's give it a try.

Now, let's try again.

That concludes this session. I hope you've learned a few things: One, how to find the Input and Context information in the Interaction Panel. Two, how to interpret the Input and Context with the help of JSON Path Finder, and three, how to use the JSON notation and If, LookUp, and Say Nodes to make more intelligent conversations. If you feel uncertain around how to access values in the Context or the Input, take some time to practice as this is an important skill for building more complex Flows

If we look at the Flow we finished with in the last session and zoom out, you can see that our Flow is growing in size. Even though it's not terribly complex, it's getting big and we've only covered three Intents. If we added just another three Intents here that needed handling in the Flow, Imagine how hard to manage it would become. That's why we recommend breaking conversations down into separate Flows. We want to keep each Flow fairly straightforward to understand. We also want to enable different people to work on a project at the same time and breaking down conversations into separate Flows makes it easier to do. So, I'll create three new Flows: Carry On, Checked Bags, and Permitted Items.

Now that I have my three new Flows, I want to start copying parts of my conversation to those Flows. Let's start with my bag rules Carry On Branch. I'll copy the If and everything underneath it by just right-clicking or control-clicking and selecting cut. I'll switch over to my Carry On Flow and paste. Because I just copied the If structure, I need to go back to my original Flow and copy the remaining Say Node.

I'll go to the end of my Carry On Node and paste it there. I'll repeat this for the Checked Bag Nodes. I need to copy the If and then follow up by copying the LookUp and I'll do the same for Permitted Items. Now, if I go back to my original Flow, it looks much simpler, just a LookUp Node and three Case Nodes. Under each of my Case Nodes, I need to add a Go to Node. A Go to Node does what it sounds like. It tells Cognigy to go to somewhere else. I'll add a Go to Node under my Carry On case. I'll open the Node to edit it and I'll select the Carry On Flow. For the select Node, I'll choose Start. What this means is that I want to transfer the conversation over to the Carry On Flow and start with this Start Node. Let's see how this works.

You'll see that the Intent is detected and it follows the Carry On branch, it hits the Go to Node and then the Flow proceeds in the Carry On Flow. I will add Go to Nodes under my other cases as well, routing them to the Start Node of the expected Flow.

So we've dramatically simplified our main Flow, which is what we want. But we need to look more closely about how the conversation progresses. I will say I need to check if an item is permitted on the plane and then ''Tweezers''. A bot tells me, it doesn't understand me, even though I know tweezers is on the list of items I might pack. The reason for this is that execution is taking place in the Permitted Items Flow and I haven't enabled the Pack Lexicon for that Flow. I'll jump over to the Permitted Items Flow now. I'll click on NLU at the top, then I'll go to attach Lexicon and select Pack. Finally, I'll build the model, and we'll switch back to Chart view. In the Interaction Panel, I'll choose my original Flow as the starting point. I'll try again.

And now it works as expected. If I turn on expert mode, I can see exactly what happened. I asked about Permitted Items and Cognigy determine my Intent. Then I switch the Flow over to the Permitted Items Flow. I said I was concerned about tweezers and it found my Slots match. Now, I'll ask, Is there a fee for checking bags? The bot asks me, which item are you concerned about instead of helping me with my bag fees? The reason for this is that control has switched over to this Permitted Items Flow and it doesn't know anything about the Intents in my main Flow. So what I can do to the very end of my Flow is add a Go to Node that returns me to the main Flow.

It's important that I go to Advanced and select, ''Go to Node and wait for input''. This tells Cognigy to stop executing and wait for an input from the user. If I didn't do this, Cognigy would send an input into the main Flow, which would then trigger the Permitted Items Intent, which would then go back to the main Flow and so on. So we just want to switch back to the main Flow and wait. I'll choose the Flow I want and we can test again.

And now it asks what type of bag I'll be checking. I need to go to each of my other Flows and clean them up. First I'll go to the Carry On Flow. I'll go to NLU and then Attached Lexicons and make sure my Baggage Lexicon is attached and I'll build the model. At the end of my Flow, I'll add a Go to Node to switch back to the original Flow. And now in my checked bags Flow, I'll attach my baggage Lexicon and build.

And then I'll add a Go To Node at the very end.

Let's look at some features of the Go To Node in greater depth. To do so, I need to take a detour and talk about another concept ''Entry Points''. You can think of Entry Points as a marker that indicates where the next input from a user will be processed. By default, the Entry Point is this Start Node. When you begin a conversation, every user input will be processed from the Start Node and onward through the flow chart until the Flow ends or until an Entry Point has been hit. We've been working with one kind of Entry Point extensively: Question Nodes.

When the Flow hits a Question Node, it asks the user the question and then the subsequent input starts from the Question Node. You can think of it as if the Question Node becomes the new Start Node. When the Flow reaches another question, that question becomes the new entry point. We've been working with Question Nodes throughout the training, but I just haven't highlighted that they're Entry Points. Interestingly, other Node types can be turned into Entry Points like Say Nodes. Let's look at an example of this. In my original Flow, I'll add a Say Node on the default branch of the initial LookUp Node. The Flow will reach the default branch if it doesn't match any of the Intent specified in the case Nodes I've created. For my Say Node, I'll just put a message that says ''I can help you with your baggage questions''. The other thing I'll do is go into the styling section and make the label be ''Welcome Message''. You'll see why this is important in a minute.

I will save and if I say hi to my Flow, it will say ''I can help you with your Baggage questions''. Now, I want to turn this Node into an Entry Point. I'll open it back up, and in the vertical ellipsis in the top right corner, I'll select Set Entrypoint. It saves this setting automatically without making you save the Node. So what have we accomplished? I'll show you by going to my Permitted Items Flow. If I go to the very end and open my Go to Node. I can select welcome message as the Node I want to execute. This means that the conversation should go to the input Flow and execute the Welcome Message Node instead of the Start Node.  Remember when I changed the styling option and added a label called Welcome Message? That's the label I see here in the Select Node dropdown list. Let's try it out. I'll start in the input Flow and say, am I allowed to bring my Xbox on board?

You can see that we switched to my Permitted Items Flow and I'll put the flight rules to the user. Then we switch back to the Input Flow and told the user, I can help you with your baggage questions. You'll find Entry Points referenced in other parts of Cognigy. For example, each Intent can have an Intent Entry Point that specifies where in the Flow the user input should be sent if the Intent is matched.

I'll mention a couple of additional settings on Go To Nodes that we won't look at examples now. Parse Intents and Parse Slots give you the option of passing control to the other Flow and re-running the NLP based on the Intents and Attached Lexicon in the target Flow. Absorb Context is useful if you're using the default context feature which we haven't covered yet. I want to introduce one other feature related to simplifying Flows, Attached Flows. Attached Flows are useful when you want to make the Intents in one Flow available in another Flow.

Let's imagine I had a large number of FAQ style Intents, just basic Intents with simple answers, and I want to make them available in every Flow. I could create a separate Flow just for all of these common FAQs and attach them to my other Flows. Let's look at an example. I'll create a new Flow called FAQs.

And I'll upload a set of travel-related FAQs and train.

I'll attach this Flow to my main Flow, and I could attach it to my other Flows as well if I wanted to make the Intents available there. I'll go to NLU, then Attached Flows, and then choose my FAQs Flow. I'll need to train as well after I attach a Flow, as well as when I make any changes to the Intent in the attached Flow.

Now I can talk to my main Flow and ask about what to do if I forgot my ID. You can see that the Default Reply from the Attached Flow is triggered, but I'm still in my main Flow. If I go to the NLU in my main Flow and look at my Attached Flows, you'll see I have an Attach and Sort option. If I click on the Sort option, I can actually sort the order in which my Attached Flows are analyzed. Attached Flows can be helpful for handling these kinds of common questions. Even though I use Default Replies, I could have managed responses in Flows and it would work just as well. The thing to keep in mind with Attached Flows is that when you make changes to the Attached Flows, you need to train all of the Flows to which that Flow is attached. So there's a little more effort in building the model for all of your Flows when you use Attached Flows. Well, we've talked in this session about Go To and Attached Flows. The bigger takeaway is the value of creating Flows that are easy to understand and orchestrating them using Go To and Attached Flows.

Cognigy was built from the ground up to support integrations with external data and applications, and we implement that through Cognigy Extensions, and Service Nodes. In this session, we will focus on a specific Node type, the HTTP Request Node that lets us retrieve data and execute commands in other systems. If you're familiar with the REST APIs and working with tools like Postman, this topic will already be familiar to you, and HTTP Request Nodes will be very intuitive to use. But if the topic is new, get ready to learn how you can make your bots much smarter, much more personalized, and much more helpful to your users.

You can work with HTTP Request Nodes even if you aren't a coder, so don't be intimidated by the topic if you haven't explored it before. Let's take a step back and consider why a bot needs to retrieve external data in the first place. In the examples we've created so far, we're providing useful information to users, but none of it is informed by what we know about the user, and none of it makes changes in any systems that a customer uses. So, for example, when the user asks about bag check feeds, we should be able to look up their ticket and see if they purchased a checked bag or if the user asks about their flight status, we should be able to look up their flight and tell them it's status.

The big picture idea is that we want to help users accomplish end-to-end tasks using chat or voicebots without requiring human involvement. We only bring humans into the conversation when human judgment is required, not for basic data entry tasks. You already have data today in a CRM, an order management system, a medical record system, or in Sharepoint. You can let your users access that data relatively easily in the bots you build. What are the mechanisms for accessing information in other systems? Modern or modernized applications, typically provide REST APIs to facilitate communication with other systems. If you want to learn more background about REST APIs, you can look it up online.

But for purposes of working with Cognigy, you don't even need to know what it stands for. All you need to know is that a REST API is a way that systems expose data and applications or the same protocol used to serve web pages. A REST API may be accessed through a simple request to URL. It may also include JSON data and authentication information. Let's look at an example you can view in your web browser. I'll go here. This is an example service that retrieves data about the users of a system. If you look at the URL, you see something typical, usually the last piece of the URL. In this case, the part that says users, it tells us something about the data or functionality that's being triggered when we open the URL. In your web browser, you see something that should look very familiar at this point ''JSON''. Let's copy it into our JSON Path Finder. You can click the beautify button to format it on the left side. On the right, we can explore the data just like we've done before with the Cognigy Input and Context. I'll click into the data then into one of the numbers. I can keep clicking into these and see that it's a list of users with their email, first name, last name, and avatar. Well, there's more to learn. In a sense that's about it, you enter your URL and you get JSON back. Many applications you use in your day-to-day work already have this mechanism built in. In this case, I just retrieved a list of users.

But what if I want to send a value and retrieve information back based on the value I send? You can do this already with some Web pages using query string parameters. To understand what a query string parameter is, let's look at a normal web page. A normal web page URL may look like this or this. But it can also look like this. If I go to that URL, I can see the search box gets populated with Cognigy. In this case, the end of the URL ''q=cognigy'' is the query string, q stands for query and the query equals Cognigy. Your marketing department may already use query strings in the URLs to add tracking codes, for example. The question mark separates the URL from the query string. The query string is a set of key value pair separated by an ampersand, for example, ''cognigy.com/?a=1&b=2&c=3''.

As you browse the web, you can look for these query string parameters in the URL bar and you'll find them frequently. You can use query strings when requesting data from other systems. If I go back to my previous example, I can use the query string parameter called page-to-page through my results. So if I go to my browser and enter this, with page=2 at the end, I get a different set of results. I can try again. Ok, that's enough theory for the moment, let's see how to apply this in Cognigy. I'll create a new Flow and name it after this lesson ''HTTP Request''.

I'll add an HTTP Request Node after my Start Node. When I open the Node, I'll see two fields: the Request Type and the URL. For now, we'll leave the Request Type as is and paste in our URL. This will retrieve page two of our users. Under storage options, I'll tell Cognigy how to store the result. I'll put it in the Context and add the Context Key, which I'll call users. I'll save and say hi to my bot.

I can see the Flow completed, and now if I look back in the Cognigy Context, I can see that I got some data. This is the same data we looked at earlier in my web browser. Now, let's imagine I want to output the name and other details of the user. First, I'll copy the Context to my JSON Path Finder.

I'll click down to the results until I find the first user, listed under the zero. I'll click on first name, take it to path and I'll copy it. In Cognigy, I'll create a Say Node.

I'll put ''the email for'' and then I'll add my double curly braces and paste my path. I'll change x to contacts since the data was stored in the Cognigy Context. I'll do the same for last name and email.

Note that for every dynamic piece of information, I'm adding my double curly braces and putting the JSON path inside.

Let's test it out. This is a base example of how you can retrieve data and present it to your user. This works great for any unrestricted public source of information, but some of these sources are restricted either for security purposes, as in the case of your CRM, or for tracking purposes, for example, if you're paying for a number of requests that you make. One method that's often available for restricting access to service is the use of Access Keys or Access Tokens. Access Keys are typically a long string of random alphanumeric characters that only you know. I'll make use of the aviation stack site to give you an example of how this works. Aviation stack provides free, real-time flight status and global aviation data. They have paid plans as well for commercial applications, but we can use their free plan for this training. It's fun to use so sign up if you're curious. Once I do sign up, I'm given an Access Key that ties the requests I'm making to my account. The free plan only gives me access to certain features and the Access Key is their way of knowing what I'm allowed to access, and in what volumes. Let's test it out in Cognigy. I open my HTTP Request Node and change my URL. You'll see at the end a query string parameter for my Access Key. I'll paste that in now. You'll see at the end of the URL before the question mark that this request will return information about flights. I want to send my departure city, arrival city, and airline name to narrow down my results.

How do I know these additional query string parameters? They're outlined in the documentation on the aviation stack website. You can see on passing in, SFO as my departure airport and ORD as my arrival airport, and United Airlines as my airline. If you're curious, 'iata'' is just one of the formats for airport codes that we're all familiar with. So dep_iata stands for Departure and the airport code in the iata format. For storage options,  I'll change the Context Key to flights and I'll save. I'll delete my Say Node as we don't need it right now. Now I'll say hi to the Flow. If I look in the Cognigy Context, I'll see my results. I'll copy these over to the JSON Path Finder to take a look. If we drill into the results, you'll see we get a few results back and I can click on them to see the departure details like airport name, the terminal, and the gate number, as well as similar information for the arrival. This is real data that we're accessing that you can use in your chat. If we wanted to output something to the user like their gate number, we would follow the same process we've been doing so far. We can create a Say Node, use the Path Finder to get the path to the information we want to output, and use that path in our Say Node.

What if we want to ask the user for their flight number and provide results based on that? Let's give it a try by first asking the user for their flight number. I'll add a Question Node with a type ''Text'' and ask the user, what is your flight number? I'll save that. Now, I'll modify my HTTP Request Node to pass in the flight number. Based on the aviation stack documentation, I know I need to do this. For the flight number, I want to use whatever the user just typed in. I will use the Last Question Result Tokens. I'll test it out. And in my Cognigy Context, I can see the data I need just for this flight. You can use Tokens or double curly braces in the URL field, just like you can in a Say Node. So you can put the Last Question Result or a Context Value into your query string parameters based on what you already know.

The last thing I want to cover is the topic of verbs. In the HTTP Request Node, we've kept the default HTTP Request Type of GET. There are other verbs you can use, like POST, PUT, and DELETE. We'll look at an example of a POST. The main difference between a GET and a POST conceptually is that a GET typically retrieves data while a POST can update data. But this distinction isn't rigorously followed. Sometimes the POST is used when more complex data needs to be sent that would otherwise create long and complex query strings. But in any case, a POST can have a body, whereas a GET doesn't. Instead of putting all of the request information in the query string, with a POST you can send JSON data. I'll show an example, I'm going to use the user's URL we worked with earlier when we were retrieving user names. I want to use that same URL to create a new user.

Based on the documentation, I know I need to send a JSON structure when I'm making my request. I'll open my HTTP Request Node and change the request type to a POST. I'll paste in my URL. In the Payload section, I'll make sure Payload type is set to JSON and I'll paste the expected format. You can see there are two expected values: a name and a job. For my storage options, I'll change the Context Key to user. Lastly, I'll delete my Question Node, since we don't need it right now, I'll say hi to my Flow to execute it. If I look in the Context, I see a user was created with a new ID and a created date. Now let's imagine I want the user to specify their name. I'll add a Question Node to ask them.

I'll make it a text question and ask, what is your name and save. In my HTTP Request Node instead of putting morpheus, I'll need to add a dynamic value. Between the quotes, I'll add my double curly braces I'll put input.result, which is the same as adding the Last Question Result Token. I'll save and test again. Now, if I look at my Context, I can see a record was created with the name Derek. So, again, we're using what we've learned previously to add dynamic information, this time to a JSON string. There are times when the double curly braces don't work in a JSON string due to JSON formatting rules. Cognigy has a solution for that. It's a little complicated to understand, so I'll cover it at the very end of this video. I'll discuss a few additional topics first

When you open an HTTP Request Node, you'll see a section for authentication. Cognigy provides several built-In authentication options. You can determine which is the right one to use based on the documentation from the service provider. In our aviation stack example, we didn't need to use this because we passed our Access Key in the URL, but that's not always going to work for every service. Under execution and caching, you'll see a couple of options. First, you can execute the request asynchronously. This tells Cognigy whether or not it should wait to get a response before it executes the rest of the Flow. You can also cache the results of your request to improve performance and limit service requests. This could make sense of the information changes slowly, and you don't need up to the moment data.

As you can see, HTTP Request Nodes are powerful. They breathe life into your bot by letting you query and update data based on what the user is shared with you. Instead of just basic question-and-answer scenarios, you can now provide truly dynamic responses. The challenge with HTTP Request Nodes is that they have a technical feel to them. If you're new to the topic, the session may have been hard for you to get through, and for someone even less technical HTTP Request Nodes may not be the right solution. The good news is that Cognigy lets you hide all of the complexity of your requests by using Extensions. Cognigy lets you upload Extensions into the UI and use them the same way you would use built in Nodes. For example, Cognigy has Extensions for Salesforce, ServiceNow, UI path, and other applications. This frees you up from having to search through the documentation from those vendors and gives you prebuilt functionality. If you are a developer or have developers on your team, you can even build your own Extensions to enterprise systems where pre-built Extensions don't yet exist. You can learn more about Extensions in the Help Center.

Our final topic is something I mentioned earlier, adding dynamic values and HTTP Request Nodes when double curly braces won't work. To do this, you need to create a particular JSON structure that Cognigy knows it needs to process. If you search for $cs on the Cognigy documentation site, you can see the structure. I'll use it to pass the name of the new user to the user service. This will have the same outcome as we achieved earlier with a double curly braces. It's just a different way to do it. In my HTTP Request Node, I'll paste the following instead of the name attribute. If we break this down one piece at a time, you'll see I have name, which is the same attribute we had earlier, just like we have job below it. Then we put $cs which tells Cognigy it needs to process the following information. For script, I'll put the dynamic value, the same one we had earlier input.result. For Type, I'll put string, that's just a special keyword, that means a string of characters. I'll save and test.

If I go to the Context, I can see the same result I got earlier. If this sounds a little complicated, don't worry about it too much. If you need this feature, you can always look it up in the documentation and then just watch this part of the video again. This concludes our lesson on HTTP Request Nodes. I hope you can see the power of this Node type and you start exploring data sources that are available to you within your organization. Note that your internal APIs for your CRM, your ERP, or other enterprise systems may have additional security requirements. For example, you might need to whitelist the IP address of your Cognigy installation in order for the Cognigy server to communicate with the target system. If you aren't getting the responses to your HTTP Request that you expect, check with your IT team to see if there are security requirements you need to review.

In this brief session, we'll talk about Slot Fillers. Slot Fillers are a feature of Cognigy that makes it easy to create conversations with your users that feel more natural. Here's the general scenario, in human-to-human interaction I might share multiple pieces of information in one sentence where I might share a little bit at a time based on a dialog. So if I call a contact center to ask about the status of my flight, I could say I'm flying from San Francisco at 08:30 on United. But I could also say I'm flying from San Francisco on United and the Agent would say, what time is your flight? and I would say 08:30. This conversation could happen in a number of different ways where I could provide all, some, or none of the needed details initially and then provide the missing information as the dialog continues.

Let's imagine the bot can't handle this intelligently, I could say I'm flying from San Francisco on 08:30 on United and the bot could recognize my Intent. But if the next thing the bot says is what city are you departing from, the user would have to repeat the information that they just said and it wouldn't feel efficient or intelligent. One way to address this scenario in Cognigy is Slot Fillers. Slot Fillers monitor every user input in the conversation to see if their is specific Slot matches. If there are, it copies them to the context. In our Question Node, we tell Cognigy to skip the question if it exists in the context. So we're only asking the questions that we don't have answers to. It's easiest to explain by showing you an example. The ingredients we need for Slot Fillers are a Lexicon or two, Slot Fillers, and Question Nodes. I'll create a new Flow called Slot Fillers.

I'll go to the NLU tab and first go to attach Lexicons. I want to attach my airport and airline Lexicons. Now I'll go to the Slot Fillers subtab. I'll create a new Slot Fillers called Airline. This will tell Cognigy to keep an eye out for airlines in user inputs. For Type, I'll choose Slot, for the Slots name I'll put airline, and for the Context Key, I'll put airline. To break this down, it means that Cognigy will look for a Slot match for an airline. The Slot name is the Slot name that we associate with the key phrase in the Lexicon. When Cognigy sees a Slot match, it will copy the match into the context, the Context Key is the name the Cognigy will use to store the copied Slot. I'll create another Slot Fillers for airports, I'll make it a Slot Type again and use airport_code for the Slot name and the Context Key. I'll build the model and then switch over to the Chart view.

I'll create two questions: The first will be, what is your departure airport and the second will be what is your airline?

For my ''what is your airport question?'' I'll make it a Slot Question Type and use the airport_code Slot name.

Under Context, I'll add my airport_code Context Key exactly as I put it in the Slot Filler.

And I'll enable Skip if answer exists in Context. I'll save and repeat for the ''what is your airline question''?

Now we can test it out. I'll start by saying, I'm leaving San Francisco on United. The Flow completes without asking me any questions. Now I'll clear the Chat then say I'm flying on United.

It asks, what is my airport and I'll say SFO, and it skips the airline question. Similarly, I can clear the Chat then say I'm departing SFO and it will ask, what is your airline?

Slot Fillers are a great way to make your conversations feel more natural and to respect your user's time. They allow you to skip questions that users have already answered. Are there any scenarios where Slot Fillers might not be a good or complete solution? Slot Fillers work best when every question has a different Slot match? That's the example we've seen in this session. We're looking for an airline Slot match and an airport code Slot match. A similar example could be buying movie tickets.

I need six tickets for Star Wars on Thursday. There is a Number Slot ''Six'', a Movie Slot ''Star Wars'', and a Date Slot ''Thursday''. But Slot Fillers are an incomplete solution if you need multiple matches for the same Slot. In the airline scenario, for example, what if I wanted to say I'm flying from SFO to ORD on United. I could create an airline Slot Filler as we did in our example, and that would still work fine. But what if I create two Slot Fillers: one for the departure airport and one for the arrival airport. Let's do it and see where it takes us. I will rename my airport Slot Filler to ''Departure Airport''.

I'll change the Context Key to departure_city and I'll save. I'll create another Slot Filler called ''Arrival Airport''. I'll again choose the airport_code Slot name and make the Context Key arrival_city.

So now I have three Slot Fillers, Arrival Airport, Airline, and Departure Airport. Let's see how this plays out in my Flow. I'll switch to the Chart view and change my first question to ask, what is your departure city?

For the Context Key, I'll match my Slot Filler departure_city and I'll select Skip if the answer exists in context. I'll add a new question that asks, What is your arrival city?

I'll make it a Slot question, looking for the airport_code Slot name. I'll store the result in the context and use arrival_city as my Context Key. And I'll skip if answer is in the context. Ok, let's start by saying Hi. I will say my departure city is SFO, It skips asking me about my arrival city and jumps to the airline question. I'll try again and say ''I'm flying to SFO on United''. And it doesn't ask me anything.

This is actually expected behavior because both Slot Fillers are looking for the same Slot type airport_code. They both get filled immediately when I mentioned SFO. There isn't a way with Slot Fillers to specify that I need two separate matches of the same kind of Slot. For this scenario, you could still use an airline Slot Fillers, but it wouldn't be a good solution to use Slot Fillers for the departure and arrival airports. I hope you find Slot Fillers helpful and you have a better understanding of how to create conversations that flow naturally.

Cognigy provides the ability to localize Flows using Locales. In this short video, I'll talk about the purpose of Locales, how they work and when they're a good fit for your Localization needs. The most straightforward reason to use Locales is when you need to translate your Flows. Imagine you have a customer base, some of whom speak English, some who speak Spanish, and some who speak Chinese. We'll focus on this scenario and then discuss other scenarios towards the end of the video. To localize my Flows the first thing I'll do is go to the left bar and look under Manage then Localization. On this screen, I can view the Locales that have already been created. By default, we start with en-US as the primary Locale. That's because I chose that language when I first created the Agent. I'll create a new Locale and give it a name, in this case Spanish, and choose Spanish for my NLU language. I can also use a Fallback Locale. We only have one other Locale in this case, so we'll keep it as English.

The Fallback Locale is used if there isn't any content configured for the current Locale. So if Cognigy hits a Node that hasn't been translated, it uses the content from the Fallback Locale instead. I'll save and now I have my new Locale. I'll go back to the Input Flow we created several lessons ago. Now at the top of the screen, I have a dropdown that lets me choose Locales. I'll choose Spanish. You'll see that all of my Nodes turn gray. That indicates that they haven't yet been translated. I will click on the welcome message. In the Editor panel, I see an add Localization button and I can see that the current Fallback Locale is U.S. English.

I can click Add Localization and I have the option to either copy from another Locale or start from scratch. I'll choose add empty Localization and for the text output the following.

To test it out, open the Interaction Panel and now you'll see a drop-down at the top called Locale.

If say Hi to my bot, it will respond in Spanish. I can continue to translate the rest of the Flow so the bot can speak to users in their native language. Note that so far I've been talking about what the bot says to a user, but how can the bot understand a Spanish speaking user when I've just created English language Intents? If I click on the NLU tab and choose my Carry-On Intent, you see I have the ability to add a Localization. I'll add an empty Localization and can start adding example sentences in Spanish.

Note that any Intent that hasn't been Localized is disabled as Cognigy won't be able to detect the Intent without example sentences. I can specify which Locale to use for a conversation in my Endpoint. In the left bar, I'll go to Deploy-Endpoints and open my Web Endpoint. In my Endpoint configuration, I can choose Spanish. I'll change the Flow to my input Flow. I'll save and open the Webchat. And you can see it starts talking to me in Spanish.

What if I want to change from one language to another? For example, the Locale for my Endpoint is English, but I want to change to Spanish if that's the user's preference in a CRM record or if they explicitly choose an option on the website or the Chat window. For this, we have a Switch Locale Node. I'll go back to my Input Flow and just for demonstration purposes, I'll add a Switch Locale Node under my welcome message.

I'll switch the Locale to Spanish and save. I can test by saying Hi in my Interaction Panel with en-US selected. It gives me a response in English. If I say Hi again, it gives me the response in Spanish. Locales are a great feature in Cognigy for providing conversations in your customers preferred language.

But before we end the video, let's tackle some alternative approaches. First off, many people ask ''Can Cognigy translate my Flows automatically?''. The answer is yes. Cognigy provides a Translation Transformer that can dynamically translate Inputs and Outputs to the user's language of choice. Second, it's good to consider whether translation is sufficient. For example, your products or services may differ substantially from one region to another. There could be different business processes or culturally unique ways of talking about things that aren't addressed by translating the same Flow to another language. You might need a combination of translated Flows and language-specific Flows. The latter being Flows that are designed to reflect the business processes for a specific region.

As you build your Agents in Cognigy, you'll find a need for two features for managing your work. First, you may want a versioning feature so you can preserve your Agent at a particular point in time, such as prior to a release. Second, if you have multiple environments, for example, a test environment and a production environment, you need a way to move your Agent from one environment to another. Cognigy addresses both of these needs with Snapshots.

A Snapshot is a copy of Agent resources at a specific moment in time. Cognigy copies Flows, Lexicons, Playbooks, and more to capture a freeze frame of the Agent. The Snapshot includes all of your Agent resources except Endpoints, Intent Trainer records, Analytics data,  Contact Profiles, and other Snapshots. To create a Snapshot, go to the left bar and click on Deploy- Snapshots. Click new Snapshots to create a new Snapshot, and enter a name.

You can optionally enter a description, Cognigy will start creating the Snapshot in the background. You can monitor the progress of your Snapshot by clicking the activity monitor in the top right corner.

Let's imagine we are currently live with our bot and we want to make some changes.

I'll go to my Input Flow and change the welcome message.

I will say that we can handle baggage questions or flight status questions.

I'll test the bot by opening the Interaction Panel and saying Hi.

And I can see the new message, but I can also compare this to my Snapshot. In the drop-down at the top of the Interaction Panel, I'll choose the Snapshot I just created and I'll test again.

Now I see the previous welcome message that was part of the Snapshot I created. You can also run Playbooks using different Snapshots. So I can verify a Playbook worked against one Snapshot, and then compare it to my current work in progress. I can also use Snapshots in my Endpoints. If I go to Deploy-Endpoints and click on my Web Endpoint, you'll see the first dropdown is a Snapshot.

If I have no Snapshots selected, Cognigy will use the current state of the Agent. But if I choose a Snapshot, the Endpoint will execute against the version of the Agent that existed when I created the Snapshot. A practical application of this is if you're live, Endpoint is using a Snapshot. This allows you to make changes to your Flow without affecting the version of your Agent that's in production. What if you want to move in Agent from one environment to another, or if you just want to make a copy of an Agent within a single environment.

To do this, you need to prepare and download your Snapshot and then upload and restore it. Let's go back to Deploy-Snapshots to take a look at how this works. Next to the Snapshot I created, you'll see a vertical ellipsis. Choose prepare download from the list. Cognigy will start preparing the download in the background. Once the Snapshot is already for download, you'll see a download icon next to it. I'll download it now. You'll have a file that ends with ''csnap'', which stands for Cognigy Snapshot. Now, let's imagine we're logging into our production system to enable the Snapshot. I'll just back out to the main Cognigy dashboard and create a new Agent, I'll call it production.

Now, I'll go to Deploy-Snapshots and I'll click on the upload icon in the top right corner. I'll upload the Snapshot I just created.

To go live with this Snapshot, I can go to deploy Endpoints and create a new Endpoint. I'll just create a Webchat Endpoint and call it Web. I'll choose the Snapshot and the Flow and save.

And now I've made this Snapshot available. As a reminder, if I upload a new Snapshot to the same Agent, it won't overwrite my Endpoints. So you can feel safe uploading Snapshots, knowing that it won't affect your live Endpoints. What if I want to make changes in my Flows? For example, after I've uploaded a Snapshot. I'll go to Build-Flows and see I don't have any Flows. Why is that? The Snapshot is, as it sounds, a static picture of a moment in time. If I want to make changes, I need to restore the Snapshot to create a new work in progress. I'll go to Deploy-Snapshots again. On the vertical ellipsis next to the Snapshot, I'll choose Restore. Because this will overwrite my current work in progress, Cognigy asks me to confirm that I'm ready to restore the Snapshot. Before you restore a Snapshot, be sure to create a Snapshot of the current work in progress, If you don't want to lose it. Restoring a Snapshot will overwrite everything except Endpoints, Snapshots, Analytics, and Contact Profiles with a Snapshot content. When Cognigy finished restoring the Snapshot, I can go back to Build-Flows and see my Flows are there, as are my Lexicons and other project resources.

As you build your Flows, you do a lot of testing to make sure everything is working right. For long conversations, this can get tedious. For example, if you ask the user a series of 10 questions and you're having an issue with the ninth question, it can be laborious to have to answer the first eight questions before you really get to the problem you're trying to solve. You also need to test your Flows over time. What if you make a change to a Flow that you built a month ago? It would be nice to have a way to make sure that your changes aren't breaking any of the existing functionality. We address this in Cognigy with Playbooks. Playbooks let you replay conversations. The easiest way to create a Playbook is in the Interaction Panel. I'll have a conversation with my input Flow. This tests all of the paths I've built for this Flow.

To turn it into a Playbook, I'll click the vertical ellipsis in the top right of the Interaction Panel and choose create Playbook. This opens the Playbook Editor. On the left, I can see all of the inputs from the Interaction Panel. To test it out, I'll go to the Interaction Panel and click on the Settings tab. At the very bottom, I'll choose Playbook as my Input mode. Now, if I go back to the Chat view, I see a drop-down menu instead of my normal input field, I'll select the new Playbook I created and click the play button to play it. As you can see, it quickly runs through the entire Flow. For testing the Flow as I build this can be a big time saver. I don't have to run through full conversations just to get to the part I'm working on.

What we've done so far plays through all of the inputs, but it doesn't verify that I'm getting the expected output. So, for example, when I say, can I bring my messenger bag in the main cabin, I want to make sure Cognigy recognizes messenger bag as a Slot match. To do this, I can click on the step and I see a new editing pane and a button that says Add Assertion. I'll click, Add Assertion and make it a Slot assertion. The term Assertion just means that Cognigy will test to see if an expected value is present as it runs through the Playbook. I will enter the Slot name I'm expecting ''bag_type''.

In this UI, I don't have a save button. Cognigy will save for me automatically when I leave the field. I'll add another Assertion to make sure I have the right Intent. I'll add an Intent Assertion and add the Intent name ''Baggage Rules-Carry On''. Now, I'll run through the Playbook again, and I can see that after I asked about my messenger bag, the Assert was successful.

At the very bottom of the Interaction Panel, I can see that there were two Assertions and both succeeded. I can add Assertions for Intent matches, Context values, Slot matches, and even just the message text I'm expecting. So, you can see what a failed Assertion looks like. I'll change my Intent assertion to referenced Checked Bags.

This Assertion failed because it didn't match the checked bag's Intent. If I mouse over the field Assert Intent, I can see the expected value versus the actual value. Playbooks can be very helpful once your Flows are in a release state. You can create a Playbook and use it again as you make changes to your Flows in the future. Playbooks save you time during development and bring you peace of mind as your Flows evolve over time.

In this session, we'll talk about Cognigy's mechanism for storing information across the user's lifetime of interactions with Cognigy. We do this with Cognigy Contact Profiles. We've learned about the Input, data that's available for a single user input, and we've talked about the Context, data that's available for a single conversation. Now we'll talk about Profiles, data that's persisted across every session for a specific user.

Let's discuss some distinctions around Profiles and how you can use them. In the standard configuration, Cognigy can store user profile information like first name, last name, email, age, and location. This can be useful, for example, if you want to greet the user by name when they return to a conversation like ''Welcome back Derek''. It can also help us avoid asking the user for information they already provided in a previous conversation. You will likely already have a source of information for user profile data, your CRM or HR system, for example. Cognigy isn't replacing profile information in those systems. Your conversations should retrieve data from them to make conversations more personalized. But Profiles provide a good holding place for conversational information that can be accessed quickly and may not be relevant to your systems of record. In addition to personalized greetings, you may want to remember things about the last conversation, like a support ticket the user asked about, a booking the user was interested in, or a flight number they were checking on. You may need to give some thought to what data you're collecting and whether or not you need the user's consent for certain kinds of data. I'll discuss this towards the end of the video.

Cognigy provides two user interfaces for viewing Contact Profile data. The most detailed view is in the left bar under Manage Contact Profiles. In this view, you'll see a list of contact IDs with their first name, last name, and email address. Under contact IDs, you may see many entries that are long strings of random numbers, and you might see many entries that don't have a first name, last name, or email. That's because our Flows so far haven't collected this information from users and we've been having conversations with unauthenticated users. Let's click on one of these records to see more information. In the Contact Profile details, I see all of the available data for a user, including their conversation history. If I click on a conversation, I see the full dialog that took place during the conversation. In actual practice, you may not go down to this individual conversation level, but it can be helpful to see examples of actual conversations with users and for giving more context for troubleshooting. On the Contact Profiles landing screen, there's a button that says Edit Schema. The Schema is a term for the data elements, Cognigy tracks in the Contact Profile. The out-of-the-box elements like first name and last name can't be altered. You can add your own Schema values. For example, if I wanted to persist the last flight number the user asked about in the user's contact profile, I could click, add and Cognigy creates a new field. I can click on that field to edit it. I'll update the field name to be Flight Number and I'll make the internal name flight_number

The field name is the user-friendly name that will be displayed in most places. The internal name is a name you can use when referencing the field in CognigyScript fields, for example. We'll look at an example of this shortly. I'll leave the Type as Text. There are several options for Types, including Number, Yes/No, and Complex. The number is, as it sounds a number, Yes/No, will store a true or false value, and Complex allows you to store JSON value. Essentially any arbitrary JSON structure you want. I'll make flight number a Text type and save. Now let's work with our profiles in a Flow. I'll create a new Flow called Profiles.

I'll open the Interaction Panel and say hi. I mentioned earlier that Cognigy provides two user interfaces for reviewing Contact Profiles. The second one is here in the Interaction Panel. If I click on the Info tab and then profiles, I see profile data for the user interacting with the Flow. In this case, it's just me interacting with the Interaction Panel. You can see the data is in our familiar JSON format. You can access this data similar to how we've done with the Cognigy Context. As an example, I'll create a Say Node that outputs my name.

In the Text field, I can use my first name Token, so I'll say ''Hello First Name'' Now, if I say Hi, it will greet me.

Note that if I want to use double curly braces, I could have done that as well. I'll open my Say Node and replace my Token with a double curly braces and use profile.firstname.

If you look back at the Cognigy profile, you'll only see values for the fields where I actually have data. So we don't see last name, for example, because I haven't told the bot my last name yet. How can we update profile values? Cognigy provides several Node types for managing profiles. We'll look at the Update Profile Node now. In the Update Profile Node, I have two simple fields, one for the Schema Field I want to update and the other for the Value I want to put there. So I'll select last name and make the Value be my last name ''Roberti''.

I will say hi to my Flow. Now if I look at my profile, I see I have a last name. I can also update this based on user input, so I'll put a Question Node. that says, what is your first name?

And I'll make the Question Type be Text and I'll save.

In my Update Profile Node, I'll make the value be Last Question Result. I'll also change the schema field to first name and I'll save. And I'll try it out.

Now, if I check my first name, it's Phil. We can make this even easier by saving the answer to our question in the profile automatically. I'll delete my Updated Profile Node, then I'll open my Question Node. Under Profile Storage, I'll select Write Result to Contact Profile and I'll choose firstname as my profile key and I'll save. Now, when I test it out, I can see the profile is updated automatically.

Before I end this session, I want to mention Cognigy's ability to comply with data protection standards. Cognigy helps maintain user privacy by allowing the export of Contact Profiles via the user interface and API, the deletion of Contact Profiles, and the turning off of data collection for individual profiles and Endpoints.

You can also prevent profile information from being stored entirely. If I go to Deploy-Endpoints, I open my Web Endpoint. In the data management section, I see a toggle for Contact Profiles. Turning off Contact profiles disable this feature for all interactions that start on this Endpoint.

So far, we've primarily been previewing our chats in the Interaction Panel, but what does this look like on a website? To make your chatbot available through a digital or voice channel, you need to create an Endpoint. For this training, we will talk about the Webchat Endpoint. The Webchat is an out-of-the-box interface that Cognigy provides, that makes it easy to expose your Flows in a web browser. To create an Endpoint go to the left bar and find Deploy then Endpoints. Click New Endpoint to create a new Endpoint, name it Web and choose the Flow we've been working on so far. For the Endpoint type, you'll see a lot of different options, but we'll just choose  Webchat for now.

To immediately preview your Endpoint, click open Webchat in the top right corner and say ''Hi'' to get started. This will largely look like the Interaction Panel with just a couple of exceptions. First, any HTML you've entered, like when we created links, will be rendered here in the Webchat. In the Interaction Panel, you'll just see the raw HTML. You won't see any of the feedback about Intents and Slots, that's part of Expert Mode in the Interaction Panel. And you won't see those cIntent payloads that trigger specific Intents. But most everything will look similar. You can take the URL for the Webchat and preview it on your phone as well. You can also send around this preview link to your colleagues to view your work in progress version of the Webchat. Let's take a look at some of the configuration settings that let us control the look of the Webchat.

Take a look at the Webchat configuration that first option allows you to either center the Webchat or to display it in the traditional lower right corner. I'll change it to ''No'' so we can see what that looks like. I can also change the color scheme for the Webchat. I'll add a title ''Cognigy Training''. Lastly, I will scroll to the bottom to add a background image.

Let's preview, you'll see our background image, the color scheme, and the title bar at the top.

We can also change the behavior of how the chatbot starts. I'll change the start behavior to ''Auto Send a Message to the Bot'', for the payload I will put ''High'' and for the display text, I will say ''Ready for lift-off''. The payload is a message actually sent to the bot, and the display text is what actually appears in the Webchat. Let's check it out. When I click on the button, I see ''Ready for lift-off'' message has already been sent and the output of my Once Node is displayed. If I choose Start with a Button the Webchat displays a button rather than automatically sending a message. I'll save and preview.

Now you can see they're ready for lift-off button. When I click it, Cognigy will send the payload that I specified in the configuration options. There are a number of additional configuration options in the Webchat configuration section, but there's even more, you can configure when you actually embed the Webchat on the website. See Cognigy documentation on embedding the Webchat for more information on showing engagement messages and many other features. You can also customize anything about the appearance of the Webchat from colors to font sizes and much more. This is covered in the documentation of our Webchat widget. To actually add the widget to your website or internet, you'll need to work with a team that manages those sites to add some embed code, a few lines of JavaScript to your website. There's a lot more to say about Endpoints, but this gives you enough to be able to preview your chatbot and share it with others.

CognigyScript is a fun and powerful feature that allows developers to add Typescript or JavaScript to their Flows. CognigyScript isn't a language onto itself, it adds Cognigy specific objects to standard Typescript or JavaScript. This video is the first video in our training series to require a developer skillset. I'll assume that you're comfortable working in a code editor and working with JavaScript and object-oriented syntax. We won't spend much time in this video actually writing code together. There will be code samples provided to accompany this video and you'll find more in the Cognigy documentation and GitHub. What I'll focus on is where you can use CognigyScript and common use cases for it. We've seen CognigyScript already, even though we haven't written any logic, we've used CognigyScript to reference objects like the Input, Context, and Profile objects. Anywhere we've entered double curly braces, we've been using CognigyScript. CognigyScript permeates the product and can be used almost anywhere. Let's look at a few examples. I'll create a new Flow and I'll create a Say Node.

I'll greet the user and either say good morning or good evening, depending on the time of day. Note that CognigyScript in Node argument is always returned as a string, unless you force the type to be preserved. You can do this by appending preserve type to your script. In this case, it just means that the code executed with the curly braces will return a string.

We can also add CognigyScript to Galleries and Quick Replies. I'll create a Gallery that shows one card if it's before noon and another if it's afternoon.

Note that I'm using ''ci'' here instead of input. Prior to the session, we've used Input, Context, and Profile to reference values in those data stores. We can do the exact same thing with ci, cc, and cp respectively. It does the same thing, but with fewer keystrokes.

The nice thing about CognigyScript is that it gets you complete flexibility in how you converse with your users, but it has a side effect of putting code into a low code platform in a way that won't make sense to non-developers. One way to deal with packaging up your code in a user-friendly fashion is Cognigy Extensions. We won't cover that in this session, but I encourage you to review the documentation in our Help Center. A convenient way to do this on a small scale is with Tokens. Tokens are small snippets of CognigyScript that can be made available in a user-friendly way to non-technical Flow Developers. We've actually been using Tokens throughout the course, things like Last Question Result or for Slots match are built-in Tokens and you can create your own. Let's do that. We can take our greeting as an example. It's complicated for a non-technical user to understand the CognigyScript, but it's something they might want to use in different Flows. To create a Token, go to the left bar and select, Manage, and Tokens. Click, create new Tokens and name it Greeting.

In the script field, we'll put some CognigyScript. For the type this just indicates where it will be grouped in the Tokens dropdown list, I'll choose Custom. Tokens are a great fit for adding dynamic content where the logic won't change much over time. If you think about the Last Question Result Token, that's referencing the Cognigy input and it's a built in feature of the platform so it's a great use for Tokens. The reason I highlight this is that the Tokens value is copied to the field where it's inserted. This happens when you save the Node where the Tokens is used. You can't make subsequent updates to Tokens, you can only delete them. If you do delete a Token, changes won't be made to the Nodes where you've already used the Token.

What if it would be really helpful to have a Token, but you also want to make some changes to it over time. An option would be to keep the logic and the Token, but the data outside of the Token. For example, if you recall in a previous session, we worked with a Lexicon of items that you can or can't bring on an aircraft. I added data to the Lexicon to indicate whether you could bring the item on board and added additional information if one was required. Let's make a Token for our Flow developers that let them add this logic to a Flow. If there is a Slot match for the item the user wants to pack, we will output the message like we did in the previous session. If there isn't a Slot match, we'll output a message asking the user what they want to pack. The catch is that this message might change over time. In the summer we might give users ideas for items like sunglasses and sandals, and in the winter we might ask users to think about packing skis and gloves. Here's what we can do. We can store the message in the Default Context, a topic we haven't covered yet. The Default Context is a set of context values that are available automatically when a conversation is started. In other words, they let you pre-populate the context. You can access Default Context values like any other context value. To find the Default Context, go to the top of the Flow Editor and select Settings, then click on the Default Context subtab. I'll add a message to the Default Context.

And save. Now, I'll create a Token by going to the left bar and selecting Manage, then Tokens.

For my Tokens, I'll enter the following as my script. I'm just checking to see if there's a Slots match and if so, outputting the explanation. If not, I'll output the missing Slots message. I will save it as a Custom type and I'll save. Now, I'll return to my Flow, I'll delete our work so far so we can start with a clean slate.

I'll create a Say Node and add my Packing Token.

The last thing I need to do is attach my Pack Lexicon to this Flow and Build.

Now we can test it out. I'll first, just say hi, that outputs the missing Slots message.

And it outputs the explanation.

If I wanted to change the missing Slot message, I can do that at any time by changing the Default Context.

This is an interesting approach, but is it a good idea? If there is fairly consistent logic that you want to put in the hands of a Flow developer, even yourself, using Tokens this could be a good idea. It lets you package up some logic while letting you manage any changing data. As I mentioned earlier, the only shortcoming of any Tokens is that it can only be deleted, not updated. Let's change topics and talk about If Nodes. In If Nodes, I can use CognigyScript to create more complex conditions than the rule builder can handle. Let's tackle something we've seen throughout the training, Cognigy recognizing certain English language words such as the, but, can, art, ask, ash, and fly? I have attached my Airport Lexicon and Build and we can try it out.

I'll delete the Nodes we've created so far. What if the conversation went like this? The bot asks, what is your destination airport, and the user says, can I ask if the airline will fly to SFO?

Cognigy finds five Slot matches, and there aren't any obvious rules that would tell us which one is the destination airport. One way to address this is to flag the ambiguous airports in the Lexicon. I'll open the Airport's Lexicon. I'll search for Can, CAN. I will click the down arrow on the right side and I'll add ambiguous: true.

Now, I'll go back to my Flow. Since I changed my Lexicon, I need to go to the NLU tab, then click Build Model. I'll go to my Chart and add a Question Node.. I'll open it and ask, what is your destination airport? I'll make it a Slot question and enter airport code as my Slot match. And I'll save. Now, I'll add an If Node, I'll open it and check for two things. First, I want to see if there are multiple Slot matches. This would be true if the user mentions an ambiguous word along with a valid airport code. Second, even if there is one Slot match, I want to see if it's an ambiguous one, and if so, confirm with the user. I'll click on Use Advanced Editor and I'll add the following condition.

In my Then branch, I'll add a Say Node and make it say ''Ambiguous''.

On the Else branch; I'll add a Say Node and make it say ''Not ambiguous''. Now, let's test out a few scenarios, first, the happy path.

Now with multiple Slot matches.

And now with an ambiguous Slot match.

In general, you can include CognigyScript anywhere you find a text or data field in Cognigy. In prior sessions, for example, we've looked at other places you can include CognigyScript, such as HTTP Request Nodes. For more complex logic, we will introduce a new Node type ''The Code Node''. Code Nodes are exactly what they sound like. They enable a Flow creator to execute custom JavaScript or Typescript code within the Flow. The code editor has full IntelliSense and exposes all Cognigy objects and actions. The execution of the Code Node is synchronous. The Flow will continue after the Code Node has finished executing. Just as within other Nodes, Input, Context; and Profile can be accessed and modified within Code Nodes.

When I open a Code Node, I get an Editor. It's helpful to expand the edit panel to give yourself more room to type. The actions object provides access to most internal Node functions within the Code Node. Actions expose static methods like output, add to context, think and update profile. Note that Code Nodes don't support imports, you're limited to what's available by default in JavaScript or TypeScript. Cognigy does include several libraries, the MomentJS module for parsing, validating, manipulating, and displaying dates. The Lodash library for working with arrays, the Facebook bot messenger module for building Facebook templates, and the XML to JS Library for parsing XML data.

As developers, when we discover Code Nodes, our inclination is to think, great, I'll do everything in Code Nodes. Code Nodes are powerful, flexible, and require less clicking, so why not. The balance we need to strike as developers is between the efficiency of writing code and the transparency of the graphical editor. If there are non-coders who will be maintaining Flows, we should limit Code Nodes to executing more complex logic while using the other Node types for what they're designed for. So a non-coder shouldn't have to open a Code Node to make changes to an action ''start output method'', for example. They should be able to do that in a Say Node. The same is true for basic branching with LookUp Nodes, and If Node.

I recommend Code Nodes for situations where you need to dynamically generate Text Replies, Quick Replies, or Galleries, process the results of responses, search the context or parse dates. These are things that aren't easily achieved in other Flow Nodes but are easy to do in code. Let's look at an example that combines a number of these. We will request flight data from aviation stack, as we did in a previous session. When we get the results back, we'll check for flights that haven't landed yet and output Quick Replies to let a user choose to see detail on a specific flight. To get it started we will work with a simple Flow I've built. Think of it as an excerpt from a conversation with the user checking on the status of their flight.

To simplify the Flow, I'm using a Cognigy Extensions. The first Node, Fill Aviation Slots handles the different ways a user might ask about their flight status. So they could say, I'm traveling from SFO to ORD, or I'm traveling to ORD from SFO or I'm leaving SFO and arriving in ORD or any number of other permutations. Then there is a Question Node that asks what airline the user is flying on. I have it set to ''Skip if answer exists in Context''. In my example, the answer will exist in the context because I've already created an Airline Slot Filler. I have a Say Node that just confirms the user's choices and finally, I have another Extension Node that retrieves all flights today on the user's preferred airline departing from the departure city and arriving in the arrival city. This data comes directly from aviation stack. I'll test it out by saying I'm traveling from SFO to LAX on United.

The Flow executes and I get some data back in the Cognigy Context. I'll copy this over to JSON Path Finder and take a look. If I expand schedule then data, you'll see I get eight results. I'll open the results and see that there's a flight status field, some of the flight status field say scheduled and others say landed. For the ones that are still scheduled, I want to give the user the option to get more details about the flight. Step one will be to get all of the flights that are in the scheduled state. To do this, I'll use the built in Lodash library. I don't have to do it this way. You can use your preferred approach in JavaScript or TypeScript, but Lodash can be a fun and efficient way to work with arrays.

The filter method returns all of the flights with the scheduled flight status.

I want to dynamically generate Quick Replies for each flight with a payload that is the flight number. I could do this by creating an object that follows the format required for the out-of-the-box Webchat client, but again, for fun, let's use another built in library, the Facebook bot messenger. I'll use the message builder to create the message for my default channel so we can see it in the Webchat.

Let's test it out.

We can see it outputs the Quick Replies. I want the user to be able to click on the Quick Replies and get the flight details and the easiest way to do this would be through a Question Node. But I can't create a Question Node using the API and a Code Node. So I'll just add a Wait for Input Node underneath my Code Node. When the user clicks on a flight, I'll look it up and output the flight details. I'll create a Code Node underneath my Wait for Input Node. I'll open my Code Node and the first thing I'll do is search for a result. I'll use the low dash library again.

Now I want to display the flight detail using the adaptive card plug-in, this gives the user a nice visual output, which we'll see in a minute. The plug-in expects an object that describes all of the formatting and data needed for the card. I'll just paste it in.

I've used my flight detail object to populate values within the card. Let's take a look. I'll go to the left bar and find Deploy, then Endpoints. I will select my Web Endpoint and open the Webchat.

I will say I'm traveling from SFO to LAX on United.

And then I'll click on the flight and I get this nicely formatted card. One shortcoming of the card is that the departure and arrival dates aren't in a user-friendly format. I really just want the time. So let's go back to my Code Node. I'll use another built in library moment.js to format my date. Again you can use standard JavaScript or TypeScript to accomplish the same thing, but if you haven't used moment.js before, it's fun to check out. I'll add some code to change my departure and arrival times. I'll save, now let's go back to my Webchat and test again. I will say I'm traveling from SFO to LAX on United. And then I'll click on a flight.

And now I see the times in the format I want. As a whole, this is a good example of when to use Code Nodes. There's really no way to accomplish what we've just done using a Flow and the logic is too complicated for a non-technical user. So we can solve the problem in Code Nodes without guilt. I recommend adding labels or comments to your Code Nodes. So for example, in my final Code Node, I'll open it under styling I'll put adaptive card. And for my comment, I'll put ''Looks up Selected Flight and Output's adaptive card object''. As a final Node on this example, in real life, I'd want to do some checking to make sure I get results back from the initial query to make sure there are intact scheduled flights and to make sure the flights that the user selected is on the list of scheduled flights. So standard checks that we haven't done here for the sake of expediency. I hope you appreciate the power of Code Nodes and enjoy using them. If you start putting a lot of logic into a single Code Node, consider creating a Cognigy Extension. You can learn about Extensions in Cognigy's Help Center.