[Music] my name is fernando garcia and i'm here to cover background scripts so what exactly is a background script it's a free-form way of executing server-side code on the fly without the need of building a trigger or script like a business row for example and so when would we exactly use a background script so when we would actually use a background script is when you want to clean maybe small decent amount size of data that doesn't require too many complex updates there are ways where if you need to update records that could have a lot of scripts executing against it as long as it's a small size or general decent size not in excess you could get around it and i can teach you a couple of functions to get around that so with that said how do you get to a background script basically you would want to search in the filter navigator background and under system definitions you'll see scripts backgrounds so you'll basically want to click that and it'll redirect you to this white screen page right here with a huge text area box where you can basically resize in the lower right corner however you need to a couple of things that you'll notice at the bottom is you have the button for running the actual script you also have in scope so if you're familiar with the global well the application picker at the top this basically functions in an identical way but basically you're going to execute that script on whatever the application that you pick from here now you also have record for rollback so when this is selected usually you would leave it by default essentially all it does it creates a record on the history for allowing you to roll back your transaction if you need to then you have these other two these are not that common execute in sandbox is more for restrictive rights so if you're trying to execute a script and you accidentally invoke a method that you didn't want to invoke like in a glide record you call insert basically this would stop you from doing those things which might not be what your background is intended for but if you're trying to be safe and you're just reading data and you just want to avoid any issues maybe that might be an option for you scriptlets that's actually introduced in the paris version of servicenow i think it's going to be used for future functionality i'm not too familiar on it at the moment but it's something that you could pretty much disregard when building a background script as of now and then this one is self-explanatory so when you execute a background script your transaction can run for hours and basically this one will kill it after four hours use this if you know that your script should finish in a reasonable amount of time and not more than four hours later especially if you're worried that your script might accidentally be executing stuff that it's shooting or updating records that you definitely don't want inaccess to be updated now a couple of tips for the background script there are two functions for starters that i would recommend that you guys read up on and basically learn a little bit more on how to use but i'll cover them briefly and that is set workflow files and autos fields so set workflow falls basically works by deactivating all types of server scripts that could execute against a glide record per se right and that could be a business rule that could be a flow workflow whatever the like this is extremely useful if you're just trying to target updating a specific field and you don't want the repercussions of any scripts triggering on that record giving you unintended updates that you didn't want now autosys fields on the other hand is more related to system update fields so this could be your created by created on updated by and updated on such fields so maybe you have a requirement from the business or whatever you implemented you don't want to mess with the process you just want to fix the data and it might depend on the timestamps of those process that are basically the system fields so if you set this to false those fields will not get updated even if you update the record so if your background script requires fixing data and you don't want any other time stamps getting modified then you would want to use autosys fields now another thing to note as well is for the set workflow function that actually also disables the audit history so exercise with caution if your plan is to update a record and you want it to be captured in the history then do not use set workflow false because that will not allow you to see it in the history and i'll show you a couple examples so here i have already built a shell for basically querying an incident and updating the state simply and in another tab i have an incident so i think i'll go ahead and pick this one you can see created three months ago it was updated two months ago and all this other information so these two system update fields i'm going to go ahead and open it we're going to take a look at the state you can see that it's closed so let's say i accidentally created a defect in the environment and it accidentally closed some incidents right so based on analysis i found such and such incidents were impacted whether an individual said or maybe something that marks them as part of my functionality so let's say hypothetically this is one that i identified and this one should be on hold per se right so what i'll do is i'll right click here copy the ssid come back to my query i'm going to go ahead and paste that society for that incident and let's say i don't want any of the rules to be triggered in case i change it to unhold so i'm going to set the workflow to false and also show you that the history is not going to get updated either as an example now i also don't want to affect timestamps in whatever form right i want to leave them the way they are now so i'll keep this on now i'm going to go ahead and before i do incident update this is the most important tip on building a background script and basically you want to make sure you log what you're actually doing before you actually do the update it's very important that you rigorously test to see what your background script actually does prior to actually making the updates because background scripts can be dangerous you can accidentally update massive amount of data that you weren't supposed to update you could impact it now there is a rollback option which i can go over in a minute but i wouldn't really depend on the rollback that the platform offers i would use that as a last resort or for very small things that you know for sure can be wrote back if you have a complex script by any chance and you mess that up rather than going for the roll back try to build another fake script to mitigate it but on the first hand try to always log your stuff and make sure that what you're updating is exactly how you want the results now what i'm going to do for this example i usually like to put my initials because if i'm sharing the platform with other developers i want to be able to see my logs right so i'm going to call this before and then i'm going to output the incident state display value prior to being executed i'll copy the logs here paste that real quick and then make that an after so i commented out the update i'll run the script and you can see before it was closed that's the ticket that i have and after it's on hold now if you really want to make sure what you're executing it against you can also add the number here as needed so i confirmed for this example that from close it'll go to unhold so i'm just gonna go ahead and update that now you can see that the update happens here and if i click into this little link right here it's going to send me to the actual rollback sequence for that record you can see some details there in case you're interested in more details and then the script execution history for what i executed now basically the scripted execution history is very useful to see who executed what background scripts and what occurred and there's also a need related links at the bottom where you can actually roll back your transaction now before i even try that i'm going to go ahead and show you the incident so let's go to the incident you can see it change to unhold and if i reload the phone real quick you'll also notice that because i set the workflow to false if i go to my history there is no entry in the audit because i set the workflow to false now going to my list view for that incident you can see the timestamps are also unaffected because i also called the autosys fields function and set that to false so i preserved the timestamp and i did not trigger any business rule or any other triggered scripts on the glide record which that also includes updating audit right so that does not appear here as an entry now let's say i messed up i did not want to update that incident so you usually would want to build a background script to try to fix it if at all possible but if it seems very difficult and maybe you really want to go for a last resort or if it's something simple in nature like this you could go to your script execution history for that script and the way to do that in the platform is you can search for script execution history go to the the module under the rollback and recovery application and find the script that you executed so the one that i executed here let's find it by the most recently created and then let's click on this one and that's basically the script that i executed recently and then i'm just going to go ahead and click the rollback scripts execution and then go ahead and type yes hit ok it's going to go ahead and execute the rollback complete completed now if i go back to my incident notice how it went back to the way it was closed keep in mind if i had not set the workflow to false and the audit history was captured this is not going to get captured in the history as well so the rollback basically i think also triggers the set workflow false function so you can see that there's no edit update for the rollback right here so it kept it back to the way it originally was a couple of last things to know if we go to script execution history keep in mind that this by default out of the box these entries last seven days before they get deleted from the system if by any chance you need to keep them more you could always go to the sys auto flash table find the script execution history table and change the age in seconds if you want to preserve them for more than seven days that's it for background scripts thank you for tuning in