all right and we are recording I believe okay Welcome to our last um s so modern change life cycle launch and learn session um as I said before and in previous emails during this call we won't necessarily be covering anything new um on the screen you'll see the topics that we've covered so far what we thought of today since we did have some personel changes during this entire process we won't be doing a recap or a roadmap we want to kind of hold office hours so if you all have any outstanding questions that maybe you asked in the past weren't able to get answered are kind of curious about um obviously anything surrounding change we do welcome you to post it in the Q&A or come off mute and ask um if you have no questions you're welcome to stay or please uh scan the QR code to fill out our survey um otherwise yeah just kind of an open floor here today so let us know what's on your mind I think what would be worthwhile too Chris do we have a link to all of the previous recordings is that something that that we can post out there uh yes I posted it in our email yesterday um so honestly if that's something that you feel like you don't have access to ping me here and I can share access immediately uh it's it's a little bit of a headache to do the giant share with with SharePoint and looks like we have a question in q& a oh what we have here uh performance analytics question okay let me check that Matt let me check in that for you wonder if it's demo data hey Shiva are you on the call hey Chris yes I'm looking at the second question awesome if you do have an answer um would you be able to answer it out loud just because I'm not sure if the participants can actually see the Q&A and so it might be worthwhile to um answer these questions publicly so everyone can benefit is that the Chad Hall hey Chad how are you doing Chris got a question about the upcoming series on Incident Management yes so for the upcoming series on Incident Management uh that starts in late October if you want you can send me an email or I prefer that you fill out the uh the survey that we have here in this slide um for those of you who already filled out the survey and just clicked yes from there we already have your information and you'll see uh invite in the schedule for that upcoming launch and learn uh in your inbox within the next few weeks or so okay thanks okay so the question that I was taking a look at is do we have a good road map a guide plan on how to migrate from old original change workflows to the change models and then to S so that a business can follow so um again I don't know if we have like a migration plan from the old workflow stud the change [Music] models I'm sure there is some guidance um that we can find out and kind of share it with you there's there's probably three question questions there right Shea which is first of all migrating from workflow to flow um and then you've got migrating from mode one to mode two and and then you've got use of s so and and there is some codependency but um it's it's not hard right you you could still be using um s so and mode one change and workl if you wanted um but um you're going to get more benefit from uh being on Flow Design for sure and being on models to use S so um so I can explain some of that um I don't know how long I'm not going to spend ages talking about it but it seems like quite a good question to answer so um first of all um there's no reason why technical reason why you need to um migrate everything from workflow to to flow other than kind of keeping up with with the the with best practice so you can start doing new change models with new flows attached to those State models um whilst continuing to use workflow I think from a personal point of view you know if I was running a service platform I would want to have everything inlow because it's just confusing otherwise and you're just looking at two different sources for your kind of workflow history and you're creating two different kind of um methodology so um first of all probably there there separate path activity first of all is migrating your change workflows your existing change workflows to flow um so take picking up the new change flows and and Mig ating your normal standard emergency change uh workflows onto that flow and the second thing which can kind of be done in parallel is working out how you going to new change models so working out if there's an area of the business that um that would benefit from change models an area of it I think I shared a little bit about that you know kind of approaches to that so setting up a pilot and and working out what the benefits are and then scaling that because change models inherently allow you to work smaller than scale right you can set our back so Ro base access on the change model and you can have its own discrete set of flows so it's not interfering with normal change and you don't have to re audit or um or do anything with normal change it's it's separated out you can keep a close eye on it um and then uh and you can start working with that area of the business to do that and then the adoption of s and change well you know that the more the closer you are to change models the more kind of ARB back change models you're using the more you've thought about change models the more you're going to get out of the S experience because that then allows you to have the experiences like purpose do change you know people having the right fields in front of them being presented with the right catalog um that kind of stuff hope that answers the question I think one thing Daniel that I looking at that question that I wanted to cover as well is I just think it was if we looking at the same one that Lucy Harper pinged that says it seems change models don't really do anything at least in our environment they don't always follow what we have built in it that's 100% accurate um from a from a model point of view so if you've done a bunch of customization around around change then the out of thebox change models aren't going to follow what you would have built in but and that but so what we what we did when we when we built models is that it sort of there's parity between the old type the mode one change and the ones the the sort of the example models we ship um out the box they do the same things and we've also replicated what we used to do in workflow in and in a subtly different way in flow so you'll notice things like in in the workflow side of the world we have a normal workflow a standard workflow actually well I think it's an example there isn't actually one really um and an emergency one now there's only a single workflow for each one of those whereas in models we change things up to when we use flow on purpose we found that managing those workflows could get a bit painful um they aren't very big workflows but some customers have workflows that wouldn't fit on an A1 siiz piece of paper there's you know there's some of the workflows are Mass mive and very very difficult to manage so we broke those up into each flow was its own separate discrete piece so we only we only actually attach a flow when you move to assess you can if you need to do something in with flow in New by all means but we don't so out the box you show assess for approvals and then that flow is finished when you're finished but the next one will fire up based on authorized so have a look at what we did because it does it should in theory make things a bit easier to manage but if there is a certain amount that needs to be ported across yeah that's that's what would need to happen um but as Daniel said you don't have to be on Flow you can absolutely manage your changes with models using workflow um but it is always nicer to to be on to be on the latest thing as well and with flow doing what it's doing in the optimizations the work that goes into flow um and it's definitely it's been it's been heavily developed and worked on with performance in your name but as we speak so it's a it's an actively developed piece functionality which is was good um so we have uh a gigantic workflow um so we've got a lot of a lot of customization we've actually had service now come in and do all of this stuff with us um so like in the change model we've put our I think we have nine states um so obviously that's not out of the box um but we've put each state in there we've said you know from assess to um task approvals do it if this happens that whatever so you have your if or or statements in your change model so with the workflow um because we don't want to go to flow designer yet because I worked on that for a year and a half and it never worked um so we're sticking with workflows for now but it's still not firing correctly like we just put in wait 10 seconds um because it's not updating the states and it's um I would think that the model because you've said if this happens then do this but it's not so I don't know what I we're we're that genuinely sounds like it's worth raising a case had one we had one we actually still have one we actually are doing stuff with uh we've had five weeks of meetings with service now and no one can figure out how to make our stuff work so it's kind of FR has anybody out of curiosity has anybody from engineering um being involved out of curiosity if you know uh last week I think her name was Sue okay not my team no I'm just thinking it's highly likely if there's somebody from my team's been involved um you would have we wrote it we understand how it works and if that's what we keep asking for is somebody like you Lucy I've been across you know definitely tens and maybe more customers doing this and I've never heard of of that kind of issue um so what I'll do is I'll drop your line um and we'll pick this up okay so just for the rest of the call this is not something we're seeing across the place we would tell you if it was right we wouldn't uh but but it's you know and and we'd probably be sweating a bit more we have these kind of calls if you know stuff was breaking left or right in sensor so um the the point of moving to flow is it's easier right and you can break down you can create a set as Cameron was saying set a set of of kind of modular components that allow you to make change work in the situations that your business needs it to work um we don't see it as being a heavy kind of lift and shift you can do it at the rate you want and that's why we called it multimodal because you can do mode one and mode two um but Lucy let me let me find your email address somewhere and pick this up after okay thank you very much Daniel would you syn up with me once you got those details I can I can go and sure I will do I don't know how chat works but if you want to chat if you want to ping me the directly what that case number was as well just so I can have a look at that um just chucking into a chat directly to me that'd be great thanks okay I can send you the last year and a half worth of them too but will be fine I can go grab the history if I need to sumarize it right I'll send you the last one thank you thank you okay we have a question here from Victor what's the difference between change devops feature in change management versus the actual devops module in service now so uh they are different but the same um so change management is going to show the devops information devops information is designed to display within a change ticket so once you have that configured in the workspace you can specify what types of changes what models of changes you would like to display devops data and then the two will interact together with each other so at the moment really devops doesn't display um much else anywhere besides change tickets themselves I hope that helps Victor yes I SEC thank you welcome and Brian on the on the last one there is a comment I from Brian which talks about ensure outage records are accurately captured in a world with less manual touch points and the change process so I don't know if you want to just come off mute and kind of talk a little bit more about what you are doing today if you're still on the call right so um we you know we have uh users or or groups uh creating change record records you utilizing uh apis and um we have Azure uh records as well and in how do we know when the change is going to create an outage uh without uh the the manual process that uh is is used today I see so today when these changes are coming in through API then is someone going and creating those outage it's manually in service now or or you don't even track them in service now no I I think our concern is that there could be an outage but we're they're not creating the outage records I see I see what you're saying okay so the changes are coming in through apis um you have an Automation in place but if there is a change that is going to cause an outage then you want that relevant information to be in service now as well am I getting that right yes okay okay and then um Brian when these changes are getting created you know not every change that you're that is coming from the API integration will cause an outage right so is it would it be fair to say that based on some contextual information in that change we can determine if an outage will be caused or not right that that's kind of the the question or or the scenario is is how how do we determine yeah right okay okay yeah I know because this is this is absolutely like today I understand you know we do like a manual creation of outter jackets whether it's incident alerts or changes irrespective U and that is something that we are actually kind of trying to solve at least starting with in inent and alert first to say that you know same thing with incoming alerts not every alert will kind of lead into an outage record but how do we kind of determine so I'm hoping whatever we are learning from that space we can apply to change uh change as well if you have any thoughts around that and if you have seen any the customer do it's it's true that outage records are a little contentious right you know raising them automatically is uh is can be a bit of a political hot potato in an organization so it's quite tricky to know you know how we would validate that an outage raised by another system was was accurate if you're measuring people's performance on on you know um Service uptown up time or application up time and you've got a system that's putting in outage records then it can be a little bit contentious to do that so it's tricky to to work out exactly what the data point is we need and and what the processes around that yeah it can be but at the same time it's almost like if you're creating them manually then that is also like a you cannot rely on the outage record information either um so that's what that's where we were talking to our itom team and trying to figure out you know what are those scenarios where you will actually create an outage record automatically um and you have to be sure about it I'm I'm with you on that anyway yeah can we ask questions out loud or should we just put them in the chat you can absolutely ask as loud yeah well I was curious from Brian's perspective we're doing we're doing devops now and we're automating change requests and so forth so the question I wanted to start off with was Brian are all the change requests that you're doing automated or do you have some automated and some manual both you have both so in our scenario it would be if you need an outage record it must be a manual change because you need permission to create an outage so therefore it would never never be automated so then you don't need the automated data the way we would look at it so we have laid out some policies with regard to an automated uh change request full deployment testing closure so forth and those would generally be deemed low risk low impact you know no outage type scenarios and then by managing the manual ones so outages would belong there and service now the workflow does have a way to capture an outage record using the change process the change enablement process least that's the way I've seen it I see it working here at our company so and and that's how we are hoping that that ours is is going to work um if if the ours is based on uh risk moderate and high risk which would have an outage associated with it or could have an outage Associated should be done manually and and so that's what we've asked and so I I think we're on the same same page yeah part of the automation um that that you end up putting in place can take a look at how your risk calculations occur and they'll put in um a a variable that'll basically say something to the effect of if your risk is you know one to two it can be this if it's three to four it can be that if it's two to three it can be that right it's all in in how you want to have it coded to support the way you want to do your business at least that's what I'm seeing with our folks I can't speak for anybody else's company but you know we're just starting that road of devops right now we're working through all the necessary fields for change change enablement so forth we just have a very bulky process and there's a lot of information required here uh I think in part because we have gaps elsewhere that some of that information could be residing that we we either don't do or don't do well so like like release management for instance and the and the connection to release to change um so things like that thanks for your perspective that that that's exactly where we're at yeah it's just difficult because you don't you can't anticipate an outage if it's in an outage that was created by mistake right you the way the way we would look at some of those things is the establishment of the cmdb and your release Windows your maintenance windows or whatever you guys choose to call it and working within those windows reduces your risk and you can identify specific CIS that would require an outage and so if that's Ci or service offering or if you have application services or what have you you could effectively use your your cmdb to identify those at least from a perspective of hey anytime we do this type of change we require an outage therefore you now have a flag set that you can utilize as part of your you however your API is going to work to create those change requests opportunities there if if your cmdb is being used in that fashion Brian do you have any yeah do you have any uh monitoring or alerting tools that you you have connected um yes the there there are more so for incident uh creation and notification um the I believe that we're going to with VR cmdb they are going to do some monitoring for um unauthorized change um in the near future that sounds in process perfect okay looks like we have a couple questions in the Q&A anyone to answer those I am looking looking at the flow one now yeah I'm looking at Eduardo's one MJ would you mind putting your question in the q& a oh sorry oh you're okay um I just put it in there now awesome thank you Happ birth you know um Eduardo there's there's actually flow designer versioning so there could be potential risk to using the CIS update version table and and that would not be recommended because it's it's more so used to track changes right um manipulating it could is not what it's there for so um as far as Flow Design I would I would recommend using its inherent Version Control feature Daniel any thoughts on that yes so I was just about to say so yeah I mean you would roll about the flow in and you're not using you sound like you're just using update sets for that yeah update sets so you would just roll you roll about the flow and put in an update set and fix forward that that sounds like a much safer way of doing things and fix forward is always like Nic approach appearing to roll back um just um inherently kind of creates Less Problems yeah I was just having a read of Chads one I'm just trying to work out Chad are you trying to determine if you have approvals in the assess dat on your change and then you have another set of approvals in authorized for example using outof the boox state model are you trying to determine which approvals were bound to which state just to be able to track them in a in a in a in a more sort of fine grain type of way is that what you're asking um kind of to which state and which approval policy I guess oh okay okay okay okay yeah seen that before as well quite quite a few times is trying to trying to track back where where there's a complex approval you know situation which which actual policy was was a person responsible for approving okay I know we do we do we do specify on the on the change which approval policy is the one that was applied so that is a related list I think we have it after the Box on change yeah so that's there but if you need to so we know which one that one was and let me just check what else we actually put in there give me a sec to have to go and look to see what it is that we did there but there's a couple of things I've seen that but does that show the kind of the action that was actually taken for that policy I had a little big and I couldn't see a way of linking it after the fact um easily I've I've suggested maybe as a workaround you know um just creating a call to just put pop it in the work notes for change um yeah you can try back because we have customers who are with with regory requirements to to report that back um is it is it an activity that you need to do on every change or is it something that you would need to look at specific changes where maybe something goes wrong or or you have you know kind of compliance issue with it you need to then do a compliance report on it is it um it's not something we do for every change I guess I would say the latter but you know you don't really know until after the fact whether you're going to need to look at that history right no so the thing that we so if we we we we will associate the change approval policy that we applied at the point that we generate the approvals for it but I don't think we associate any further information with that because at that point in time if somebody we just we will then we then actually jump into um the ask for approval side so the way change approval policies has been built is it uses decision tables which is a platform um feature which allows us to put together the various decision with their answers in a in a in a really nice way but then that's all just sort of wrapped up with the ask for approval flow action we that's what it it literally just it leverages that the exact same um piece of code that handles that so it's the approval side of the world that's actually doing doing the work for us um and that's we support all the bits most the bits and all the bits that that approval support as well so we don't actually track that information I can tell tell you that the decision that we took was the maybe assess technical approvals and the action was a suon group approval and that's when we generate the approval and the same thing goes for cab you know requires cab approval and it was the cab approval action that we took and we pop in the activity name there as well so we do specify um the activity that was that we did that one as before as well so we know which decision that came out of but we don't specify for example anything else other than that so you're still going to see your network group with all the approvals whether one is approved and the rest are no longer acquired so we don't we don't find we don't actually um log more than that there's a couple of there's a couple of limitations that stands right now though um in that we don't know actually flow doesn't know flow doesn't know which specific approval ask for approval action or approval policy flow action it doesn't really make a difference one and the same you could you could argue it doesn't actually know which one of those is the one that has and owns the approvals at this point in time either there's various reasons for this um most of those are actually performance um lots of lessons learned from from the approval side of the world and on workflow and they've they've done incredibly amount of work to try and make flow and the approval side of that as performance as possible as well so no we don't precisely what you're asking for Chad isn't we don't have the capability um as it stands right now no okay do I have any recommendations for making the approval timeline more understandable I mean something that's that that Daniel said would would might be useful if there's if it's work notes related I mean I generally hate going over work notes I work cases and case tasks for for for for our customers for us and to help support relatively regularly and sometimes trying to track through the information that's put in from various people can be incredibly difficult to do changes um I'm guessing would have a definitely have a a lot fewer um updates in the work notes that might be an option but the best way to track the timeline on that I'll definitely have a bit of a think about that I might just have a chat with Daniel because he's already looks like he's got some experience around that and with the with the issues that customers have there might be some there might be something um that we can slot into the road map for some point in time too to really look at enhancing how how we report on that or track some of those things to make life a little bit easier but no nothing that's going to be very helpful at this point in time sorry but um definitely take it away and have a think about it okay thanks uh question from Joan mon she uh is asking about monitoring for unauthorized changes so Joan yeah uh first and most importantly you will need Discovery to make use of unauthorized changes so that is one of the major products in the itom suite okay so uh if you have Discovery you also uh need to definitely have a mature cmdb right because when we look at un unauthorized changes it's only looking for applications in your service mapping so first you need Discovery then you need a mature cmdb then you also have to have applications in service mapping right so if the reason for that is is if something goes down it's going to be an application right so disc Discovery looks and sees if there's there's any Deltas or any changes uh that are already in place for a certain CI and verifies if if it's allowed okay so there's there's a list of CI classes that can have unauthorized changes like memory on an enduser PC okay but if if the application is of importance it creates an emergency change with with the CI and notes from the Discover process so hopefully that that kind of gives you a foundation of what you want to look into for unauthorized changes that answer your question John yes it does thank you aw we have no open questions anyone else have anything top of mine we can wait here a few more minutes I got a question Chris for the customers is anyone uh implemented anything on the back of these um webinars or be prompted to adopt a different part of the product to think about things differently like actively or or has anyone actually you know um done that and had enough time to realize value from doing it it would be a good bit of feedback to us to learn if if anyone has hey this is uh Matt here with metti um the nextg risk kind of gave some ideas when you're talking about the change success War plugin um we we already have Sorry my phone's blowing up in the background I mute that um we had already adopted the use of the change change success score plugin we call it a change quality rating because we um Met Life ofi it we'll say um where we we're incorporating it directly into our risk conditions um we we were leveraging the information or trying to leverage the information just kind of like procedurally but um it it's part the idea of being able to incorporate it directly into the risk conditions so that part was helpful um it'd be interest to see like how like on that one page that you had um with all the boxes and the arrows um it looked like it was something separate from risk conditions but we've actually pulled it directly into risk conditions yeah now that's a great call out mat because this is Michael John hearen from elevance Health we were looking to leverage the uh change success score we've been calling it uh kind of the credit score uh uh and the the challenge for us is one filtering out some of the groups that aren't involved and change it kind of throws off the overall risk score uh dashboard for us but outside of that uh really we're trying to make risk calculation less uh user subjective because users try to game it and and really make it more you know ative so we had some things in the back end that we did you know configure customize whichever were works best for you that helps calculate certain things which the change success score is factoring in like how many P1 you know high priority incidents are involved by you know caused by change and things of that nature so we really want to leverage it more just you know having challenges trying to incorporate it into the calculations that's where we're having challenges but I I think think that was one of the good things we did see from these sessions is understanding how um nextg success know risk calculations work and can work for us yeah we we've had pretty good success with it if you want to reach out we can I can partner up with you give you some suggestions on how we've done it um just just for awareness for the service now team we're we're going to try and copyright the changes that we've made to it um we've also made um a a change success score plugin kind of equivalency for configuration items so right it's kind of a twofold there's the group doing the change but there's also how well does the configuration item the application the service at receiving change um as as a kind of a twofold two-prong approach to measuring risk um so far it's looking pretty good cool I'm just wondering as well because you've got the two different approaches right you can use a you can reuse that score a risk condition or I've seen customers as well using it in directly in approval policy are you on approval policy yet for change are you moving towards St we are on approval policy and we're looking at leveraging that primarily we still have change advisory boards um like it's the 1990s um so we're looking at uh automating the approval for those really successful groups um for the for appr through approval policy so it still generates but it's pre-approved for them but we're not quite there yet I think goad go ahead Daniel go ahead Daniel sorry go ahead no it's your call you you told no Matt I was going to ask how confident are you with the calculation of the the success scores for your teams in terms of using it to go and kind of give them I'll say give them the fast pass the change management approvals based off of it yeah the out of the box calculation didn't give warm and fuzzies so like I said we met lifeof fight it so we converted it to be 12 months instead of 30 days on um yeah we saw that as well yeah and we rather than looking at the incidents and the priority of the incidents we're looking at the outages like what was the actual business impact from that change did you cause the business outage and incorporating the outage record based off the incident rather than the incident directly um and using the the hours how many impact hours did you actually cause because not every incident's the same right not not even every major incident is the same right a P1 that lasts 10 minutes should not be weighed the same as a P1 that had 10 hours of outage right well what I was goingon to say just just then as well ties in with what you're saying which is uh kind of indirectly which is your ability to analyze failed change is really important to your ability to allow teams to work faster and and understand whether the risk calculations have been done correctly because you only really understand risk when it manifests right I mean there are ways to do it it's like we only know white planes crash from the black boxes right so um so near misses and and um and fail changes are really important toize it sounds from the approach you're taking like you've got a good understanding of how those uh you know how those fail changes are are there because you've got the idea of of impact and you know that's accurate from instant anes which which is good yeah hold I I would go so far as to actually call that plugin and the updates that we've made to it kind of a GameChanger for the way we approach and manage risk right so a lot of it is reactive historically it was reactive when something happens but now we can use that historical data to proactively combat it moving forward M thank you for insight just a followup question on something that you called out cap workbench or just cabs in general um what are you thinking are you thinking you're going to go more into the direction of kind of getting creating Dynamic groups for approvals or are you thinking you know CS are still relevant um I would very much disagree with the latter statement there me personally right and and I think the data reflects it where cab is a no value ad process at least here at MetLife um it doesn't really do much to in the form of communication because it's always at the 11th Hour of the change and it doesn't really do much to avoid impacts because the people attending the cab generally um come there with the best intentions and hoping for the best right they plan they they might be planning for the worst but they're hoping for the best and that's how they will socialize the change so Cab's not really doing much to keep stability in that regard um the first part of your question we we do have specific groups service now groups we have a bunch of different cabs because we're a global organization so every country every region has its own cab um and we want to kind of scale that back kind of roll it back and eventually hopefully I'm knocking on wood over here remove them from the process so that we can improve the velocity of change okay got it that makes sense anyone else on the call has you know an opinion feedback on just C process in [Music] general yeah sha this is Michael John from El we still use cap we actually have uh two caps that we definitely feel there is value to the cap from more of a communication perspective um so teams are aware what's going on es especially as we have releases big releases over weekends and whatnot uh as it relates to prevention of outages I kind of agree you know they don't they don't prevent things from happening unfortunately we still have outages when changes uh go arve for whatever reason um but it does at least give um I'll say our our Network team um our talk our technology Operation Center and other areas that have to respond to outages kind of a understanding of what's going on in the environment leading up to weekends and things of that nature so there's value in trying to reduce meantime to repair based on the cab uh but prevention you know you you can have a change and do everything right and still have an out it so whether you have a c whether there's approvals something can still go wrong so you know it's kind of hard to say is preventative at that point yeah got it is there is there anyone on the call who's um looking to reduce cab or looking to move it into more of a release process so separation of release and deploy and it probably mainly applies to like mode two type changes but I can see mode one where it work as well so that's changes where you have kind of either cic pipelines or you have an idea of um doing lots of small changes or blue green deployments or like feature toggling that kind of stuff but where you're allowing change to flow and not needing that cab to be there because you've got those kind of business sign offs in the release layer is there anyone who's in that kind of Paradigm who's moving towards that yeah Daniel well in my case um I've been looking into see how I can plug in releases and part of that Ops as well in in h well currently the change management process it's just getting overloaded with all all of that that it's not in service now at the moment we have teams doing releases in other applications or using Jura but it's not connect the service now so I'm feeling the same that as well cap see them to uh work effectively because we're trying to hold things to that point uh where it should be the other way around right capture be maybe just to review a couple things and it's ready to go right because you had all the pre-work before so I've been doing some investigation about that and I know that I think the plan is that service now will improve the release management module next year that's what I heard I'm not I don't have anything else we have something in we have something in Labs right now so we have digital product released Labs if if you look in store I'm pretty sure it's available to everyone sha can you can you confir maybe confirm that or someone else Mt what was that uh uh digital product release uh I know it's in Labs but I'm just I think I don't know whether I could just get to it because I work for service now I haven't checked that but I'm pretty sure it's it's available for subp instances widely and it's part of the standard itm license although it's greatly enhanced by having Pro and devops plug turned on yeah you're right it is um I just don't know if it is like approval based um Innovation Labs because sometimes I need I think there's a light I think there's a fairly lightweight approval on it approval yeah yeah yeah yeah yeah I'm actually meeting with um uh Colin later today so I can find out more but it's a really interesting product right and and and that's one of the reasons I was kind of asking the question is just to find out how that's kind of whether people are moving toward I certainly seemed like customers I talked moving towards that nice bit of innovation anything else this is been an incredible call by the way I'm gonna be spending a good amount of time trying to record everything that was said verbally um well we'll try to for those of you that may have miss something we'll try to send you a followup with some of these questions answers is there anyone who feels we didn't cover something in this series or there's something we really missed you know or something that we didn't cover in enough depth and it's like well I you know I had to go at that but I just didn't have enough information because we did we did try and kind of give support materials that had a bit of depth to them as well as kind of going over a lot of topics so just wondering if there's anything that really confuses people that we haven't or maybe just still confuses them despite the F we talked about it so no good I don't know if I call it perfect but I if there is anything that you all wish you heard more from U please let us know uh these these kinds of calls and your feedback really does help us to figure out what direction we want to have with the product and what new documentation should be first um we know we we kind of have a way to go on some of this but your feedback is very integral in that process I will suggest something um so the multimodal change one like some of the other ones that we had earlier on there was more of a how to like you know we actually saw how we did stuff and you know um went through the actual process of it where with the change model the multimodal I don't think it was it was pretty high level so I would think it would be nicer to go in in deeper okay that was one of mine so I appreciate the feedback and uh maybe I'll talk to Chris about that and see what we can do thank you thanks Lucy anyone else no all right um well if there are no does anyone on our end have any questions for our customers here today before I close this up all right awesome well well thank you everyone um very much appreciate everything you've given us um attending these sessions participating it's been an absolute wonderful process as always I'll try to get a recap out to you by Friday um with the recording please fill out that survey if you haven't already um and if you have any further questions feel free to reach out to me directly via email or anyone on the call for that matter thank you enjoy the rest of your weeks thanks Christopher thanks te guys thank you very much thank you all bye thank you