Welcome everybody. This is getting started with custom connectors and Power Automate. My name is Hugo Bernier, I'm a Principal Program Manager for Microsoft, and with me is David David. Hi, everyone. I'm David Yak. I'm with Colorado Technology Consultants in Colorado in the US Excited to be here to talk to you about custom connectors. Awesome. And this session today you can join us at aka Ms. slash learn Live 20230523 G and this. Actually in this module you're going to learn about the role of custom connectors, which are very exciting. And you're also going to build a custom connector and use it in a Power Automate workflow. And by the way, a little tip here is this module will help you get prepared for the exam PL-500 Microsoft Power Automate RPA Developer and this session is live and interactive. Well, in theory it is. We have Q&A open, I believe chat. I'm live, Hugo. Well, you live. Yeah, I'll try to be as animated as possible, but we've. Got a bunch of moderators that are ready to answer questions? Absolutely, we do. So don't hesitate to say hi, ask questions and we are here to take care of you. All right. So what are some of our learning objectives today? We want to. All right. We want to learn about the role of custom connectors. Custom connectors are great way to integrate with some of your existing systems and existing APIs. And then we're gonna show you how to build a connector and use it in the Power Automate workflow. Now David, why would you want to create a custom connector? Hugo, thanks for asking me. That's a great question, you know. The reason you want to build a custom connector is because you want to use it with an app or a flow to be able to make it easier and more consistent to be able to use the service and API that you want to integrate with your application. Now what's interesting is there are a number of prebuilt connectors, I think it just topped over 1000. Does that sound about right? Exactly. Yeah. Yeah, so so you the first thing you want to do is obviously go see if there's a connector, but if there isn't a prebuilt connector then you can go ahead and build a custom connector for those. You also might want to build a custom connector if the prebuilt connector you found doesn't have all the actions. For example, when I first want to use the Vimeo connector it didn't have some of the things we needed for working with videos, so we had to build a custom connector to extend and and do the operations. Let's talk a little bit about the steps to build a custom connector, because this is the real fun part. It's not that hard to do, you just have a few things you need to take in mind. The first thing you want to do is identify the the API that you're going to build the custom connector on. But you know what you want to do before that, Hugo. I feel that's a trick question. It is a trick question. You want to make sure there's not already one that does what you're looking for, because if there's already one there, you can just add on to it. And so they've been adding tons of custom connectors and certifying them either as certified connectors or independent publishers. I'll talk about that in a second. Then you want to describe the API. This is the fun part, because. If the service or API already has a definition and we'll talk more about the options here, this is how you tell the app and the flow what the connector can do with the API. So this is all about describing the API to this for the service. Then once you've done that and we'll talk about how to adjust it some, you can use the connector Hugo. I think you're going to show them this later, right? I will, I will, absolutely. And then if you really think it's something that would be useful to other people, you can go ahead and certify or open source or do both. Now, when we talk about certification, you can certify. If you own the API. You can go through the certification process and publish it as a verified publisher. If you're just a community member that built something and think it would be helpful to others in the community, then you can publish it as an independent publisher. Either way makes it so other people can take advantage of it. So let's talk a little bit about how you would actually describe the connector. Now this is where it gets into. You could simply start from a blank. Have you done the blank? One Hugo I I well, yeah, I will show starting a blank and then I'll import the import some some open API. That's great. You're going to show them that. So blank is great when you have maybe 1 action or a couple actions that you want to configure on the custom connector. Because if you're going to do 20 or 30, you're going to be there a while doing it and it's not the most efficient. More efficient is if you built the API using any of the Azure services such as Azure Functions or Azure API Management. You can import it from there. You can also export it from the each of those services. To create the custom connector, and that's a pretty quick way to do that. The other option you have is using an Open API file. You might have heard of it as Swagger. Open API is a standard definition for defining the operations and triggers that a service can offer and allows you to quickly bring that in and we'll show you an example of that as we go through the the content in a little bit. You can also use Postman. Postman is a REST tool for testing APIs. And so it lets you basically take the API request, make that request to the API, capture the the request and the response, save it as a collection that you can then import in to create the connector. Not bad, it's a good way to go if you don't have the open API file. Personally, the open API file is the quickest way to get things up and running the other quick way. Take my example, the Vimeo that had some of the actions that I wanted but didn't have all of them and I wanted to add on to that, but I still wanted to keep the existing definitions I could import from GitHub. Importing from GitHub lets me bring in the definition from an existing open source connector and allows me to make some tweaks to that for my own use. That's very cool and I have to say that creating from the Azure service is one of my favorite. As the world's laziest developer, right? To be able to just point to a an Azure service and and get the API, that's beautiful. All right, So how do we authenticate with with those custom API or custom connectors? Well, you're really. Just using the authentication of the API. And so this is where it's really important. When you're basically going to bring a connector for an API that you go look at the docs for the API, that's where you'll find out what the authentication. It requires and what you're configuring is how the connector's going to talk to the API. And so there's four basic options that are supported. No authentication. This is kind of the free for all. This is your jokes API that gives you back kind of the the jokes or the message of the day. Nobody cares about security. There is no security, so basic authentication is user and password. You have Oauth 2, which is one of the more common ones. So that could be Azure Active Directory, that could be Facebook, that could be anything that offers Oauth 2, and I'll talk a little bit more about that in a second. The final one is API key. An API key allows you to essentially pass an API key that you get from the service. So for example, on our 365 training site, you can get a key and then come to our connector, provide that key. And use it to connect to the service and perform the actions on there. Now Oauth has a little bit of extra configuration that you can go through, so there are different Oauth configurations for each of the different Oauth services. And what the connector designer does is has a quick path for configuring first about 15 to 20 of the different common services that you use. For example, if you can check Facebook or as your Active Directory, it already has the refresh URLs and some of the things you'd have to configure for other services on there. But if yours isn't on the list, that doesn't mean it's not supported. That just means that you have to go get those URLs and you'll have to do a few extra configurations on the connector. Now why don't we show you a little bit of that experience of how to make a custom connector and so you can do that using the maker portal, right? So you can build that in the maker experience and I'm gonna show you how to do that with a a custom connector. Now I'm using a pet store example. This is based on in the in the learning modules you'll see that. David has actually created a beautiful video that illustrates the same thing. I'm going to show you there so you can follow at home when when you're doing this. So the first thing we're going to do is we're going to use that custom connector. And to do that again, we need a pet store sample API that will build our connector. So this is the sample API now. For those of you who have not used this, this is Open API or also known as Swagger which is a way to describe APIs and all the operations that it can do and everything. So if I go to that custom API, you'll see here that I can actually go to my Power Automate portal. I could also use the Powerapps portal. And then from here what I want to do normally if I want to create a custom connector is I go to data right here. Then would go to my custom connectors and I would go on the upper right corner and say new custom connector. And from there I can just create from blank or I can import any sorts of information that again David has talked about a little bit earlier. The problem with that is what if you're trying to create a connector that you want to deploy across environments, right? Because what we're doing here is in our default environment. Or whatever environment this is. But what if I want to create an app and I want to move the app between environments or I want to follow proper application lifecycle management? David, you got a suggestion? Solutions. That's that's the right solution. Solutions are the solution. So to do that, we're going to go to right there. Solutions. And again, solutions is a way to package your applications and all the assets that you need. And I already have a pet store management solution that I've created. In the labs you'll actually be creating your own solution. And in my solution I have an application, a canvas app, and I have a workflow or paranoid workflow that actually calls my custom connector. But let's go add a new connector. And to do that we're just going to go to new automation and custom connector. There you go. And then it'll take us through the wizard that allows us to create a new custom connector, and it's pretty straightforward. Let's go through the steps. So the first thing you should know is that from the general information you have the way to create a custom icon. You can put a background color, you can put a description, and. You can connect to an on premise Data Gateway. Why would you wanna do that? Well, if you have an API that's hosted internally that's only available on your network, you can actually connect to it using an on premise Data Gateway. That's a great way to integrate with your legacy systems and to make it available through Power Automate and Powerapps. Okay. But the first thing I should probably do here is I should go provide a host URL. So here I'm lazy. I'll just copy this here copy, I'll go here and I'll paste it and that's the base base URL that it will use for all the API calls it will make. All right. So I can just click on create a connector and of course make sure that I gave it a name, connect a pet store. It's going to save the connector here. Now I've just created the blank connector. I didn't create any. Operations. Yet you're not gonna be able to do much with that connector, Hugo. Well, I mean, I can at least say that I created a connector, but let's let's actually go do that. And so here's a little trick. Here our actions are empty, our triggers are empty, nothing is done, right? So but if I just go back to the previous page. I have a menu here that's available that allows me to import from different things and the one thing I can do is I can open an open API from a URL and I just so happen to have the open API URL right here. So let me just copy that, let me move that over here and paste it, click import and continue and right away you'll see that it started to populate some information. I have my description here. And what else do I have? Well, I've got a few things, including some of the activities that are available. So let's go do that here. And we have the security as well. Now the security. You'll notice that my API already says that it uses an API key, but I could change the authentication mechanism if I wanted to. But again, to David's point, you should always respect the security that your API implements. So in this case, we need an API key. All right, so let's move to the definition and definition. You'll see it already created 20 actions that I can use in that API. Again, that's because Open API defines all these calls. But you'll also notice that I have some little blue dots there and it's saying that every operation needs to have a description. So I'll just say here, upload an image by the user. And it needs an operation ID, but the operation ID is already there. The problem is that operation IDs should always start with an uppercase. And why is that, David? Why do we want to take the time to actually put a summary and a proper operation ID? Well, the by having the proper summary and operation ID, you'll be able to actually see that from the maker. That's what you're actually going to see. And the operation ID is what you're going to use when you build your apps and use the function the actions. Yeah, and it's it's really important. Again, remember that when you're creating a connector, you're trying to create something that your makers can use, and you don't want to make it abstract and complicated and use weird names. You want to try to use as user friendly as possible for for names and descriptions and things like that. All right, Now you can see as soon as I updated that it already told me that everything was good. Now you'll see if I go to another operation, I look at the body, I can actually edit the body. These are the parameters that I can pass through an operation, an action, and you can see that I can edit any of the things that were described here and I could change the title, description. And the visibility and visibility is going to be useful later because we can hide things that we don't want to clutter the interface. We can make sure that only shows up when it's an advanced property and other things like that. But let's move on and let's actually use the Swagger editor. So if you want to see behind the scenes the code, and I know this is a low code platform, but you do have the full power to be able to go to the Swagger definition. And you'll notice on the right that I have a whole bunch of errors. That's because the way Swagger has defined this API, it shows security. But if I remove some of those security constructs that are not in use right now for the Power Automate connectors, it'll start removing the errors. And you you can see as I'm going through and removing the some of the things that are highlighted to me, it's actually removing the errors on the right. Now, through the power of demos, I've actually gone and fixed all that, and I've removed all the errors. Now I could actually go to my actions and I could delete actions. I don't want to do that to this one, but what if I wanted to import my own action, let me delete an action that's already there, and then let's go recreate that same actions, just so you can see how you have the ability to make customizations. And why would this be useful? Well, again, we talked about. What if you have a API or connector that already exists that doesn't have all the operations you need? Well, you would follow very similar steps to do that. All right, so let's go to the bottom right here, click on New Action and then I will retype the same command that I had before, which is get Inventory. And I will give it a description. Otherwise it'll scream at me. And we don't want Power Automate to scream at me. And we'll put an operation ID and remember the operation ID should have an uppercase. Now we can control whether we want that action to be available and visible to our users. But more importantly, right now, what I should probably do is go look at. There you go. So I can go look at the request. So how do I make the request Now I've got all these things like GET, DELETE, POST. How do I know what it is? Well, if you go back to the Open API definition, you'll see that the GET inventory command or action starts with GET. It's a GET operation, so I know that I'm gonna use that. And I can also see a sample of what the responses look like. But because I'm lazy, I'm just going to go and copy the information right here. All right, so now let's go back to that definition for that new action. I'm gonna say it's a GET and I'm just going to paste the URL. Now you'll notice the URL is a relative URL. You could put an absolute URL if you wanted to, but everything is already defined to relative to the base URL that I created when I first created the connector. So save yourself some trouble and just continue using your relative connect URLs here. All right, now we need to actually also understand what the response is going to be like. So let's just go add a default response. And again, because I'm the world's easiest developer, I don't want to type all this stuff in. Let's go look at what the responses look like. There's a few ways to do this. I like to just click on Execute and then go look at the response body and copy. I think David likes to call the API directly. And copy from the page again. I I like that it has a little handy copy button. Hostman is also good way to do that. That's true. Yeah, that's a very good point. So here, now I have the same thing that I had before. I have all my my response information with the body, the definition of how the body is going to respond, and all sorts of good things like that. All right, so now let's click on Update Connector. And David, this is the part where you and I need to banter because updating the connector can take some time. Well, I guess I could ask, why didn't you update the connector before the session? All you're gonna have to show us. What? Well, see. Look there, It's ready for you. There you go. So OK now all I need to do is I go to the test, I click on new connection and I pass my API key. Now my API key is a very special API key. Ohh, don't tell them what the key is. Ohh, I'm sorry. This is not recorded, is it? All right, so now I've created the connector and so if I refresh the page I now have my connector and I should be able to. Now if I go to get inventory, that's the one I just created. I clicked on Test operation. I will see hopefully if the demo gods are with me. Yes, I see results. There you go. So that was creating a custom connector. Now in the labs you're going to do something similar. And I will walk you through these steps a bit later. But before we do, let's talk about what we want to do with exploring custom connectors and configuration options with David. All right, so now that you've got a basic connector, so you what you've got is whatever the API defined and whatever the open API brought in or whatever the definitions you'd had. But you want to think about how the names and descriptions are used, and do some adjustments in some cases. You want to think about action visibility. You also want to think about the request and the response, because the request is what the maker is going to pass in to use the action. The response is what they're going to use to consume the output that's on there. And that's really important to think about. So it all starts with when you name the connector. So you got to pick a good name. You can have up to 30 characters you you can get creative if you want. But think about this is this is for the maker to figure out. Do I want to use this connector? That's where the description and the name come in. And I think the icon is also important. You'll notice the C is very contoso like it's very clear that you can see it. When your flow has 10 actions from the Contoso connector, you can see them real quickly. And people don't spend the time to do this, but if you think about it, if you've got over 1000 connection connectors available. You have that little mnemonic device that allows you to see the C and the color that represents your brand. It makes it easy for people to find it. You know I want to do try that. Do one flow that has every single connector in it, just to see what it looks like. That'd be cool. All right. So then you get into. Once you've gotten past that, then you get into naming your actions and your triggers. And now I I actually once created one that just used ABCD and so forth for the action names. It was kind of funny. I was going to use it for a demo. But you just want to pick names that are meaningful because, again, somebody's building a flow, they're using the app, They're going to get in the prompt. You know, as they type the connector name, they're going to see the. Actions that are available, they're going to have to pick which one to use. So instead of saying add, you'd say add invoice. Instead of saying get invoice or get, you'd say get invoice and make it a little bit more consumable. That's actually a very good point because you you want to be able to see these actions out of context and understand what they do and Hugo. Talked about this a little bit briefly in his demo, but the action visibility is also important, so you may look at that and say it says none. Does that Hugo? Does that mean it doesn't? Show no, it just means it's the. It's the default, right? It's the default, so if you pick none on everything, they're all just going to show up in alphabetical order in the list that's there. If you go ahead and you want to give priority to some, you can. Choose the the important. Obviously it puts it at the top. You don't want to make everything important because then it's just like none. So do that. If you know if there's two or three things that 99% of the people use, important is a great way to highlight them advanced. Says hey, this action is a little more advanced that everybody doesn't need it. It really matters if you have 20 or 30 actions, it puts it at the bottom so that you have to Click to see more and that the flow action list to be able to get to it. And then the other one is the internal so you don't have to put hide or hidden or acts in front of the name to get it to go to the bottom if you have an action that you don't want people to use. And this is not uncommon. It may be that you don't want to expose all the actions, but you're not ready to delete them from the definition, because maybe later you'll make them available. You can mark them as internal and they won't show up to the maker, and that's a great way to kind of shield them from the complexity of the overall API. Yeah, that's smart because if you ever want to update your API from the API definition. You don't have to go redo everything cuz you've got your your settings there, right? Well, yeah, you go delete it and then you're gonna realize 2 weeks later somebody's gonna come and say, hey, can you add that action back in? And you're gonna have to go figure it all out. Very smart. So the request think about these is what you're going to provide. When you do you at configure the step on the Power Automate flow. These are the things that are going to show up on there. So again, the names matter and a lot of times the API's that you use, even if you import an open API definition won't have good meaningful names on them. They'll be more developer names and you'll want to edit these to provide the good names. Now one thing to be aware of if you do edit the names on the configuration of these different things. If you reimport that open API file, guess what happens, Hugo, You know what happens, don't you? Yeah, it's like deja vu all over again. Yes, you're back to Ground Zero. So I mean keep that in mind. If you own the API, the better way to do that is to go back to the API developers and say, hey, can you provide some more meaningful descriptions. We're using this in low code and that would be a better way because if you round trip, update it again. You won't have problems with it overwriting your customizations on there. Although a little tip here is if you go to the swagger view you can copy and paste and put stuff back in. But again, go to the source right? It's just a lot easier. So the other side of the request. Is, well, the response. So this is what you're getting back. Now APIs can give you different shaped responses, so when things are good, may give you these answers. When things are bad, it may give you an error message. So this is where you can define the different HTTP codes. So 200 is an HTTP code that you're defining what the fields are for that response that comes back on there. And if you have an API that gives different responses, you can configure them and customize them from here. And the default is what's used if it's not defined for the other ones. Validation. It tries to help you. It tries to make it so it's easy for you. It gives you a list. It puts the little blue dots. Look at the validation at the bottom, the different sections. This will tell you if you have anything you need to pay attention to. Red is just like a traffic light. You need to stop and do something. It's not going to let you proceed. The other ones you have some flexibility on it, just whether you're lazy like Hugo or efficient like Dave. See what I did? There you go. Is that what we're calling it? What about the other settings? The other settings, yeah, there's a whole bunch of other things you can do with custom connectors. And you know, one of the things we didn't mention about the learn modules is there are five or six other besides the first one that we're going through today. There's five or six other ones that go through some more advanced topics on custom connectors. So I highly recommend. After you take the time to do this one that you go through the whole learning path on there. But things like the triggers you can actually define events that cause your connector to run the flow. So that's a little more advanced. Not all API's support triggers. You have to either support web hooks or polling, and the API has to support that to be able to configure them. We show examples of that in the learning path. As you go further, you can also have references, references, or reusable definitions. So you'll see that in some APIs they'll actually show up as in the model section, that they have objects that are reused it within the API. And then the other thing is policies. Policies allow you to do things like set the host name and kind of tailor the connector to make it easier to work with the API. And you can do some data transformation on the request and response to handle certain scenarios with APIs that need that help now. In the labs or in the the learning module we have a few exercises and I. It should look very familiar because we just pretty much showed you kind of the process, but I'll show you exactly what you'll get to see, right? So in the the exercise, you'll actually get a page where you can you can find a definition or open an API for Contoso invoicing. If I could speak, you can also get the open API definition file. And in fact what we'll do is we'll just save it. You can see I've done this a few times already. But I'll just save it on my on my downloads folder and then that's all I need For that, I think, well, I let me go download the logo. We wanna make it pretty. You gotta have the logo, Hugo. Yeah, I I. Just talked about how the logo is important. It is important. Thousand connectors. You don't wanna compete with that. All right, So once you've downloaded all this good stuff, let's go. If I can find the right tab, There you go. Let's go create a new solution. Now we're we're going to call it Con Contoso invoicing. We're gonna pick the default publisher. I would prefer to use a custom publisher, but in the labs we're just trying to speed it up a little bit. And then you would do the same steps we did before go and you add a new custom connector. And then instead of, you know, typing or leaving everything blank like we did before, we're actually going to start filling all the information. So we're gonna upload the logo. We're gonna copy the background color. In the labs we actually tell you where the background colors are. We're gonna put some description in there and I'm using my clipboard to make it faster because trust me, you don't wanna watch me type. We only have an hour and then we'll put the the host again. This is the base URL we wanna use and I will create the connector. And you'll notice here I it automatically called it Contoso invoicing 1 because I already had a Contoso invoicing when I was practicing this. Make sure I didn't break anything, but it's saving the connector. And now we are ready. We're gonna use the same trick that we did before, except that now instead of using a API URL an open API URL, we're going to use the open API file that we just downloaded. So let's do that. Click on. The little three dots open API file, select the file that I just downloaded called swagger dot JSON and now I have all my operations that brought in. And again if we take a look at the security now, it should automatically say that it's using an API key and if I look at the definition, I should have a whole bunch of actions. Now in the lab, the open API definition we've given you. Is missing a few things. You need to have a summary, so let's just see. That's why you don't want to watch me type. I can't. Turns out when you don't have labels on your keys, it makes it really hard to type when you're putting your fingers on the right keys. I feel you're making excuses, Hugo. That's, that's that's my go to excuse, all right. And then we'll put a description on the pay invoice just because again, we want to be nice people and we want to make sure that we're supporting our makers. They understand what each action does, all right, And So what else do I need to do the? Well, let's see here so we can put some descriptions. OK, so now we got your get invoice schema. You know what? That's an internal API. We don't want people to get to see that. You'll often see internal APIs like that, like get version, get schema, things like that. We don't want to expose that to our makers. They don't need to have access to this. All right, so and then I apparently I forgot to paste my host and let's update the connector so it wouldn't be a demo if I didn't do something wrong. At some point we're saving the connector. And so now what we've done again, it's pretty much the same thing I just showed you before, but that's actually the steps we'll walk you through in the labs. And what else do we have to do? Well, we wanna test, so we're gonna go create I always. Test your work. Yeah, I mean, I I always test in production personally. All right, so go create a new connector. We're gonna create an API key. Now in the labs, we're not using a generic key. We have a dynamically generated key for you. So go copy that, you go paste that in your API key. And create your connection. Now here's the thing that may throw you off a little bit. If your connection doesn't show up, you get that little refresh button right here. Click on that. It will bring that newly created connection. And then let's go pick the list in voices. Where is it? List in voice Types. OK, let's pick in list in voice types and test operations and look at that. We have a body, so we actually called the API. And for my custom connector, that was pretty easy. So again, this is the exercise that you're going to do in a solution. Now what else are we gonna do? We're gonna use a connector. And to use a connector, David, I think this is the part where you tell us how to use a custom connector. Well, it's quite simple. It shows up in the list of connectors. I mean there is a tab on there that you can click on custom and it it is nice because it shows just the custom ones that are in your environment. The key thing to remember about custom connectors is they're defined in a single environment, so if you want to use them in other environments, you have to move them or redefine them in those other environments. So the first option that you have if you want to use let's say in environment B. Is you could download the definition from environment A and import it into environment B and essentially recreate it. It would be just like importing like Hugo showed in the example there. Not the most efficient way to do that. The other way that you can do that is using solutions. So that's what we saw with the Contoso invoicing API. We saw that we could create it in a solution, then when we export the solution, import it into another environment. We could rehydrate that and make it available for use in that other environment. Now, one thing to be aware of, there is a current limitation of Canvas apps. If you're doing that and you're not doing Power Automate flows. Power Automate Flows can see the connector in the same solution. But canvas apps right now I I believe there's still an outstanding issue where they can't see the connector if it's in the same solution. So the the solution for that is you just have that in a separate solution for right now. The other one way that you can do these is using the command line utility. So there's a power apps platform, connectors command line interface that allows you to download the assets. Now the most common reason people want to do this is because they want to open source it or go through the certification process. This gives you the individual files. It's also in preview for the power apps CLI, the developer CLI to do the similar type of operations, and effectively that will become the probably the preferred path for doing the CLI operations in the future and. I let's go back for a moment about the downloading and importing because I've heard a lot of customers that will say oh, you know we we strongly follow dev. UA UAT production and then they actually download and reimport at every step. Right, they recreated in each one. Yeah, so you're essentially invalidating your testing. There's no point in doing this, right, if you're if you're going to go through an application lifecycle management process where you wanna go through, you know, again testing and and uating and going to production. You wanna make sure you're not changing the variables at all. You're not introducing you bugs between versions, so make sure to use something like a solution to move your connectors between and and your assets between. Them, yeah. I mean, most people would use the solutions or the command line tools to do the movement because they get all the assets then. Yeah, and don't get me wrong, I use the command line because I can script it and I'm lazy. But wait, have we mentioned that? I see a theme that's coming along. All right, so let's do so. In the in the learn module, you have another exercise which is using a connector from Power Automate. Now what we're going to do is we're going to use a manually triggered Power Automate crap Cloud flow that will call the Contoso invoicing that we just created before now. You might say, well, I don't really use a manually triggered power automated workflow. I want to use some other triggers. You would follow the same process. It's just it's a lot easier to demo a manually triggered process than to wait for like a SharePoint document or an e-mail to come in to be able to demonstrate that. So how do I do that? Well, I go to that same solution that I created and I will create a cloud flow, but we're going to create an instant cloud flow. And then we're going to here. I could, you know, just skip everything and go manually define everything. But I'm a nice person. I will actually say what the flow is supposed to do. Please take the time to name your workflows and then yeah, I could skip all the definitions and everything, but let's go to our manual trigger. And then. Here I have my mail trigger. So what do I need to do? I need to create my first step because our flows should probably do something useful. If I go to the the custom connector as David showed before, I can just go find the connector I want. I want the list invoice and now I have to name my connection because it's going to create a connection for me. So let's give it a name again. This is the part where you watch me type. Super exciting. There you go, Invoice connection and the API key. We have that API key from the lab, so let's go copy that, let's go paste that in here and if everything goes well, I've created my connector. Now I have some parameter in the list invoice that I could call, but I'm not going to use any of those, I just wanna show all the invoices here. So because you're lazy. Because I'm lazy. Have we mentioned that? OK, so I'll just save this and now I should be able to test it, right? So we could go back to the previous page and test it. I think it's saving. There you go, it's saved. So now I can actually go test it. And I just to show you that it got created inside the solution because that's kind of important. I can just go click on it again and let's run it. And to run it, yeah, what do we do? We just click on run. I could have also tested it but that was boring. And then click on continue and I'll run the flow and it said it has run successfully. Now you can see in my 28 day run history I can actually go click on that workflow and you'll see that. Come on, there you go, it completed it actually called. List invoices and it gave me a whole bunch of invoices. So do we get the money when the invoices get paid? That's what I wanted to know. That's the part I'm trying to create a Swiss bank connector that I can take care of that for now, we'll just e-mail some money. Come back for next build for that. Absolutely. All right. So we've gone through all this. What do you say we we keep our audience awake by asking them some questions? I think we should see if they've been paying attention. Awesome. Now we have some polls and you can actually vote at our polls at aka Ms. Poll G or follow the QR code and let me just bring the poll right here. There you go. So the first one is you've been asked to build a Power Automate flow that uses an API from Fabrikam and you have decided to build a custom connector because a built in connector is not available. See they listened to you David. After reviewing the API documentation you discover that it has an open API definition file and examples that could be used with Postman. Considering the possibilities which approach. Makes the most sense to quickly get started building the custom connector. I'm reading this to give people a chance to actually respond. Yeah, we've got some different options on here. So you could use the Postman collection and then import the collection. You could import the open API definition. You could import the open API file as a reference and then manually add the custom connector. I'm just going to help them out a little bit. Manually adding from the open API definitions probably isn't the most efficient way to do it. You think, Yeah, I mean you, you know me. If I can, if I can, go directly to the open API definition file. I I just saw the word manual in there and that that was the hint for me. That's right. That's right, so. Looks like a bunch of votes are coming in, yeah? So let's give it a few more seconds. What do you think of run the samples and capture the network trace that that seems pretty low level to me. I don't know. I mean, I I've done something like that in the past, but it's probably not the most efficient thing to do. But that's definitely if you ever need to reverse engineer something that has not been documented. But hey, we're looking for the best solution here, so let's reveal the answer. You ready? I'm ready. B Beautiful. And you know what? Most people got the answer right. Yeah. And again, I wouldn't say that all the answers were wrong. It's just some were better than others. All right. How about another one, Hugo? The next question, OK fine, hopefully I don't have to read as long which of the following authentication types is not supported by custom connectors. Well, I don't know about you, but I brought my cookies. Now you're just teasing me. Yeah, I think we mentioned it once or twice, right? So let's see what people are saying. But you got API key and you got Oauth, you got anonymous. You got several options on here that you could go for. And you have several flavors of Oauth as well, so. Is that like flavors of cookies? It all comes back to cookies. Well, let's reveal the answer. It's be cookies. Cookie authentication. Ohh you got the cookie on there. I got it. Just in case you're not ready. All right. And then last question, you have built a custom connector and want to make it available to other companies similar to builtin connectors. What would you do? What should you do? HM, we didn't really talk about that, did we? No, we we we didn't. But I think we gave them some clues, the things that could work. So actually I did talk about a little bit in the early part actually when we went through the different stages, we we did talk about it. That's true. So they're on the. See if people remember you have. No. Were they listening to me at that point? Well. So again to reiterate by the way you a lot of our our custom connectors that are there and there was a question in the chat that we, it looks like we're gonna have enough time to answer. It is possible to get your custom connectors certified and to make them available to other people. So I guess the answer is B. And one of the questions I did see in the chat when I peeked over there, Does import export of solutions work from one tenant to another? And I. And one of the things you can do with solutions is it once you've exported them, you can import them into other environments. In fact, when you go through the later modules in the learn, it actually gives you the ability to download a prebuilt solution. So if you just happen to jump into module 3, that solution is there. So you absolutely I could give it to Hugo. Hugo could import it into his environment and that custom connector definition would be there. Absolutely. Hey you know what I think we have enough time for extra question bonus question Bonus question 4. You have imported an open API definition and it included ten actions. For now, two actions should not be visible to users of the connectors, but you might make them available later. What should you do to implement this preference? Sounds like that's something we talked about. We did. So again, you wanna make sure that you're able to. If the Open API definition gets updated, you wanna be able to reimport it. And you don't wanna lose all your changes. So that would be bad. Yeah, that would be bad. All right, let's see how we're doing here. Do we have people responding? Ohh, yeah, we got some votes. It's like it looks. 90% are getting it right. Yeah, looks like most people were still awake when we talked about this. All right, let's reveal the answer. B. Select them as internal. Again, Selecting them as internal prevents them from showing up, but it will retain their definition for future use. So the great thing. And it's much cleaner than put in hidden or do not use. It's kind of like emails. You ever get those emails that say recall what? What's the first thing you do when you get an e-mail that's been recalled? Look at it. What's the first thing you do? When an action says don't use, you're going to look at using it. Absolutely. In fact, when this forms that says do not write anything here for office use only, I'll write. OK, so all right. So let's maybe summarize this a little bit. So in summary, what did we talk about today? Well, we learned about the role of custom connectors. Again, custom connectors are a great way to integrate with APIs that don't have connectors already available or they're missing functionality you're looking for. But also, and that's my favorite use of of custom connectors, is the ability to connect to your own APIs, both internal and cloud connected APIs. That's huge. And then build a connector and use it in a Power Automate flow. But again, we could use it in other scenarios, but that was today's easiest way to do it within the timeline that we had. And one of the things I'll call out is the independent publisher program. If you start liking building some of the custom connectors, there's the real movement to define connectors that can be published for some of the API's that aren't out there. And this is a great way to really help and give back to the community. You can use your skills building the custom connectors to fill in the gaps that of connectors that aren't already there. Absolutely. No, we have a few questions in the chat. Should we, should we look at some of these because we have some that are topical right now. One is should we or can we trust third party connectors? I'm concerned that I don't see a certification again. You can do your own custom go ahead. Yeah, well here's the thing to remember about connectors. Connectors just define how to talk to the API. They're all about information about what the actions are, what the the responses are, the requests. They don't actually do any logic unless there's transformations that are in there. So when you say trust the the you know that connector. What you're really trusting is the definition. And if you look at any of the the published connectors, you can actually go out and look at the definitions if you want to see what's in the GitHub repository, because they're all open sourced. Yeah, what's that saying? Trust, but certify. Or verify, I think is what you're looking for, yeah. Again, the certification makes sure that the the connector is not making calls to other locations that shouldn't be used right. But ultimately you are trusted trusting an API that you're calling because that's all we're doing and that's I think that's really important to remember that now someone also said Jim said, I've tried in the past to create a custom connector for our API. But it seems the custom connector framework does not support the Oauth 2.0 refresh token grant and I think there's a little bit more to that grant. For authentication support refresh token. I mean there's the refresh URL you configure on there, so I'm not sure where that's going with that. I think and Nick. You actually showed when you looked at the various flavors of Oauth 2.0 you were showing some that had refresh token authentication. That might be from a while ago. Yeah, awesome. And then there's there is a bit of a gap at the moment around APIs that require basic plus API key authentication. Is the best way to do this still. To use basic authentication and then use a policy to use to force the API key into the header of every request? Or is there a better way? I have not run into that, I've not done one that needs both on there, but some of the the transformation, I would look at possibly some of the transformations and see if you could accomplish that. Check out the policy module and see if it helps you get a little bit further along with that. Also, look at some of the code transformations that's in preview right now. Hopefully it'll be out of preview soon, but there's a lot of cool things you can do to adapt and deal with some of the nuances of API's using the code or the policies. Yeah. I'm just trying to think if there's anything else here that we can leverage. The one thing I would say though is. You know, one thing you people should remember when they're creating solutions and connections to things is Remember also that you have the ability to create a connection reference as well. So you can actually create your connection in each environment and point to your. Instead of bringing the connection into that solution, you're using a connection reference that requires basically every. When you import the solution, it will reestablish a connection to each environment. I know that's not exactly what you're looking for here, but I got a few ideas here. All right, well, let's go back to our unless there's more questions or David wants to impart more wisdom. I was just going to remind everybody to go through the other modules because I think it's really important to kind of round off the other topics on the custom connectors. And there's some really good examples in there as you go through them and you've got the link up. I do. I'm not gonna read it again, but there's a QR code right there. And again, there's a a beautiful video created by David that shows you the same stuff that I showed you earlier, but I'm sure it's much more eloquent than I did. And bonus is, you don't have to watch David type everything. All right, so this was it. So let's just put in our last slide here. Thank you everyone for joining us. Make sure to join the Microsoft Learn cloud skill challenges because you get free certification exam exams by completing the collections of Microsoft Learn and you got until June 20th. And of course dive deeper, right, Microsoft Learn Collections has tons of. The latest learning content. In fact, David, you're updating some of that content regularly, aren't you? There's been a bunch of updates. That's awesome. Even before we were preparing for this thing, David was making updates so you know you have the latest on Microsoft Learn Collections, and then make sure to connect with the Microsoft Learn community so you can engage with a whole bunch of people. And of course, you should also go to AK To the mess. Slash join the community and go to the power platform community and make sure that you interact with our people in the community. And most of all, go build a custom connector. Absolutely. And I honestly, if you're building a custom connector and we we met with Jocelyn Panchal a few weeks ago on the show that David Warner and I do and we were asking her, hey, is there a connector that's too small? And as far as we're concerned, there's no such a thing as too small of a connector, because there's always a business scenario. I mean, you were talking about the Vimeo connector. There's all sorts of connectors like that that you can leverage if if you find it useful, someone else has been to find it useful. Yep. All right. Well, that's especially any connectors you build for things that other people use your internal APIs. Most people don't want to see them, but if it's something public that they can take advantage of, those are great examples that you should look at publishing. Awesome. Thank you. Well, I think that's a wrap Hugo, everyone I know. Great day. Thank you everyone for attending. If you'd like the if you'd like the session. My name is Hugo. If you didn't like it, my name is. My name is David. I see what you did there. All right. Ohh, you have Ben. If you wanna post some some questions in the chat, we're gonna keep an eye for couple more minutes. Unfortunately, I don't think that you're able to unmute, so you'll have to chat or use the Q&A to post your questions. David, I'm just sticking here for another couple minutes just in case people have questions. There's. One that just came in is there an application for Power Automate, Use case, Commercial invoices and shipping lists, and Dynamics 365. Sounds right up your alley, Hugo. Let me go read that. All right, let me hit use case, Commercial Invoice and shipping lists in the 365. I would go out to the Dynamics 365 community and post that on there. That's probably where you're gonna get the best answer for that right now. Yeah, I mean, my immediate answer is yes, but there's also several. D365 applications here. So I'd love to understand a little bit more how you want to use that, but absolutely there are solutions like that. And for those of you who are still around, don't forget that your feedback is important. You can go to Akms, Microsoft Build Evals and let people know that we should come back next year. At least David should. And then Trisha is asking can environment variables be used in custom connectors? Actually, yes. There's in preview right now that you can do some actions with them, so check out the docs. That's a little bit beyond the basics, and because they're in preview, it's not in the learn content yet, but it is on the docs part of learn. So you can kind of look at how to use them and where they can apply. One cool thing by the way that I don't know if we well we didn't get to talk about it, but you can also associate C# scripts to your connectors. Yeah, that's the code transformations. Code transformations. That's right. The code tab. Well, I think we're at the top of the hour. They're probably gonna boot us out of here. So yeah, let's say goodbye. Thanks everyone. Talk to you later. Thank you, David.