Morgan Stern • 00:01

Hello, this is Morgan Stern, VP of Automation Strategy, and welcome to our webinar on how to streamline and orchestrate service order fulfillment with the Itential app for ServiceNow OMT. In a little bit, we’ll be joined by my colleague, Karin Munlingo, who’s the head of solutions engineering, who’s going to walk us through a demo. But in the meantime, let’s get started. I wanted to set the stage before we jump into the attentional for ServiceNow OMT integration, and really talk about the landscape as it’s been for a long time in the telecom world. Historically, there’s been one stack that’s focused around service order management, meaning that’s the software that takes the order from customers, decomposes that into the services pieces, and then executes on the fulfillment of those services. Sometimes it happens in an orchestrated fashion, sometimes it is a manual activity to be able to turn up the customer. At the same time, there is a network operations stack that’s focused on performing network maintenance of the infrastructure, on performing day two changes to the network, and that set of tools around network operations.

Morgan Stern • 01:15

And in some organizations, that capability is augmented through orchestration and automation platforms to automate a lot of the day two activities within the network. Additionally, there’s almost like a third stack around service assurance that isn’t represented here because we really today wanted to focus on day zero, day one, day two, change management. But you’ll see we’ve got really two sets of technology talking to the same network pieces. Everything around order management is one set of software, everything around operations is another set. While that has served the telecom industry for quite some time, it’s becoming less and less viable to maintain these two separate stacks. One from a cost standpoint, but second from a functionality standpoint. That as new kinds of services are being introduced, there’s this demand for being able to expose different capabilities to end customers for things like self-service.

Morgan Stern • 02:17

And at the same time, the products themselves are starting to evolve such that there are a lot of operational changes that service providers are wanting to expose to the end users. One example would be if it’s a security service, they want to be able to let the end customer self-manage the policy rules. And we’ll be talking a little bit about that during the demo. So what we see is that the environment has started to evolve, that those components that are actually interacting with the network are starting to be consolidated, at least from a platform standpoint, so that the tooling that needs to be able to talk to all of the different technologies in the different network domains is really being driven through that. Thank you. Thank you. things like multi-domain service orchestrators, or cross-domain orchestrators, right?

Morgan Stern • 03:10

And these orchestrators are being called on in some cases to perform service activation and service fulfillment. But at the same time, these capabilities can be extended pretty easily to the network operations needs. So that one set of platform can really be serving both day zero, day one, and day two activities, which means a couple of things. One is obviously I have less situations where multiple tools are trying to talk to the network, which not only is redundant, but also can introduce some security concerns. But that means I only have to integrate at one point with the technology. That also means that I can start to offer up these capabilities in multiple different ways. And while today we’re talking primarily around service order management, a lot of these things can be extended to operations to be able to say, okay, if I’ve got these building blocks and these set of tools, I can start to selectively offer these capabilities to my end users as a self-service.

Morgan Stern • 04:14

So that you really start to create this capability that looks much more like an environment where you can truly do network as a service, and you can start to do very coordinated actions across both the service level and then the network infrastructure and operations level. Before we talk about the Itential for ServiceNow OMT, I just wanted to also kind of set context to say the partnership between ServiceNow and Itential is really based on this recognition that the platforms are very complementary to one another and that our focus is different and subsequently the tooling and optimizations are very different. If you think of ServiceNow, you typically think of orchestration around people, processes around IT systems and things like that. And so from a capability standpoint, heavy, heavy focus on service management, this growing focus on order management and like inventory activities, as well as service operations. Whereas at Itential, our orchestration is really network facing and the problems that we wanted to solve were more around how do I create a platform that can be very adaptable to different technologies to address that problem of integration, to say if we could eliminate all of the friction associated with integrating new devices, new systems, new vendors, new technologies. we could unlock a really rich set of capabilities. So the attentional platform, really our focus is around service fulfillment, around service lifecycle, around network orchestration and automation, around infrastructure orchestration, so that we can share that capability with ServiceNow.

