Rich Martin • 00:00

Hello, everyone. Welcome to another Itential webinar. In today’s session, we will be going over building your modular automation library. This is part four in our webinar series. And of course, I am Rich Martin, Director of Technical Marketing at Itential. Like I said, this is the fourth in this series. So technically the fifth, if you have watched the intro, but we have been building on in this series so that we can take kind of logical progression one session at a time, so that we can start to build and understand kind of the fundamentals, the foundations, and start adding to your workflows so that you can end up with an end-to-end workflow that matches your needs and the processes that you are following in your organization.

Rich Martin • 00:46

And so for today’s, I kind of left you at a cliffhanger last time. So for today’s, we’re gonna be talking about building your modular automation library. As we always do, here’s the overview of it. We’re going to continue where we left off before. We’re going to take this workflow that we’ve built. It obviously has some integrations to a network device. This is a Cisco network device.

Rich Martin • 01:09

It’s a CLI-driven device that’s accessible through Automation Gateway. We’ve already implemented some integrations, some data transformations. In previous sessions, we’ve sat down and really went through some data transformations. We started to do an integration, well, we’ve already integrated NetBox through the APIs, and now we’ve started to build an automation to bring net querying NetBox for inventory and IP address information and create an automation to do that. Now, we haven’t put it into the main automation yet, and that’s where I left you last time, but we’ll also discover how we can do the same thing with ServiceNow. We already have an integration, and how can we build an automation, a modular automation that can be leveraged in other… other multiple workflows.

Rich Martin • 01:52

So in order to do that, we’re going to talk about and identify some common reusable tasks, what makes for a good modular task, reusability, obviously. Then we’re going to talk about how to create a modular workflow. I think this is going to go pretty quickly because, surprise, spoiler alert, once you build a standalone workflow, there’s not much more that you need to do in order to make it modular, and that’s what I want to show you today. Then how do you call that modular workflow from, let’s say, a parent workflow? We use that using something called a child job task, so I’ll show you how to do that. Then of course, transformations are just a critical component to building automations, and so we’re going to see how transformations are leveraged to format data to and from child jobs. So passing data to and from child jobs, and then extracting that data or formatting that data through transformation.

Rich Martin • 02:43

So like I said, we’ve used transformations before. This is the exact same concept, And so you will already have the foundation for that as it applies to child jobs. It’s really the same concept of manipulating data and formatting it. And then finally, how we’ll implement everything, test the parent workflow, step through it when we run, and we can see how the modular nature works with everything. And then hopefully you get the full overall idea of how all this works together. So with that, let me share my screen and we’ll go into the Itential automation platform.

Rich Martin • 03:15

So this is where we left off last time, and I know this is hard to see, so I’m gonna zoom in in a minute, but let’s take it a little bit at a time. We started off our workflow with querying the user with a form so that we can get the input for their data. Remember a stub task is a holder, we’ve used it to kind of like stub out or basically as a placeholder for different processes or tasks. So one of these is to get an IP address from a NetBox server that we have on the network. We have our transformation. This transformation originally we built it so that it would take the user input form that gave us the network device and a port description, because we’re bringing up a new interface, and then turn that into a set of CLI commands that can be used to push to a network device that we have selected from that form. That’s that transformation.

Rich Martin • 04:08

That’s what it was built for. We’re going to be updating it because now we’re getting more information that can be used for the config changes. In this case, it’ll be an IP address from NetBox. We’re going to update that in a minute. This is part of that process of building modular workflows and how you will integrate those back into your parent workflow. Here’s another stub task of creating a change request ticket. This is for service now.

Rich Martin • 04:31

We’ll be addressing that as well with a modular workflow. We have our command template. This is our pre-check process. It looks at that network device and it says, hey, we’re about to make this interface change. Does this interface actually already exists? Because if it does, we probably shouldn’t make that change. That’s what our evaluation does.

Rich Martin • 04:51

