Rich Martin • 00:03

Hello, everyone, and welcome to another Itential webinar. Thanks for tuning in. Today’s exciting topic, and I promise it will be exciting, is how to connect ServiceNow to your infrastructure with ITentual. And as a bonus, it’s also to drive more efficiency in your IT infrastructure delivery. As always, my name is Rich Martin. I am the Director of Technical Marketing at ITentual, and I am excited and pleased to be joined by my friend and a colleague here at ITentual, Ankit Bansali. Ankit, why don’t you take a moment to introduce yourself?

Ankit Bhansali • 00:37

Hey, Rich. Thank you. Name’s Ankit Bansali, and I’m a Senior Solutions Engineer at Itential. Thank you.

Rich Martin • 00:45

Fantastic. If everyone will give me just a few minutes to indulge in some background and some context, it’s super important, especially for this webinar, when we talk about integrating with ServiceNow. There are multiple ways that we talk about integration in our platform. If you spend any time listening to any of our webinars or looked at any of our content, you’ll know we’re all about integration. It’s important to set stage here when we talk about integrating with ServiceNow, because there’s multiple ways to do it, and we’re going to be highlighting a very specific way. When you think about this, you’re really taking two different platforms, the ServiceNow platform and the Itential platform itself and allowing them to talk to one another, and we’re using APIs in order to do that. But in one case, and I think if you’re familiar with Itential, we released a ServiceNow app for integrating into Itential, and that’s number one here in the pink circle. This is something that a ServiceNow administrator within the ServiceNow platform can find in their marketplace, their App Store, download, and install into the ServiceNow platform.

Rich Martin • 01:54

Once it’s configured and installed, it allows you to directly access workflows and automations that had been published within the Itential platform. It simplifies the ability to do this through the application, and even gives you a nice GUI interface so that you can dynamically generate a list of published applications that you have access to. So that’s one mechanism of integration. The second mechanism I’ll discuss here is number two, through itential actions. And you’ll see it’s highlighted here simply because this is the focus of this particular webinar. We wanna highlight itential actions and show you not only how they will operate inside of a ServiceNow flow within the platform, but also what you can do with them to drive more efficiency when you’re delivering infrastructure across your different IT domains. So the ServiceNow action itself is part of the, so when you download the application in ServiceNow, you get access to all of these actions.

Rich Martin • 02:50

And this is what we wanna spend a little time showing you the actions, how they work, and how you can start to implement them into your ServiceNow flow. So really the focus of this is going to be very specific to helping the ServiceNow developer or anybody building flows in ServiceNow using Flow Designer to how to leverage and use these actions. Number three, we have a very specific application that exists within the ServiceNow platform called IAP for OMT. This is very specific to telecom. So this is order management for telecoms with an associated piece of that application that exists within our platform as well. So you can see there’s another piece of that there. We won’t be talking about that, that’s very specific, but that does exist as another form of integration.

Rich Martin • 03:40

And then finally, another form of integration that we do with ServiceNow is really from within the ServiceNow platform. So the top three here, it’s almost as if ServiceNow platform is kind of a user of Itential, right? So we’re integrating into the Itential platform with the origin point being ServiceNow, and that’s what we will be focusing on. But let’s not forget a lot of automation and integration that occurs within our platform uses an adapter that allows a workflow to speak to the ServiceNow platform to accomplish some number of tasks. A lot of them around ticket management, like creating tickets or change requests or incident tickets, things like that, updating them, modifying them, those kinds of things.

Rich Martin • 04:23

So the ServiceNow Adapter is something that exists within the Itential platform that allows now a workflow or anybody building a workflow to leverage a series of tasks in a workflow that can communicate directly to your ServiceNow instance to do functions within their ticket management, catalog requests, things like that. Exposed through the APIs that are integrated into our system. So you can think of it in terms of Itential becomes a power user of ServiceNow in that regard. And so with all that being said, that sets the context. We are gonna be focused on number two, which is around actions themselves. Really, what are these actions and how do you use them? If you take a look, and we’re going to get into a deeper dive, so I won’t spend a lot of time on this, but an action is within a ServiceNow flow.

Rich Martin • 05:12

If you’re building a flow and flow designer, an action is the ability to integrate to a existing Itential automation platform that you have deployed, in order to do a number of things, but ideally, it opens up a lot of new capabilities within your ServiceNow platform. The one capability we’re going to open up here is because it gives you the ability to integrate, authenticate, run a workflow from ServiceNow in the Itential platform, but also receive data results and things like that, back from the network through the Itential workflow back into a ServiceNow flow. This opens up a tremendous amount of capabilities. Probably the primary capability is being able to, from ServiceNow, fill out a request form or a service catalog for some infrastructure services, and running a workflow from the underlying flow that gets triggered by that request, running a workflow in the Itential platform to actually provision and deliver that particular request. That’s what we’re going to look at today, because that allows you to deliver infrastructure, whatever it may be, network security, even compute, through a workflow on the Itential platform and deliver it with basically like cloud-like efficiency. They click, they request, it gets approved.