Morgan Stern • 06:07

We’ve been evolving our level of integrations with ServiceNow, and we’ll talk about the different pieces later on. But the idea really is to say, for those folks who are users of both ServiceNow and Itential, we can offer some really compelling functionality for the whole lifecycle. Then for folks who are looking to get past that historical monolithic service order management OSS stack that has become really problematic in terms of its flexibility, its agility, and its cost. The old stack really hasn’t proven to be capable of supporting the needs of the business going forward for agility, for new service capability, and for this evolution that people are talking about, the whole telco to techco evolution. We think by partnering with ServiceNow, we offer a pretty compelling story in terms of capability around agility, around flexibility to be able to offer new capabilities, and to offer a simpler way to interact with the network for day two operations. The things that we have focused on around this I-Tential for ServiceNow OMT application, I’ve already talked about the integration flexibility piece. But it extends a little bit further even, that by integrating I-Tential with ServiceNow, it really becomes a single integration point by which we can offer access to all of the different kinds of technologies that we’re connected to, which means less maintenance and management of those integration spokes that are responsible for talking to the network, and really a focus on how can I optimize that stream that I have to I-Tential to be able to offer all of the capabilities.

Morgan Stern • 07:59

We’ve also had a great track record of showing how we can help service providers transform existing services that were very manual step intensive into fully orchestrated service activations and service management. And at the same time, start to offer a really streamlined way to get new services developed, realized, and operationalized to be able to capitalize on the opportunities that are present in the market today. So as we’re showing you the demo, you can kind of think in two different terms. One is this is becoming a mechanism by which you can turn existing services that are very manual action intensive into orchestrated services. But at the same time, you can leverage a lot of the capabilities in the platform to create new, unique, differentiated, high value services that can enable service providers to remain competitive in the market. The thing we focused on with OMT was really about how can we streamline the whole service order management, the whole product creations kind of set of actions, and around how can we streamline fulfillment of the services. And so once you start to look at the ways that you can publish, create, compose, consume the services, you start to see that this becomes a real accelerator as you’re moving towards new capabilities and new services.

Morgan Stern • 09:37

We also have done this integration very consciously of saying how can we hook into the entire ecosystem so that we can minimize the amount of tools and platforms that folks need to be able to manage their network and to be able to manage their services. I’m going to explain some of these things using an example, because I think it really helps folks to visualize what’s going on. In this case, we’re talking about a fictional new product called Managed Application Hosting. What I’m representing here is how it would look from a hierarchy within a product catalog within ServiceNow Order Management. But this catalog concept goes beyond ServiceNow to really any kind of service and product catalog within the telecom environment. At the highest level, you have the product, that’s the sellable piece, right? And that the product is then decomposed into customer facing services.

Morgan Stern • 10:40

So cloud infrastructure service, access network service, security service. There are times when a customer just wants to purchase a capability, not necessarily focused on a specific vendor or a specific product, but be able to say, yes, I need a security service. They may not care that it’s being delivered on Palo Alto or some other platform, just security service. But for the service provider to realize that service, they’ve then gotta do that bottom level that’s in blue. This is the resource facing service. This is the service that actually is implemented within the network around talking to the vendor’s equipment, doing the configuration and provisioning and kind of handling the activation of the service. What we’ve done with the ITENTIAL for ServiceNow OMT application is give users the ability to auto publish ITENTIAL automations into the ServiceNow product catalog as RFSs.

Morgan Stern • 11:41

Once we do that, we’re providing all of the information that’s required as you’ll see in the demo. We’re providing that as part of a service specification in the product catalog. We’re using standard interfaces, in this case, TMF633 to publish that specification into the catalog. Now, the product owner has a much simpler way of being able to construct the product because they’re starting to get these building blocks that are published into their catalog, that they can construct in all different kinds of ways. I think that this combination of being able to publish and then also as we’re publishing, we’re setting up all of the paths on the receiving side of Itential, where we’re listening via TMF641 to be able to take orders for that service. And when we’re taking orders, we’re providing all the standard capabilities you would expect from an order system around being able to provide status, around managing those things, and being able to execute on the fulfillment of the service. Thank you very much.