It gives us a fallout routine if something doesn’t look right with the state of the network before we make the network change. Then we go on to make the network change. And of course we do an evaluation there to ensure that the network change we made was successful. So that’s our fallout condition here that we’ve already built. And then finally a post-check process, which is another command template that we’ve built previously that allows us to say, okay, now that the change is made, we know the change was successfully called. Now let’s look at the network state through a show command to ensure that the interface is up and it’s actually showing up in a show interfaces command. So that’s what we do here.

Rich Martin • 05:27

And then we evaluate that. And then our last stub task that we’ll update here as part of the primary workflow is to update the ticket state. So after everything’s done. So that’s a quick review. So let’s now take a look at what would make for a really good modular workflow. In this case, we’ve already identified the fact that sometimes querying a source of truth like Netbox for inventory information or IP address information would make a really good modular workflow. Why? Because it’s reusable.

Rich Martin • 06:01

Is it something that occurs quite often in your day-to-day processes? Every time I have to bring something up on the network or bring up a new interface or assign something to a server, I have to pull an IP address. from Netbox or other source of truth could be Infoblox. That probably makes for a good reusable modular workflow because you can build it once and then reuse it in multiple parent workflows. That’s why we isolated that. But also change requests tickets, creating new change request tickets, updating them also makes for a nice reusable workflow. A reusable workflow can be something network related.

Rich Martin • 06:41

It could be querying a router or a switch for a set of data, that you want to document in a ServiceNow ticket. If this is something that occurs quite often, that might make a nice reusable workflow, as well as a reusable workflow for making network changes. This is where you can sit down, especially during the process where you’re blocking and stubbing out your workflow, thinking through what would be really good reusable use case here. Then as you’re building those workflows, incorporating this idea of reusability so that you can, as you’re testing the workflow, you can say, here are the variables that I need to be input, here are the variables that we need to be output, and then building it in such a way to make that possible. It’s really not that hard. In fact, quite honestly, everything we did to build the previous Netbox workflow that’s going to be here, is really the same step as building just a regular standard parent workflow. and I’ll show you that.

Rich Martin • 07:43

So that’s really what makes for a good reusable workflow. And it’s just thinking about the mindset of making this instead of something standalone, something reusable. So where we left last week or last time in our last session is here. This is the workflow we built to query Netbox for an IP address. So this does a direct API call to Netbox. And then we created a transformation to turn that response data because the data that we get in response is basically the IP address slash in the CIDR net mask. We needed to turn that into a CLI command.

Rich Martin • 08:21

So what we did here in this transformation is we built, we took, we extracted that data from the first call and built the CLI command around that using a series of different methods and string manipulation methods. You can go back to the previous series to see that. But that’s where we left it. And so the idea here was now that we’ve done this, can we just replicate all of these steps and this information and put it back into our original workflow, replacing the stub task that we have here. with those two workflow steps? And the answer is, yes, we could do that for sure, but we’re not going to because we want to now transition this into a single step that calls this workflow. So just by example, Let’s just take a look at some of what we’ve got going on here, just so I can show you, again, by a refresher, how this works, and then we’ll run it and I’ll show you.

Rich Martin • 09:19

This is a direct call into the NetBox installation that we have here. We’ve defined an ID number which is, this is data that’s all required from NetBox. When we did the integration, these are already defined in the NetBox API, so we’re reflecting them here so that data can be filled out, either statically or through another task, or as we’ll see in a moment, you can pass variables to and from different jobs. That’s part of the modular nature of building workflows that way. In this case, 32 is assigned to the IP address prefix for this, for where we want to query against. Then we’re just passing some data in an object here, so we can update the status to active and then set a description up. It’s as simple as that.

Rich Martin • 10:06