Rich Martin • 06:33

And ideally you’re saving a lot more time over manual processes. But because you’re also working, these workflows can do things like provide real-time operational network data that might be useful for a ServiceNow flow as well. So these are more capabilities than you normally have because you’re executing a workflow that can do a multitude of things in our platform across a lot of different infrastructure domains. So you can get real-time information on what a particular part of the network looks like if you needed to. You can also dynamically query for a list of applicable automations that have been published and you have access to, as well as being able to take a look at the metrics of a particular workflow that has been executed, which may be really, really useful for streamlining your IT service flows. And so for this example, we are definitely going to take a closer look at how you can drive more efficiency by executing workflows that deliver infrastructure, services, and resources. For this, I want to bring in Ankit because he really gives us some good perspective.

Rich Martin • 07:39

He’s worked not only as an expert in our platform, he is by far the most expertise person I know at Itential with ServiceNow, and he’s worked with a lot of customers and prospects on how they can start to go from how they’re delivering infrastructure requests in ServiceNow today into how to integrate with Itential so that they can become more efficient in delivering those infrastructure services. So Ankit, please give us a little color on what you see today when you start to work with customers and prospects on how they’re delivering self-service catalog requests in ServiceNow.

Ankit Bhansali • 08:16

Yeah, thank you, Rich. Yeah, it’s a very important to understand. ServiceNow has been a de facto for, you know, organization, large scales, large enterprises to take in IT infrastructure requests. And we’re trying to make sure that they not only get the benefit of what they have built in ServiceNow, but also leverage Itential and hand off problem statements where Itential can automate things for them instead of doing the traditional approach of doing everything manually. So I’m going to give you a real world scenario where that’s how folks usually, you know, implement these kind of designs and solutions. So for example, we learn on how integrating ServiceNow with Itential can streamline IT infrastructure requests. In this slide, like we are sharing, we are demonstrating three use cases, creating a DNS aid record in Infoblox. It’s a very common implementation of a request from a ServiceNow team. Adding a new ingress rule in Panorama. It’s again, a very common request. Adding a ingress rule in a security group in AWS.

Ankit Bhansali • 09:33

Again, very standard cloud operations ServiceNow request. Before we bring in Itential, this is how teams were managing these requests. You would have ServiceNow catalog, which allows users to request these structured IT services. And we would have typically an engineer, would go in, fill up a form that would trigger a workflow. Once the request is submitted, ServiceNow automatically generates three distinct tasks, each assigned to appropriate team. So if you were to have a complex network request that needs these three separate legs of services, you would have three separate tickets associated for each team. Without Itential, they would do this process where each team would get a ticket and they would assign team managers and engineers on that ticket once the request comes in.

Ankit Bhansali • 10:35

The DNS team would then look at the request, you know, and they would have to manually log into Infoblox to see, is this record already there in Infoblox? Am I overwriting somebody else’s record? Is this IP already in service or reserved for somebody, you know? So they would have to do these manual checks by themselves. Similarly, the network security team, when it gets the request, they would have to go into Panorama and manually look into Panorama, see if the rule exists. Is this a good policy or is this a good rule that they should allow folks to, you know, access the network through? You know, does it have any inheritance based on the different rules and regulations around that kind of domain or infrastructure?

Ankit Bhansali • 11:28

And similarly, the cloud operations team would do the same, where they would log into AWS, look at all the ingress rules. If they have to prioritize one over the other, they will have to reshuffle. So there’s a lot of manual work that goes into serving this request. I mean… It is doable, but like for how long and and how standard is this process is is the question because This is how the world has been working so far and they would have their own set of tools here and there to help them But there’s not not a streamlined end-to-end automation that gives them the validation that the checks and balances and also making sure that You have the record and the audit trail of the complete change from request to to execution Does that help you paint a picture of the world without itensual debt? That’s how ServiceNow and Teams use and leverage ServiceNow.

Rich Martin • 12:25

Yeah, that’s great Ankit. And so just to summarize, you have a user requesting some sort of infrastructure service from a self-service catalog that exists in ServiceNow. That is composed of three separate infrastructure resources, right? And in this example, DNS, AWS and Firewall Teams have to do, they get their own requests and they have to do something within their tool sets, within their domains, within their applications in order to fulfill their part of the request. Again, these are all parallel tracks that they have to do. And sometimes they’re interrelated. So you have to wait for one to finish or you need some information from another perhaps, depending on that.