Morgan Stern • 12:50

Now that we’re at this point, I’d like to hand things over to Karin, who’s going to give you the demo of how do we put all of these pieces together.

Speaker 1 • 13:00

Thank you very much, Morgan, and hello everyone. In today’s demonstration, we’re going to cover a few pieces on, you know, the integration between Itential and ServiceNow to facilitate the capabilities as well as the value that Morgan covered at this previous part of the presentation. So as part of the demonstration, we’re gonna do three of them today. And the first demonstration, we’re gonna show how infrastructure teams can easily build automations within the Attentions Automation Platform, but also very easily publish that as a resource-facing specification into the OMT portfolio, right? It’s gonna be a product catalog that’s gonna be utilized in order to create innovative products within the OMT product line. The second part of the demonstration is gonna focus on how does Attention actually facilitates the decomposed service and fulfillment of those RFSs that are part of a higher level product, right?

Speaker 1 • 14:00

We’re gonna actually show a real example of a managed application hosting as outlined here within this demo architecture and a product set where we’re gonna be delivering AWS cloud services, SD-WAN and network services, as well as security services as part of the orchestration. And the last part, which is the last demonstration, is gonna focus on some of the day two capabilities where providers can actually expose some of these automations as a service externally via an API or CSM to help facilitate faster consumption of all the capabilities that the providers are actually exposing. So with that, let’s go ahead and jump right into the platform and we can run through all of these demonstration in the upcoming minutes. All right, so with that, to kick off the first part of the demonstration, which is to publish an automation easily as an RFS, which is a resource-facing service within the OMT product. So what you’re currently looking at is the Itential Automation Studio. This is a canvas that a lot of infrastructure teams will use in order to actually create automations against various different domains, integrating into various different systems to actually provide an infrastructure-facing service. So in this example, we’re currently looking at an access connectivity automation.

Speaker 1 • 15:30

As you can see, as part of this automation that someone built within the team, the network team is interacting with Netbox APIs, Infobox APIs, but also your existing scripts and playbook assets, along with some of the controller APIs. In this case, we’re interacting with an SD-WAN controller to actually activate some of the policies in order to provide this access connectivity, which is required as part of the wider product. This is just an example, and as you can notice here on the left-hand side, this is a task palette. How do we enable multiple different domain-specific teams to participate and create these automation very rapidly? As you can see, these are all the on-boarded integrations. Itential has close to 280 integrations open to multiple systems here. These are some of the ones, these are just a sample set that it’s actually on-boarded within this demonstration platform.

Speaker 1 • 16:28

As you can see, there’s Teams, there’s GCP, there’s Azure, some of the controllers down here below where we’re interacting with even ServiceNow through an API and Panorama, which is a security controller. So from our standpoint, the more customers would integrate rather easily into their existing technology investment, the faster they can build some of these automations and expose that as a resource-facing service as part of the product catalog northbound within OMT. What we’re going to do next is we’re actually going to take a look at one of the existing automations here that the teams have already built as part of the Federated Development Program. Let’s take a look at Azure. What I’m going to look at is a deploy virtual network. As you can see, this is composed of a lot of API integration into some of the Azure native services, some of the Cloud native services. When I focus on one of these, when you see a concept of child job, these are actually modular automations that have been created to do specific things.

Speaker 1 • 17:38

But as a whole, it actually creates an entire virtual network that might be needed or required as part of a wider product. We’re going to discuss that in the next part of the demonstration. But let’s stay focused on this one. The Azure team or the Cloud team actually took advantage of potentials capability and its integration into Azure services, and use the drag and drop capability to build some of these automations out. At the end, when the automation is actually executed by a human or a machine or even part of the product catalog, it delivers a custom virtual network that is required to host some of the application services. But the more interesting part is what is actually required to kick off one of these automation, from a consumption perspective. As someone builds out an orchestration or an automation with an intentional, the Automation Studio automatically starts keeping track of what is actually required.