This data comes from the documentation for NetBox, for this particular API call, and we covered that in our last session. Then this is the transformation. The important bit here is when you build your transformation in our Canvas, you’re going to have an input schema and an output schema. When the input schema is defined, and you now reference that in a task, that transformation that we built in the canvas, you save it, now you reference it in a workflow with this transformation task. That input schema is read in, and it’s displayed here. So now we know that there’s an input schema that matches, that’s an object that we called it from NetBox when we created this transformation.

Rich Martin • 10:53

And then we have the ability to source the data for this object from a previous task. In this case, a previous task here in this workflow, which is this task, get IP address from NetBox. You can see it here. And then that particular variable that is the result variable is going to be passed into here. So that’s the source data from which we are, we’re taking the data to do the manipulations. And then we defined an output schema. And so I’ll show you this here.

Rich Martin • 11:20

The output scheme is understood as well. So we created something called iOS command. And by default, there’s an error. If anything happens in transformation, we can capture the error and store it. Now notice here, we didn’t check these boxes. And this is where we take this from a standalone automation workflow that can be run to a modular workflow. If I click this here, and I won’t do it yet because I want to show you the difference in a moment when we run this.

Rich Martin • 11:47

But if I click this here, it makes this particular variable, which was defined in our transformation that we defined available to a job. or a parent workflow that can run this workflow, and we’ll put this all together in a minute. Let me run this without that checkbox. So you can see the difference. So when I click that and run, you’ll see very quickly everything finishes. Again, we’re taking a look. A job is an instantiation of a workflow as it’s running, and now it’s doing the dynamic calls, API calls, and the transformations, and we can take a look at the data that’s coming in and out.

Rich Martin • 12:27

So the incoming data here from our transformation, I’m taking a look at our transformation, is the outgoing data that came from the API call. So the NetBox API call provided this data to us. Now the transformation is gonna take that as the source, and it’s going to extract it and format it the way we defined it in our transformation. We’ve built it on the canvas, and it outputs this command. So this is the data that is output, this iOS command. This iOS command obviously is in the format of pushing for a Cisco CLI command, so that’s usable for the parent workflow that we’re going to use this with. But if I click on end here, you’ll see that the end task has got these two default variables, ID and initiator.

Rich Martin • 13:14

What we want to do is we want to have this outgoing variable passed so that it’s available in this end task, so that makes it available to any job that calls this one. And this is really one of the key components of a modular workflow, is that you’re gonna have data that you want to preserve after this workflow ends and make it accessible by a workflow that has called this one. If I go back to this workflow, so I’m gonna close out that operations manager where we ran that job, and I’m gonna now click on this. This is what preserves that variable that we defined in our transformation so that it’s available at the end task, and therefore passed back into a calling workflow, a workflow we call a parent workflow that calls this modular workflow. Let’s save this. Close this out, we’ll save the whole workflow here, and then we’ll just run it again, and it should do the same thing. It’s going to get a new IP address obviously, because it’s the next one in the list there that Netbox is using.

Rich Martin • 14:19

But if I double-click on this transformation, you’ll see nothing has changed here. We still have the iOS command. But now when I double-click on the end, we have now passed that iOS command to the end task, which will now make it available to something that calls this through a task called child workflow. That’s the first step. We built this workflow no different than building the original workflow, the main workflow. We built it the same way, but now I get to extract certain information and pass it along, helping to make this a modular workflow that came up by something else. How do we call it? That’s the next step. Let’s go back to our build a workflow, parent workflow here, and I’ll zoom in.

Rich Martin • 15:06

Now we want to take this sub-task and replace it with our modular workflow. In order to do that, the key component here is to leverage a task called child job, and that’s an internal workflow engine job here. It’s called child job, and I can drag it over to here. Let’s get rid of this. We can delete and merge this. This will preserve our line, and then if I drop this right onto it. It’ll put it in line, and now we have something called child job.

Rich Martin • 15:38