Rich Martin • 13:11

But because of that, and this is the way you normally do it because it’s been difficult to integrate these three different types of requests, in some cases, completely different infrastructures, obviously different tooling here. Being able to automate that process that they would have to do manually has been difficult. And so this is where a lot of organizations find themselves. And so typically speaking, how long can this take if one or many of these teams are doing these things manually?

Ankit Bhansali • 13:41

Right, that’s a very good question because that’s where when I talk to the directors and managers, they generally share these numbers and they tell us that they’re trying to optimize, they want to make sure they are getting best out of their engineers and they’re not civil sharing to serve these requests. And I think you made a very important point. When there are complex service requests or network requests coming in, there’s a dependency that also builds on one team delivering a solution in the right timely manner and in the right format so the other team can then layer upon those other requests. Usually when we are talking with these customers and prospects, the DNS team would manually log into Infoblox, create a record, validate it. Depending on bandwidth availability, manpower, headcount, this could take from a few hours to a couple of days. The same is true for other teams, generally speaking, because there’s security involved, right? Since you’re poking a hole in the network, you cannot just deliver it just because somebody knows somebody, right?

Ankit Bhansali • 14:53

That’s what I hear from a lot of these customers or the operations team. Like, if you know the right person in the organization, you can get it done faster. But how about we build a standard process so everybody can have a SLA defined and we can actually, you know, gauge the requests and the deliverables in a timely and efficient manner again. So again, it depends on a lot of factors, but the folks that talk about these setup is usually takes from hours to days to weeks. And the reason being they need to validate that changes, not just their changes in the network configuration, but they also have to collaborate with other teams to avoid conflicts, which again takes time because if somebody goes on PTO, you have to wait for that person to come back and explain where they are providing that kind of information. So the other team can, you know, carry that request forward so that they can deliver the request.

Ankit Bhansali • 16:01

So while this process works, right? I mean, this is working right now. It’s not that the world just started yesterday or something, right? This process is working, but it’s prone to errors. That’s what I would like to highlight. Especially when teams work in silos without a unified flow, the complexity of networks and the reliance on manual steps can lead to a lot of inefficiency, non-standard configuration, and that’s when we see why people are very hesitant on changing things on the network because of how things are built to serve this request. I hope that made sense.

Rich Martin • 16:39

Yeah, no, that made perfect sense. So let’s take a look at this. So with Itential, how can we help resolve that for them?

Ankit Bhansali • 16:48

So, I mean, the process still remains the same. That’s the beauty of the flow, right? We wanna make sure that the teams that have invested in service now are leveraging that existing business process. So we don’t want them to get away with that process. We want them to keep the process they have actually defined because it takes a lot of hours and weeks and months to define a business process to serve a request because it’s a standard which you’re trying trying and making sure folks in your organization can follow, right? So that being said, Itential is very powerful with the integration with these systems. So what we want to provide some context here is we let you build automation and workflow creation.

Ankit Bhansali • 17:38

Each team can now contribute towards automating that task by creating workflows in Itential, ensuring consistency and reducing manual effort. What do I mean by that is they can put checks and balances. They can put the same set of steps which they were doing manually. They can bring those steps into Itential workflows. These workflows are then exposed to ServiceNow, allowing product owners to integrate with them into their existing business logic for request management. And I think these two factors enable folks to contribute towards the organization’s goal of having standard requests for standard domains.

Rich Martin • 18:22

That’s fantastic, Ankit. Thanks for that. What it looks like here is through ITentual Actions we’re allowing these independent and many times siloed infrastructure teams to leverage automations and orchestrated workflows that they build within our platform, expose those to fit in almost in a Lego style, just to fit into the existing ServiceNow flow, which like you said earlier, takes a while to build and to architect and to get going. What we’re allowing them to do is really increase the participation of both teams, leveraging the infrastructure teams can leverage their tools through integration into ITentual, build workflows to model those particular processes that they had been doing manually or even partially manually. Maybe they have some automation tooling to do changes, to push changes, but they’re doing pre-checks and post-checks like you said, manually. Now they have the ability to build their own workflows modeling the existing processes, and now we can connect these two teams together. They expose through APIs and publish those workflows. They being the infrastructure teams working in ITentual and the ServiceNow teams, building flows can now call those directly through ITentual Actions.

Ankit Bhansali • 19:39

