⏰ OasisPro · Scheduled Reports Migration · IFS Cloud 26R2
Nobody remembers setting it up. Nobody's watching it either.
Crystal Reports scheduled reports are the part of an estate that's easiest to forget entirely, because they don't show up when someone opens the reporting tool and browses around. They run quietly in the background, on a timer, and the first sign something's wrong is usually someone asking why a report they depend on stopped arriving.
An estate audit that only counts reports people actively open misses this category completely. A scheduled job that fires every night at 6am and emails three people has no visible footprint until it silently breaks.
Here are the 6 things nobody checks about scheduled reports before IFS Cloud 26R2 catches up with them.
A scheduled report has no user actively watching it work. That's exactly why it's the report most likely to break silently and stay broken the longest before anyone notices.
Interactive reports get discovered broken quickly, because someone's actively looking at them. Scheduled reports get discovered broken whenever someone finally asks why an email stopped showing up, which can be weeks later.
The 6 Crystal Reports scheduled reports things nobody checks before 26R2
- 1. The scheduled job registry itself. Scheduled jobs don't automatically carry over to a new scheduling mechanism just because the report they run does. The job registry needs its own explicit audit, separate from the interactive report count.
- 2. Distribution lists. Who actually receives a scheduled report by email is often undocumented anywhere except the original schedule configuration, and that list is easy to lose entirely during a migration if nobody specifically preserves it.
- 3. Output format compatibility. Formats used for automated distribution, specific PDF settings or file naming conventions downstream systems depend on, may need reconfiguration rather than carrying over automatically.
- 4. Failure notification and monitoring. If a scheduled job fails after migration, who finds out, and how fast? A migration that doesn't preserve failure alerting turns a broken job into a silent one.
- 5. Historical archive of past outputs. Some organizations need past scheduled report outputs retained for compliance or reference. That archive doesn't automatically travel with a migration unless someone plans for it explicitly.
- 6. Timing and timezone handling. A job scheduled for 6am in one environment needs to fire at 6am in the new one too, and timezone handling differences between platforms can shift that silently.
Why the job registry needs a separate audit
Scheduling configuration lives in a different place than the report itself, and a migration focused only on reports can leave the schedule behind entirely without anyone noticing.
Why distribution lists are easy to lose
Nobody documents who receives a scheduled report anywhere except the schedule configuration itself, which means losing that config means losing the list of who's supposed to get it.
Why failure notification matters more here than anywhere else
A scheduled job with no failure alerting can be broken for weeks before a single person notices, simply because nobody's actively watching it the way they would an interactive report.
The audit step teams skip entirely
Pulling the scheduled job registry as its own explicit step, separate from the interactive report count. If it's not in the estate audit specifically, it's invisible until someone notices a report that used to just show up in their inbox has quietly stopped.
How to actually audit scheduled reports
Pull the scheduled job registry as a distinct line item in your estate audit, not folded into the general report count.
Document every distribution list before migration begins, since that information often exists nowhere else once the original schedule configuration is gone.
Confirm failure notification survives the migration for every job, so a broken schedule gets noticed in hours, not weeks.
A report nobody actively opens is still a report someone's relying on. It just fails more quietly.
What skipping this audit actually costs
A nightly report that quietly stops arriving, discovered weeks later when someone finally asks why they haven't seen it recently.
A distribution list lost entirely during migration, with nobody able to reconstruct who was supposed to be receiving the report in the first place.
A compliance-relevant historical archive that nobody planned to preserve, discovered missing only when someone specifically needs to reference it.
We'll audit your scheduled jobs as their own workstream.
OasisPro pulls your scheduled job registry, distribution lists and failure notification setup as a distinct part of the estate audit, so nothing quietly stops running after migration.
Start with the Crystal Reports estate auditDon't let a scheduled report quietly stop arriving.
Send us your current IFS Cloud environment and we'll pull the scheduled job registry, distribution lists and failure notification setup as their own audit, separate from your interactive reports.
Why do scheduled reports need a separate audit from interactive reports?
Because scheduled jobs have no active user checking them, so a failure can go unnoticed for weeks. An estate audit that only counts reports people actively open misses this category of risk entirely.
What happens to distribution lists during a migration?
They are easy to lose, since the list of who receives a scheduled report often exists nowhere except the original schedule configuration itself. That needs to be documented explicitly before migration, not assumed to carry over.
Why does failure notification matter more for scheduled reports?
Because nobody's actively watching a scheduled job fire the way they would an interactive report. Without failure alerting, a broken job can run silently, or stop running silently, for weeks before anyone notices.
Should historical scheduled report outputs be preserved during migration?
For organizations with compliance or reference needs, yes, but that archive does not automatically travel with a migration. It needs to be planned for explicitly as part of the scheduled reports audit.
Audit the jobs, not just the reports
A Crystal Reports estate audit that only counts what people actively open misses an entire category of risk running quietly in the background.
Six things, all of them invisible until someone notices a report stopped showing up. Check them before that happens, not after.