So this is a task like anything else, but the purpose of this task is to run another job, and this job is going to be our modular workflow. We call it Build a Workflow 3 for Netbox. So all I have to do here is select the workflow by name. Now, if I click on this little eye, it’s going to show me the input and the output schema. So we’re not passing any data to this workflow. It’s just doing a static query to Netbox at that particular ID, so we can get an IP address from that particular prefix. So we’re really not passing anything to it.

Rich Martin • 16:19

We could, if you wanted to make this workflow a little more modular, you could pass an ID value so that somebody could select a different ID and therefore access a different prefix to use. But in this case, we’re going to keep it simple, and we’re just going to not have an input schema, but we do have an output schema because remember, when we click that checkbox to export the job variable, now iOS command shows up in the output schema when we add this to this child workflow task, and we reference that. So we can change the name here to make this a little bit easier. It’s IP address, and really, that’s all we have to do. That’s it. It’s as simple as that. There’s really no difference other than thinking ahead, and I know I led you into this in the last session, but there’s really no difference, and exposing those job variables that you want. It does require a mindset of thinking ahead and saying, okay, how modular do I want this to be?

Rich Martin • 17:26

Do I want to allow somebody to provide the prefix ID? or do I want to keep that static? Now, this particular modular call, maybe it should be named something like, get IP address from Netbox for prefix x, y, z, or whatever that prefix name is. To be more specific because it’s nailed down to that particular ID we set statically. But if I wanted to pass a variable to it, we could do that, thus making it a little more modular. Those are some of your options as you’re building these things out. I’m keeping it simple, but I’m going to show you an example of input.

Rich Martin • 18:06

This is an example of outputting variables, but I’ll show you in a moment when we do the ServiceNow ticket creation, the example of input and output. So let’s think this through in our next step. So we’ve now added a new data source here, and that data source is the IP address from Netbox, but the transformation is turning it into a CLI command. So by default, that variable is now available, but we have to integrate it back into the workflow somewhere, somehow. So the thought is, okay, when we make our iOS change, where does that data come from? And if you remember our previous sessions, it’s this transformation here. This transformation, if I double-click it,

Rich Martin • 18:46

was created to get data from our form. Remember, our form is going to ask the user for which network device you want to make a change on, and it’s a drop-down. Then it’s also going to ask for what’s the port description for this new interface. That data comes from this task, and it’s being referenced from this task. This transformation can now manipulate that data to create the CLI commands to push to the Cisco device. We want to now put an additional command into this that comes from this data source from NetBox, and it’s now setting the IP address from the next IP in that prefix that we just pulled. So that’s that iOS command that comes from this particular task.

Rich Martin • 19:31

So now what that means is once you start to integrate these child workflows that are modular, you may have to update your transformations to match those. And so I’ve already updated the transformation because the change is not that big, but I’ll show you when we update it here, build a workflow, and I just called it four because this is session four. you’ll notice that the form data is still there and we’ll have to define it, get input from user. So I’m saying the form data that this is requiring as one of the sources is gonna come from our input form and that variable is called export, but you’ll notice this is new. This is what I added to the transformation. We’re now saying there’s another source of data that we want to include in this transformation. And I’m just calling it from NetBox query because that’s what we did.

Rich Martin • 20:24

We created NetBox for the next IP address. And that also is gonna come from another task. And that task is this child job, get IP address from NetBox. And it’s already selected because it was the immediately previous task and job details. That’s the output that it’s gonna come from. I’ll save this, and then let’s take a look at this transformation and the change that I made to it. Again, if you’re going to start to integrate these modular workflows, they become sources of data that you’re going to use in other places most likely when you output their variables.

Rich Martin • 21:01

Now you might have to update some transformations to utilize those. In this case, everything up here, the only thing new I’ve added was this particular input schema here and it mapping into this array, and I’ll explain it, so I’ll give you a good look there. This is the only thing I added. From our previous session, we already had form data, we already created this. This is extracting the two pieces of information from the form we’re showing the user in our very first step in this automation. We’re doing all the manipulations so that we can provide two variables, a host name, an iOS command that’s required by making the task that makes the change to the network device. All we’re doing now is I’m adding another source and that source comes from our child workflow that we’ve just created, and that’s the iOS command.