Correct, and that makes that consumption model scalable, because now you can have SMEs of each domain that can automate and provide best practices for standard change. And once you integrate Itential into ServiceNow workflow, the process becomes nearly instantaneous. It’s event driven, and it’s consistent across all requests. Because I have a philosophy, when machine handles these kind of tasks, the accuracy improves like tenfold or depending on how you’re checking for things in the network, but it’s very much increasing in terms of accuracy. And you can now build multiple levels of checks and validation throughout the process. Because machine-to-machine, API-to-API, it’s a much more seamless handoff, it’s faster, it’s less error-prone, and it increases efficiency across. Like, to your point, I’m sure if you’re trying to deliver a rule on Panorama, the security team already has an engineer who understands that concept.

Ankit Bhansali • 20:48

And the process they would follow is they would go into Panorama, make sure the rule does not exist before creating. And that same approach can be leveraged inside of the Itential workflow, where they can build a workflow that can automatically check for the rule before adding it, ensuring consistency and avoiding errors. Because there’s a standardization on naming conventions of the rule, what’s allowed, what’s not allowed. You can handle it globally on each request that’s going into Panorama. And this philosophy applies to the other two types of requests too. Because again, it’s a standard and you want to make sure you’re doing checks and balances because Itential can go into Panorama and look for things, validate things if they exist or not, or make other decisions along the way. Similarly, how an engineer would do.

Rich Martin • 21:39

That’s awesome, Ankit. Let me take a moment now to give you the demo overview in the audience. We can start to show exactly how you start to implement this, and that’s precisely what we’re going to do. We’ve mentioned Infoblox, AWS Security Groups, and Panorama Firewalls. Those are the individual resources that are going to be composed into a larger catalog request that will be initiated from ServiceNow. That’s going to kick off a flow. That flow includes Itential Actions that are onboarded through the Itential App and ServiceNow.

Rich Martin • 22:15

Each one of those actions is going to kick off a workflow for each one of those individual infrastructure teams. Presumably, they would be building these and publishing them so that the ServiceNow flow designer can start to leverage them to deliver that infrastructure as quickly as possible. With that, I’m going to go ahead and let Ankit share his screen, so that we can start to see precisely what this looks like from a ServiceNow perspective, and then even from seeing this run, and then seeing this from the perspective of the Itential platform as well. Go ahead, Ankit, go ahead and share your screen.

Ankit Bhansali • 22:52

So, I want to go into service now first, because we’ve been talking about, you know, designing these business processes, architecting it, and it takes a lot of effort and time. So I want to take you into iDenture. And before I do that, I want to take you into service now. Just a quick conversation just to circle back on what we were trying to reach, right? We’re not trying to reinvent the wheel here. We’re trying to make it more efficient. And before we do that, let’s see how folks used to do this before, right?

Ankit Bhansali • 23:25

So this is a whitelisting IP and access flow where somebody wants to have access to one part of the, you know, they want to have access to an application that’s sitting behind a firewall that’s in some data center. So that being said, usually the process is. folks would build service catalogs, which would take in inputs or take user inputs, usually forms, then they’re gonna ask for approval whether this request is good or bad. And that’s generally the flow. And this is where, depending on the type of request, if it’s a complex network request, there are times that there are dependencies on these requests where you need to have you know, parallel threads of these requests. So depending on complex network requests, you might have to deliver them independently. So that being said, in our example, we have a DNS request that gets generated on requesting a whitelist IP access.

Ankit Bhansali • 24:35

At the same time, we get a network security request for Panorama and we get a cloud operations request for AWS. So this was their existing flow, right? This is without itensual, without automation. Based on that request, when it’s generated, there would be a team that’s dedicated to delivering this request. And usually an engineer is assigned on that request and depending on their schedule times and experience of these domains, they would then try to serve this request by logging into these systems manually, which means now they have to swivel chair by firstly getting notified on the ticket, they have to log into systems, figure out the whole network topology, the network changes where they’re intended to making these kind of change. Once they feel confident, then they’re gonna push that change or make some changes into the platform or the end system. And that stays true for each independent thread.

Ankit Bhansali • 25:39

This is without Itential and this is where we were talking about, this is prone to error, this is prone to delays because a lot of manual steps are involved to validate changes. Don’t get me wrong, the engineer will do their best, but there are times where they might not be available, there might be dependencies on the request, and they might even fat finger, which is something that happens all the time. So we want to use these engineers’ background on how they deliver these kind of requests and make it automated, you know, from the Itential workflow perspective, still keeping the best practices of what the engineers usually follow. Before I transition into how Itential is making it seamless, do you have any questions on this?

Rich Martin • 26:27

