alrighty good morning good afternoon or good evening depending on where you're calling from uh Welcome to our now sixth uh s so modern change life cycle launch and learn session today we'll be covering devops um you're gonna receive a presentation short demo from Isaac barks as always we do have other devs engineers and PMs on this call so if you have questions we do ask that you use the Q&A function I know a lot of you like to use chat um there are some times when that's necessary if you want to maybe give info for the rest of the participants but if you have questions regarding devops change anything of the sort please use the Q&A function for us um I also want to point out this is our second two last session so in two weeks on September 3rd we will have our last change launch and learn I know time flies um and in that session we'll be covering honestly somewhat of a recap of all the topics we've covered so far um so if you really if you need to attend one session I think that may be the one you want to ask any last minute questions learn a bit more understand where you can get more resources on change or S so um I'll recover all of this in the Recaps always um but yeah that's all for me and I will pass it off to Isaac to go ahead and get started ready thanks Chris beautiful right let me go ahead and get things started here so in this journey we've been taking over the launch and learn series we have built up to today and we've gone over things like change success scores risk we've gone over um features such as change approval policies there's there's a lot of information that we've built upon and we now want to talk about devops change veloc at this point we've gone over a lot of the foundational information needed to um proceed forward with this topic so today you want to really think about connecting your change management world with your development teams how is that done right let's talk about this a little bit these are two very unique teams where they have separate missions separate goals separate tools that they're using right and uh at the moment we we want to look for opportunity to automate as much as possible between development and change management there's also some insights that we need to glean and there's also governance that we need to talk about when we we get into the world of devops and change management so if you talk to a developer today are are they necessarily going to have a favorable opinion of change management or not um so re researching ahead service now actually did our own investigation where we found customers were waiting in upwards of three weeks to get production code released and passed through change approval policies this is this is very painful when it comes to that development team right so three weeks to get code out the door um not something they were they were very fond of another option would be to actually have developers involved in the change management process but that's again not something that they're going to be focused on and also administrative tasks that we don't want to add to their plate talking about some of the teams that have challenges when you're speaking in the uh the devop solution we've talked about the developers we don't want to add any more Administration to their plate um most developers really don't want to deal with service now and the change management process the change management team if if you've already got your your standard changes coming through your your pipeline and your road map what are you really opening up here when you talk about development and change management what volume of change tickets could your organization be adding a day to the change management policies it could be dozens or even hundreds we've seen so that's a that's a pretty large scale that the change managers would have to deal with if you were to open up uh the devop solution governance we need to make sure that uh there's compliance that we've got full visibility to all relevant data what type of impact it's going to have on your environments and also the the audit Trail that's going into your your cicd builds all the way up through the visibility to your your top level uh teams do you really know where the the efficiencies need to be improved or is there are there bottlenecks what's working well what's not that's that's a lot of information to think about when you when you're connecting uh your world with devops so let's talk about where service now steps in here and fills this Gap first off the tools that the development teams are using and even further back when it comes to your your agile and your planning methodology numerous tools we speak to customers every day that they could be using Azure devops for one team and then another development team in the same organization could be using uh jira and GitHub and Jenkins right so tool agnostic I think is probably one thing that we really need the solution to be and from there we want to talk about automation if you're if you're talking about change tickets getting added based on the developer's workload that has to include some really important information into it builds need to be successful we need to make sure that there's there's testing going on you've probably got other tools that are performing those tests and that change creation is going to be really critical to if in in and important but we have to make sure it has all of the information it needs going over just a bit of the architecture and then we've got quite a bit of product to show here this is this is pretty much a straightforward deployment that our customers would be working with in their development teams on the left side you've got the planning and development taking place that's another tool that we need to integrate with so just as we talk about these just to keep in mind the Integrations so are you using service now's SPM for your agile and your planning or are you using something like jira then the developers once they get those work items they have that backlog to work through that's another tool so they're doing their code commits and inside those code commits uh you've got all of the the the pipelines being run and that's in the orchestration process so your orchestration that's most likely another tool that the developer ERS are using we've got the building the testing and releasing ha happening um all day pretty much every day so every time those pipelines are running you've you've got information that's important and critical to that software and we need to capture that so where does service now capture all of this information in a change ticket it's really in a unique position here to include all of that information that goes back to your the the pipeline run so your code commits the user stories anything like sonar Cube or uh even Vera code right so we're going to talk about security operations a little bit too the releases the artifacts these are now going to be included in that change ticket based on a pipeline being run the change ticket has all of the information you would expect it to have the the service now system of record has your incidents your outages your maintenance Windows any type of blackout schedule so when we marry that information together and we see the relationships there's there's some great opportunity for automation that comes into play once that change ticket is created there's a couple options you can do you can actually put it under what's called change control which if you're dealing with something critical in in production if you're pushing release a release out the door you might have Change Control where that code isn't pushed forward in the orchestration process in the pipeline until we get confirmation back from service now that everything is a okay there's also other options for you where we just create that change ticket and allow the orchestration tool to move forward and that's called change receip we'll talk about those options a little bit as as we go forward here but ultimately when we communicate back we want this to really add more automation to your change process and we want it to improve the relationship between your development teams and it so that way everybody focuses on what's critical to them they focus on the tool tools that they are used to working in every day and and we can make sure those two teams really get the best benefits okay so we're going to go ahead and move into some demo environments here today I'm going to be focusing on Azure devops as a developer but um we've also have um GI Hub and a Jenkins instance being represented today as well so for anybody that's not sure of what we're looking at right now this is where a developer is is going to be doing their work throughout the day uh Azure devops is is unique it's a bit of a One-Stop shop so all of your your planning and your your coding the orchestration that takes place here and then there's other setups which are uh represented here with the GitHub and Jenkins where there's multiple Tools in your cicd tool chain so I'm going to start as a developer I'm going to go ahead and make some some code commits just some pretty simple code commits here just to get that started all right so we'll go ahead and get that committed and what that's doing is it's kicked off a pipeline run and the pipeline run uh is in the background here so we've got this queued up up and there's multiple stages so building validating and then deploying so that's going to uh take a few minutes to process and we'll see what that looks like uh in a few minutes in the meantime what I'm going to do I'm going to switch over to another cicd tool in this case here it's Jenkins and let's take a look uh at the stages that this pipeline has run through very similar to what we looked at in Azure right we buil validate so on and so forth so over here again we're retrieving sources checking it out of Version Control there's building there's there's testing that's happening and then finally uh the prod deployment stage what I want to point out here is now we're going to switch over to service now for the first time in the demonstration and what the developer has received in this final stage of their pipeline they received the notification that the job was under change control and they also were given a change ticket number so if they are of a mind to they can actually go ahead and and look this up let's look up that change ticket that ends with uh 3838 inside of service now and see what happened uh back on the Jenkins screen you can see everything um was ultimately approved which is great so we are going back after the fact and seeing what happened when this change ticket was created by running a pipeline all right so there's the one that ends in 3838 and already you can see here by the short description this is something that was most likely automated automatically created so just a just a few things to look at here now this change ticket is is going to include uh some information that is is very helpful and that's right here we're seeing that this uh was assigned to a particular service and we've also done a risk calculation on this that service is is a representation of all of those those virtual and physical machines these CIS right so your web server database things along those lines the importance to that is most likely developers are not paying attention to things like um is is there a a hot fix going out on this particular machine that houses their Oracle database is there is there a blackout schedule on this Apache web server so when that change ticket is created it was created automatically when the developer committed their code and ran their pipeline there's now that blending together of information where yes the developer has committed code they've they've got a change ticket that was created but that change ticket is now going to be able to stop uh any issues that may happen in advance especially if there's things like um maintenance windows that the developer may not be aware of so moving back to this change ticket let's see what else is going on the assignment group has already been uh pre-populated and we've got a short description and implementation plan backout plan all of this was created from the uh the automated integration now along the bottom here's some wonderful information that is not something uh a lot of people are used to seeing in a change ticket what were the work items that went behind that pipeline run what code commits were there what's really great about this too is if someone was doing a root cause analysis you can see this URL is how and you if you have the ability to access these instances there was a change made that's the minus and then the the plus sign is what was changed so you can really do some great investigation uh with this information and metadata that's stored inside the change ticket some other things to point out here as well we've got uh software quality summary so think you know sonar cube is is one of the most commonly used software quality tools so when we're creating that change ticket based on the integration we're also reaching out to all of the other tools connected to your cicd tool chain so here the the work item this one is coming from J I can tell by the ID the the code commits we already looked at those these were coming from GitHub software quality summary right we can look at that scan ID and here's all of these values is somebody in change management really gonna look through these values and um pick uh look through them line by line or or really are they going to understand what some of this information means uh most likely no so what we're going to do with this information coming in all of this connected information is we're going to put it through a change policy so this was change policies were done a few sessions back and they're really instrumental when it comes to devops and the information here is not only coming from service now so we can see are there any current outages in that service are um there any you know x-ray violations that's a that's a thirdparty tool called jrog security vulnerabilities so verac code veric code integration is part of this as well um software quality results that's that's sonar Cube this change approval policy becomes very powerful at this point because we can look through all of the information and metadata that we've pulled in when that pipeline ran and Blended together to uh with service now's information to ultimately make decisions these decisions um we've got three of them that are in this approval policy we've got an autoject auto approve and manual review so here's here's the automation right Auto approve let's take a look at that it's when all policies were met so the conditions are going to be represented here right so sonar Cube did we have a 95 or greater test results that came back from that are there any outages that we need to be aware of remember we're we're connected to all of these CIS so service now can tell um what's going on with them are there any open incidents service criticality is this something like you know your your parking app for your employees is it is it a lower level criticality or is it is this software where a change ticket was just created in and for more critical like something along your your dotcom or a payment processing Ser something along those lines so if you if you allow service now to to um see the criticality of this through the approval policy if if it's level maybe we're okay with some more automation maybe we're okay with uh checking some of these other metrics and and parameters to push that change approval forward if it's a level one or a level two you probably want to set of human eyeballs on this change ticket so just some ideas for you to think about when it comes to that Automation and I would encourage you you know project by project different software has different needs and service now can identify what sof software that that is and based on that you can either have more automation or or maybe you still have some additional checks and balances that take place so if all of these conditions are met then we're going to Auto approve that change request okay along the same lines Auto reject there's just some examples where you know hey there there's been some outages we have had some poor test results coming back there were security vulnerabilities detected so then at that point uh we would we would Auto reject the ticket there's there's a couple ways to approach this as well where you could have um certain change approval policies do a do some checking and on those parameters that you're setting with your um you know things like your sonar Cube information your software call Quality results uh and then push them forward to a human right at that point so think about the the flexibility you have here one other bit of flexibility multimodal remember we talked about multimodal in the last session where Daniel presented this you could think hey this is great Isaac looks looks wonderful change tickets are automatically being created based on the developers being in their own tool I get that but we've got some pretty complex change policies in place already so right now this is a normal change ticket and most likely it's it's something that's already heavily utilized in your organization in that case I would encourage you to activate a different mode and call it something you know devops ticket where it's a completely separate type of change request and you could have a completely separate workflow process without interfering with any of your existing change management policies right so very powerful concept here um again we've built up on that right we understand what change approval policies are we know we also understand what multimodal is so as these come together it really gives you quite a few options when it with your devop solution okay so this this ticket uh we can see here based off of the action taken it actually it needed to be sent to a to a human right it needed manual review there wasn't enough information to Auto approve it there wasn't enough information to Auto reject it so this did go forward and we can see here um that it it had to be manually approved let's take a look back at this this pipeline that we've got running remember I did a code commit at the very beginning of our session so about s uh about seven minutes later same thing this is the view in Azure devops we want to communicate back to the developer that a change ticket uh was created and it is pending a decision okay this is Change Control we're actually pausing the pipeline and we won't go forward in the deployment until the change ticket is addressed I'm going to copy this change and take a look at that inside my in yeah see already it is a devops ticket this was automatically created just by running this pipeline okay so a lot of that information we're expecting to see uh what were the work items what were the code commits right all of that is now stored in this change request okay uh the approval policy it is waiting for approval so there wasn't enough information in here to Auto approve the change request and and that's fine that's what we wanted to show in the presentation today so I will go over to the approver screen just going back here again it's still waiting for an answer and I will approve this with Bushra okay and now um while that loads do quick refresh just in case we're going to communicate back to Azure and you will see this move forward in the uh deploy application State I want to kind of pause right here uh Chris Gary senthil there any questions right now uh just just to see you can see that uh we did move forward once that change was approved Azure devops did release and we've got some approval messages that were sent back and now the the rest of the process in the orchestration pipeline can continue okay we'll just kind of pause things at the moment and uh see if there's any questions we do have a coule open questions in the Q&A one from Lucy Harper says do you have to use change model with workflow or flow designer like do you have to create a whole new workflow to support the change model and change approval policy that's great question so yes it will you will then one of the benefits for using multimodal is you will then be able to use your own approval policy your own flow and so yes to answer your question you will you will have an additional workflow to work with and out of the box we kind of give a sample flow what uh what you might want for the devop solution so you've got a great starting point to uh to take from there nice we also have another from Aaron Buttle um with multimodal change what prevents the maintenance schedule from showing up as a conflict or does it use conflict calendar and the change holds till then I'm gonna phone a friend on this one here sen giri so preventing let's see yeah I I think Aaron what what we're looking at here is there will be scheduling conflicts and the traditional change management technology will we'll see that so when it comes to that we we're not going to push it forward in the approval policy until changes are until conflicts are addressed um yeah thanks not and also you all should have the ability to unmute so if you want to add um maybe a comment or a little more callor to your question feel free to come off meute so uh this is Aaron UT uh related to that question on on conflicts with maintenance schedules so is it a we basically to understand that that multimodal change uh allows them to create their basically their own change type and and they they would all still need to follow their maintenance windows and blackout schedules um it would just create an alternative flow to the normal change type is that the is that the gist of it that would be the gist of it yeah okay so um all right that makes sense so this record that you've got here looks like it went ahead to implement even though there is a conflict yeah this I've got a pretty flexible workflow in here so just yeah definitely not something that we would we would advise but I don't have any logic built into my flow around that so I can just push it through for demos so the workflow would have to recognize it then to stop it and you would want it to yeah okay thank you hey this is Robert just a a thought since you're going through all the automation efforts to work through change and change is getting fed by the cmdb and the maintenance schedules is there not an accommodation in the cmdb to accommodate this type of scenario so that you're not going to have maintenance schedule conflicts or adjusting the maintenance schedule to be a 24-hour 24 by7 maintenance schedule short of blackout periods so just just making sure I understand that um what I what I showed today definitely did not want to throw anybody off when it came to that maintenance schedule but this would respect your maintenance schedules and the approval policy would be set up to to not push that forward if there were uh scheduling conflicts at all gotta but you're suggesting though there's no automation via the cmdb that you would do to accommodate maintenance schedules you wouldn't typically need to worry about that you would want to uh it's not that you wouldn't have to worry about it you would you would definitely want your workflow process to include that in its decision making okay very good thanks yeah little bit more to show so uh hopefully my team can continue to answer the the text q&as so how was this connected right how did we get that communication going back and forth I'm going to move over at this point to what is called our our devops change workpace just keep in mind all that we're showing today is itsm pro right so all of the devops solutions fall underneath that skew and when you have that activated you have the ability to access any type of spoke or integration that service now has built to connect to your cicd tool chains underneath the workspace called the devops change workspace that's where you're going to connect to your tools and create applications we'll talk about applications in a little bit there's also some traditional onetime setup where you need at at least a devops administrator you're going to need um a devops system account to facilitate the communication back and forth underneath rolls you can refine those even further right if you want somebody that can connect to your tools right that would be a permission you would need to give them once they have that proper permission it allows them to access any type of spoke or integration that you've activated so from the from the service now store also from the plugins I've activated uh some of these most common used tools so underneath planning we can see service now is agile we've got jira gitlab and of course Azure devop rally so some of those commonly used planning tools underneath code these are your code commits so things like GitHub gitlab moving forward to your orchestration process Jenkins is still definitely used so Jenkins is in there um and of course the the the Azure devops is represented so across these you've got some some really great connections that you can you can activate software quality sonar Cube Vera code is going to be represented underneath the security tab here so what does it look like when when you start this process it's going to kick off a Playbook and what the purpose of this workspace is we really wanted to make it as straightforward as possible for our service now administrators to get this connected right um and every one of these cicd tools has different requirements for getting connected if I click on Jenkins it just wants the the tool um well I'd have to click forward but it just it basically just wants the uh the connectivity and and connection options but Azure devops there's there's a little bit more that goes into connecting Azure devops so are you connecting to your your org at your org level are you just connecting to a specific project so some things to keep in mind as you do um activate these tools is that it's going to be a a pre planned out workflow process from this point onward and all of those unique needs are going to be represented as as you work through it so I'll start with Azure devops and I'm going to live dangerously here and and connect to my or level we'll go ahead and just grab my org URL put our test Ado connection and kick that off so you can see the Playbook is loading in the meantime uh I'm going to go ahead and grab a personal access token go ahead and pause my screen here for just a second okay so I'm going to give myself full access here okay coming back online so there it is it wants that password or access token I'll go ahead and paste that in there we do still have customers that are using on- premise tools we see that uh a lot like with Jenkins there's still um some customers that are using on Prem gitlab has on Prem so if that's the case just one additional step you'd have to make sure that the the mid server is is specified or you could Auto Select it but that's just for um anybody that's on Prim all right so once that connection kicks off the rest of the Playbook uh goes forward there's a permission check that takes place we'll just get some validation from there all right so we do have the permission required to access work items your commits all of this is is H where it needs to go so we'll go ahead and move forward here and we'll kind of we'll kind of stop at this point but the rest of the rest of this workflow process is going to talk about you know what what groups are allowed to access and maintain this connection which projects you want to synchronize and uh which pipelines you want to be synchronizing okay so once those tool connections are created service now still needs to know what the relationships are between the those tools and that's where an application comes into play so an application is essentially like a micr service if you will um an application could be a combination of one or many tools so let's take a let's take a look at an application that's already been built and talk about your options when it comes to refining your your tool connections so here's our our front end this is an application that's that's uh been built in service now I'll go to here into plans we've already selected and Associated the plans these are uh one of them is coming from SPM one of them is coming from jira how did we do that I'll go ahead and click associate plans this is now referencing any and all planning tool connections you've created in the in the previous step we just talked about so you could say it this is the plan plan project from jira right so that's that's what I want or is is this really connected to this microservice from SPM okay so you can select one or more and Associate those same with repository this repository here we've got it coming from GitHub and there's there's more options right if you needed to to change that but these are based off of the connections the tool connections we made hypine is it's where a little bit additional work needs to be done and we've selected here underneath pipelines that particular one that's running out of Jenkins that's not the only orchestration tool we've connected right we've got a gitlab connection a GitHub connection those are those are all tools that that we connected to previously once you have that Association you can see the actual stage and steps that are inside of it so take a look at this right we've got uat deployment junit testing all of that it's from here so service now is able to now that that connection's been established we can see the stages inside your pipeline and at this point what we're doing is where do you want us to create the change ticket at what point do you want us to to uh to do that so underneath prod deployment that's where that change control step was configured and we did that here so here it is prod deployment the Change Control at that stage is set to true it's not the only option we talked about Change Control versus change receipt that would be where you would establish uh what you want to happen when that change ticket is created that come up here everything going okay with the uh the chat Chris and team yeah chat looks good the only question that is unanswered right now Rosa white asks can guided tours be used with this workflow this is about 10 minutes ago so I think she was referring to gued or we'll have to somebody can answer that or we can follow up on that one okay sounds good we'll try to follow up Rosa bup that out again all looks good though we do have a poll we want to launch um let's say like at 8:50 if you're were able to close up by then does sound good Isaac that sounds good we're we just got some reporting to look at and and then we'll wrap it up from there and thanks for asking questions everyone please don't be shy no questions too dumb we we love to understand kind of where you're getting stuck where you have are having issues um this helps us to create why not just better demos and better products down okay I'll take a look at another one here so under this particular application the pipeline stage was deploy that's where we created our change control so um not sure what's happening on that one but here we are inside this particular step we said this is where Change Control takes place this is the service that's connected to it so making sure it knows all of the CIS that uh need to be represented when it comes to things like your maintenance windows or any incidents that might be open we've got our our approval group that's been set change model this would be where you say is it is it a you know a normal change or or is it part of a new model you've created called devops okay so this is really um where you where you make that change in in the differenti for your for your multimodal then change receipt so if that were to be activated we would not pause the orchestration process we would just log the receipt and uh the change request all of the information work items code commits would be inside of service now and the orchestration pipeline would just continue running so for the demonstration we did show change control so that way we could represent the work that the change management team had to do all right so wrapping it up here I want to show what's called insights and inside the the change workspace we've got a link to insights over here and this is showing you the basically it's like the Dora metrics so Google Cloud their development team kind of created uh such information like the meantime to resolution what what you really want to look for in your devop solution and right now we're looking at the last 30 days for every pipeline that I've got connected okay if you wanted to you could say uh I only want to see one particular application I'm I'm gonna step away from that instance here I'm not sure what's going on with that let's go back here all right so I could say here's you know here's my corporate website and then apply that see how the information changes okay go ahead and go ahead and clear that but underneath this we've got information like you know how long is it taking to close changes what's the change volume how many of these were you know Auto accepted and a question we get from customers is well what's good and what's bad and the answer I I like to give is we give you the report card you set the grades so for one organization uh it could be you know just absolutely wonderful topnotch to have things done in in less than an hour but maybe a a good score for another organization could be you know a day eight hours right it's it's really specific to your organization specific to also the the pipeline and that represents the project if this is a project where it's you know fast you've got a lot of automation it's a low-level service criticality you're probably going to see different numbers than some of your your larger more important applications okay so lot of great information in here you can see who's actually making code commits some little little gamification if you will how fre ly are those codee commits coming [Music] through but uh this is our our devops Insight which because it's part of the itsm pro package you do get performance analytics and that's what we're taking advantage of here all right so as far as the demonstration uh we had still there's there's more to show right there's there's always a uh more information but I think we got today what we needed to get you just started familiar with the concept and uh and how you can get started so at this point we'll go ahead and open things up if there's there's any more questions nice John I like that question thank you that's excellent so Aaron answered a question for us and we've got our Vancouver release right so guided tours are being added to workspaces uh we do have one in Q&A that has yet to be answered um sreco so how do you separate different changes coming from Azure devops when you use the Enterprise single project setup oh that's great so shco you will actually need to uh set up every project would be a separate tool connection so that's important when when I went to uh my workspace and I connected the [Music] tool right you'll use Azure and then project okay once you select your project you well that's right there you need the URL you need the Project Specific URL then during the creation of the application that's where you would uh you would set the different change type and it h it has to be set based on you setting it up um project by project so underneath application I believe this is a project level connection and we have all of that information underneath steps needs to be populated so at that point um you would do your your change model if their app if your approval group changed if it was a different service all of that would be said here and Isaac they added a comment and said how to automate this as they have 300 differences a day fantastic okay so we do we do have uh devops API and in the questions we'll I'll put a a reference to it it's actually off of our our developer page so that is what we encourage customers to use that that want to automatically create these applications good rule of thumb um it's not difficult to set up right if if you already have itm Pro just go out there a couple a couple ways to do it you can go to the store you can also go to your system plugins and it's um pretty much same thing thing underneath devops you'll see devops change velocity and right there you can you can do your install okay right beautiful we do have 10 minutes left if there are no outstanding questions I believe we're getting most of what's in the Q&A answered right now I'm going to go ahead and launch a poll i' would very much appreciate it if you all could fill this out um only two questions just uh around devops and I'll give you a few minutes to answer that all right and for U for the onboarding uhco I'm gonna go ahead and put the link the dev API okay uh Lucy so do you have to use change model with workflow flow designer you don't you don't it is actually a new edition that was put in place say probably four months ago is when we activated multimodal for the devop solution before then it was only the normal change types that were being created so I have a so I can do change model without a workflow or flow designer is that what you're saying do you have to use Change Model no I I think uh so luy so Change Model doesn't um need workflow so basically if if you create a type based change that actually triggers a workflow for your approval but uh models by default have uh its own flow designer which we ship actually out of the box uh you could also customize those flows depending on the procurement but change models especially devop change models use float designer flows okay but you have to use one of the other you can't just do a change model with like approval policies and expect it to work you would you would need change approval policies specifically need a flow okay yeah we ship out of the box uh but you could customize that flow in fact okay thank you thanks for clarifying that Lucy it's I give it a another another minute or two for the poll um only half of you have participated I know you see the poll please fill it out um but if you do have any more questions you do have a little bit of time feel free to to ask away we're here for you all right oh close the poll on my end um Isaac anything else for you it doesn't seem that we have any outstanding questions left no that's good and um want to make sure everybody gets started so definitely want to encourage you to to start activating this plugin and and uh testing it out it really is a very straightforward process it's uh the tool connections are meant to be helping you get integrated as quickly as possible so you get things set up in an afternoon start testing so definitely want to encourage everybody to go ahead and activate those those plugins if you're entitled to them absolutely very good call out Isaac um and with that that's gonna end our session for today um as always you can expect a recap Honestly by tomorrow afternoon I would imagine um as I stated before this is the second to last session so our last session will be more of a recap on all the topics we've covered so far if you or anyone in your organization has outstanding questions regarding change or S so please make sure to come to that session um we'll do our best to answer all of your questions comments concerns um with that enjoy your weekends thanks everyone thanks