Speaker 1 • 18:37

As you notice here, when I drag and drop additional task or bring in additional scripts and those scripts have parameter requirements, it automatically gets added to this incoming schema. If you pay attention to some of these like location, resource group, the name of the virtual network that might be required. When we publish this automation as an RFS, all of these parameters are going to be exposed as part of the RFS Service Northbound within ServiceNow OMT. Why is that critical? It’s critical because over time, as infrastructure teams continue to enhance their automation, we want to reduce the friction of what is required to actually execute the automation, so we don’t put a lot of burden on some of the Northbound OSS or OMT systems. In this case, what we’re going to do is we took a quick peek at what is required, which was auto-generated. What I’m going to do is go into Itential’s self-service portal, which is Automation Manager here.

Speaker 1 • 19:39

Where we’re going to take a look at is, we’re going to search for Publish, and this is an out-of-box automation that’s available to all of our customers, the OMT customers, where when you build one of these automations, now you have a choice to make, do I want to expose this? Obviously, after building the automation, testing it against your environment, now you’re ready to expose this as a service or as an RFS to the OMT product line. I’m just going to call this Azure VNet Service, and this. Quest Azure Info Applications. Now I have an opportunity to actually look for the workflow that actually serves that purpose. Let’s go ahead and create network. Actually, just do Azure.

Speaker 1 • 20:40

Deploy virtual network. This was the overall top-level flow that includes some of the other subflows within the attentional ecosystem. As soon as I kick this thing off in the background, it kicks off an automation, which is going to automatically understand what is required to consume that automation and publish that as an RFS. What I’m going to do next is jump right here. You’ll notice these are some of the already published resource-facing services in order to support some of the other products. What I’m going to do is refresh here, and you’ll notice there was a new one that got published. This is exactly what we named it.

Speaker 1 • 21:18

This is exactly what we wanted. When I click on it, it gives you a few details about the service specification. Currently, it’s in draft mode. Once you’re happy, once you review, you would publish that for consumption at the product level. But first, what I’m going to do is jump right into the specification characteristics. You’ll notice these were the characteristics associated with this particular RFS that were automatically created and generated within the ServiceNow OMT product. What this enables you to do is over time, as you’re versioning your automations, you don’t have to do a lot of work in order to actually create some of these specs.

Speaker 1 • 21:58

These will be auto-generated and then you can version those. Then you can actually associate those with version products when those are rolled out as an enhanced services. This was our first part of the demonstration, where we showed how someone would take advantage of the attentional automation platform and the studio capabilities in order to create one of these automations or orchestration, and how we can take advantage of some of the self-service capability within Itential to expose that as an RFS, as shown here within the ServiceNow ecosystem. This is a great segue for us to get into the second part of the demonstration. Now that we understand how infrastructure teams can expose these RFS build automation and expose them as RFS, now we’re going to talk about how can those RFS be utilized to actually roll out a product for the end consumer. What I’m going to do next is click on the Manage Application Hosting product specification. This is an already created product, and you’ll notice how this product is actually taking advantage of some of the exposed RFSs down below.

Speaker 1 • 23:18

In order for us to actually provide the Manage Application Hosting service, it requires the provider to create the infrastructure on behalf of the customer. It requires the provider to also provide access connectivity, which means changes into the SD-WAN strategy and configuration or your datacenter, and then finally, your security from a machine or a user access for those application end-to-end. These three legs actually make up this product. What I’m going to do is quickly just as a reference, show that these RFSs are actually, again, workflows within the attentional automation platforms. As you can see here, the security rule, panorama automation, AWS Cloud Infrastructure Automation, and access connectivity. If I were to jump back to Automation Studio, these are the ones that were already created and published as RFSs within ServiceNow OMT catalog. I’ll quickly click through this.

Speaker 1 • 24:19