No, it makes perfect sense. This is probably where most of our customers that haven’t already implemented Itential actions to start leveraging workflows directly, this is where they start from. So this should be, you know, fairly relatable to a lot of folks out there who are looking to accomplish what we’re showing them. So what does this look like when you start to integrate into that existing ServiceNow flow, you start to integrate the Itential actions?

Ankit Bhansali • 26:55

Correct. So, I mean, we wanted to make sure the barrier of entry was very low. We don’t want you to change the world. So if this is the world where you have already defined your business process, we want to be accommodative in that process. So if I go back into the one where I’m leveraging Itential, And you can take a look at this real quick. Yeah, it’s gonna look very similar.

Ankit Bhansali • 27:20

So I’ll go from the top down. Same process so far where you’re gonna have a form which is gonna take in input variables which would be any fields which are necessary to be passed down to the next task. It goes through its own approval process depending on how you design this flow. And once your request is approved, it will again create three tasks for each team independently to serve that request. What changes from the previous design is that if you look at this flow, I’ll just stay on one of these threads which is the DNS request. In this flow if you look, I just added three more boxes to begin with. And that’s all you need to actually extend it and automate it, right?

Ankit Bhansali • 28:15

So this is where we’re getting a DNS request, a ticket gets generated, engineers get assigned and they approve or disapprove. If they approve the request, instead of them logging into these systems, we’re gonna initiate a workflow which will basically do the things which they are doing but it’s automated in a standard process which means every request that goes through this kind of service will always follow standards built by the engineers and the best practices followed by the organizations. They would log into Itential platform, trigger a flow, pass on the information to the flow, so they can then create a record in Infoblox and get the status of the workflow. Now, these three boxes is where we’re going to save a lot of time. These are Itential actions that come out of box with the application. I think the ServiceNow developers would appreciate the effort because they no longer have to code every time to talk to Itential. They can leverage these actions out of the box and just point them to the right concept of what they’re trying to build.

Ankit Bhansali • 29:28

If they’re trying to create a record, that could be an API service published by the Itential developer for them to consume, and they no longer have to write code to integrate with Itential. This becomes a very seamless and a simplified way of consuming anything you build in the platform and can be leveraged in the ServiceNow flow. Is there any comment or any questions from you on this design?

Rich Martin • 29:55

Yeah. Well, one of the things I would like to comment on is you’ve provided one thread, but if you look at the other threads, they’re identical except for one change. That change is the intentional action that runs the automation endpoint, which is really the specific workflow that gets published by that specific team in the Itential platform. This is where we’re talking about increasing participation. All of these teams own their independent workflows that are built around their specific processes using their tools and automating as much of it as they can within that workflow, which is ideally all of it, and then publishing this to the ServiceNow team saying, hey, whenever you need this particular resource, you run this workflow with these inputs, and this is the standardization you were referring to.

Ankit Bhansali • 30:48

Yes, and I was trying to cut you off there for a minute. Apologies for that, but yes, you pretty much are talking in terms of how we want to leverage these teams. So we want teams that can focus on their area of expertise while contributing to a unified workflow. For instance, the security team, like you said, can automate changes directly in Panorama, eliminating manual steps. Instead of working in isolation, teams can now collaborate to publish and use these workflows via Itential. This will 100% ensure best practices and are consistently applied across infrastructure changes and can be managed more efficiently. I want to point out this thing, right?

Ankit Bhansali • 31:34

In a brownfield environment, you don’t have to change the design from a ServiceNow perspective, but what if there’s a new standard somebody wants to introduce in the Panorama workflow? They can do that without having to change anything on the ServiceNow side. ServiceNow developers no longer need to spend time manually integrating with each system, because we all know like itentials out-of-box actions, itentials out-of-box integrations, where you can quickly build these workflows that can span across multiple systems and infrastructure teams can execute them reliably over a number of period of iterations based on what they would prefer as a best practice or a standard.

Rich Martin • 32:19

Yeah, thanks for that, Ankit. This is awesome to see behind the scenes on what all this looks like. Do you want to walk us through what the user experiences would look like on this through ordering infrastructure through a catalog?

Ankit Bhansali • 32:34

Yeah, no, absolutely. Very excited to demo this because since the flow has not changed from how folks use service now, we’re just introducing Itential, and that was the pitch that instead of having to rebuild, three design business processes, we are encouraging them to keep their existing one while you can plug Itential in the portions where you are doing manual steps, and you can even spend those out, right? You don’t have to call one service that does everything. You can create independent flows and associate them in these threads, depending on the domains and the actions you want to do, and you’re no longer writing code to build these kind of actions. And to your point, you’re very true. This thread, the one that is doing DNS record is calling a service, which is create a record service. That’s the name of the trigger in Itential.

Ankit Bhansali • 33:25

