 Requesting a service with the out-of-the-box BMC chatbot, such as a PTO request, time off, is pretty straightforward. But what if you would like the conversation to take a different flow based on other information like your accruals? The customer would also like to keep track of PTO requests and do additional workflows around those. For example, Dave Matthews logs in and in another system, which is based in JIRA, he has accruals tracked for three days. So when he says, I would like to take a vacation or some time off, immediately it will tell him it looks like you have three days accrued. If you request more paid leave on that, your manager will have to approve it. On the other hand, the conversation should take a different flow if there's no time off accrued because the manager will certainly need to approve it. And we'd probably rather they didn't even make the request in this case. So when he asked to apply for a vacation, it says, do you want to proceed anyway? There's no accrued time? No problem. The main components of the architecture are IBM Watson with a conversation generated by BMC chatbot based in turn on the digital workplace catalog. How would we change this in order to inject our own flow? We note that the data is back in JIRA and that has to be fetched somehow using a connector into innovation suite. And that is integrated into IBM Watson as an element of the conversation. So where do we start? It's probably a good idea to go to the source of the data itself. Understanding this is key. That way we can figure out how to get to the data. In our process, we see that it's stored in JIRA. We see that it's stored keyed by a label on a record and that the description field holds the days off the days accrued. Now we need to configure our JIRA connector to get that data. Let's make sure that integration service is running. This integration studio should show a connector for JIRA and the credentials should be properly set up so that we will be able to access it in innovation suite. It looks like we're good to go. The credentials and the URL of the JIRA connection are there. So now we can turn to innovation studio, go to the admin tab and go to the integration service tab and make sure that we're connecting innovation suite to the integration server. Now we're ready to look at the process that will get the data. You could create a custom process in the BMC chatbot app, or if you have the privilege to create a new bundle like this library, it's a codeless bundle. You can just create it and start creating a process. I already have one on my system. So I can go in create a process and first thing I'll do is define the inputs and outputs to this process because that's the interface Watson will use to get the information. First thing we do is define an input parameter. We'll call it requester and we'll map it to a well-known ID number. Then we'll do the same thing for the output coming in as the cruel number with another well-known ID number. We'll use those later on. Now the process itself, in this case, I'm using the requester to do a get records by query in the process to look up the foundation record for the person who's requesting the PTO. Now we can move on to actually getting the data from the Jira connector using a connector activity in the process. We can configure it using the same profile we created earlier. By passing in the requester as the label, it will return all the issues in Jira with that label of the requester's name. This next activity is a piece of custom Java code that helps map the issue JSON returned by the connector into the accrual information we need. You don't always need to do this when creating a custom process, but in this case, it helps make the data coming back from the connector easier to consume in the application. This last activity simply creates an audit record to satisfy the customer's requirement. It will write out a record showing the VIP status of the person requesting. The PTO, and it'll capture the time and date and all those things automatically. Before we actually try to consume this in Watson, it's a very good idea to test it using the managed process console. We can run the process. It will prompt for the requester, as the input parameter, and then when we run it, you can go in and examine the path it took. It looks like it followed the correct activities. It called the connector, it mapped the answer back, and then we can see what the accrual output variable was mapped to. Looks like three. That's the correct answer for this user. So the process is working. Now we can integrate it to our IBM Watson conversation. Now let's consider the technique we're going to use. We're going to intercept the hash PTO intent. Instead of calling the out-of-the-box node directly, we're going to have a custom node that calls our process to look up the accruals. Then, based on the accruals it finds, it can take two different paths in the conversation. Here we have an IBM Watson assistant conversation editor. The dialogue shows the out-of-the-box node and our custom time off node, which precedes it in the flow with the same intent. This is where the integration actually takes place. When we switch to viewing it in the JSON editor, we can see the essential aspects. Let's take a closer look at them. Of course, we need to pass the requester into the input map of the process using the well-known IDs that we established. Similarly, we can capture the accrual as an output parameter of the process. The process definition name has to be fully qualified with the name of the bundle, and this last parameter is very important. By setting this to true, we force the conversation to wait until the accrual number is returned by the process. This will be how we can actually use it. Even though it's called wait for user input, the conversation user will not experience a wait here. Instead, that variable will be already populated before it goes on to the child nodes here. That way we can use it to figure out what flow we should take. Let's take the case of no accrual. You recall this is where we see the question, do you want to proceed or not? We can match the standard entities for yes, which we can handle by performing the jump to the standard out-of-the-box BMC time off flow. On the other hand, if they say no or any other response, it will jump to BMC start over. So now we have completely handled the path of no accruals. If the dialogue is still flowing here, it means that there are accruals. We can report the number of days accrued, remind them that they need the manager's approval now, and then as before jump to BMC time off. The beauty of this approach is that we're not actually customizing the generated nodes. This keeps the customization separate from what is automatically generated. It makes it a lot easier to maintain going forward. Now you may recall there was another thing that we were capturing with the audit record. It's easy enough in Innovation Studio to whip up a view to display these records. We're just going to include some key pieces of information. And when I preview the view, you can see the view is there capturing some details from the foundation at the time and the person who requested it. This gives you a quick idea, but obviously the possibilities are endless for how you use this data. To summarize, you can customize a BMC chatback conversation extending it by creating custom processes in Innovation Suite. You can inject information and dialogue notes before the out-of-the-box flows, making it really easy to maintain, leveraging all the power of connectors, local data, specialized views, and even custom Java code if you need it. Thanks for watching, and as always, you can get more information from developers.bmc.com.