Rich Martin • 21:55

Now what this is saying is, this transformation requires another input schema coming from another task, and that’s going to be coming from child workflow, and we expect it to give us this variable called iOS command, and when this variable is there, we’re going to map it into our array. That array holds all of the iOS commands that we’ve generated, and then it’s going to save that as an array that gets pushed out into this variable iOS commands. When it does that, that sets everything up so that it can be used when we make the network change, that particular task that makes the network change. If we run this now, You’ll see as our example output. We’re running this with example data that we derive from our inference from JSON objects, and you can see the net last sessions on how to do that. It makes it super simple to create these incoming JSON schemas.

Rich Martin • 22:55

But you’ll see here the addition of this. This came from that child job that we just made modular. It used to be just these two lines, now we’re adding this. That’s that Netbox query, getting the next IP address, and then putting it in the format that’s applicable for an iOS command for that particular change. And now we’re defining that as an input source and then utilizing that. So this is the whole transformation to accommodate that new data source that was our child workflow. So now let’s go back to our main workflow.

Rich Martin • 23:31

Yeah, I’m OK. I really didn’t make any changes there. Let’s go back to our workflow. And let’s talk a little bit about the next two tasks that are StubTasks that we can now update and turn from StubTasks into actual modular workflow. So those two are around service now. So this is creating a ticket and updating a ticket. So these two is what we’ll tackle next.

Rich Martin • 24:00

Again, these will be child jobs as well. The key to this here is that knowing that a regular workflow can also be utilized as a child job in a bigger workflow is the key to this. And so what opens this whole thing up is let me step away from our platform for a moment. And let me take you to our website. So if you go to itential.com, if you just navigate to Products in our pre-built collection, This is so key because as you’re working and building automations in our platform, all of this whole entire pre-built library is accessible inside of the platform. This is a great way to view it outside of the platform, but all of this is accessible inside the platform.

Rich Martin • 24:46

When you start to search, like for instance, we’re about to do some service now, modular workflows, you already see that we’ve created several workflows and any of these automations can be utilized in your parent workflow. We want to make it easy to start to leverage a lot of these reusable tasks that we’ve published so that you can just bring them right into the platform and utilize them because that particular workflow is usually built so that it can be done in a modular way to save you a lot of time. Now, that’s one option. Obviously, another option is to build one from scratch like we’re doing, or to take something that’s already been published in our pre-built library and modify it based off of what your organizational process is or your unique needs or those things. We want to give you all those options, and any one of those three options is super simple to do because you’re just building a new workflow, and you’re just determining which variables to pass on to a parent workflow as a child workflow. That’s really it. I’ve just created very simplified versions of this because this is hopefully giving you all the foundations on how to build these. Let’s take a look at this. This is creating a change request ticket.

Rich Martin • 26:03

I’ve named it Modular ServiceNow CreateChangeRequest, and this looks very similar to the Netbox one. The first thing we do is we identify the direct API call to ServiceNow. We talked about that in the last session and probably the session before of how to identify those things. It’ll require a little bit of looking through the documentation or looking through the API documentation that’s onboarded in our platform or perhaps in their platform and their documentation resources because those API calls are defined by them and we just read them in through whatever documentation they have available that gets imported into the system, integrated in the system, so that could be OpenAPI or Swagger spec. And so when we choose those API calls, remember, we pull them from the task palette, drop them down here and then once they’re there, we understand the variables that are required or defined by that API call. And so in this case, it takes some identification of the object because they’re a little less specific for this particular API call and service now instead of defining each one of these variables individually, they prefer to pass an object with these variables set. You’ll see it both ways, like for instance, in Netbox, they define a lot of variables that can be set.

Rich Martin • 27:23

