[Music] hi everyone welcome to glide past on air today's webinar the trifecta new york-presbyterian solution for incident transfer and search across three instances I'm Lauren Jankowski the marketing specialist here at Glide fast and I'll be moderating today's webinar I'm excited to introduce to you today's presenters David Arbor a senior ServiceNow architect at Glide fast ed Shea a service delivery manager at Glide fast and Smit patel a senior technical consultant at Glide fast before we get started we'd like to give you some background information on glide fast consulting glide past is a consulting firm that is dedicated exclusively to ServiceNow as an elite ServiceNow partner our expert team of developers and architects have worked on both sides of the table on the customer side and the consulting side our company was founded by ServiceNow architects and we're proud to have a team of over a hundred experienced consultants an average CSAT score of a 9.6 and more accolades as you can see here will be monitoring the Q&A throughout today's session so please send in any questions as they arise and we'll do our best to answer them as another perk of attending today's webinar we'll be giving away a $50 Visa gift card we'll announce the winner at the end of today's session now we'd like to hand things over to our presenters to dive in Thank You Lauren good afternoon everyone appreciate everyone's time this afternoon before jumping into the case study here first slide here who is new york-presbyterian I'm just a little background on the client landscape here so York Presbyterian is an academic health care delivery system located in Manhattan but locations throughout the New York City metropolitan area a little bit about the organization from a healthcare perspective about 2600 hospital beds over 6,500 affiliated physicians and and 20,000 employees and they see about two million visits annually within their hospital system they are rated the number one Hospital system in New York and they make the top 10 best Hospital list across the United States with in this case study just want to call out they have a collaboration with two Ivy League medical schools Weill Cornell Medicine and Columbia Columbia University Irving Medical Center so jumping into the NYP opportunity so given NY peace collaboration with wall Cornell Medicine and Columbia University or Medical Center NYP was looking for a solution to to effectively manage when I say manage you know triage and track incidents that originated in an instance that wasn't in white P and and managed across those three institutions while also improving the the end-user experience you know when an incident is open to getting updates and then you know resolving that incident and and and through those conversations understanding you know what NYP was looking for there was three major pain points that we identify they were pretty consistent across New York Presbyterian wall Cornell and Columbia first one being helped us staff could not manage in triage incident tickets effectively across the three institutions so for instance if an incident was opened by a New York Presbyterian doctor or staff member in the NYP instance but after the New York Presbyterian helped us realize Serena reviewed and determined it was actually an incident that belonged to wall Cornell there was no great way to triage that ticket over to the wall Cornell helpdesk and and it just it was it was a cumbersome process and it wasn't efficient enough to kind of work that incident second pain point lack of search and traceability there was no intuitive way to track or update newly created incidents in another institutions instance so if we take the scenario I just described in the first pinpoint where that NY p doctor or staff member opened the incident in the New York Presbyterian it helpdesk it was transferred to wall Cornell in some way that that doctor or or staff member would call back to the New York Presbyterian help desk and look for an update on the instant they created but the New York Presbyterian helpdesk would not have save the most up to date you know work notes you know where the incident was you know what was going on with it so there was this almost a slack of communication or way to update the end users and then number three helpdesk that each of the institutions were using email and phone calls to transfer an incident that require the other institution to work and I touched upon this a little bit and then the second pinpoint but but yeah so it going back to the original scenario once an incident was identified and triage to another institution or organization the way the help desks transferred was by email or by phone call and that wasn't always the best way to do that so that was the the overall opportunity and the pinpoints and then kind of what what New York press attorney was looking for glide fast engagement so near Presbyterian engaged glide fast and we partnered together with collaboration wall Cornell and Columbia University to you know build out the requirements and develop a proof of concept leveraging the ServiceNow incident workflows we spent a good amount of time on site and in Manhattan with the glad fast team through workshops we had many virtual workshops working through a number of proof of concepts and the time was required because it we were only we were not only creating a solution for New York Presbyterian but we also needed input from wall Cornell and Columbia University you know there that helped us stakeholders process owners but they're their own development team you know our architects on their side so there was a lot of coordination that we required not only from NYP but you know across the three organizations and various teams well throughout the beginning of that project and determining what the best solution was what the what the best solution is for you know those requirements and and one of the biggest challenges with what the development was that coordination and and and as you could just imagine you know determining the requirements but also we only we developed the solution in a single instance and then had to coordinate user acceptance testing we had to coordinate you know working through defects with wall Cornell and Columbia development teams you know releasing multiple iterations of this of this product it was just a lot of coordination and it was very successful so right now I'm going to hand it over to David Arbor who's gonna talk through kind of the big four requirements that came out of those sessions that we had on-site and virtually David take it away yeah hey everyone David our board here so yeah so just to sort of add to what ed was saying there so the the you know the overall requirement here was that NYP needed to be able to take a chunk of incidents that they would typically work you know in a period of time and those incidents may or may not need to be transferred from NYPD one of the other institutions or back from one of the other institutions to NYP and so you know there was it was a real challenge there because we didn't know beforehand what's going to be transferred or what could even potentially be transferred so we couldn't really flag things as you know hey this might be a transfer and what's one of our initial thoughts on this was that we were gonna create copies of incidents in all three instances so that they would be there and when we transferred them we were just basically update estate and you know that was sort of our first solution and that really was wasn't something that that we went with because we're talking about million of incidents here per year so it ended up not being a good viable solution so what we ended up coming with was our solution was okay let's let's do this two ways let's do sort of a two-pronged approach here the first part is going to be the actual transfer piece to wear with in the normal fulfill UI of service now we can transfer incidents from instance to instance or organization organization and then we wanted to provide them a way to search for those incidents across all three institutions so we kind of knew from the beginning when we when we decided it was gonna be a search piece to it that was going to be a widget something in their portal and so that's what we went with and so you know basically what we're gonna do here is I'm gonna pass this one to Smith here in a moment Smit patel and so Schmitt is gonna go over the transfer piece of that so the that that's sort of half of things and then he's gonna pass it back to me and I'll talk about the search tool and and how we built that and these are gonna be primarily demos that we're gonna show you guys how sort of how it works so yeah that's the overarching requirement slash solutions that we came up with and now we'll show you how we implemented them submit you want to take it over sure thanks David all right so as David and I had mentioned the biggest challenge is we didn't want to hard-code a bunch of things into script includes and so forth so the main goal of the solution was how can we make this a configuration based setup where you would have a table you go in there set some properties and that's all you would have to do if you want to make some changes or if you want to add a new instance that you want to be bond with and so forth to transfer instruments between instances we're using UI actions and Russ api's calls between those so whenever you would click that UI action they would go ahead and then made a call so that we have setup in the backend to connect with other instance so let me go ahead and give a demo of that functionality all right so I mentioned something about a configuration table earlier where we call that remote instances so basically what that is is it's just a number of records that you want to integrate with so for example this is a PDI that we're using for our demo with any wipies instance so in here basically we come in we fill out what the instance is who could transfer to what what the URL is of that instance the namespace and so forth so all these properties were using in our code on the back end to make sure the transverse are smooth and make sure the instruments are keeping insane Cabala thinks all that we had to keep in mind was the state feel for example is a primary fill that every instance has their own definition of what is an open field versus what's the closed versus what is a warden progress so we decided to have these fields here where we're defining okay state field what the name or the backhand name is and then what are the open States were the results days or the closed State so this will help us when to match those States whenever we're transferring instruments over and with this type of configuration base as you can see you could have as many instances that you want to connect with and there's no limitation really on what you could connect with so let's go ahead and transfer it an incident so I'll go to my PDI real quick so this is my PDI where basically what we're going to be doing right now is trying to transfer an instrument to the NY piece environment so just follow the mentor it feels on their crayons for a demo one and then we'll go ahead and save that so as you see now there's a you are action here that says transfer to NYP so at this point I'll go ahead and click that and it will ask me to make sure that I'm doing what I want to do and we get a message saying if it was not successfully transferred we would get an error message but in this case it was so as you see the message here and one key feature that we wanted to include is so for example once the instrument is transferred over we didn't want the user on the primary or the source instance to be able to change the field so that way there's no conflict information when whoever from whichever help desk is given the information so we go ahead and make all the fields read-only so that way only the instrument that this incident is active in will only be able to work through that we also had to decide to add some fields here for specifically to the transfer information so we can keep track on what's going on with the synthesis so in this case since I transferred this instrument over to a new IP the state will be transferred and it the cool thing is also tells you what is the source so the source instrument is 0 0 1 0 so as you see it has a prefix for which instance it came from and what the entrant number is and also where did it transfer to so for example we sent this to NYP and then what P's answered number is that so since we're not copying all the instances and to begin with we had to come up with a system to track all these individual instrumented will mention the search tool later you'll be able to see how the hierarchy is built and so forth so let me just quickly go to NYP since and then I'll just bring these side-by-side so we can see the comparison of both alright says see the incident that was transfer over to NYP it does not have all we'd only feels all the fields that were on the PDI one or two or transfer over this couple feels that weren't because we don't transfer those over because I didn't fill out that information on my end so I'm showing quickly to you that alright so save that okay so one key feature was to make sure that whenever I transfer an incident from one instance over to another we have this first initial work note that we're transferring stating okay what are the fields that were already populated on one instance so that way you don't to go back and forward saying what was populated or what came from another instance where says what was handled on mine sense with rules and so forth so that was a cool feature that we had established also if I go to the same transfer information tab you see the different values so on this case since NYP received and when the state is received and we also have something called transfer count so I will say how many times this instruments being transferred so currently it was one so it's one their same information on what the source says and then where the instrument came from I don't think that we had to do was with additional comments or work now so as you see notes here so even though all my fields on this PDI and sends are read-only we've kept the work notes and additional comments for free because if I want to let's say ask for an update from NYP I would just simply say hey that's Ramiro is on the call is there an update and as you see it just pops right over to the NYP ensign so that way it's easier to get updates it's easier to get nodes and there are notifications that the customer gets is always from the primary or the source instance so for example if I had to put something let's say I got an update from NYP saying the instrument is being worked on we should have an update in 30 minutes so this if there's any notifications on the source instance the customer will automatically get that so then you know they don't have to worry about calling back or anything like that if for some reason that you leave the call to attend some of their businesses so that's some cool features that we've added they're just so everything's in sync and get over there so let's now try to transfer the NYP instance over to PDI one and see what behaviors we see with that all right so now you see the same read-only field because now this instrument was transfer over because they and what he was working on we're okay with weight it has to go to a different company or a different institution to get worked on so then they would transfer it over and as you see in the transferor hierarchy now we have where it's being transferred to and if i refresh here let me pull up the PD I'd Warren so as you can see the fields were transfer over and then you also get both sets of workmen so what was what were the fields when it was first transfer over what happened during that time so we had added the comment hey customer is on the call is there an update so it brings up all the historical data from one instance to the next to the next and the last instance wherever this resides we'll have all that information so if I'm a help desk technician at that's their distance all I have to do is just go through the work notes and see what's going on so it's fairly simple as that I think that's about all I have on my transfer piece David do you have anything you want to add to this transfer piece maybe just show the transfer information tab there in PDI 1 ok yep yeah so yeah go ahead yeah sure so the tap here the important thing to see here is the transfer form so as you see the hierarchy is being built were you know it was sent from PDI to 2 NYP and now is residing in my PDI 1 so David will go over later on how this is an important factor into how the portal site comes through and how that is determined there so yep well with that I'll go ahead and pass on to David awesome and David before you get started I think we just had one question come in what happens when incident gets resolved does the source system get updated yes so we have business rules in place and that's when when I showed that state field you know where we're matching States to state that's the key factor into when something is resolved somewhere we want to make sure we cycle it through all the different places that they enter and reside it so that's a key factor in to ensuring that when one gets resolved all the rest gets resolved us all so yeah and I was one of the reasons we're mapping those fields the state field in the configuration record because a result state in in instance a maybe a different resolved state and instance B so that that's helping us figure out what actually is a resolved state and closed state okay so now I'm gonna go over the search tool the search functionality that we built this part of this as well so like the transfer functionality this is configuration based so I'll show you actually those same configuration records they submit showed you but I'm gonna show you a few other pieces of data that they hold that helps us with the search tool it's built as a single page application so this is a single widget on a single page and that's that's how it works it's angularjs JavaScript and we're using rest api is to do the searches so both the transfers and the searches are all done through REST API is even if we're searching for something on the local instance or yeah if we're searching for an incident in the local instance which they will show up you'll see at the moment that's still using the REST API to actually grab that information because we wanted a consistent way to grab the information okay okay so I've got a split screen going on here I've got NYP here on the left and I've got my Pei and Smith's PDI over here on the right so the first thing I wanted to show you was like Smit showed you we've got these configuration records so obviously like Smit told you we've got the URL of the the other instance we've got a namespace for API for attachment API information we've got an off profile so the the login information is all posted there and one of the other things here I wanted to point out is that we have a list here of the different instances based on their codes that they can transfer to so the requirement here was that one institution either Rockwall Cornell or Columbia could transfer to NYP and then NYP could transfer to either of those institutions but they could not transfer to each other so when we built this we had to put that in place where we can easily configure that so right now this is set up to go to all four from NYP but if we look at another record here you see that this one PDI one is only set up to go to NYP we is the reason when you come to PDI one here it only has one button transfer to my P right but if we were in the NYP and looking at the same instance or incident we would see the old buttons that it would go to okay and then we've got let's see the other pieces that I wanted to show in here that incident properties we already went over so I think that said we do have the color here so one of the key pieces here was in the search tool we want to be able to tell very quickly what institution something belongs to or what instance something belongs to so we gave each one of color and these are their branded colors for the for the different organizations and that's defined in here okay so um real quickly here I'm gonna go to this remote search tool remote and it's under service desk we have a remote search so here so the server desk can come and actually do searches on there incidents so what I'll do here this is the incident that Smith sent to NYP so this one is actually right now just for context it it came from PDI to to NYPD and then NYP transferred at the PDI one so over here in PDI one is where it's actually active okay so I'm gonna grab the incident number real quick and we're gonna put it in our search tool and let's see what we get okay cool so we got our incident right we can see that in this search tool here we have multiple setups right so it's searched in ype it's searched PDI one and it's search PDI two did not find any results at PDI two and it did not find results at in YP it only found results in PDI one and the reason that is because PDI one right now is the quote unquote active instance so it's the instance where this transfer can be worked on where it's active okay so a few key features here of this the search tool we can see the short description and the number right off the bat we can see that what instance it's in with that color coding that I mentioned before and we can expand and collapse things so we can make this you know more readable as we need to because a lot of times when you search an incident here you're gonna get you're gonna get multiples because you know especially low number incidents like this because instances all go through those low number incidents at some point right so they show up so anyway we can see here too that this incident has been transferred two times if it is more than two times and this was another requirement from the customer if it's more than two times this is gonna show up in red because at that point they want to know hey we need to do something about that if it's been transferred more than two times um from here we can expand our view of the PDI one instance so we can see our comments here so the comments that are showing over here we can see them here and we can see our work notes here as well and we can easily add work notes and comments from here as well so we don't have access to go into the actual incident record from here because we're not in the in the the right instance but we can see everything that we need to see and we can communicate with the customer everything we need to communicate with the customer so I'll collapse that so now I'll show you the transfer so we also have this expandable area here that shows us the two transfers that these came from so we can see it came from PDI - it was transferred in YP and then from my P it came to PDI one now this is what Schmitt showed you where we have a higher heat against Bill but it's not I don't know one that I call it true hierarchy because if this were to get transferred again it would only show we only have three total instances in our and our grouping here right so it's not gonna show that it was at PDI - then NYP then PDI one and then back to my P it's only gonna show the last two places it was at right now if you had five different instances configure here to do all these transfers it would show all of those if it went through all of this that's sort of how that works so here's our transfers now since we are local to NY P we can see that we have a button here that says open transfer and so that'll actually take us to the incident record itself where we can then do what we need to do with work and comments because we're not adding those over here on because we can we could open it now since this one's in PDI too and we can't actually go to it we do have that same option to expand and look at the comments and work notes so we can make informed decisions on these on this incident okay so that's how that works now I will do real quick I'll show you as well that we can search not only by incident we can also search by name so username that's what this is seaweed or uni it's actually username so a key point that I'm not sure that we pointed out initially is that all three of these institutions share users that do not have the same society but they will have the same user ID which is what allows us to search across all instances so we can put my user ID in here and there we go it's gonna bring back all incidents that's not only incidents that that we're talking about right now but incidents that are opening any of these these instances so we can see that these four that showed up we're all just things that I've tested with that do not have any transfers associated with them because you don't see the transfer link underneath so you just collapse out and get rid of that and then see the one that we really want to look at right so um I want to do this real quick so we know that this instance I mean this incident is live over here in PDI one right now but I'm gonna transfer it to back to my P so we make a full circle here I'm actually gonna add a work note here transferring back to in YP for work so first off you can see if we come down here in PDI one I'm sorry let's see it's the wrong incident I think all right is it what's this one I think it's here when I go it is it is I'm looking at the wrong one yep okay sorry no worries all right so this is it I think the search or just the wrong one but I see I take yeah I see yeah let me go back to 18 it's because it's in Smith's name and not my name and I was thinking it was in my name okay back to 18 and PDI - okay so I'm gonna transfer this back now again remember we have PDI 1 here is the top incident right now because it's the incident where it's it's active so I'm gonna take this one and transfer it back to NYP okay so it's been transferred we can see here when we refresh that this incident is now showing returned we have a transfer count of 3 again our transfer source initially was PDI 2 we transferred to PDI 1 at one point and then the last two the last two instances it's at and we're PDI 1 and PDI's you okay so now when we search for this incident we're gonna get a slightly different view so now we see the NYP is the active instance and so it's the one that shows up first it's one work shows up for you to view and again since we're any myp now we can open incident with this button and we can still view our transfers or two transfers and get all the information that we need so this fulfilled the requirement another thing that all of the requirements so another thing that we don't know that we talked about enough prior this was how difficult this was to develop because we were developing in one instance where we did not have access to the other instances to do development work and we did later but not right right first so we really didn't have a way to test so we had to develop everything in in 'wipeys instance against our PD eyes like we're showing you now but you know obviously PD eyes aren't going to be the same thing as customer instances so when we got to the customer instances we actually had very very few problems you know a few tweaks that we had to do but overall everything was done in one large update set and that was the goal because we didn't want to have to push multiple updates that's the multiple teams so everything was letting one update set and I mean we've had multiple enhancements since then but initially was all done in one in one update set so yeah so this is the tool this this fulfilled the the customers requirements they that it's been very useful I think our original volume of incidents transferred per year when we initially talked to them was a 150 to 200 it was not that many but I think last number I heard whenever I talk to them was it was in the thousands because they now have the ability to do that to do these transfers without you know major issues along the way Smit is there anything I missed um no but I think we should add the attachment piece so oh yeah yeah yeah I think I forgot to mention that so if you just want them with that that's fine yeah so the active right here let's go ahead and add an attachment it's just gonna be a random attachment I don't know what this attachment is but we're gonna put it on here anyway yes not not only are we transfering work notes and comments but we're also transferring attachments so here's the attachment we just attached it in this instance it transferred over to this one and if we look at PDI - submits PDI we should see the attachment here as well now the requirement from the customer and this one was that if we transfer I mean if we if we add an attachment anywhere they're gonna show up on all of them but deletion of a attachment should only occur or she'll only propagate to the other instances if it occurs on the instances active so if I delete this here and I will we remove it here from PDI - we're going to see that it's still here in PDI 1 and that it's still here in NYP instance we have to remove it from the live when for its it for it to cut out from all of them and another little cool feature is it from any instance and do it over here well sorry yeah oh there we go so if I rename here it actually propagates over as well no sorry there we go and it rename to a a2 dot JPEG so renaming actually making the attachments and the deletion if it's the active incident as well so work notes comments some states or the states when they go into result or closed and you know key pieces of information that they need to like short description who the user is things like that they all transfer over Schmitt anything else oh no I think that's all about this too and what we've accomplished at this ok I think that leaves us open for Q&A do want me to pass it back to you we haven't we do have a couple of questions coming in here's the first one can you transfer incident back to the originating source system yes as David just demoed he was able to transfer it back to NYP and from an RP he could transfer it back to the PDI - yes yeah the only thing limiting you and where you can transfer it is what we had set up in those configuration files as to what was a you know a valid receiving instance or in incident I'm sorry instance here's another one can you describe how the UI for this tool was built ah sure yeah so like I mentioned before it's a single page angularjs widget it is it's a single widget on a single page I have multiple directives including services that I've created for as angular dependencies and script includes that pull all the data in as well so um this the searching actually takes place actually I see a new question how are you able to I was about to talk about search capabilities so searching I think I mentioned this briefly as well before so I'm moving into the next question I'm sorry Lauren unless you wanted to go so the the search capabilities like we mentioned before are based on rest halls so with those configurations that we showed you we do all of our risk of so that it's a basic auth off that gets passed in using we are using three api's we're using the table API to pull information we're using the attachment API to do some attachment stuff and then we're actually using because attachments you can't I can't remember what the limiting factor was but there's something you can't do with attachments to the attachment API I think it was removed them so we had to do that through a scripted REST API so ever script a REST API and then we're using two out of the box of the table API as well as the attachment API and so all that's done when we go to search we're basically in that search tool looking in those fields so the transfer fields like transferred from and transfer to we're looking for records that match our instance and records that match our incident number and that's that's basically it it's a it was it was key that we had those pieces of information right so we couldn't lose a incident that happened to be in the in the trail because then we would never find it again so or it would take forever because we'd have to search an entire instance for something that may be related so that yep transfer information was was key all right well that looks like that was all the questions so that's all the time so we have for today but we'd like to announce the winner of our $50 Visa gift card and it looks like the winner is Frank garner congratulations we'll e-mail your prize to you directly but don't worry if you didn't win today don't be discouraged everyone every on-air webinar you attend for both glide paths and our sister company fair code counts as an entry into our on-air grand prize giveaway of a mirror workout a $1,500 value and that winner will be selected at the end of June thank you to everyone for attending and we hope you enjoyed if you still have any more questions feel free to tweet them at us send them to us at info at Glide fast comm or reach out to any of these speakers from today's session to see more sessions visit glide past comm and find the on-air section to sign up for more webinars coming thanks everyone [Music]