post a link to this about Digital Services Forum this has everything that we use to get our content out there so there's this Zoom meeting that you guys are on now so you found that link already there's also a home page and this home page is on the community that that's where we share all the content so if you want to go and find a deck that we use because you like a slide or two or some old code or a link to some demo inside of our instance that'll all be you'll be able to get to all that from The Forum home page there's also YouTube playlist that's where we keep the videos so there's a there's kind of a reference back to the YouTube playlist onto each of the different blog posts on the community for each of these meetings so that we have a little bit of the content and you know have it all together with the video and the content that was shared during that meeting and then there's also a shared instance that we have and sometimes people like to do demos on that shared instance so anybody who sends me an email I eventually get you an admin account on that instance I think last count we had about 160 admins on that instance it's it gets a little sluggish at times but it um it gets the job done it has a lot of our content on that was developed for for these meetings okay so like I said I'll post this link that'll get you to this page and if that's the one link you remember from the Digital Services form it has a reference to all the things that you need to get to for any of the the content that you'll see the a little bit about why we created this group we created the group originally because a lot of people were just confused about the cmdb as we moved on we learned more and more about the cmdb the people we're trying to do a cmdb they were trying to do digital transformation and use the cmdb as as a launch pad for that so we switched over to really focusing on digital transformation and more specifically to enable the members that come and join us to be part of their own digital transformation we share all the work we can so we have discussions like we'll be having today there's papers there's that shared instance that we put code on whenever we can or configurations it's not always code and make that available so that people aren't doing the same things over and over and over again the group that I'm in is the Enterprise architect group with servicenow and we're the ones that host these meetings so there's always one of us on even if it's just like kicking it off like I am today but also a rune is on our team as well so he'll be our speaker today and the structure of the what we've been doing for the last five years actually since 2018 are these bi-weekly calls this is the main way that we get information out but there's also other things we've done like workshops and things like that along the way okay so today we're going to talk about uh like I said it's gonna pretty typical case study format that a rune's going to take us through today we're just going to talk about the current state he's going to talk about how they re-designed that current state and then how specifically how they standardized within that design and then we'll have some time at the end for Q a but if there's things along this the way that come up in chat so things that you might post I might just stop a rune if there's something in context where we can do it there so we might interrupt and bring questions up along the way you don't have to wait till the end but definitely get your questions as we're going into chat all right just a little bit of a setup before I hand it off to a room we always tie back what we're doing almost every single meeting to the common service data model in some way and just to make everybody familiar real quick I always use this intro where there's four domains of the common service data model the design domain is when people decide what they need they need a capability and that helps them decide what to buy what applications what platforms to buy before they can use that could get any value from it they need to hand it to a build team and the build team are the ones that configure it or write some code to make it work for their organization but that build team cannot operate without the operations team so the operations team is down in the orange here these are all the people that that turn that application on that make it available for the organization and then only then can you deliver back into the domain where we're giving people what they want right we're giving them Digital Services in some form whether it's at the business consumer side or the technology consumer side for technology for more of a technical portfolio okay so that's what we're doing today we're really focused on this area so roon will spend all the time down here we don't jump around in the other areas that much and more specifically he's going to be talking about the um the requests right the request parts to come out but just keep in mind these requests are typically going to be connected to a business service that has a service level commitment right so a lot of a lot of these work hand in hand uh the catalog requests that we'll see going out work hand in hand with those Business Service offerings that we uh love to talk about so much and that's a quick intro so with that I'll I'll welcome maroon I'll let you do more of a formal introduction introduction to yourself [Music] yes I do I'm going to share now excellent uh hopefully we can get this thing up I'm going to share first and then hopefully everybody can see my screen looks good yep thank you um so uh thank you John that was uh that was a very good setup and intro and leading into you know uh most of the meat of my presentation here but before I start a quick uh intro about myself um uh like John mentioned I am a peer of his and we are colleagues uh get some opportunities to work together um and I put I personally work mostly in the federal space uh but I do have background in healthcare and other parts uh you know the other domains um and you know typically we all come from different domain backgrounds and also some roles that we have played and I've been in service now like two weeks two and a uh two years and three months now uh but I have been in the service now ecosystem for more than 11 years and in that I've kind of been a platform owner also BP of digital Solutions uh where uh you have the challenges of uh you know doing more with less you know and you know you're part of some digital transformation uh which I think most of you are interested in and which is what I was a part of but prior to that I was an implementation partner of service now so bringing all these together what I'm trying to do here is to bring a specific experience that I've been through uh and which I've seen a lot of customers kind of facing the similar uh scenarios and challenges and prioritization so I thought hey why not kind of uh you know use this uh case study as an example to highlight some of these things so um I just want to set the stage that this is a conceptual presentation of an implementation and it's about an approach uh and it's not based on a specific version of service now not some specific uh new functionality Etc things that have existed on the platform for a while now uh and it is this discusses the you know the original implementation was classic workflows but there's no reason why it cannot be implemented in flow designer and I'm not going to go into code and you know we have limited time here so I want to kind of give the gist of what really we faced and how we went about it and you know what benefits cannot be derived from that right and obviously you know I have no qualms and no delusions that this is like a perfect thing there's always things that can be done to improve this and I'm not really even talking about the full implementation because I want to kind of give you the the core of the implementation and the architecture and and then you know you can see where some of the other parts can be improved upon uh I do want to call out uh my former colleague uh and uh who has who still kind of managing this environment uh and Prashant if you can just identify yourself uh you know you know I might reach out to him for some more technical depth because he's a senior software engineering manager at the customer uh Prashant can you just say hi um of video so if you uh and so people can uh will know that you're here and we'll have questions yeah hi Arun this is a prashan from Magellan Healthcare so I'm the servicenow platform owner at Magellan looking at the platform all the enhancements and different modules uh for my team thank you okay thank you prashantha and you know um based on how we position this thing Prashant is here in a personal capacity but you know he's willing to share all his uh knowledge about the the platform and how it is working um and it continues to work in this way right so going further in um uh as they say necessity is the mother of invention right so I use that metaphor a little uh extended leap but here here's the background that we were uh in right so we had a business critical ticketing system that was implemented across three business lines I mean lines of business uh and it there was a fourth shared service organization so you had four different major uh business units uh that were the customers of this um of this service catalog and these Services included both I.T and business requests and there was a need to migrate from a legacy on-prem ticketing system to service now and I specifically call out that as a ticketing system to service now because it was primarily a ticketing system it you know it was not the platform that service now pretends to be a protest to be but it was a ticketing system and there was an end of support for the Legacy system causing immovable deadlines so with that uh since servicenow was only in-house and it was not yet being used for service catalog it was being used for you know uh major incidents P1 incidents and some parts of the operations I.T operations Management in terms of uh events and service mapping and things like that so the platform was already in place uh but the we needed to move the services from the old Legacy system to the new one uh and with this we kind of saw that there were around 350 services to be migrated around 16 000 end users both employees and contractors uh around 450 fulfillers in various different areas of the organization and the organization was undergoing exponential Transformations I'll take just a couple of minutes here um to call out and uh kind of give attribution where it needs to be given is exponential transformation is a book that was written by uh Yuri van giese and Saleem Ismail and it's it's a whole uh approach to transforming organizations but the CIO uh had specifically taken that to do the exponential I.T transformation so only I.T but it also kind of started uh seeping into the areas of the business so you know uh other than the actual approach to exponential transformation you know it was the cloud first SAS preferred mobile first buy and integrate all of these things that you typically hear about and this happened Circa 2016 right so that's when it all started um so there was a quite a quite a lot of change going on in the uh way things were done in the way processes were being approached and we were doing things like value stream analysis and we were looking at every process whenever it was identified for the transformation so with all of this churn and things happening uh we had uh also a Workforce that needed to be uh kind of transformed at the same time so we were trying to do all of these things together so these you know this I'm just trying to set the stage saying this is the kind of environment we were in and one of the approaches that we were also thinking about was hey why not we delegate the deployment I mean uh this is a lot long before you know the uh low code no code was was considered you know as a uh in a buzzword we were thinking we should delegate it increase the uh resources available so we can get these things done faster faster so we had a Federated approach that we were trying uh to train people on service now workflows and catalogs and all of that was going on at the same time so we were trying to modernize but here is what we found right in terms of uh the requests that we had and the request that we had were um we we said they're all following a typical request approval task fulfillment kind of uh uh flow and when we started analyzing the 350 uh different Services uh there was request one approval one task close or request one approval one you know task one task too close so you see the different types of request patterns that we observed within the set of uh 350 services but some of them were really one-offs so they didn't fall you know very cleanly along these lines and they had needed to be addressed specifically everyone every one of those 350 had their own yeah what's the wrong request type yeah so it was it was a different kind of Technology where it was like a form base and you heard it Define each one and it was not uh kind of uh tied into uh I mean you could not abstract out the workflow you had to kind of specify it in in the each one of the items specifically right okay so that was one of the other challenges so we said we cannot take that approach because we didn't want to uh make it a maintenance Nightmare and having so many workflows uh and for different items and you know uh incur that expense uh the end users the requesters typically requested multiple items at the same time that's the other thing that was happening but that was happening outside the system because inside the system there was no way to bundle everything right and then there were requesters that were requesting items both for themselves and on behalf of the others your typical case in point is your manager requesting for an onboarding new hire right so those kind of things were happening and here's some things that we noticed from the analysis uh you know uh of the current state was that almost all the items are approved and those that were rejected or canceled were because the requester made an error or did not need the item right so the approvals were becoming huge bottlenecks and we were was adding an overhead on the slas so I just want to pause here and see if this is kind of something that any of you in the audience have observed in your own environments that the approvals become the bottlenecks and uh uh that that kind of uh you know hits on the slas and mostly everything is approved any any thoughts any comments in the audience got some definitely in there yes we have the same bottleneck uh yes 100 100 accurate so it sounds like you're hitting the mark okay thank you uh so so I think something that there's more comments sorry uh yeah from research in the industry um that backs up that it's either number one or number two reason for breached slas the next and you know um so yeah bottlenecks the list approvals you need the better so yeah okay so uh you'll see that I'm just setting up on the theme that I'm going to follow through here right but there are some other things that we found uh we found that uh there are common groups of request items like um somebody um comes in uh and uh we were already doing things like you know our integration with work day as soon as somebody was on boarded which was two weeks ahead of uh actually coming on board it would kick in start spawning processes and we would give them Birthright applications right the birthright applications that you need time sheets access to the typical uh tools uh you know we were just spawning that and that was okay but even after onboarding there was specific roles that required specific access to certain applications and that application access was also in groups uh you know in certain groups uh Hardware workspace items were shipped to the same location and that was something that was in a group uh there were related software that we found that was in a in a common group and there were other things from the business like NDA or request for document review Etc that we had internally those were in groups so all these bundling uh bundling was required in various places in the application however uh as we were trying to analyze and we were trying to do this really quickly because of the transformation and the other deadlines that we had uh we couldn't get the bundling uh defined you know in a way that we said okay this is the bundle and this is what we're going to do for this Persona uh and in the meanwhile something would change in the organization and the bundle that we assumed would now cause uh kind of dissonance saying oh this for this case it's not true there's an exception here and we were spending a lot of time in that analysis so that is something that you also observed that the bundling could not be really defined uh to a fine-grained level so we had to kind of provide for that um another thing that we found was that low dollar value items and high dollar value items the approvals were treated same oh you send it to the manager and the manager approves and the next level manager approves and everybody still approves it and there's no rejections but everywhere it waits two days here and two days there and it causes all this kind of consternation and we said okay can we avoid some of that uh you know and you know can we just Auto approve and things like that we discussed uh but the internal audit team team said oh no no you know we needed a record of the approval that some manager has actually approved this uh you know such as application access because you want to do provision and then you want to de-provision and independent external Auditors would come in because it was Healthcare and certain systems you know who saw the data who couldn't see the data those kind of things they need to connect so with this is kind of the problem statement that we were arriving at so um yes I got a couple people on here that say um they've stopped using a lot of approvals because they weren't being used correctly um can you elaborate please yes so Josh you were one of them and then Kevin what do you guys mean they weren't being used correctly they were just so in in our experience it we would trigger a notification that goes to the requester's manager and they would essentially just Auto approve they see the the approval email coming through and just bypass it that way um a way that we're trying to start correct yeah exactly um we're trying to correct that today is more of a role-based provisioning so we've been working with our clinical teams um basically building out the predetermined set of tasks based on their position so that way our audit team knows that it's going to bypass an approval they know that 100 of the time it's going to be requested by this specific team and there's no question on the accesses whatsoever okay right so um uh and then that's that's one approach and I'm going to discuss about the approach that we do okay just in a couple of minutes here if you'll give me a chance uh just uh there was some other comment I don't want to miss out on the other comment somebody else also had a comment and Mitch had a good one here that a lot of people aren't familiar with uh about ocm right for non-it people when you start I guess you're talking about requests specifically when you start getting non-it requests in the catalog admin training yeah yeah John I mean our I.T folks are change managers especially are really used to the approval process going there reject to prove ask questions but when we're talking about non-it like uh we have a senior business officers which are basically in charge of the budgets for departments they get a notification from service now but without training and education on how to use servicenow to to either ask questions of the requester or approve or deny it just often goes unnoticed and that really lags uh it leads to a you know lagging of the approval itself and so they wind up sending an email saying yeah I approve so it does require ocm and training um and of course approval license right the department has to be willing to pay for the approver license so yeah so a good point Mitch and uh um the way I have organized this presentation is I've set up this problem statement I'll talk about the architecture and towards the end I will talk about the user experience and that's great I heard you're kind of alluding to that so that's gonna be great yeah thank you yeah thank you uh and and that's that's good discussion uh and by the way I will not be discussing anything about licensing uh I I try to stay out of all the licensing stuff uh uh even professionally in my role uh we are pre-sales folks and solution folks so we don't we leave that to the account teams so but uh I think it's a point is well taken that you have to kind of consider uh the uh the licensing uh needs as well right so so uh this being the scenario I'm going to talk about the uh the approach uh the components that kind of played key roles in the solution and then um can I give you a high level on how we did it uh and I know uh we have until 12 30 so I want to be able to uh go through some of these steps uh quickly here but I want to give it the due respect right so so here's what we did said just coming to the point that was just being made uh we said that specific items were identified for automatic approval you know like application access items with the purchase uh value less than 500 so we had to go to purchasing we had to go to the business process part of it and get approval from those uh uh those areas in the organization saying that we could do this because technically it was possible but how did we do automated approval we said we'll we'll send a notification to the approver that the item was approved with the link for rejection in the notification should the approvers choose to reject so this was like an optimistic automatic approval right saying that most of the scenarios were the item is coming in we are going to automatically approve it but we will store an approval record for audit purposes so this is how we kind of were trying to be compliant at the same time not cause any bottlenecks in the process Does this answer some of the points that were brought up earlier I think uh Josh brought up the point where you know their approach was slightly different where they they got the uh the process approved whereas we kind of maintain the records that's the slight difference uh Josh just because you brought that point want to see if uh I'm connecting with your uh uh you guys handle versus how this is being handled this is a great alternative because it appeases our audit team with knowing that there's some sort of approval record Associated to the record itself um but also give that flexibility if you set it for like 24 hours after the request is submitted or whatever it might be that the manager can reject it yeah right so so that that kind of uh uh you know we were trying to take the two different uh competing parts of the uh problem and try to kind of solve for both and this is how kind of we we came up with this thing so uh so one of the desired outcomes that we got from this was reduce the approval bottlenecks we complied with our uh auditing requirements while still providing options to reject and until a certain point right I mean after a certain point you cannot reject it then you've got to go through cancel and everything else um the other thing we did which I didn't put on the uh slide here is that um we also decided that uh you know there was really only one approval that happens in most of the scenarios it's not like approval one approval two and uh and this was a kind of a discussion with leadership saying that uh why are we first going into an approval and then when it times out when it breaches that level of uh approval SLA we are then escalating it and then somebody else has to take that on uh and you know and then we there's this whole escalation path of approvals we said we don't want to deal with any of that there's only going to be one approval uh level and after that it kind of escalates right up to very high levels so it also kind of creates a organizational kind of uh uh why aren't these things being approved and a VP level says you know why is it coming to me why aren't you guys proving it so we created a kind of a little bit of a conflict there and you know a little disruption but uh it it changed Behavior so that was count there's more on the organizational Dynamics part of it but uh we use that to make things kind of go faster remember we were in an exponential I.T environment so we really wanted to get going quickly on all of these different things right okay so so next thing we were said we'll have to make it a metadata driven uh approach to the whole flow and that's where we kind of set up a marinator model which in which you said we'll have standard flows and the catalog item will be associated with one of the standard flows and we will have approval attributes that we will know for that item as metadata and then the tasks that it goes through because we know there's standard patterns we'll associate the catalog item and the tasks and there will be like a task type and the ordinary which has to be done and we also went through to the task text so this is kind of a table structure but I'm going to show more of the form and how it would look like so you had a catalog item let's say iPad Pro uh and there's a flow name called standard metadata driven flow I made these things specifically for this presentation to kind of communicate this whole approach uh you can have any name I just went a little to Captain Obvious on that one but standard metadata driven flow and there's a record in that table you have the approval details saying is there an approval required or there's no supervisor approval required or the initial approval is by user or group or field or script and various such things options that be stored in the metadata table so that's kind of the level one and I'm going to come back to this I'm going to pause after the I explain these tables and uh open it out for questions if you need to get deeper into any of these uh table structure and the relationships Etc and then we said catalog tasks defined for that item we're going to say there's an order in which it is executed there's a type of task in this assignment group and this task test that is used inside the task so these were the kind of two main tables that were associated with the catalog item that we were mapping any questions on what we are trying to do here if not let me go one step further and keep keep interrupting me there's no uh issue I just kind of since I was presenting a new kind of a table structure Etc I want to kind of pause there so what this allowed us to do was it allowed the approval and fulfiller groups to be stored outside the flow so the floors themselves did not have specific approval groups or uh or assignment groups you know inside the flow it allowed for the delegation of changes to the domain business unit that owned the item or service what I mean by that is if you know there's a business unit that manages a certain set of uh items uh because it's something that they use and they provide uh and on the back end they are the fulfillers and there are some changes that happen in there um tasks or in their uh groups and things like that that form that I showed you you could give it you could give access to that form to those people for those items and they could come and make changes um so that did not require any uh change in flows uh and the testing was really not uh more than trying it out once because you're not changing any part of the process and it's executing and only the next time the the flow is invoked is when you're going to see the changes existing ones that are going to go through the completion so that's how we kind of try to abstract out the uh the item and the underlying standard flow with the associated uh groups and tasks that were being used I'll go one more step and talk about the flows and show how the flows use the table right again at a high level so the typical request pattern we talked about request approval fulfillment and close right um and see you said we said we'll have standard stages for all of these things no matter which flow it is they'll all follow a standard set of stages so again giving the user that consistency on how they would see a flow go through for a request that they made right um and initially here's where we started we said we're going to have one flow per pattern right we said oh one request one uh approval sorry one approve one request one approval one task close uh one request one approval two tasks close and each one of them would have a specific flow we associate the request item with a standard flow type and each flow has predetermined approval and task tips and only the groups are Dynamic what that meant is in the flow we actually mapped our separate flows which had one approval task one close one approval two tasks closed and only the groups or dial Nick so we are using groups and for approval and tasks but those were Dynamic and those were read from that table so with that what we had was we ran into like you know 10 or 12 uh workflows uh or different flows where they were addressing the uh uh patterns and the table actually had task columns separately uh and the functions within the flow would look up the assignment groups and look up the pre-degreement task uh no subflows and this approach uh although we started with this we soon realized that there were limitations to this one uh I'm saying that this works but it was kind of uh our needs were started to look like they were more than what this would help with us right help us with them so the flows and patterns are fixed the tasks were always serial scripting tasks were not supported and it was not flexible or modular enough for expansion unless we changed the metadata table and then that defeats the purpose right I mean we started with the metadata table saying that that gives us the flexibility and we can do many things with uh standard flows and it suddenly started kind of uh defeating our hypotheses saying oh we'll have to change the table if you have more tasks or more approvals and that kind of uh was going against the grain of our initial philosophy so what we do is we went kind of one step further and we said one flow for all standard padders one flow not for all requests but for the standard patterns uh that we knew of but we also knew that we could have more and we should do that without having to change the metadata table so similar to the previous approach we said associate the request Adam with a single standard flow each flow has Dynamic approval and tasks so this was the slight difference you're saying so what we are doing here you said not only are we going to have the uh the one flow but the tasks themselves are not predetermined which means it's not like you know up to five pass or up to six times you said we could have any number of tasks and they could be also run uh you know parallely instead of only serially uh and the other thing we also said is that hey sometimes we need to run scripts and we should be able to support that so those are all the things that we were able to um support uh in this more uh more apparent child way where we said there is a a parent table which is part of the flow and catalog item association with the approval details uh and a child table which would have the tasks and it could have any number of tasks and it could have different types of tasks and still keeping the stages across all flows but now we started using subflows I'm going to pause here to see if uh I'm saying something complex or something that uh I'm uh not able to communicate or you know if everything is kind of getting uh across from the way I'm explaining this James Vivian had one question I don't know if you want to come off mute um I don't know if he Arun answered that since since you posted it or um if it's still an open question okay I guess she doesn't want to come off she says so how are you going to manage a new Joiner who requires a laptop bag a laptop a gold software build plus five specific software titles for their job role all right so uh I'll just come to that uh thank you for that question Jane um uh I have the other component that I've also identified as enabling um catalog features and that's how we kind of went uh went about that approach um and I I'm sure that is one approach there are other approaches as well like somebody else mentioned where they defined a Persona based or role-based uh bundling of uh uh uh catalog items but I will get to that in a minute I just want to make a get to through the standard flows and and then move into the next one uh so any questions on the standard flow so far but I will definitely address Jane's question after that thanks I I do have a question uh so just to clarify that the standard workflows those can vary and also the socials they could vary based on each individual catalog item uh excited last part again yes can those vary based on each uh sort of work the flows and the subflows can those vary based on uh each individual catalog items yes yes yes yes yeah so kind of to explain that let me kind of give you how this thing would work conceptually right I'm not going to show code because that distracts us from understanding the uh actual uh concept here right so the request comes in and the first thing you do is like you prepare you go get to the go to the standard flow meditate table and get some of the um uh the details that you need to move forward and you set up scratch pad and you do all those kind of things and then you say okay now I'm going into approval State and in the approval I I need a resolve approval subflow what am I doing in the resolve approval subflow I'm checking whether I need no approval required or you know one of those kind of things that I checked off and if it is so then I will insert a record and do all those kind of things if there's no supervisor approval required um I'll kind of say okay then what is the approval type I want is it the user type is it the group details is it the user sorry I think it's just supposed to say field um so you can actually have a field which specifies what where is the uh approver information stored and the script results or a script that determines how that approach should happen so that's the subflow for the approval uh so again it is not kind of a hard-coded it's not specified inside you are always using scripts to go get that information uh then we go into once you've decided on the approval and that flow is kind of executing you also look at the Fulfillment part of it where you don't know how many tasks there are going to be uh and you say okay let me generate the task I look at the details from the standard flow task table and I generate the tasks and use those tasks for the current instance of that item and its Associated flow and it may be one it may be multiple it actually may be even parallel because we have this thing called order that can have two tasks with the number one that means they are going to be in parallel and then they'll come and join at two those kind of things we kind of did inside that uh inside that execution but at a high level what we're now doing is the approval is a subflow the Fulfillment is another subflow and they're all dynamically deciding what needs to be done and executing on them till it gets to close and launching of the survey you know just kind of say every every one of these things is standard so you have service for everything Etc is this part uh you know I mean this is kind of the core of this entire approach using a standard metadata driven flow reaching out to the metadata tables getting the specific uh details for that item in that instance of the floor and executing that I'm going to pause here to see if there are any questions all right two questions off for you that we had come in there's um I don't think there's any mention of using case or anything to get any additional like I don't believe case no I'll read the question out did you have to use case to create parallel uh just flipped over did you have to use case to create parallel sequential tasks if you ask how did you take care of the same oh I don't think it is case uh I mean you're talking about the inside the actual flow like switching between serial and parallel yeah I meant uh a catalog item might have a requirement to have parallel tasks yeah and the other item might have the requirement to create the sequential tasks right so dynamically uh has that been taken care in your Solution that's yes and I'm going to show you the table and I'm going to uh ask Prashant if you want to address that question also in a little more detail so let me show you the table uh that I was talking about here so if you see this table in the the child table for catalog tasks you see the order so if you see multiple tasks here and if you see two of the same order that means that becomes a parallel task and then so if so let's say there are three tasks um uh and two of them have to be done parallely and then do this so you'll have a task with order one another task is order one and the third task could order two so only after one and one are done will you go to two so that happens in code actually understood uh answers my question thank you okay thank you right yeah so that's how we kind of have so the earlier approach that I was talking the initial approach did not handle all this and we ran into kind of as soon as we started that approach we said oh no we have a problem right so that's why we kind of Bend into the so there was not much of a lag between the approach one and approach two but I want to say that if you're really not having so many different options and it's a simplest it's kind of a uh environment you can stay with the initial one and if it's not too complex right uh but this one requires a little more scripting a little more skill sets in their teams and things like that so that's why uh but but this is where kind of the the real benefits we got from the whole approach right Yeah Yeah so basically if somebody comes up with a new catalog uh flow requirements that I want to task in parallel then three in serial and then four in parallel or any kind of combination of tasks can be handled in this one table uh because the code the scripting code inside that workflow handles all these combinations properly so essentially any combination of tasks sequence after the approval is done can be handled by the same model there is no code change or there is no new code to be developed just a configuration in the child table thank you prashan that's that I think explains I hope the question answered uh I mean yeah yeah remember before you go on uh Richard asked is is this something you could Implement using item designer um now catalog Builder right because if this is mostly what you're talking about is mostly in the workflow right and the scripts that are in the workflows yeah so actually you can do it in Florida as well yep yeah yeah so but uh is that what was the question flow designer or was it uh yeah I think they mentioned specifically uh item designer which is probably too high level for this this is the next step underneath item designer yes yeah and and even in floor designer I mean the the the main flow part of it the subflow part of it is what you are really doing in flow designer you still have to get into the scripting because you make made it dynamic so you have to go and resolve some other things to do this uh but the the investor investment that you make in the scripting is like you know upfront right it's it's something that you do up front and then everything works off of that table and I'm going to kind of briefly give you the steps on how you would go about adding a new catalog item right and you'd see the steps are going to become standard uh with that every time right so uh let me get quickly identify kind of the scripts that you might have right you might have something to set up scratch pad to set up the Persistence of for the context of the flow uh you'll have a approval attributes you know go get that get the approver specifically if everybody knows what scratch Pad is okay all right let me uh uh let me um double click on that so Scott uh what happens is when you have a flow running it is running in a context in that session and when you want to pass uh variables and values or constants from one flow to the other or want to use it in different actions within that same flow instead of having to pass it back and forth you can actually set up something called a scratch Pad where you are persisting the values that you started in an earlier action or activity and use it use it later and it's available throughout that session and it is not something that's available across sessions it is just within that instantiation of that flow so it is available so because we we don't want to keep going back and reaching to the table you get it once and you put in the scratch pad and then you don't have to go back and read the table again so it's a little bit for efficiency and also to kind of do it once and use it many times right so it's like a global variable exactly Global variable right thanks and then uh get uh approval attributes get the approver inserting the auto approval record these are all kind of scripts that you'll have and then one for creating the catalog tasks dynamically and another for getting assignment groups right and I've just put the scripts here that support that uh kind of a conceptual approach that I was showing in those in that schematic right so with this uh like Prashant mentioned all different kind of um uh uh requirements for tasks to be serial to be parallel to have different uh text inside of the attacks so that the fulfiller gets the appropriate instructions Etc is all managed in that metadata table okay and this is the answer I want to kind of I was saving for I think it was uh Jane who asked how are you going to now combine different things for a user when they want a um uh set of applications access and some software and some uh workspace uh needs that they have so we used order guides extensively and for those uh that uh are not familiar with auto guides Auto guides are a catalog service catalog uh feature or functionality that allows multiple items to be required requested at the same time in one interface by the end user and it gives a better user experience because there are certain things that you enter for multiple requests um like the demographics name address uh uh you know Department cost center things like that you enter that and then you ask for item one item two item three if you don't have an order guide each of them becomes a separate request but if you do have an order guide all of them are in the same request and when you submit it it spawns off each of them as a separate flow which you can still track separately but is available as a bundle but you're not really uh tied them all together in a relationship inside the database you've done it only while using it and I the reason I say that is I think once upon a time if some of you have been around a long uh in the servicenow space I I say I am a Berlin so so I've been around since Berlin and I've seen some of these things there used to be a concept called bundle which is I don't think we push uh forward anymore but that bundle used to have that definition where you could bundle things together and there are ways to actually categorize and you know bring items together to use inside the uh request process but the way we did the order guide you could actually um assemble your own bundle for your current user and then use the requested for attribute so that you're doing it on behalf of another user and spawning that off to multiple requests Jane I want to come back to you to see if I've answered that question I mean I don't know that she's off yes she said yes in the chat okay okay thank you yeah so uh the the thing that I want to also bring here is um the order guide you know we talk about this fact that you want to bundle it and your the organization is not really letting you do it because you now have uh uh changes happening so much that you're not able to uh iron out what that specific bundle definition is so what we did is we also um allowed users to copy require requests so that they could take the request and modify it and do it right so those are some of the other usability things I know I'm going to run out of time here quickly so let me hit a couple of the other points variable sex this is the other enabling catalog functionality which from an implementation perspective was a huge Time Saver because we could uh use the variable sets uh and reuse them in multiple order guides or in even requests right uh catalog item configuration so how would you go about in a new catalog item comes you create the catalog item and then you use reusable variable sets add to auto guide if applicable create item specific variables associate standard metadata driven flow and then you populate the table with all the other approval attributes as well as the tasks uh uh rows with order and attributes so now with these steps you're ready to test right you've just entered data you've not done any other configuration other than entered data and created some variables and then you can test the floor this is how we could really increase the velocity of what we were doing and I'm going to give you a quick migration notes on we had one agile team doing this one platform owner one architect two developers one business analyst unit and acceptance testing were by users in specific domains this is where we started the organizational change management the users saw what was going to come to them long before we we kind of uh released right uh and the team had concurrent responsibilities so we needed everybody on board and we were able to release at approximately 40 catalog items uh and we were doing monthly we had bi-weekly Sprints but we had monthly releases so every month we were putting out 40 catalog items and one of the main reasons we could do this was all that I've been saying so far the standard flows we knew the patterns populating the I mean creating the item uh reusing variable sets order guides so suddenly you had an application access order guide there was only one application access order guide but it started getting more and more items available in that order guide so we didn't have to go through a whole new organizational change management or enablement because it was only drop downs were increasing and we we did a communication uh uh plan where we would say okay in this release you've got all these things now coming new in these order guides so that's kind of a way we were handling that velocity of implementation uh so one of the other things that happened and this is a not necessarily uh the uh the architecture or the solution part of it but more on the ocm part of it we had two platforms and we were migrating services from one to the other but we populated both with all the items but they were cross-linked so if it was not uh implemented yet you would do it in the old platform if it was already implemented it would take you to the service now platform similarly if you went to the servicenow platform it was not yet implemented it would take you back to the original one so we didn't put the onus on the user to determine where they needed to go so that's how we kind of manage that other things we did was although we had categories for kind of managing uh the maintenance of the items uh we really said search is the way you should go about it and we use the meta tag for each item extensively so you could you had the old names as meta tags in the new items so you could search and you could find what you're looking for and you use user criteria to window down the list of things that were being presented I've said a lot here I'm going to pause and see if they have you got any other I think Craig has been waiting for a question yes yes please yeah hi Aaron um I'm going to try and make this pertinent to what we're talking about here because we are talking about standardization of you know workflows really across catalog items um basically hjf who I represent we are I guess mature with everything that that you've detailed here we pretty much are following this path and it has worked out pretty well for us my question is really do you or anybody here in the group um have a way to account for when a request you know the the details of the request change right now when we went live in 2018 we used variables uh and the variables are very static and you know when the when a quantity or what have you changes and what have you we don't have a way of updating those variables and we don't have a dynamic uh interface in the back end uh to be able to account for you know when you know the dependent Fields when some values change and I'm just kind of curious if it's not pertinent to what we're talking about I get it but um since we are talking about standardization has anybody here or Aaron have you have a solution for you know kind of standardizing that across catalog items uh I mean uh I think I need to also understand your uh question a little deeper but I think what you're saying is after you have defined the item and after it's been instantiated if something changes is that the question correct okay so the the workflow is already in in context and executing and that's when something changes yes okay uh yeah I think that can get a little heavy because now uh it depends on the stage at which your execution is and if it has not gone past the stage or reached that stage that may be one thing but still you're not trying to get into the context right yeah I mean if something changes before approval or after approval it could potentially have a different workflow right yeah but I mean I I would ask some other follow-up questions before you know kind of thinking about a solution is I mean how often does this happen very often unfortunately uh you well we follow the self-service model you know very heavily when we went live uh but that kind of over time is kind of backfired for certain items because we're we're finding that users don't really um detail things very well uh especially if you give them a comments field they might just get a free lunch and skip a bunch of stuff and you know this but this also has downhill effects with our uh reporting you know the you know bad data by bad reporting so so I think there are a couple of ways I think just over the top of the head uh solution that I can think about but I think we can take it offline and you know I'm willing to uh kind of engage in you know let's have some emails right I think the way you want to do that is you want to do it in the process because what's happened is you've started a flow and something has changed so uh the way I would say is that we give them functionality to restart it so instead of saying cancel you give them a restart functionality and behind the scenes you terminate the prior flow start a new one with the same set of values and allow them to change it and then go forward will that make sense yeah the doubles in the details there yes yes but I I recently was talking to a customer who had that need and we made them do that because uh changing values mid context uh messes up a lot of things because now you are in in a transient stage right so that's so which is why the cleaner one is it's almost like a restart but don't let them feel that they have to go all over again let them restart and bring them back with the ability to change that uh so let's let's take it offline it's interesting it is interesting sure sure yeah I don't want to hijack this thank you yeah and I think John couple of minutes to close out or you want to close out um now go ahead and close out because we're a little over now so yeah yeah so I only want to kind of uh point out some of these things and this is a whole uh presentation in itself uh about how we went about some of these things because uh we have prior to this thing we did not have a specific I.T service portal uh and we did that we did a focus group and we did design thinking sessions to um design the portal we went through notifications in Mobile and dashboards Etc uh and we got into a place where everything was has to be contextual Persona aware personalized branded and consistent what I mean by that is I'll use the notifications as an example we I think somebody brought up this thing unless you have ocm there are business users who will never look at it uh and this is what we did we said we limit the number of notifications and to avoid notification overload and we branded everything it just doesn't come from servicenow it came from the name of our portal and every message that came from the service catalog uh or the the portal uh had the standard look and feel and it was very conversational saying why am I getting this message what I do I need to do and no action required all those things we did that and it was also you know consistent in its look and feel so that they knew where to look for what kind of information on the notification and it was device form factor aware because a lot of times you get messages on your phone you and I do get this and it says action required but there are six action requireds I don't know which one is what and should I open it now or later so we try to put the significant information up front and started uh shortening the message text so that you drew attention where it was important and things like that right so that's all part of the ocm including the communication plan so in closing I would say you know some of the things that we look at governance execution adoption adoption is really the the key and for adoption we have to do organizational change management uh I know I've gone over uh I hope this has been informative we ran out of a time for Pure question answer sessions I hope you have been asking questions when when needed and thank you to all of you um to spend your time with us today here and thank you John for this opportunity uh back to you John appreciate it very much room great presentation uh lots of good interaction it's exactly what we want here thank you so much thank you thank you Prashant for your contribution thank you