This was the first one we looked at. Finally, this is the one where we modify and add security rule to support that product northbound. Now that we understand how the RFSs help make a product up, what we’re going to do next is in order to support the second part of the demonstration, which is to show the audience how Itential facilitates fulfillment of these infrastructure services so the product can be delivered to the end customer. We’re actually going to kick one of these things off. We’re going to emulate as the end user, we’re going to fill out a form. This could be this particular product. has an API, so it could be invoked via the customer’s portal itself or from CSM or from ONT, or it could be from an API endpoint.

Speaker 1 • 25:14

From our perspective, what we’re going to do is take advantage of another application that Attentional has exposed within the ServiceNow Store, which is called the Attentional Automation Services app. As you can see here, in this case, to emulate the end-user portal, I’m just going to point to an existing automation platform, and it federates all the existing automations that are already exposed to the end-user. The one that we’re actually going to kick off to show you how the product actually gets decomposed, and how Attentional actually delivers on the RFSs from a fulfillment perspective, this is a form that we’re going to fill out. Obviously, this could also be invoked via an API, as I previously stated, but for the purpose of this demonstration, let’s quickly fill out this form. We’re going to call this Attentional Automation Service. We’ll just call that as the application that I’m trying to launch, call it 0.0.0.2. Then I would ask for a CIDR block for my own application here, and we’re going to ask for a 24.

Speaker 1 • 26:31

I would like the Platinum service in this case, and for deployment region because our team is located in North America, that’s what I’m going to choose. Then from a type, I’m going to go in and ask for a Dev environment first. In this case, it’s asking me for source addresses. From an access perspective with respect to security, I would like to provide a sample IP address, and from a destination perspective, whenever this actually gets hosted within the CIDR block here, so 1234. All right, so that’s an example. So at this point, I’ve provided all the information that is required in order to kick that product off. And someone may ask, like, how do you know what is actually required?

Speaker 1 • 27:17

So if I were to go back to the product that has been created and hosted as a consumable piece within ServiceNow OMT, you’ll notice the product itself has nine pieces of information that it requires from the end customer, right? But we’ll quickly see, once we kick off this product, the RFS themselves have their own sets of inputs, right? As you saw early on, when we publish one of them, it’s not necessary for us to ask the customer for every piece of information. Reason being, because Itential can integrate into many systems, we can actually do that as part of our own infrastructure-facing orchestration, right, we can actually dip into the inventory, we can dip into another source of truth or the network itself to fetch enough information to provide this product. So these are the nine fields that are reflected here. What I’m going to do is I’m going to go in and kick this thing off. What it has done, it’s actually interacting with the product API to kick off that request within ServiceNow.

Speaker 1 • 28:24

So if I come back here, what we’re going to do is go back to the list. We’re going to click into the customer order. So you’ll notice there was a new order that was kicked off here, which is 1314. As you notice, the state is currently new. What we can do is I’m going to go and approve this. Once it’s approved, acknowledged, and in progress, we’re going to quickly go into the order line items here and take a look at all the order characteristics. As you notice, the customer provided nine pieces of information, but these were automatically fetched from different sources.

Speaker 1 • 29:02

These are all the parameters and attributes required for us to actually deliver every piece of RFS that supports that product. Let’s see what the breakdown looks like. You’ll notice it automatically generated the order tasks within the ServiceNow OMT product here. At this point, because we have included change management as part of this demonstration, what I can do is I can individually kick off one of these order tasks when I need to. There might be a sequence, but at the same time, the ServiceNow OMT product also enables us to create a decomposition sequence where once the product is approved, it will automatically kick off all of these RFSs in a particular sequence or in parallel to support product fulfillment. But for the purpose of this demonstration, what I’m going to do is let’s go ahead and kick it off with the Cloud infrastructure. What I would do is come over here, move this into qualified,

Speaker 1 • 30:04

We’ll save this. And at this point, I can create the outbound fulfillment request. So when I click on this particular button in the background, the OMT application actually interacts with the Attentional Automation Platform via, you know, TMF 641, in order to actually kick off the request to Attentional so it can fulfill the automation, the orchestration, and the service that is requested here. So let’s go ahead and do that here. Okay. And we’ll get some activity responses. It has been initiated here.

