How to *properly* push/migrate Scheduled Jobs from one instance to another?

[ceskie]

Hello guys,

Scheduled Jobs are not part of the Application (are not considered application files), so they are not captured within an update set. I wonder, what is the correct procedure to migrate a Scheduled Job, from subdev > dev > test > prod?

We pull & push Update Sets from subdev to main dev instance. There, we make an app release, which is installed to test and prod. Regardless of this, when migrating from subdev > dev > test, I imported the Scheduled Job as an XML file. Record in sys_trigger.list was created on each instance.

The Scheduled Job executes properly on dev, but does not execute on test.

And today, on weekly push-to-test, somehow one of the Scheduled Jobs (an updated one) was a conflict with an existing Scheduled Job while installing the app on test instance. How come it was a part of a released app, when they are *not* considered application files?

Im very much confused, any clarification will be appreciated!

[ceskie]

The comment did help, however, you did not answer any of my questions.

What is the best-practise method to migrate Scheduled Jobs, is there any documentation for this? I highly doubt Service Now recommends importing a bunch of XMLs files each time you need to move Scheduled Jobs from instance to instance and then making ad hoc changes and saving each one to make them run...

TL;DR even if this approach works, my Release Management won't let me just import inactive files and making manual changes to them in TEST or PROD instance.

[Ankur Bawiskar]

Hi,

I believes how the deployment takes place the manual activities such as xml import/export and may vary from customer to customer.

I have seen in some scenarios client insists on minimal manual activities and hence in this case you can add the scheduled job in update set

In some cases there is a separate deployment team for moving update sets in this case you can have import/export xml option

Mark ✅ Correct if this solves your issue and also mark 👍 Helpful if you find my response worthy based on the impact.
Thanks
Ankur

[Slava Savitsky]

Although I agree that it is a good idea to use update sets as much as possible and minimize the number of manual steps during deployment, there are situations where avoiding manual adjustments in TEST or PROD is not so easy. For example, if each of your ServiceNow instances has a dedicated MID server, any deployed records that have a reference to a MID server (e.g., Data Sources or SOAP Message Functions) would require a manual update of that reference (unless you choose to write a Fix Script for that purpose).

As for XML import, I can understand the concerns of your Release Management team. This is a very powerful yet rather poorly controlled feature of the platform. In case of a human mistake or deliberate misuse, it can be very difficult to find out what has happened. This improvement suggestion gives some more details on the topic. Feel free to comment on it and/or vote it up.

[ceskie]

Thank you for your reply!

I do agree with you, but for most cases if you need a manual change, it means a System Property should have been involved (and make a per-instance adjustments in the properties, rather than modifying a record).

Btw. I believe that MID server case could be solved using a one MID server record (same system ID) across multiple instances, but with different configuration of this MID server record on each instance (eg. TEST or PROD), since MID server is considered data but here I am just thinking out loud.

Back to the topic, I understand the concerns of my Release Management too, that is why I am not arguing with them, but seeking a best practise solution. Importing activated Scheduled Job as an XML seems a (not really nice) way to go - but frankly, doesn't (always?) work - and importing and manually activating a Scheduled Job is a no-go even from me (but it does always work).

I wonder, whether if I make Scheduled Job (sysauto_script) and corresponding sys_trigger an Application file (eg. force it to be a part of an Update Set), if it will be executed after applying this update set (or releasing it as an app). I will give this a try and if this works out, I will consider this the answer and close this thread.

[Chuck Tomasi]

I've never really liked this as well, but I kind of get it because a scheduled job is typically specific to one instance. You don't necessarily want your dev, test, and prod instances all running the same job. I have one like that right now that MUST run in production.

Here's a few options:

1. Use a utility that forces the current record to an update set. There are a few on the Developer Portal share site. This one seems to be the most recently updated. Include in Update Set (Form & List) - A Single Button on All Non-Tracked Records - Share | ServiceNo...
2. Ironically, scoped apps include scheduled jobs when you publish them. IMHO, this is a great motivator to use a scoped app. 🙂
3. Consider using Flow Designer. It has a scheduled trigger to run nightly, every 15 minutes, etc. Less scripting means easier to build, test, and maintain - and the flow is captured in the update set!

If you do need to run it on a single instance (e.g. production only) add a line of code similar to this to prevent it from running on other instances (change myProdInstanceName to your production instance name)

if (gs.getProperty('instance_name') == "myProdInstanceName") {
  // This code only runs in prod
}