Scheduled reports sending even though schedule is inactive

[conanlloyd]

Our sub-prod environments, (dev, test, and sandbox) are all set to send all emails to a specific email box to allow us to troubleshot notifications and share demos when needed.

As part of our clone down process, we now deactivate all scheduled emailing of reports through script, marking all of the entries in the sysauto_report table as inactive.  The assumption was that this would stop all emailing of scheduled reports in our sub-prod environments.

However, we have noticed that the reports are still being sent based on the schedules.  Today for instance 41 emails were sent for scheduled reports that all are inactive in the sysauto_report table.

How/where can I shut them off?

[Ankur Bawiskar]

Hi,

I don't think turning reports as inactive stops scheduled reports.

you can inactivate the scheduled reports as well

Regards
Ankur

[Ankur Bawiskar]

@conanlloyd 

Did you get a chance to check on my above response?

Regards
Ankur

[Aman Kumar S · Accepted solution]

Hey,

This is an known issue for scheduled jobs and applicable for scheduled report as well

Description

Schedule  job deactivate but schedule still getting created.

Cause

sys_trigger record is set to run Daily and that's why it keeps running the job.

Resolution

Please delete the deactivated record in the sys_trigger table
https://xxx.service-now.com/nav_to.do?uri=sys_trigger.do?sys_id=xxx 

Ref link:

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0855616

[PriyaRanji]

Hello All,

Good Day! Thanks for your inputs, I have recently come across such behavior but could resolve it as stated below.

Based on the analysis, here are the findings and recommended resolution steps:

Key Observations

1. In lower environments, disabling a scheduled email report automatically removes the corresponding entry from the sys_trigger table, which is the expected OOB behavior.

2. The issue typically occurs in higher environments when the scheduled email report is moved via an update set in a disabled state. In such cases, the sys_trigger entry may not be cleaned up properly, leading to unexpected behavior.

Why This Happens:

Update sets capture configuration changes but do not always replicate system-generated records (like triggers) accurately. When a scheduled report is migrated in a disabled state, the cleanup process for sys_trigger may not execute as it would during a manual disable action.

Recommended Resolution:

• Step 1: Manually reactivate the scheduled email report in the target environment.
• Step 2: Then disable it again.
  This ensures the platform executes the proper cleanup logic and removes the associated sys_trigger entry, resolving the issue

Hope this helps!

Thanks,

Priyanka R