all right so we're going to get started um you know welcome welcome to the second episode of our ongoing series here around solving servicenow data challenges um you know this episode is calling securing service now date against the unexpected uh you know hosted by certain solutions and we also have uh you know our guest michael here from from perspective as well thanks josh uh just introduce myself and perspective for those who have not attended our series yet perspectium is an integration as a service company and we are centered around servicenow and and its data and so we provide ways to either integrate servicenow data with other tools or applications or even other instances or pull servicenow data out for analytics archival and and backup and restore type functionality so thanks for having us today josh yeah of course and certain solutions uh for those who don't know is a you know elite service now partner who provides services across the platform and specifically has a lot of expertise around integrations and store apps so um you know very interesting to have michael here talking about kind of the the perspective view of things um just as a reminder you know we did we did previously have a our first episode around achieving data transparency and that was really focused like like michael said around getting getting uh you know data out of servicenow to facilitate uh centralized uh roll-up reporting for big organizations um and and a couple other use cases you know around that um and you know obviously we're episode two today extending or securing servicenow data against the unexpected and we'll have a an upcoming uh you know webcast here most likely in february that's called extending service now workflows to partner so taco you know talk about the uh the third one here a bit more at the end um as we get into this you know feel free to stop it feel free to ask questions via the chat we'll make sure to either hit them as part of the the webcast or or circle back to them at the end as they come [Music] so so i mean i think you know you you see a securing service on a date against the unexpected and and you think about the the kind of um you know when we talk about that i guess generally outside of servicenow's ecosystem you know we think about backup and restore right we say well i've got it in a system it's got important data and i'm gonna i'm gonna back it up in case something hap something unexpected happens and i can restore it and that's kind of the traditional model and you know those those could be things such as um air law or data loss or uh or deletion right so so i've actually um you know seen an example there where uh you know we were working with a customer and one of their developers actually just published a published a catalog item to production and you know hit an edge case and kind of spun out of control and ended up commenting um all of their incidents in a you know a loop right so they ended up with hundreds of comments in the in the journal entry of all the incidents and it became this kind of uh big big ongoing effort right where we had all hands on deck to write you know clean up activities that were going to fix that and and you know make it so the incidents were usable again and they effectively had an outage so that's one of the examples i've seen and i think we'll get into maybe how perspective can help with that yeah so you know there's a couple things that we can do if we had taken a backup of all the incoming data we could either roll back to a recent uh instance of of our service now or we could um just take this this backup that we had had been recording effectively and then overwrite the data that had had happened in error so there's a couple of ways you know to to approach that one other use case that we see a lot of or not a lot of but it does come up is the event of a failed upgrade of servicenow now servicenow is really robust right and in an upgrade you're continuing it's typically live and you're continuing to create incidents and cases and and all of those other things that we use it for and and so what we're able to do is if there's a failure in the upgrade for whatever reason if it doesn't align with our applications our custom applications and and we've got to roll back to the snapshot that was taken pre-upgrade then we're able to take the backup that perspectium has has been taking of the specific data and then put it into that updated version so we're current on all cases and all data that's been entered during that upgrade process so we'll get a little more into that um i think a little further in our conversation but i did want to bring that up because that is uh you know a potential problem area for a lot of organizations as they uh upgrade their service now and and seek to you know keep data current and and real time and and not have any data loss yep yeah that's a good one and then one of the other ones we've seen or seen people at least consider right is the is what do i do if something malicious happens right which has the same outcome data's data has been lost or corrupted as as part of you know maybe a data breach of some kind or or even like you know issues with third party libraries et cetera and while these things are kind of rare you know everybody knows and it's become pretty pretty standard practice here that as we as we start using kind of um you know enterprise tools right we introduce them to our environments we want to know hey what do we do if something happens and servicenow does do daily backups you know they typically run those after hours um you know they they are able to restore those things but it it is a it is a pretty it's the nuclear option right to do a full restore from the servicenow backup because you lose everything between the time that the backup ran and and the time you restore it and you really do have an outage as part of the restore activity right so that can be especially depending on you know what you're using your instance for and how much volume you have going on there can be really disruptive to the business and we have i've even seen a scenario where you restore partial data by restoring to a different instance then copying that data over but every every part of that required a tremendous amount of kind of effort and technical expertise to make sure the right things were getting copied in the right way and it and it did you know it wasn't uh a solution that occurred in a couple hours it became a couple day exercise so so you know those things exist that can be painful and one of the things we encounter with lots of people is there they're undergoing the servicenow journey is is you know they want to understand what options exist so so i think i think this is kind of a good time to talk about this yeah and you know you mentioned that the restoring from a servicenow backup is considered kind of the nuclear option right yep and and the cost can be quite large for that especially when we have your scenario that you talked about where it was really only the journal fields on um the task that were were messed up and so it's it's nice to have a more surgical approach to it that that says can we restore a component of of service now maybe it's incident maybe it's even more specific than that maybe it's the journal fields or um there was a mass update to all the priorities and and hopefully that would never happen but um but really it we we're afforded that opportunity to be a little more surgical in our approach to this type of a backup and restore with prospectium but let me let me tell you a little bit about just how that works and and the types of solutions that we're providing from a backup and restore perspective and there's a few different approaches one that we talked about last time is is we take data out of servicenow or we copy data out of service now on a real-time basis and put it in a local data store right and it may be cloud or maybe local on-prem either way and that data is available to to archive for whatever period of time that you want to keep it and it could be restored back to a servicenow instance the other thing that we're providing that's actually some one of our more recent products that that we've developed is very specific to backup and restore in that that's really its whole function we're not trying to copy data for reporting or analytics or anything like that what we're doing we actually provide we can provide as part of the product some some cloud storage to actually make a backup of servicenow and and store it there and when you approach that uh through our native application in servicenow you would have the options to choose uh groups of tables by subject for example maybe i want to copy the itsm module uh tables that are relative relevant for me i may want to make a backup of those and so i can just select itsm that automatically grabs incident task problem change and and some of those other related tables i may want to create a custom list and i want to bring those over but i also want itom and maybe itbm bring over some of our project data and back that up so i can do that i can stick it in a cloud storage and then if something happens i need to restore it it's right there all i've got to do is go into again the perspectium native application and and pull that over so so that's the other approach yeah that's that's really interesting what you know what about so you mentioned the ability to do the partial restore right and that certainly would have been tremendously useful for us when we when we had a customer with you know with with incident corruption effectively you know is there what about the challenge we have you know with with kind of traditional snap shot options where you're taking a snapshot of the database and you can restore that snapshot but then everything after the snapshot is lost yeah so so good question so um in that scenario um that's when you're backing up to a complete instance of servicenow right it's not a partial thing and that would be done through servicenow so so the way that our backup and restore works is it's pushing data out on a real-time basis to make a copy of it and so it can also do it in a bulk schedule if you wanted specific time stamps to a larger set of data so in that case you would just use the timestamps to filter down what data i want to restore you would recognize okay we had to restore back to our snap our servicenow snapshot dated january 1st and then you know we can easily take all of those records created between that time frame between now and january 1st and and just run those back into servicenow and that would be done again through our our native app and i keep talking about our native app and i probably haven't told you much about what it is so i'll give you a very brief description of it okay so just an update set that we would have you install in servicenow and in this update set it connects to perspectium's integration mesh okay it's basically a cloud-based uh message bus and that's where the cues are that we would send data out to you know put it wherever we want to put it whether it's in this backup repository that we talked about that we provide and then also you know if it was a local database so in the native application we would decide are we doing a regular backup and restore uh and like i talked about before what groups of tables are we going to back up and restore you would also said do i want to do it on a real-time basis or do i just want to do this nightly so all that flexibility is right there and the control is completely in the hands of our servicenow admins okay so so that sorry that's really interesting and and i know we talked about this last time but um it sounds like there's a your or perspective uses a mechanism for this data you know they're copying the data back and forth right so backup in restore that's that's pretty low impact on on the servicenow instances or at least as low impact as it can be what you know we had a question actually and this is a good question is you know what's the what's the time frame around some of these activities right if i decide to back up a set of tables like you described like itsm you know how quickly does that complete and then if i were going to go action a store for you know some set subset of that data what would that look like okay so so good questions um so the the technology that drives our solution is is fundamentally different from the way that most people would do this if they're building their own homegrown solution typically people doing this on their own and even really all of our competitors they're making arrests or api call into servicenow and when you're dealing with large massive quantities of data and you're making these continual calls in you start to risk performance impact so our approach is a little different what we're doing is we're doing an https post so we're basically pushing the data out of servicenow and we do it on a scheduled basis and we can even be as granular as assigning it to a specific node in inside of servicenow if we want to control which ones do all the work so i'm getting a little bit more technical here for for the technical folks um and so i'm gonna i'll back off from that just a little bit but um but basically um time-wise it's difficult to say because it really depends on the the amount of data that a company is is pushing uh through their their instance and then how large or how extensive the time set is for that particular backup okay right are we backing up just one day's worth of records are we just sending one record over it we call it virtually real time because it's within you know a few seconds that it that it gets to the um the destination well that's still i mean that's still that's still a tremendous difference right because there's there's um you know if i were to have to do a full restore right i've got to restore the entire entire data set and what you're describing is ability to to pick the things that have changed or pick the things in a certain time frame so you're already talking about you know a much smaller subset of data that you actually have to write not to mention all the things that that you've described as far as um you know design decisions i guess that make things more efficient yeah and and that's the key word you know that's we're trying to make this more efficient so that we're not just uh being kind of clunky with these big updates that uh that lose uh large amounts of times worth of data yep yeah of course interesting and then you know we've got these we've got these two components um you know backup and restore these these i imagine i mean these are these are things that you have to do in lots of scenarios that aren't even just restoring data have you seen you know what other use cases i guess have you seen people use kind of the copy and copy out functionality for well there's there's a couple that people use for kind of a migration type of approach what we're seeing a lot of right now is customers that are on an old instance say you know eight plus year old instance of servicenow they've done a lot of custom development in their instance and they have a lot of applications uh that they've built and they want to go back to more of an out of the box type of an approach in their servicenow instance and so we find that a lot of people want to um migrate a lot of their old data as they they change to this new system right and then for the tech folks in the room you know they're moving from an oracle db and back end of service now to a maria db and so there's some different requirements there and and the structure can be a little bit different and there's some complexity there so um and so that's one of the places that we step in and are really able to help we have two we have a medical company and a and a banking company right now that are using us for that specific reason of simplifying their data and deciding what they want to bring over because they have this history of data that they're bringing over to their new instance of service now so so again you have control what do i want to bring right i if i have an incident form and it's you know in the past 10 years we've built it up to i don't know 100 fields on the form and we decide we don't need all those anymore we only want to bring short description priority estate um then we do that we decide that's all we're going to bring over in one of those use cases of our customers that i mentioned they also decided that uh prior to two years ago we don't want to bring that data over instead we just want to stick it in a snowflake database and so you have that option as well so you can bring over what's relevant and then if you have uh archival or regulatory requirements for keeping data you can push that off to somewhere like a data store where you could um you know you could do analytics you could just keep it in case you're ever audited or you know you can do machine learning on it as well so our customers have found a lot of value in using our product for that as well yeah we've i i've personally run into that a lot right as you get into is run to organizations that have some some regulation right whether that's pci socks something medical related like hip hop you know anything like that you run into these scenarios where certain parts of your data need need to be kept for a period of time and we've seen lots of variation of that right sometimes people um they say well we're going to keep it in the system where it was created which means hey i can't i can't um or sorry we're going to keep the system in in like an archival race like a vault somewhere somewhere nice and safe and sometimes if it's like i've seen requirements for 21 years of data and in some environments hit too many things on the task table by that period of time and they want to remove stuff older than five years but where do i put it and i've you know we've helped customers with that and it can be a a pretty big undertaking and it sounds like that might be a good use case here yeah absolutely the other the other thing that it takes into account too in that situation where you're looking at long periods of time that you've got to store the data due to uh regulations is and and we don't want anyone to do this but if at some future date you decided as a company to move away from servicenow to some other tool and again don't do that not a good idea because servicenow is such a robust and powerful tool but but should that decision ever be made your data's already backed up and it's already archived and and there's no uh process at that point that you've got to go through to to meet those requirements so well then the other thing to do is you could be you could be archiving something you know you could be deleting it out of servicenow older than a certain date and for some reason at some point in the future you need to restore that to a service now instance prod or subprod to do reporting or something it sounds like that functionality would be a native a native piece as well yeah absolutely it would just be a matter of subscribing to that table that you stored it to and and bringing it back into servicenow along with its related tables so that would be something that would be uh critical in that scenarios that we make sure we bring over related tables and data that's really interesting so this is something we don't encounter you know all the time right not every company has this challenge but it's always a big point in discussion with discussion when they do and i actually have a utility provider right now who they have this process of instead of instead of worrying about kind of what's kept or deleted in each of their enterprise systems they as a system is onboarded decide which of the data from that system is critical and then they they want to replicate that data real time to a system that's retaining everything for them and and so it's kind of like this you know like archive kind of not in the sense that you know they're not just worried about stuff that's way old um they're doing it in real time so that so that you still then have freedom to be pretty agile and in the in service now and when talking to them about that you know it was it was a really big concern they're really concerned about transparency and all the types of things there and you know certainly something you can accommodate with with you know uh ad hoc integrations but it sounds like it sounds like um this is kind of the all-in-one solution that covers that use case as well yeah absolutely and and you know you mentioned having different instances of servicenow you know that's another use case that um that we've seen be used actually we have a customer um one of our customers qualcomm is using it uh using us perspectium to copy data in real real-time fashion as it's created in production to a sub-production instance and and the reason they're doing that is so they can develop their apps uh with the production load right so if they're creating 20 million records or 20 million incidents a day in production and i don't know what the number is for them and i don't i don't want them to know at this point but if they're creating a large quantity of data they need to be able to develop their applications against that type of a throughput and so perspectives making that possible for them because once a record is created in production it immediately is created in uh their development instance of servicenow and makes that that development really a realistic uh type of a testing for that so yeah that's that's really interesting so something we run into all the time right is um customers um you know customers have the scenario where they've got you know their production environments and they got their test environments they got their development environments and those may look they may look pretty different and you know i've got a customer's financial institution that that has this policy where they can't they can't connect stuff in the test layer to stuff in the production layer well then how do you how do you take you know do realistic testing and tests based on like production cmdb data for example and you know cloning and whatnot there can be pretty painful so i mean this isn't actually something i've seen done before but but it would be really interesting to take you know the the things that your that your tests are dependent upon and replicate the production data down in real time to help facilitate that that's very interesting yeah and you know this one this one fit into this segment because um and and i've experienced this as a servicenow developer as well prior to working at prospectium is everything works fine and in test yeah under a small load but then we move it to production and and we suddenly have an unexpected result right it's just not handling things so yeah it's important uh that that everyone knows you know the customers know that's an option and that's a benefit that perspective can can add awesome so yeah migration replication i think we're seeing we're seeing there's three use cases mentioned here in the replication that you've seen um both both of these are interesting i you know we're seeing more and more customers like you like you described migration earlier find uh or make the decision to to move to a a fresher new service now instance most of the time that's driven by the fact that they were early adopters of service now maybe even before before the letters right and back back in like 2000 the late 2000s and um they built lots of functionality to solve their business needs and now service now has parity with that with servicenow supported apps right and so they're saying hey rather than building maintain this thing my own why don't i adapt the service now features that they're doing all those things and and often those customers are really really heavily invested they're using lots of the platforms and supporting lots of the business and then when it comes time to migrate things to the new clean fresh snow white stack as you call it here that becomes a very large conversation it takes a lot of time and it you know it's very complex and it very interesting to see that there's a solution for that here yeah absolutely i think if there's any takeaways that i could i could hope that all our attendees had from this meeting is that um you know perspective can give you control you need to what you're backing up what you're going to restore we can make it as granular as you want down to the field level or an entire instance or even subsets of groups and and and really reduce the time that's needed to to make these types of big uh migration especially if we look at large large quantities of data so yep yeah and one of the things because i know we talked about this before um you know previously but one thing we talked about potentially covering here was the um the the acquisition scenario and i actually just got reminded because because somebody posted a very good question in chat right but you know we've had a number of customers where you've got one company purchasing or merging with another company and they both got service now and there's some consolidation effort that's going to happen in the future right um and you know what what do we do then to retain that data and i think we talked about that before and you said that you had seen customers use use um perspective to do that right yeah with accused acquisitions there's a couple of different approaches that i've seen and that that are all pretty reasonable approaches and one of them is to combine instances right the parent company may want to eventually be the master and and actually migrate all those users over yeah and so there'll be a period of time where you want to have incidents that are created in one instance of servicenow automatically appear in the other so there's complete visibility but they may not be working in the parent system yet but you want that continual data flow back and forth so there's a real-time picture on both sides and then it makes the the actual transition when it's time to bring subsidiary into the parent instance of servicenow it's a it's a more seamless transition for them because all their data is already there yeah there's not a big massive effort to to migrate data right we've already brought over the users and we've kept those in sync real time we've already been keeping the cases and the incidents real time sync and and so it just makes it a lot easier so that that's one one case where we've we've seen us kind of a gradual transition and and typically uh i think in a lot of cases we see we don't see the big bang approach with those types of of migrations it's more of a you know they'll move over a group and and work their way across the company so so so that's one approach there is the other idea also that you could do a big bang approach and just move everyone at once and then there's an exercise of going through okay what's going to go over what are we going to bring from child company to parent company and these fields don't matter anymore because we have new policies that we're following and so you have again complete control over what you want to bring over and how granular it could be so so again largely the same functionality just a new application uh and and use case yeah that's interesting so so something that just when you describe that that just occurred to me as is you know we've seen lots of customers go through that process the acquisition process consolidation etc we've helped with it a number of times one of the things that almost always seems to be a challenge is okay we've announced the acquisition and we've we're building a roadmap to consolidate technology and these things take you know one to three to five years so it takes a long time but in the meantime maybe i'm maybe i'm running a vulnerability response program in both servicenow instances and the new company or wants to be able to report on vulnerability across both companies in their instance so what you just described which is the the hey while you're using the thing separately replicate stuff across and then it's an easier transition it also solves that that midterm reporting gap where you've got to be able to report on the whole program of things in one place yeah exactly and that that uh that will provide a lot more visibility and insight into what's going on as you know you're looking at it from a governance perspective so yeah yeah absolutely um and we had we have one other question here which was um is this capability and this was i think around the migration and replication is this capability included with the data sync subscription or is it a separate subscription do you know the answer that so that one it is typically sold as part of data sync but i would have to defer to the accounting executives for a specific example or you know a specific case if there's a customer already or if somebody is considering it um to give the details on them okay so yeah good question i think i think we'll have to follow up on that one then um [Music] all right so uh anyone who has any other questions feel free please to put them in chat um as always uh michael was nice talking to you uh for anyone who joined us um you're welcome to uh we encourage you rather to to stay tuned you know we'll have the the link to the third webinar here shortly and uh you know we'll distribute that oh i think anna actually did it here in the chat thank you thank you anna so if you look at the chat you can you can subscribe to the webinar for the third webinar around extending workflows to partners um and in the meantime you know please do please do follow and subscribe uh to go to cern on perspective there's there's some links here in the webinar