Scheduled reports get executed post clone even though they were disabled through post clone cleanup scriptIssue When using a post clone cleanup script to disable Scheduled Reports ([sysauto_report] table), the already scheduled reports prior the clone will still run on the target instance. Below is a sample post clone cleanup script: disableScheduledReport : function(){var gr = new GlideRecord("sysauto_report");gr.addEncodedQuery("active=true");gr.query();while (gr.next()){gr.active = false;gr.setWorkflow(false);gr.update();}CauseThe above code will only disable the active Scheduled Reports when it is run as part of a post-clone cleanup script or background script; nevertheless, its associated entries in the [sys_trigger] database will not be deleted.As a result, the already scheduled jobs will still be triggered even though the Scheduled Reports are dormant.ResolutionEvery time a Scheduled Report is designated as inactive in an out-of-the-box instance, the accompanying record in the [sys_trigger] table is deleted. There is a new entry made in the [sys_trigger] table whenever the Scheduled Report is marked as active once again. This entire process is carried out by a business rule called "automation synchronizer" The above script ensures that the "automation synchronizer" is not activated by using "gr.setWorkflow(false);". The Business Rule titled "automation synchronizer" will be executed if this line is commented out.