Why Cloning Can Silently Break Scheduled Jobs<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Background sysauto table (and child tables sysauto_script, sysauto_report, etc.) contains the definition of a scheduled job.sys_trigger table contains the executable job queue — the only table the scheduler actually reads for job scheduling. If a job doesn't have a row here, it will not run, no matter what sysauto says.The link between sysauto and sys_trigger is managed by a Business Rule which runs on sysauto after every insert, update, and delete, and keeps sys_trigger in sync: On update or delete, it deletes any existing sys_trigger row linked to that record.On insert or update, it builds a brand-new sys_trigger row from the current sysauto field values and inserts it.In other words: Whenever a change to sysauto is saved, sys_trigger is fully regenerated from scratch — never patched in place.The platform has no way to enforce referential integrity between the two tables: nothing stops an active sysauto record from existing with zero matching sys_trigger rows, or vice versa. Why this can break during cloning Propagation of sysauto to sys_trigger only occurs if the Business Rule fires. Any write path that bypasses Business Rules can introduce a discrepancy between these two. Examples include, but are not limited to the following: a direct database write (database layer)certain bulk-load/import pathsor a scripted update with Business Rules explicitly disabled, e.g. GlideRecord#setWorkflow(false) One scenario that can result from this: sysauto.active=true shows the job as enabled, but no sys_trigger row exists, so it silently never runs. The reverse can also happen: a sys_trigger row keeps executing after its owning sysauto record was deactivated through a path that skipped the rule. Instance cloning is exactly this kind of path. To minimize overhead, cloning operates directly at the database layer and does not execute Business Rules of any kind — it copies table data wholesale rather than going through updates one by one. If sysauto and sys_trigger were always cloned identically, this wouldn't matter — both would land on the target in the same mutually-consistent state they were in on the source. The risk appears the moment the two tables are treated differently during the clone — which is exactly what clone's per-table exclude/preserve configuration lets you do. Clone Excludes and Preservers Exclude and Preserve are two independent, per-table settings, configured on the source instance (System Clone > Exclude Data / Preserve Data) and applied fresh on every clone. Nothing ties a setting on sysauto to a setting on sys_trigger — each table's config is its own record. See KB0717012 and KB0715621 for full configuration details. Exclude ≠ "protected" — a common misreading. The actual effect of each combination, for a given table (S = source, T = target before the clone): PreserveExcludeResult on targetIn practiceNoNoT replaced by SDefault clone behaviorNoYesT emptiedNo source data copied, no target data keptYesNoT kept, plus any S rows not already on T are addedA merge, not a pure "keep"YesYesT unchangedNothing copied from source at all Since sysauto and sys_trigger are configured separately, they can land in different rows of this table for the same clone — that mismatch is the root cause of every scenario below. Discrepancy scenarios Depending on how your exclusions/preservers are configured, the following problematic scenarios can arise after each clone on the target instance. While we provide a short-term fix for each scenario below, you should make sure your exclusion/preserver rules for sysauto, its child tables, and sys_trigger, are aligned as closely as possible to prevent/minimize such scenarios from reoccurring. Note: For each Fix below, "Re-save" means applying an actual field change (to trigger the relevant Business Rule), not just clicking Save. Saving a record with no field changes won't reliably trigger regeneration. The simplest way to guarantee it fires: disable the sysauto record, save, then re-enable it and save again (or the opposite, if it's currently disabled). Scenariosysauto settingsys_trigger settingScheduled Jobs (sysauto) UI showsWhat actually runsSymptomFixADefault (replaced)Preserve=Y, Exclude=Y (unchanged)New definition from source (current schedule/active state)Old, stale sys_trigger row from before the cloneJob runs on the wrong (old) schedule, or keeps running after source deactivated it — invisible from the sysauto formRe-save the sysauto record — it deletes the stale row and regenerates one that matches the current definition.BDefault (replaced)Preserve=Y, Exclude=N (merged)New definition from sourceTwo sys_trigger rows: the old preserved one plus the new one merged in from sourceJob runs twice, on two different schedulesRe-save the sysauto record — it deletes both existing rows and regenerates a single fresh one.CPreserve=Y, Exclude=Y (unchanged)Default (replaced)Old definition — inactive, or configured differentlyNew sys_trigger row from sourceUI says the job is off/different, but the scheduler runs it anyway — the most dangerous case, since admins trust the sysauto toggle as the on/off switchIf sysauto still exists, re-save it — this deletes the mismatched job and regenerates one matching its current (e.g. inactive) definition. If sysauto no longer exists at all, there's nothing to re-save — the orphaned job must be deleted manually.DExclude=Y, Preserve=NExclude=Y, Preserve=NEmpty — no scheduled jobsNothingMistaking Exclude for "protects data": both tables come out empty, wiping every scheduled job the target hadNothing to re-save — the job definition itself must be re-created or re-imported from source (or a backup); it will generate its own trigger normally once saved. Addressing Long Term Key takeaways sysauto and its child tables are templates; sys_trigger is the only table the scheduler executes against. A Business Rule syncs them — not a platform guarantee.Cloning bypasses Business Rules entirely — the pair only stays consistent if both tables are treated identically during the clone.Make sure to be as consistent as possible when applying clone rules on sysauto, its child tables, and sys_trigger.