The second one is adding a firewall rule, which is an access rule service. And the third one is adding a inbound rule, which is again, a AWS service. So these are three independent workflows, which are published by iTential developers into ServiceNow. And then ServiceNow flow designers can incorporate these depending on where they wanna put these in their flows. That being said, let’s get to the exciting part of how would we like to demo this, right? Sure. So let me just open another tab.

Ankit Bhansali • 34:03

And usually Rich, folks already have their own ServiceNow catalogs, right? Organizations prefer to keep things in their own ServiceNow catalog. So we have something similar. I’m gonna go into the Itential catalog, which has all the network services. I’m gonna click on one of these, and I’m gonna focus strictly on the one which I’m gonna demo right now. That is a whitelist IP and access. It’s basically helps you provide control access by whitelisting a specific IP address, ensuring only the authorized traffic is allowed, right?

Ankit Bhansali • 34:39

So in this case, you will see this form. This form is again created by somebody in ServiceNow, and this is the design they chose. They’re expecting us to provide two input fields. One is the source IP, and one is the host name. So I’ll put a source IP, which, is a random IP. This could be your IP from your network, your Mac, depending on how you wanna do it.

Ankit Bhansali • 35:05

And just because it needs a host name, I’m just gonna call this as Ankit Work Mac. So I wanna make sure that this host name is reserved for me with the IP I’m requesting from. So the process is once I hit order now, if you look at that service now process, right, there should be three tasks generated for each team to proceed with. So I’m gonna hit order now. So you can see a request was generated. Very good. And looking into the request, it is going to tell you there’s a request item generated. So now we’ll see what this request item contains inside of ServiceNow. So it is currently sitting in a stage which says it needs request approved. Very good. Because we just approved that request. And the current state is work in progress. So if you take a look at this, right, at the bottom, there are three catalog tasks generated, one for each domain. In this case, one is for AWS, one is for Infoblox, one is for Panorama. So let’s start by picking one of these tasks. Usually this will be done by independent teams. But since I’m driving, I’ll be taking ownership of all the three teams. So I go into one of these tasks. And you can see there’s a source IP, there’s the host name. Currently, it’s in the state open. Its approval is requested. So let’s go ahead and approve this. So if you look at the approver section, This is where I feel, okay, I’m comfortable. I would wanna approve this.

Ankit Bhansali • 36:45

You know, it’s the right time for me to put some configuration on Panorama or Infoblox or AWS. So I’m gonna start with Infoblox first. So I’m gonna hit Approved. Once I hit Approved, it’s gonna basically call Itential with the Itential actions to an endpoint that’s gonna serve that request, which is creating a record in Infoblox. And we’ll also check into Itential after we approve this. So, once I hit approved and I hit the check mark, it basically runs that flow where it goes out, calls Itential and then updates the comment here where Itential has successfully implemented the request and if you look at this, it changes the state to close complete and it’s already approved. So, even though it might look that, you know, it’s very comprehensive because now it’s doing all of those checks and balances an engineer would do, which is embedded in the Itential workflow instead of, you know, a human logging into Infoblox and doing all those checks and balances.

Ankit Bhansali • 37:53

Since it was successfully completed, that has moved the state of the ticket to close complete. The next one I would like to do is add a rule in AWS. So, let me do that. Same process. You see the state is open. Approval is requested. Let’s go ahead and approve this.

Ankit Bhansali • 38:13

Yeah. Rich, feel free to ask questions along the way. If anything you might be curious about, happy to chat through that.

Rich Martin • 38:22

Now, this is great so far. I think one of the things that you mentioned earlier about this is the ability to remove human error. What we’re seeing is the same variables passed from the original form in the service catalog are now passed directly to these workflows, through the intentional action. That’s really helpful to understand too. So they’re all working on consistent validated input, even though it’s being passed to three different teams using three different workflows here.

Ankit Bhansali • 38:48

Correct. And these are independent threads. You can even make them dependent on each other. Let’s say I don’t want somebody to approve the firewall panorama request if they have not added it into a info box, right? So this is where ServiceNow design and architecture comes in picture because you’re not changing any of that. You’re changing the execution layer, which will give you more efficiency, more standardization and speed to be really honest. So I’m approving my third request, which is for the panorama. And it looks like it is closed, complete, and approved.

Ankit Bhansali • 39:26

So now if you look, once all of these request states were closed, completed successfully, that is when the request actually closes itself out. So now we have delivered a request that spans into three different domains, follows three different best practices identified by the engineers, built into the workflow. And this is where we can actually successfully show that we have completed the state. But guess what? You don’t trust me, right? Do you wanna see actually in the end system, you wanna see how iTensile processes data to your point? Like, where did these variables go?

