hello and welcome to the service Ducks podcast I am co-host James darrins and I'm Rush here and we're here to chat about all things servicenow everyday life is a servicenow consultant new features implementation successes and perhaps more entertaining when it doesn't go quite so well [Applause] [Music] hello and welcome back to the service Ducks podcast Russ what you been up to this week um well um well let me have a think so I have been there's a couple of things I was going to mention actually so first of all I was back in London every time we do one you're always in London it seems like I'm in London I'm not in London a lot um and it seems like we haven't spoken for quite a while actually seems like a while since we've done this um but yeah so so I was in um London again um and the exciting thing for me um it's nice to get out um see customers see clients and and have workshops face to face um but what was nicer let me tell you um I found the brewdog bar in Waterloo there's a in Waterloo train station just underneath there's a um there's a brew Dog Bar I'm a big fan of ipas and stuff so I found that had myself a sneaky little point before I got on the train very nice um and let me tell you the place is massive it's humongous it's got an ice cream van inside uh an ice cream van inside what the there's an ice cream van inside um actually I was gonna tell you something so there's an ice cream bun inside there's a slide so if you've got to get a little bit tipsy you can slide yep make it worse you got ping pong tables there's a bowling alley um if you got bored of beer you can just have coffee you know they cater for all very nice but interestingly right they also have meeting spaces but get this this is what we're gonna do this year my friend they have specific podcast spaces oh hello hello so I'm thinking in the summer we should get ourselves down there have a few beers and do a podcast this sounds ideal from Brew dog in Waterloo a bit of sliding a bit of ping pong I I think we should I think we'll probably need um some high level sponsorship though before we could do that because it's going to be quite you could we could do Jewel you know you could do you know you could podcast while you're doing ping pongs I might come across okay that's very true actually you don't need to hire out the specific podcast bit do we could just do it in there probably get kicked out but anyways so that was really exciting yeah yeah um and the other thing so work related because that's what people are here to to listen to about service now I guess um I've been mucking about with predictive intelligence and when I say mucking about I mean yes I've had a project to do but I've been mucking about with it um and it's not something I really mess around with too much since it was first conceived many versions ago did you have men enough records to go on to train it oh God yeah yeah yeah yeah we got like 200 300 000 so we've got enough okay yep um but what gets me so so I was trying to do so I've done a bit of um for those who don't know that there's different kind of arms of predictive intelligence like classification similarity and clustering right so I've done a bit of clustering which is all about spotting opportunities for automation okay that's done great so we can now see a visual but it's kind of how do you how do you present that to the business to say these very opportunities let's go and do something with so that's the next step um but the classification thing is all about take an incident right based on the fields in this incident what's the output field so that might be an incident comes in it gets categorized in a certain way therefore we know the assignment group is this yep which is fantastic um but I think a lot of a lot of companies are more advanced than that now and it's not just about I want to reassign because that's like a silent rule right yeah exactly um it's not it's not just I want to reassign to this group it's based on this I want to then create exit you know these other records that need to go here there so do you see what I mean there's another process behind it and I think that's that's more your process automation um from what I can tell process automation the process automation workbench I think it's heading more towards that so I've been mucking around with predictive intelligence yeah am I impressed um such an underused feature I think isn't it I know it's been there a little while now and to be quite honest I've not known many servicenow customers who are at that point in a you know a maturity point where they could start investigating its use and how they can you know start to be really using intelligence I think if you have tried it and gone had some questionable results and you know does it does it really give you the kind of value um you know what's the thing yeah that's the thing does it give you the value and I think there's not enough material out there to kind of help you go through that look you've done the techie nerdy bit now what's the the business case yeah you can put forward through um and I think that's part of the challenge um but I also think there's this process automation which I need to wrap my head around a bit more um I think I did see it at one of the knowledge events and I kind of I don't know it was while I had a donut or something so yeah paying too much attention um so if you've used predictive intelligence and you're listening to this and you've got views on it either positive or negative then drop us an email and we'll read them out absolutely um excuse me so yeah so that was me um for last week uh what about you what have you what have you been doing I can see that we do this on video um and we're gonna probably start videoing these but I can see you have a a new addition to your windowsiller I do have a new addition I've expanded my uh my mascot range other than the mag the mighty here which is from Game of Thrones um mag the mighty yeah I don't think I know that one do you know that's the uh the you know the really uh big guy from Beyond the Wall Jesus it's been ages since the Game of Thrones is that why he's called Mighty no he's big I guess so yeah well he's he's Mighty Fierce uh yeah um can't be called Keith the Placid you can come up with all sorts could you no but my new addition is uh my new little ducky um I'll call him Dave um he has Dave the duck he's a nice kind of like assault ensemble in terms of like he's got a mask on and he's got a nice little headdress thing and um he looks good he's he's yeah he's different he's a different kind of duck my uh he's bigger than mine um oh Christ I just thought how that sounded but the the duck I have we both have ducks in our background mine's very small yeah it's about my duck it's about how you use it which is not a euphemism this has taken the term for the worst and this one's very dark yeah um okay but yeah no it's my dog yep that's my guy okay um but no in terms of what I've been up to as well in the last week or so um my my daughter is learning about the Titanic um at the moment at school yes and her one of her tasks well which I've deemed now my task was to build the Titanic in Lego so they've asked her to um almost create a boat and you know test it out on some kind of like you know a bit of water to see it'll float and sink and come up with you know reasons why it's flowing or Sinking so I bought this 40 pounds uh Lego Set uh to rebuild Titanic um was it a Titanic set yeah specific yeah yeah it was roughly three foot wide I'd say uh the 40 quid yeah that's not bad yeah it was not yeah it was decent to be honest with you um but it it sank within a couple of minutes the windows were too low and stuff things started to break off immediately and you know the three three or four hours hours it took to put it together was uh not entirely well anyone would say that's quite a good experiment then right yeah yeah it's supposed to sink isn't that the whole point exactly yeah yeah it was um yeah factual it did its job yeah exactly yeah he demonstrated it demonstrated this is what happened um but no it's good though is it it's good I think I think I get to invested in specifically when it comes to science and history with my daughter's homework yeah um I'm like you I get too invested it's yeah it's no longer your homework yeah yeah let me tell you why your teachers are wrong about this yeah proven them wrong yeah well yeah no it's all good it's all good so yeah so busy busy week for you then yeah busy week yeah fun week yeah all good busy week should we um for a little bit I think so let's move on from Lego [Laughter] um I thought what we do um and this again has been quite topical in the last uh few weeks and it always comes up every now and then is around what is best practice slash what is your mode of transport to get can you stay with me to get configuration through the development stack so you've got let's assume you've got your Dev test and prod environment and you're doing some configuration in your Dev environment how do you move it through the environments physically we all know we've got update sets you've got things like xmls we've got git repo repositories if you're using um uh like scope Taps and whatever yep um or interestingly you can do um for Global apps now um but how do you do that and then how do you coordinate that with teams of people that are doing that perhaps working across the same kind of products or different products and so let's start with that yeah go well I think the first thing that you you one of the things that you mentioned there around teams is quite important because sometimes obviously it depends who's listening to this if you are you know a developer for a organization if you're a developer for a partner and you could be involved with multiple different teams it really depends on um you know how many people are involved at one time is there multiple Dev instances as well that's another consideration to think about that could be more than that that's a good point all right so let's let's tackle that in a bit let's just assume we've only got one let's keep it simple one will be here for a long time it was a good point though you're a sold um developer um on a platform working on something onyx um okay yeah so my first uh Instinct with that is um obviously you want to keep things controlled moving things through the instances you may have uh teams looking to you know QA or you know uat your work that you're doing in a separate instance so you need to start thinking how am I going to track what I am doing um when I move my configuration up to the next stack okay yeah I'm with you so for me personally um I like to write things down um I like to keep a separate um logbook or I call it a run book where I can just or just in a spreadsheet nothing too fancy um and I'm sure there's other clever methods of doing this maybe even within servicenow as well um in you know Pipeline and deployment management for instance but I like just a simple spreadsheet where I can just write down these are the xmls these are the update sets this is the order that I'm intending on applying them to uh okay so you're old school old school I quite like it it's controlled and it even works if there was multiple developers so you can really understand the correct order that things are going to be applied as well so so that's for you so if you're working alongside someone in a in a team do you get them to also do the same thing yep to update exactly the same documents so you know what's being okay what order things are being completed in and what other things will be applied because I know we're going to come up to this very soon I'm sure about the argument of merge versus batch oh we will oh we will but that's interesting thing that that that you'd say if you're working with other people get them to do the same thing I think that's a key key point right yeah and I've had this argument with um I won't name any names but I've had this argument around um either and we'll come on to this as well pulling update sets from one instance to another using um sources or exporting the XML and loading the XML and and from what you just said and I agree I think as long as you're all doing the same thing and it's documented and it's agreed yeah it's a lot easier than place than if you're if you're noting everything down on a spreadsheet someone else is doing it on a packet someone else just isn't bothering it's in their head yeah I think if everyone's consistent that's that's for me that's the key yeah absolutely so yeah consistency is absolutely key and especially if you're brand new to a could be a project or to a particular organization you do want to ask about those set principles and guidelines to ask if those things are there and in place most likely you'll just see blank faces by the way yeah no no I agree I agree but it's important to you know set something down on paper to say this is the way that we're doing it so just winding it back to its simplistic terms so one of the ways you can move stuff is via update sets right yep and we we've mentioned that do you have a um a standard do you have a policy around update sets and update set management so what I mean by that is do you say right I want a standard naming convention do you have a um a policy that says each update set must have something in the description do you say that update sets are attributed to stories or epics or um I don't know some of the weird word that I can't think of but you get the idea yeah yeah and to answer that I think you you've essentially answered it for me because typically yes I didn't want to do that I know if you printed it which is pretty good we can move on no um absolutely I would absolutely include the likes of the story numbers within the short description or the naming of the update set um for some reason I don't know if it's just a habit thing I always put my initials in the update set name as well yep I know that once you move them it's going to say you know it's from James or that sort of thing but it's always good to see that your name in there because you could be exporting these files you could be like viewing it in a spreadsheet it's handy to have in there so I'm going to counter that and say well I'm not going to count you I'm going to completely agree I don't know why I said that um but I'm just going to agree it's good to put your initials in the name because if it's so if you did it and then I pulled your update set to the next instance yeah and my credentials were used in that um update Source it would be like I created the update set so it's not always obvious that James created it yeah so yeah so I would agree initials in the in the short description the name of it is a good way to go another consideration would be do you create an up this I guess it's my question to you do you create an update set per story I know if you are against this I've come across lots of Architects where say oh it's just a waste user can have so many update sets you know and you're gonna have to have them per scope as well um okay I'm gonna be bold I'll be bold yes that's it yes and what's the benefit what's the what is the benefit of having one mindset per story I so I come from an agile background right yeah um and each if we think about what a story is a story is something that is that can be deployed independently by and large it's something that we should be able to deploy on its own to deliver value to the business as quick as possible that's the whole point of agile all right is get stuff out quick yeah so the way uh when stories are written they should be written in such a way that you could deploy individually now we know that's not the case when you've got things like Integrations what's the point in deploying one without the other I get that yep but if I if I use that as my base then I'm going to create an update set per story yep that's why I would do that there are obviously edge cases and you know it's it's fine to have a discussion about it but I think if you have that starting point that's a good place to be yeah I agree I've seen examples where people will create update sets per almost per process sort of thing so you'd see like this is all the work that we're doing for Incident Management I guess that's more waterfall style isn't it really and it depends it also depends on your testing cycle and how that's going to work in terms of like you say pushing up to test it is waterfall but then then let me ask you this right so if you add an updates there per process and you're doing an incident implementation you have one updates there right yeah this would never happen come on who would do this so yeah one update set that contains all your updates you can have thousands of rows in there thousands yeah I mean you could decide to say right this is my update set for Incident Management one push that up then internet management two so here's a leading question so if and we've focused mainly on update sets haven't we so let's just go with it let's just make it all about updated um other methods it's a big part of it yeah it is yeah so if let's take your argument there so you say if you've seen people that um that contain everything in it like a product or a process update set is there a better way of doing that that's a leading question is there a better looking blank yeah is there a better way of having well other than having yeah I don't understand what you're leading to right right I see you were looking up there he's not going to help you [Laughter] take to your ceiling no what I was getting at is if you if you carry on and have update sets per story yeah there's nothing to stop you batching those with using the batching facility up into a product yes yes yeah so that's that's when we start talking about yeah Sprint batch or something like that typically yep absolutely yeah so you can deploy stories individually but you can kind of group those update sets of stories against an epic a feature whatever you want to call it product process um and then deploy the batch which then deploys all your update sets which are attributed to the stories yeah I mean it sounds perfect doesn't it sounds really good yeah yeah in theory I'd argue that the the merging or batching is purely there as an ease ease of way to um to push your config up between the instances yeah as opposed to um a feature or tool to um to help where you're storing your information and update sets if you get what I mean okay um but yeah yeah because you could also do the same way you could say you could have an update set for internet management change problem yeah and then you put that into a batch for the entirety of all of those into that'd be interesting yeah yeah but yeah it's it's horses for courses and um like you say as long as you kind of set these things up up front about how you're going to be doing this and your whole team our understanding of that I think that's what matters here's a question for you um I've got two actually so are you on the merge camp or are you on the batch Camp are you on the don't do anything camp or do you mix it up I am so I'm on the batch Camp so before batch came along because obviously it's not been there all the time merge was there and it was the the way to go um but there's something mysterious and a black mattress and black magic about merge you almost kind of like put your trust and faith in it you know it's like yeah we're gonna just merge these you know put all these things together and we're gonna trust it when it goes into uh the next instance I don't like that so just to just explain very quickly what merging is yeah so merging allows multiple update sets to be convert uh to be combined essentially into one um and the you know there is good things with that you know you you could be having multiple um developers working on an instance developing and you know you're not all in control of who's doing what and you're touching the same script sometimes and you know it's good to say right we're gonna just keep on updating it and then we're going to merge all of our config and that's what we're going to push up um okay so it does help it increases speed um you know there's probably better conflict resolution that way because like I say you know you could be working on the same script and it will just take up what's the latest um yeah the the downside to to merging is the control element right because you're pulling everything in and trusting this kind of process that whatever latest is correct gotta get with the times you've got to trust you got to trust the platform James oh you are your team merge no oh okay no do you know what I I used to be I used to be a big um not a big fan of merge but um I saw the benefit with it um yeah and I think I know when you and I were on a project we used to merge um our update sets but I think we used to why did why did I why was I comfortable with that I was comfortable with that because I was comfortable I was comfortable with you right and that sounds weird that sounds really weird I was confident in your um ability and you have some of the same personality traits as me that you're very um uh organized yeah and what you're doing right yeah um so when we were emerging I understood what we were all working on we used to speak all the time yeah that communication that dialogue all the time and if there's any kind of um conflicts or um I don't know questions around what we're merging then we'd sorted out pretty quick yeah so so yes so I I was with merge um batch I I'm I haven't merged anything for a long long time yeah since you've actually come along I'm the same yeah favoring more on um batching but his is well he's a he's a massive question right is if you're working on see if you've got a team of developers and you're working on individual update sets because we've already decided they're based on stories yep right for the purpose of this argument yep when do you batch do you batch in Dev do you move stuff up to test and batch in test or do you do some in-depth and then do the the hierarchy in um in test in fact before we get on to that let's just explain batching a little bit right so batching is where you can add um you've got a bunch of update sets and you can add a parent update set to those that creates kind of a hierarchy so consider let's take incident as a product you might have high level high level parent as being incident update set yeah and that would be the parent of other update sets let's say you've got two levels of two tiers so you might have incident routing and incident hello resolution yes maybe your second tier down and then within those update sets you've got another layer of update sets that have those as the parents so it's kind of like a a pyramid yeah I guess um and it's and it's absolutely worth making some considerations and an agreed policy of what those hierarchies are going to be as in what are you going to have on the parent levels what you can have at the second levels how many levels deep do you want to go before you start creating another hierarchy yeah I would say anyone listening to this absolutely consider that there is no right or wrong answer but consider it spend some thought and I think the key theme we keep going back to as long as it's consistent across everyone that's working on that project it's going to make it a lot easier absolutely um I think one of the other benefits that I can just add to these things is that with batch also you can include the other scopes so remember if you're working on merges and things like that very good yeah emerge cross Scopes update sets yeah so that's very good yeah yeah that's been how often are you incredibly handy it is because how often do you work in things like incident and then you have to flick over to the yeah I don't know what's it called insulin operational workspace space space work space space scope yeah it's on to the original question definitely in Dev I think having that kind of organized in Dev and together and then moving that up together rather than changing it in tests I don't know if you have a different opinion on that but I prefer to manage yourself I I think I agree I I guess it depends there's a lot of variables isn't it it's like where are you doing testing hmm where are you doing uat um because some people some people only have developer um and prod instance right so we're going to think about that so some people don't even have a test yeah I think it's um it's quite rare but you're right yep there is a few so I guess again it keeps coming back to it I I think you got to take each scenario as it comes but as long as it's been considered there's been a discussion he's been agreed and it's documented I I would you know I'd I'd say anything goes um yeah I think for me in the right way yeah if you're if you're batching it up or all kind of like ready and Dev and you're pushing that up to up to test that's your first kind of you know check that it's going to go into a different environment as you'd expect so when you're pushing this into prod you know generally what you're going to expect by doing that so yeah if you're you know if if some kind of issue happens and um you know what you don't want to do is just kind of then start to change how the update sets look and feel and test and then you're testing almost something completely different going into prod so you're almost setting yourself up for a fall potentially that that is a really good point actually um unless you have a staging environment yep yeah you've made a good point because we we need to remember um the proper flipping coin by me there but we need to remember that that it's not just testing that the dev works yeah tests it's testing the deployment as well so you're you're quite right is deploy it as you would from Devon to test as you would from test into prod you know because that's your kind of dry run right yeah I'm going back to our very first point about having some kind of run book you can then document all of those expected skipped updates or which things to accept which things do it yeah um all there ready and you're going to get the same thing going into broad yeah that that's good I mean I we've just um I just did a project the other week actually where um it was kind of an ongoing piece of work and we cloned over another environment purely to do a dry run of the deployment again yeah so we'd already done it into test yeah but anyways belt and braces let's do another one and do you know what that allowed us to refine the implementation plan because that's another good thing have an implementation 100 it allowed us to refine that and spend time because we're not all perfect we're going to get errors we're going to get collisions and you need to document them and make the decisions right you accept the errors do you skip the errors what do you do do you do a fix update set or whatever but it allows us that that kind of comfort blanket to do that document it so at least when we're deploying it to live we know exactly what to expect yeah and and the other argument and I always say this right would you rather do a dry run that takes two hours in office time that means your deployment outside of office time takes 30 minutes or would you rather or would you rather not do that and spend two hours 30 minutes deploying it in your own time exactly yeah yeah if you want to think about it like that go ahead and like like you're saying it comes down to instance management and how if you have any instances you've got whether you can get a temporary staging instance um you know there could be multiple teams pushing things up to test so can you can you you know can you really do the additional clone back just for that purposes for your yours yeah um lots of things to kind of consider um but yeah it's worth its weight in gold if you can do that oh I think so especially if it's a big release yeah I I I I think so um I think so absolutely so okay we spoke a bit about merging we spoke a bit about batching yeah we've talked quite a lot about update sets yep so what's your what's your thoughts and how to move those updates so we we've decided that we're going to do in the story and we can batch and all that kind of stuff yep how do you move them from environment to environment are you on team export the XML and import XML or are you on team pull it across using the update source so um this is going to be very gum really thoughtful where you cross your other you've got quite defensive I noticed my way only this is going to be a similar story to like the murder free batch I think up to a certain point I don't know when I kind of switched my ways but up to a certain point I was always export export export I still like to export regardless of option by the way because it's good to have that kind of copy of your work you know what happens sometimes when you yeah accidental clone backs when you don't expect it or you know something happens on the inside on the instance yeah um so it's always good and a good practice to export your update sets regardless uh okay but I am on team pull up for the update sources I find it theme pull up easy to use um it's just so quick um I do like if you were to for example have an update set on dev you pull it up to test there's an error to do with you know skipped um or you know um uh you know collisions where it can't update immediately so I like to go back and say okay well I'm going to delete that update set then from test I'll go and fix it in Dev first so it's clean when it goes back up deleting so I like to do that as well rather than additional updates to fix what's previous yeah yeah yeah yeah so so Okay so what uh what can we call the other team I can't call it team exported import oh we will okay okay so I like you I was always on team export yeah and I think I know why I was um that way and it's probably the same as you maybe years ago I would always export an import and that was because I had complete control of what I was moving I had I I knew because I have a run book as well right I call that run book let's not dress it up it's a spreadsheet right yep so I had that as well where I'd export update set log in my spread Twitter sheet import into the next environment and I would go through the process it'd be like a process in my head ticking the box to say it's now in the test environment yep but um and that was when I was working on a project with multiple different teams multiple different partners so I didn't want them to pull my stuff up before I was ready to do it yeah yeah good point yeah okay yep um I have now moved on to team what do we call it pull up so I I have no team pull up yep um the the things I would mention around that is when you go so it's um update set sources is the module and you can pull it up from whichever environment you like but make sure it's a sub prod one um and you can add in the credentials the only thing I would say is make sure they're they're some kind of service account yeah um and I guess you have to be you just have to know that when you complete an update set in Dev and someone else pulls it up it's going to pull your updates out just don't mark it as complete if you're not ready for it to be pulled up and that's the point right so yeah and that's the point if you're batching as we've said that we're going to batch in yeah Dev you've completed them if you start completing them and think well I'll add the batch later and then someone comes along and pulls it up yeah pull it up very good point yep so you you I guess you need to have a process that says yes we'll batch in death but we'll do it at this point and this is what the state of the update sets need to be before or after whatever yeah and the only downside of that I can see is you you could be a developer with multiple update sets open yeah in progress yep and even though if you're done it's a track yeah well that that's what I mean if you've got if you've got a developer you you could have let's say 10 update sets open all in progress right yeah that you have actually done yeah you're waiting to match them right um and that brings me on to my next point I don't like that at all I can't stand that are you one of these people that has multiple web browser tabs open no right that is one of my biggest bug Bears if I do a share screen with someone and I see them have more than 10 web brows I I had to manage it yeah yeah how can you do it I think finally when you go through life with that many different browsers yeah um but it's the but it's the same with updates for me if I see I've got multiple in progress I start to panic yeah I don't like it don't like it yeah I know what you mean and it may well be that you're not then becoming agile if you know what I mean so if there's 10 different update sets and you know it's still there after a Sprint should it still be there well that's it yeah I guess it should be I guess completed no you could rely on your run book more than your update sets yeah lists and it depends I guess it you're quite you're quite right it depends what methodology you're using to deliver right whether you're using agile waterfall wagile um yeah I guess you have to come up with a method that's going to fit it yeah but again I keep coming back to that same point as long as it's documented and everyone's on the same page absolutely yeah um another consideration is that you may not have access to prod so you may have to think about um you know that you only have the ability to push up into tests and some organizations will be okay with that but again it's up to a different completely different department um who will then do the push to prod for you so you know whether it's going to be exported xmls they could miss some XML so you know during the night they're going to call you and say yeah oh I'm missing all this stuff whereas if you're just pulling up through update sources it's a lot easier that's very true um that's another thing to think about yeah and that that's another good point is if you're if you are um a customer of service now and and you know you live and breathe this in your in your day job uh I guess that's different than if you're a partner like you or I where we go to work on someone else's instance and sometimes they might already have their policies so what you do in one project may not be the same for the next project yeah exactly so your naming convention may be different your method that you used to pull up you might be working with an architect because fortunately for you you are the architect so you make the rules um more often than not um but you may be working on another project the architect says no no I want you to export them put them on a floppy disk there's something we haven't heard for a while copy this um you know and post it and we'll load it ourselves in fact actually I've been on one of those projects where you where you do stuff by disk yep um yeah so yeah I think I think we we we're making some good points and I think the sailing point which keeps coming back around for me is consistency agreement and some kind of policy around it yep 100 I think that that kind of summarizes it quite well yeah I think we need to summarize it because we've we've we've gone 38 minutes don't say 38 minutes because I'm going to cut a load out um but no this has been a good conversation actually and I wasn't expecting it to kind of ignite as much as it has we're obviously quite passionate about it we haven't even talked about things like GitHub repositories oh I know app repo team development um what would you put in the change when you pushed to prod um yeah lots of different things I know we're gonna have to come back to this um and and yeah and go through it's obviously a Hot Topic that we're passionate about yeah it applies to quite a few different people from different backgrounds as well I think so yeah and do you know what else I noticed right is you didn't because I can see your hands right you didn't look on the web for the textbook answer you didn't do you didn't do your research to say this is so what service now say about updates no no I didn't at all um I think like you say because it's something that is common for every single project that you were that you were on um yeah the you're gonna have update sets and you're gonna go for this again and again and again so you've I think you can guarantee that everyone listening to this has been burnt I I listen to um might have been a podcast uh with Chuck tomasion as a name drop um going back ages ago and it was all death to the update sets we don't want update sets and this was this was when they bought out the fact that you could do uh that you could put uh Global apps inside yeah kind of send it off to yeah at reposter like you thought the word I couldn't think um and that was oh God that was how long ago um so so yeah it hasn't happened does it no no they they're pretty the same thing with me on my on the CMA course I attended and they said update sets will at some point go I think they're they're even saying that it'll be you know sunseted or um I think they'll struggle to Sunset but I think they're they're really quite pushing I think they are quite well no let's launch our campaign to uh take our banners that's it go outside servicenow offices it's this you know organize a Time keep the update said no um but anyway James this has been really good I hope um people listening has found this really really useful yeah um if you are listening you've got any thoughts observations anything you do any funny stories we like funny stories yep um then drop us an email make sure you're following the podcast and until next time I've been Russ I've been James and this is service ducks that's all for today's podcast thank you for listening and if you want to get your question answered by the service Ducks get in touch through talk to the doc at service hyphandux.com or just use one of the links below [Music] [Applause] [Music] [Applause]