In this video, I'll walk you through how to use Katsura's integrations script builder, which generates preconfigured integration configuration to accelerate deployment of these integrations to Katsura instance. Please note that the generated scripts and the integration it deploys are fully owned and maintained by you. Here we have fifty eight different integration templates which span across categories such as ITSM, observability, communications, and cloud providers such as AWS. So for the purpose of this video, we will be deploying integration with EC two. And here I see that we have fourteen different integration actions within the e c two integration that I can deploy, and there are two phases for the integration deployment. One is to do with getting the required information on the AWS side, such as the external ID, AWS role ARN, regions, so essentially creating IAM role. This step is not mandatory because you can always configure this once the integration has been deployed to Cutsober instance. So I will skip the phase one. For phase two, this is where we'll be deploying the integrations into Cutsober instance utilizing the generated script. As you can see, I need to select the target CutOver instance. In this case, what I'll do is I'll deploy the integrations to the demo dot cutsover dot com. The last integration that was created here was AWS Lambda, so no EC two instance integration. And, essentially, what I will need is the instance URL, so core URL, but also the API token. Of course, the API token here, I'm just masking it. So, essentially, what you'll need is the core URL, which will also auto detect the API URL. So as you can see, it has detected the API URL, and now I'll fill in the API token. As all the, required information has been populated, I can test the connection to the CutSover instance, and you can see seven workspaces have been found. So the connection works. Now what I'll do is I can rename the integration, and I'll call it demo, the AWS EC two demo. I can then select deployment scope, which means that I can decide whether this integration should be visibly, global across all workspaces or to a single workspace. I know that I have seven workspaces which I found, so I'll deploy it into the a t sandbox, which is my personal workspace. I can, choose whether deployment mode should be fixed or dynamic. Dynamic means it needs utilizing dynamic custom fields, but let's just do fixed for now. I have fourteen different integration actions in here, which are accompanied by twenty eight different custom fields that we will need to deploy. So each of these custom field will be linked, directly to one or more of these integration actions. But for the purpose of the demo, I will only select, maybe one or two integration actions such as stop the integration and get recover instance state. So two two actions out of fourteen. And you can see these two integration actions have four custom fields that we'll be needing, and let me call this demo as well. So I renamed, the integration custom field, and we will be deploying the integrations to the workspace that I selected. What we can also do is select whether I want a companion runbook, which means that once you have the integration configured, you can automatically include a runbook to that instance where you're deploying the integrations to, and the integration will be linked to this runbook so you can immediately test the integration as well. And if we scroll down, then you will see that all the validation has passed. So, for example, if we've forgotten the API token, the validation would fail, and you would be have been notified, about, the API token being missing. And the download button is ready. So that means that once I download the script, I'll be able to then deploy it utilizing this script, but you can read all about it also here. So I have the script ready, so let's deploy it. First, what it will do is run a preflight conflict check, which means that it will check whether in the instance where we are deploying the integrations to, are there any integration names or custom field names that already exist? And as you can see, no conflict found, so it will start creating custom field groups, custom fields, the runbook, the integrations, all of the, configuration so that, you are deploying the integration as quickly as possible. As you can see, we are we have completed the integration deployment, companion runbook created, integration created. So now I'll go into the demo instance. And as you can see here, the integration has been completed with those two integration actions. And if I look into the detail, it's utilizing the correct authorization method. The region was also EUS one, but that could have been a dynamic custom field as well. And the request has all the parameters that we wanted to deploy, including those custom fields as well, including polling. And if I go now into the a t workspace, I said that we also created a companion runbook, and here we have that companion runbook for e c two in integration, which then is utilizing, the integrations that we just built. So you can see this integration we just built, And this is an example how you can quickly deploy these integrations with Runbooks into a Kotover instance. And then what you will need to do next is just verify the connection between Katsuver and your third party service by adding the correct, required fields for the third party tool as well. Thank you for watching.