Ankit Bhansali • 40:02

How did iTensile know the best practices? How does best practices looks in iTensile flows? So let me go into iTensile. Before I do that, do you have any questions or comment you wanna make?

Rich Martin • 40:14

No, I was gonna comment. Of course, everyone wants to see the results in iTensile. So let’s take a look at that. That’s the big next part. How did this actually operate within the iTensile platform?

Ankit Bhansali • 40:25

Perfect, perfect. So I’ll go into this instance, which is the Itential automation platform, and I’ll go into the operations manager. That’s where each request that is served in Itential can be looked into. And I’ll go to all jobs. So if you look at all jobs, you can look at the time, 154, 156. So this tells you the recent jobs that were completed in the platform. And at the same time, you can see the services that came through.

Ankit Bhansali • 40:55

If you recall, we did the DNS first, and then we did the AWS, and then we did the Panorama. So it tells you that it successfully completed those. And let me jump into one of these. I like Panorama because it is crowd favorite because changing rules, you have to have checks and balances in place most of the time, and it’s also very critical. So let’s look at the firewall configuration. So I’ll go into one of this flow, which is Panorama rule service, which is basically calling another flow, which goes out and adds a new rule. I will quickly highlight on your question on how does that data come in and looks like, right?

Ankit Bhansali • 41:41

And how can I trace the request to the flow that’s coming from service now? So, Step number one, if you look at this, I’m just expecting information, data. And if you look at the source IP, that’s what I put in. I put in a host name and this is what I did not put in. It was dynamically generated and passed on to Itential. So now you can put this in descriptions and in different places.

Ankit Bhansali • 42:09

So you can always circle back with the request that came into Itential and connect it to the source, which is the service now. So you can check the task number that was generated. That being said, let’s take a look at the actual Panorama implementation flow. So let me zoom in a bit and restructure the… the screen for you guys. So if you look at this flow, and this is where I was saying, the best practices are embedded in the flow defined by the automation engineer or the SME of that domain. In this case, the engineer was like, before you put any new rule in Panorama, make sure that rule does not exist in Panorama.

Ankit Bhansali • 42:54

So we are doing a pre-check on the rule. That’s what an engineer generally does. So if you look at this. space, it’ll tell you that the object is not present. And that’s exactly what we want, because it’s a create process. We are adding a new rule. We don’t want to overwrite or modify.

Ankit Bhansali • 43:11

That should be a separate service with its own separate checks and balances. In this case, we are checking whether the object is present or not. Since it’s not present, we are doing some evaluation. This is where you could build best practices. I want to go ahead and then provision that rule or add that rule on the box. So based on the information, I provided, it was able to go make a request into Panorama using our adapted layer and then get a response back saying, okay, I successfully added the new rule. But guess what?

Ankit Bhansali • 43:42

You still don’t trust, right? You want to make sure that you can revalidate to make sure that the rule really exists. What if Panorama just send us a false positive, you know? So in that case, we also have a post checks, which is like the standard norm in network changes. You do prechecks, you make a change, and you do post checks. That’s like best practices defined by the gods of networks, right? Because that just builds faith and confidence in that process.

Ankit Bhansali • 44:09

And to do so, we do something similar. We pretty much make the same call that failed in the prechecks, but in the postchecks, if you look, it comes back saying, okay, I have a count one, which is the rule. And I see there is a rule that is named the way you want. So this gives us that confidence, which is built by the expertise of that automation engineer. And that is pretty much true for each of the flows. that is defined in this case, where each one has their own best practices embedded in each flow. Rich, any comment or questions you might have on this?

Rich Martin • 44:47

That’s a great example, because as quickly as you approve that from ServiceNow, it was executed and completed. And a lot of times you might think, well, you’re just executing a blind change, right? You’re just running one step to execute a blind change. Actually, while you could do that, what we’re really doing is we really are modeling this manual process. And while this looks complicated, to the engineer who’s building this, this is what they do almost subliminally every single day that they have to do a manual change. So what we’re doing is we’re saying, model your process. What are the stipulations?

Rich Martin • 45:22

What are the contingencies? What are the rollbacks that you would normally do? You start very simply in a workflow. It could start with pushing a change, but then you need to think about what do I need to check before I make the change? What do I check after? And that could change over time, right? You may add more checks.

Rich Martin • 45:37

Now that you’re automating all of this process, you might say, you know what? We have time to do even more checks, right? Or something may change in the process that says we are now required to check this and to check that as a pre and a post check now. So this gives you a tremendous amount of flexibility while maintaining efficiency. And like you said, and I love this part that you said earlier, is the network team can now modify their workflows that are applicable to their day-to-day job without impacting anything that needs to be done in the ServiceNow flow itself. The ServiceNow flow is simply executing the workflow that these particular teams are publishing and they’re responsible. It’s their methodology, it’s their tool set, it’s their environment.