So they’re very specific. In cases like in the ServiceNow particular ServiceNow call, they’re saying, hey, just pass us an object called body, and you define the variables as keys and values. Go back to our integrations and transformations to understand the basics of JSON and how to set this up in an environment. But basically, I’m statically assigning all of this just for a test. Obviously, we could take an input variable for summary or name or any of those things and dynamically change those that would make this a little more modular. But in this case, we’re just going to use this statically set because this is, again, another example of outputting data from the change request. This is important because when you’re creating the net new change request, if you want to update that change request later, you have to know the particular ID of the change request, and that’s given to you when you create the change request.

Rich Martin • 28:18

When this call is completed, we want to pull that data in to this transformation, and this transformation is simply going to extract the ID that we need. This is going to take data from the ServiceNow request, and it’s going to output our change request ID. That’s the transformation variable that I’m calling it, change request ID. Notice I’ve already pre-clicked store output as job variable because I intend to use this as a job modular workflow. That’s an example of that. Now, let’s take a look at the, I call it close change request, it’s really update change request. Because all you’re really doing here is you’re updating the state, and the state can be new, it can be review, it can be implement, it can be close.

Rich Martin • 29:06

Closing is just changing the state, that’s what this does. But you’ll notice I’m putting a transformation before the API call directly into service now. The reason why is because this is an example of passing a variable or data from the parent workflow into the child workflow. This is the other side of creating a modular workflow. If you want to make this modular in this case, I want to be able to change the state of a request, but I don’t know that request ID, so it has to be passed in. We got that from our initial create. and so that gets saved as an output variable.

Rich Martin • 29:44

I just showed you that in this last one. Now, when this gets called, this transformation is going to expect that data to come in, and be available, and when it is available, then it’s going to extract it and then pass it to the change request call to service now. In this case, you’ll see the change ID that’s being derived from this previous task, and then the body similar to the last one where we set the body with a bunch of notification, information, and title, and things like that. I’m just changing the state to zero, and this is going to move it from new to review. There are some other processes depending on how you implement your service now that may require certain steps before you can close. But even a close is just a change of state based off of a particular process. But changing the state is really what we’re going for here.

Rich Martin • 30:40

Okay, so with that, let’s take a look at the whole workflow as it sits. We don’t really need to show creating new child jobs. It’s the same process as we did before. So I just took those modular workflows for create a ticket and updating a ticket. I created the change, the child job, I drag it in, I replace the stub task, I reference the modular workflow that we created, and basically that’s that. And so now when we run this, let’s take a look, we’ll take a look at, it’s gonna complete pretty quickly, but we can take a look at the individual tasks and identify that data as, you know, the data being passed through child jobs, through transformations, things like that, as it progresses through. Let’s run this and then I’ll zoom in.

Rich Martin • 31:31

Again, our first step is to require the input from a user. If you remember, I can work this task. It’s going to give me a form to fill out. This is all definable in our platform through a low-code Canvas. The first section here is a drop-box with elements in it. I’m going to choose this. This is the device we’ve been testing on. Then an interface description so that we can set the port interface description.

Rich Martin • 32:01

I’m just going to give it that. Click confirm, and now it will progress through, and that data is now going to be used in this transformation. But before it gets there, it’s going to run our child task, our child job task, and let’s take a closer look at that. It’s already successfully executed, but we can take a look at it as we’re managing this job and looking at it task by task. If I double-click this, I can see the incoming variables, there are none. Because remember, we didn’t define any incoming variables for this one, but we did for the close or the update task for service now at the end. We don’t have anything here, but the outgoing variables, we should have something.

Rich Martin • 32:39