Speaker 1 • 30:37

So in a minute, what we’re gonna do is go back into Attentional and see what does that actually look like. But before I do that, what I’m gonna do is to support the demo speed here and to showcase a proper fulfillment of the entire product, I’m gonna go ahead and kick this thing, all three of these services off at the same time. So let’s go ahead and qualify this. Save. And I’m going to create the fulfillment request towards Attentional, and I’m gonna do the same thing for the connectivity service, right? So now that we have successfully assessed what is actually required to deliver the product, and the requests have been made to the Attentual Automation Platform.

Speaker 1 • 31:21

What we’re going to do is quickly dive into the Operations Manager application here, as you can see. So this is what actually gives you an operational view of who has requested automation towards Attentual and how it’s actually being delivered. So as you notice, you know, these are all the ongoing jobs. Some of them are already complete. This is the one that’s currently going on. So if I were to click on it, you will notice this is the current state. So this is within Attentual where the request already came from OMT to fulfill the access connectivity piece of the puzzle.

Speaker 1 • 31:56

And as you notice, we are, you know, successfully reaching out to various different systems to actually fetch the information, and then we have successfully delivered. So at this point, you know, the expectation is all three of the automation and orchestration already ran within the Attentual platform. And we have successfully communicated northbound to OMT ServiceNow that we have delivered and fulfilled the requested service. So if I were to go back here. You’ll notice we automatically change the state to close complete for this specific service order. And, you know, we can click through for all the other ones. We have done this for the Panorama rule as well. And also for the ITENTIAL, you know, the AWS cloud infrastructure.

Speaker 1 • 32:44

So at this point, what we have successfully shown and done here, if I were to click refresh, three of these requests were kicked off towards Itential, you know, from an RFS fulfillment perspective. And you saw an example of how Itential fulfilled that. And we communicated the status back to ServiceNow in this case. So at this point, you know, Itential has done its part in changing the infrastructure to support the customer’s product request. And now what we can do is go into the PO here, the product order. And because everything was successfully delivered, you may choose to close it. So now at this point, we have successfully delivered a product to the end customer, where Itential facilitated the fulfillment of all the pieces of the puzzle that were required against the infrastructure.

Speaker 1 • 33:35

If I were to actually go back to one of these service orders here, one of the main pieces that we also do when we actually go and create and change the infrastructure, we also update the PI, which is a product inventory here, the record. If I were to click on this and go into this section, you’ll notice we have successfully added the source IP. This is what was provided by the end user on what client would actually get access to the application and the data sources potentially on-prem. This enables us the API communication and the two-way interaction that we have from my potential to service now enables us to constantly update the product inventories that are being delivered on behalf of the customers, and any changes that are actually made within the infrastructure on behalf of the customers. This way we have an audit history, but also the customers can see what does their actual service look like. This was the second part of the demonstration where we showcased how the RFSs were utilized to form the product, but also we showed as part of the demonstration, how Itential actually uses its capability and its integration to fulfill the required services here. What we’re going to do now is for the third part of the demonstration, we’re going to focus on some of the day two changes.

Speaker 1 • 35:02

We’ll hang in here for a second. You’ll notice, as part of the managed application hosting product, we had to make some security rule changes and maybe created some objects within the security domain. But from a provider’s aspect, to provide a self-service portal or capability to their end customer makes the customers happy because they can rapidly make changes to their existing product and services without having to face a lot of friction, right? Instead of making phone calls, now they can actually make API calls or fill out their own forms to make changes like security rules and providing additional clients or users access to their own application. So the third part of this demonstration is going to focus on us being able to modify an existing product set, which means we’re going to change some of the rules as part of their security leg of their product and enable more access to more people within their organization. So let’s see how does that work, right? So what we’re going to do now is to emulate.

Speaker 1 • 36:09