Ankit Bhansali • 46:20

Correct. And just another point here is the time and the standardization concepts, right? Even though you see it took one second, I mean, that’s automation for you. Like nobody can log into a system, process that much information, figure out the right place, the right rule to put it in one second. But I’m going to drop the time matrix. Instead, I’m telling you you’re getting a standard which will be true for all requests, which most of the organizations definitely want over speed because that’s quality of configuration, which also leads to better network health, right? So even though everything took one second to do all of this function, which is, I mean, tremendous, like, I mean, imagine how much times this can be event-driven instantaneous delivery of requests where you build best practices in the flow while I actually execute it, you just couple it with your snow business process.

Rich Martin • 47:18

Fantastic. Well, they say the proof is in the pudding. So what about the end systems? Can you walk us through the end system so we can see the actual changes that all of these workflows were able to execute?

Ankit Bhansali • 47:30

Yeah. No, 100 percent. Happy to walk you through the systems. Do you have a favorite one to start with?

Rich Martin • 47:38

I’m at your disposal. You’re the expert.

Ankit Bhansali • 47:40

Got you. So let’s take a look at Panorama first. So let’s go into Panorama because we are sharing that flow, and I’ll just do a quick refresh here just to see. Yeah, this is the one that came in, number 6, OnKit WorkMac. If you look at this and if you try to click into it, it’ll tell you all things about this rule. There’s this feature I like is the audit trail, which I think a lot of managers do request, and they always want to connect the source with the execution. So they can always come back in time and review those changes if they have to. If you look at this, this is a request for Ankit Mac and the number, request number coming from ServiceNow is associated with the rule.

Ankit Bhansali • 48:28

Tomorrow when you’re doing audit or trying to migrate things, you exactly know where it was originated and you can go to the source where the requester, and you can even talk to the person who requested this. This is where you can tie a lot of these things together. Like you can see, the request comes in, there is a name, there is the IP address, and since you’re asking for access for a web application, it’s telling you it’s going to be in this zone. That’s something on panorama. Feel free to chime in if you want to make a comment or have a question.

Rich Martin • 49:04

Now, you’re doing great so far, but I love the ability to pass data along. That particular request ID was passed along from ServiceNow through our workflow and now passed into the Palo Alto rule that was built. Like you said, you have this correlation of not only the change but where it originated from.

Ankit Bhansali • 49:23

Correct. Correct. Yeah. And it’s very important. Like I’ve heard a lot of these directors and manager when they design this, they want to make sure everything is tied together because when they try to move a service or when they try to change, they want to have that one connecting thread that tells us, you know, how everything is coming together for that service. So, so very important point. Thank you, Rich. That being said, let’s check it out in the second system, which is the Infoblox. And you can see there’s nothing here. Let’s hit refresh. And there you go. We are in the DNS section, data management of Infoblox. And you can see this thing that came in and you can see the name, you can see the A record, the data and any other information that you might need for this record is there in Infoblox. The third one, I’ll go into security groups. So if you look at this, the number is 15 because I’ve not refreshed the browser. But when I do that, this number should be 16 as it is. And you would see the traffic that came in. So if I slightly move on the right, I should see the IP address, which is 192.112.443.

Ankit Bhansali • 50:38

And I think, and this is what I was saying, you might forget what you requested, but you can always have that connecting thread and you can find out, figure out who it belongs to. So if you look at this, it’s 192.112. If you go back to security group, it’s 192.112. And it’s only for HTTPS because that’s what the service is providing. So that basically concludes my demonstration on how we expose itensual workflows in service now and then consume it from service now and follow those steps to actually execute them in a much more standardized, efficient way.

Rich Martin • 51:17

Ankit, that was incredible. I appreciate you taking us through all that detail, putting all of this together and showing us, not only the Itential stuff, which we’re obviously partial to, but really focusing in on the ServiceNow side of things, diving deep into flows, how you pass data along, and really how to leverage these Itential actions so that you can help the participation between all your different infrastructure teams along with your ServiceNow teams to help drive more efficiency ultimately for the end customer and ultimately to deliver value to the business. Ankit, thank you again very much for all the help that you’ve given us today and for being my partner today. But I also want to thank everybody in the audience, and if you have any questions, feel free to reach out to us. We’re always available to you, and we look forward to seeing you at the next webinar. Thank you very much and goodbye.

Ankit Bhansali • 52:15

Absolutely, my pleasure. Thank you, Rich.