In this case, this is the outgoing variable that was created from our transformation, that we click that checkbox to say, hey, pass this along as a job variable so it can be used in this parent workflow. The other thing to note here, if I right-click on this and click open because this is a child workflow and it runs as an independent workflow under that child task. Sometimes it’s helpful to see the independent steps from that. If I right-click and open, then I can see the independent steps from each one of these. Then ultimately, what we got and what we’re looking for is the job variables coming out of this, so that this was passed along. This makes the data from this workflow usable in the parent workflow. If I want to go back to the parent workflow, I click here.

Rich Martin • 33:29

Now, that was the task we looked at. We can take a look at the transformation. In the transformation task, we were passed that iOS command. Remember, the outgoing should give us the host name and now all three of those commands to pass to the network change task that we have a little bit later. Now, here’s our next child workflow, modular workflow, child job. This was the create change request ticket. It doesn’t require anything incoming as a variable, but it does give us the change request ID.

Rich Martin • 34:08

This is critical because we need this to pass to the update task at the very end of this. This is why we exported this out. This is why we clicked that checkbox that says change request ID, pass it on as a job variable. This makes it accessible on this child workflow. Now, this is pretty standard stuff from our last session. We run a command template, we do an evaluation, it passed it. Now, it’s actually pushing the change command.

Rich Martin • 34:35

If we double-click here, we can take a look at the outgoing. This is after this is run, and we can see here that the commands we pushed are those three commands. This validates that our transformation that we updated up here, is taking that in and appending it to the array, that came from the NetBox child workflow. Then of course, the status is success, which is what we’re evaluating here. Because the status is success, it’s continuing down. It’s running the command template for our post-check process to make sure the device interface is up. Finally, the evaluation is passed because it is up and it’s online.

Rich Martin • 35:13

Then finally, here’s the last piece, is the child job that we created, a simplified child job to update the change request ticket. In this case, this requires data coming in, and remember that change ID, and the form data is what we’re really looking at here. Sorry, the form data is passed in. We’ll take a look at the job in a minute. But outgoing is the validation that everything was complete when it made the update call. Really, the final evidence of that is if I go into, we’ll take a look at one thing here. Let’s go back up. We did this ticket in this child job.

Rich Martin • 35:54

and we look at the incoming data. Actually, we probably need to open it so we can look at the direct API call. This is the direct API call to create that new change request ticket. This is the ID that we extracted, but we want to take a look at this. This is the human readable number. That’s output and it’s 34553, that’s the ticket number. If I go into our ServiceNow instance, we refresh it, 34553, I believe that’s what it was.

Rich Martin • 36:32

34553, here’s the ticket. It created the ticket, obviously. Now, initial state when a ticket is open is new. This pushed it to review, which was that last task. So it needed that ID in order to execute that last task, which was our child workflow to do the update, and that changed the state to zero, which turns it into review, and then from there, you could close. So that brings us to the end of the demonstration. We hope that I was successful in showing you that while I left you at a cliffhanger last time, it really wasn’t that much of a cliffhanger.

Rich Martin • 37:13

All of the hard work had already been done. And really, it’s a matter of we’re thinking about creating modular workflows. A lot of times, you’re creating them as standalone to test them anyway, to test workflows. And now it’s just a matter of saying, what data do I need to export? What data do I need to import, if any at all? And then how do I fit this? Is it reusable enough to actually become a modular workflow?

Rich Martin • 37:39

Hopefully so, because if it’s something that you’re running into all the time, then that makes it a perfect candidate for that. But it’s really about thinking about how you want to pass data in and pass data out, just like a task, a common task. And so with that, hopefully that’s helpful. As you start to build your own library of modular workflows, you’ll see that you no longer have to rewrite all of these things. And that’s going to save you and your team and your organization a lot of time, and investigate modular workflows that are already available in the Itential pre-built library to save you even more time. So that in many cases, you may not have to write anything. You can just leverage what’s already out there.

Rich Martin • 38:16

With that, I want to say thank you very much. Hope to see you in our next episode of this session, which is the final one where we learn how to take this completed workflow and publish it and turn it into something that can be useful for self-service. With that, thank you very much. See you next time.