You know how end customers could take advantage of the self service capability and it could be via, you know the CSM Product within service now right within CSM. They can take advantage of all the existing capabilities and connections that they have so when they become a customer and Because I order this service as part of the funko international group You’ll notice these are all my customer orders and this is the one that was recently completed So if I were to click on it It will tell me exactly what was ordered and what I currently have and this is the one that we’re currently looking at Right. So as you can see, there are multiple different ways to expose day to operating operation services to the end customer in today’s demonstration what we’re actually going to show you is You know, we’re gonna emulate just a form like we did for the initial product order But in this case, it could be a form or it could be an API So, let’s see, how does that work Before I actually kick one of these things off, I’m going to quickly jump into the Automation Studio and show you what the day two security change automation actually looks like. You’ll notice here, someone part of the security team actually created this automation to enable a pre-check in place to say, hey, the new rule or the new IP client or the client that the customer is trying to add or whitelist, does that already exist? As part of this flow here that the security team actually created to support this day two capability, you’ll notice we’re interacting with Panorama using the native APIs. But at the same time, once we actually determine that the rule actually does not exist, we can go make that change, so we can update the security pre-rules or the post-rules. But at the end, we can also notify service now and update the product inventory, so they can clearly see what the customer actually requested and which IP was actually added to their existing product. So this is the underlying automation and it’s actually being exposed.

Speaker 1 • 38:17

So when I go back to the self-service portal, let’s take a look at this automation. You’ll notice this is a workflow in the background that gets executed and how it’s actually exposed. So you’ll notice there is a form. So there’s a manual way of actually invoking this automation. The customer may fill out a very simple form providing, and when I click on this, you’ll notice it asks for the company name, product inventory, the source IP that you want to add, and maybe a business justification. But at the same time, let’s say we want to expose this to the DevOps community or the AppDev community, and they don’t want to fill out a form. You also have the ability from within the attentional platform to expose that automation via an API endpoint.

Speaker 1 • 39:02

So I can now give this to the DevOps team and they can include that as part of their pipeline in order to invoke and request that product change. For the purpose of this demonstration, what we’re going to do is again, take advantage of our attentional automation services app that’s already within the ServiceNow store that customers can download. When I click on it, you’ll notice the same form that you saw within attentional also gets exposed here. So now what I get to do is I can say, hey, this is a company name, this is a product inventory, so this is the one that I’m going to choose because that’s what the firewall change PI is. I’m going to go in and add so we can clearly see this source IP. The justification is, application. So I’m done filling out this simple form and I’m going to go ahead and run this automation.

Speaker 1 • 40:02

So one of the critical pieces that I wanted to call out is just like we were able to expose this automation shown here via an API endpoint, all of these automations being created within Itential by various different infrastructure teams, is also available as an action within the ServiceNow Flow Designer. In order to support that day two change, you’ll notice if a service catalog entry was added and filled out and requested, maybe a rhythm gets created. When the rhythm is actually updated and approved, that actually triggers the automation within Itential. You’ll notice this add member to firewall group, is actually a step that calls that very automation that we saw here, which is exposed via an API, but also it’s exposed via a ServiceNow action within the Flow Designer. You can imagine how providers can take advantage of this capability to have all of these things that are considered day two services, exposed in a way where someone could be filling out a CR or a CSM entry and based on what they do and the state of those particular artifacts within ServiceNow, it actually triggers an automation within Itential. This is what facilitates faster consumption of infrastructure services.

Speaker 1 • 41:27

Now that we have kicked it off, what we’re actually going to do is go back in here, go to all jobs, and let’s take a look. You’ll notice it’s successfully completed. This was a day two automation that was kicked off via that portal, but it could be via CSM as well. We have successfully reached out to Panorama, done some pre-checks. We’ve actually made the rule change here. As part of the final product, the final result, what we’re going to do now is go back here. All right. So this was the one that the user actually selected.

Speaker 1 • 42:03

from the form that they wanted to actually change. What we’re going to take a look at now is because the automation successfully ran, we’re actually going to go in here and take a look at the product characteristics. You’ll notice here, in addition to some of the other members that were added, we’re showing the audit history and an update to the actual source here. This was the latest and the greatest requests came from the Funco customer. As part of their product change, which shows how customers have the ability to take advantage of the self-service capabilities via APIs or consuming that within their own pipelines. But at the same time, making sure that we’re updating their existing products, and the inventory, and the record of those products. That way, it’s highly visible to them on how many folks are actually interacting and making changes to the existing product that they already have established.

Speaker 1 • 43:05

That was a third part of the demonstration that showcased, existing automations not only could be exposed as RFSs, but also could be exposed as a self-service motion, which potentially helps our customers and the providers make it easy for the customers to take advantage of all the infrastructure services they’re actually providing. That was the last part of the demonstration. What we’re going to do now is hand it back to Morgan. I’m going to stop sharing my screen. Morgan, please take us away.

Morgan Stern • 43:41

Okay, Karan. Thank you for that demo. That was great. Just to wrap things up, as we launched the Itential app for ServiceNow OMT, as you’ve seen, the goal was to provide a solution that would tightly integrate the ServiceNow order management capability with the Itential platform, both to enable publishing to the service catalog for faster and more innovative product realization, but then also be able to take the orders. The whole goal here, as you’ve seen, is we need to be able to accelerate the introduction of new services and accelerate the whole transition from manually configured and manually fulfilled services into orchestrated things. We think this is a unique solution in the market, but as I mentioned, this is really part of our overall integration strategy with the ServiceNow folks. So you’ve seen Itential for OMT. Previously, we released the Itential ServiceNow app, which provides exposure of the Itential catalog for service management activities. Later, we introduced the Itential Actions.

Morgan Stern • 44:52

Here, we’re providing a set of actions that ServiceNow users can incorporate into their ServiceNow workflows and subflows to make calls to Itential, either to execute orchestrations, or to just run specific commands, or to interact with any of the systems that we’re integrated with. All of those things live up on the ServiceNow side. They’re available in the ServiceNow store today. You can download them, install them, and use them. On the itential side, we have the ServiceNow adapter. The focus of the ServiceNow adapter was to provide access from within itential orchestrations to make calls into ServiceNow, to do things like create new tickets or interact with tickets, to trigger ServiceNow flows. But basically, anything that you would need to do to be able to make calls from itential side into ServiceNow, that’s all available in the adapter.

Morgan Stern • 45:49

Our vision really was to have a full lifecycle approach. So while today you saw what we do with order management, we also have a robust capability around change management, either through that kind of order stack of providing it, the functionality through OMT as a change service request, but also there are many kinds of changes that may happen in day two that may be exposed through service management, or may be exposed to end customers through service bridge. And similar to how we’re providing interaction with inventory as part of order management, we’re providing that same kind of interaction. So supporting multiple paths for changes, so that folks have the flexibility to offer the self-service capability in the way that their customers want. We’re also focused on the whole troubleshooting and remediation, self-healing kinds of actions, but also self-service interactions for troubleshooting a service or providing remediation of the service. Here, we’re talking about integrations with service management components of ServiceNow, as well as with some hooks into service operations, and we’re going to be doing some additional work this year around that piece. For ITENTIAL users who are already familiar with our golden configuration and compliance capabilities, these can be hooked into service management or can be used within the context of GRC so that you can use the compliance capabilities of ServiceNow, leverage the functionality that’s available within ITENTIAL to provide fully automated compliance remediation actions around configuration standardization.

Morgan Stern • 47:38

And then finally, the kind of end of the service life cycle, which is really around how can we do effective service termination, when do all of the cleanup work that you need to do both on the Itential side, but then also with the inventory side and the billing and whatnot. And that’s going to conclude our webinar for today. We really appreciate the time that you took to watch this. Looking forward to additional webinars that we’re going to have around some of the ServiceNow use cases in integration. But in the meantime, that’s it for Karin and I, and hope you have a good day. Thank you.