Skip to main content

Refresh Cadence and Delivery

ISC only learns what's changed in your application when a new file arrives. There's no other channel — no live connection, no polling your database. The file is the aggregation. Whatever cadence you deliver on is the cadence access changes, leaver disables, and drift detection all run on, no matter what's configured on the ISC side.

Why this matters more than it sounds like it should​

If your extract is delivered weekly:

  • Someone who lost access on Monday still shows as having it in ISC until the next Monday's file.
  • Someone who joined or was granted access on Tuesday doesn't show up in ISC until next week either.
  • A leaver disabled on Wednesday keeps their account visibly enabled in certifications for up to six more days.

None of this is a bug in ISC — it's a direct consequence of the cadence. The right cadence for a given system depends on how sensitive its access is and how fast people actually move through it. Agree it explicitly rather than defaulting to whatever your export job already runs on.

What "agree a cadence" means in practice​

  1. Pick an interval and a delivery mechanism — and say so explicitly when the source is set up. Daily is the default assumption, landing before the pickup window (typically 02:00 ET — confirm for your system). Weekly or monthly is for genuinely low-velocity systems and is agreed in your onboarding ticket, not assumed; err toward daily — the operational cost is trivial and the audit story is much cleaner.
  2. Keep it. An irregular cadence is worse than a slow one, because nobody can reason about how stale the data might be at any given moment.
  3. Every delivery is a complete population, not a delta — see the Owner Guide. This is independent of cadence: whether you deliver daily or monthly, each file has to stand alone as the full current state.
  4. If the cadence needs to change, say so before it changes, the same way you'd coordinate a column change — the people relying on the data need to know its freshness assumption just shifted.

If your current process can't hit a real cadence​

Say so. A one-off file with no plan for repeats is a starting point for testing, not a production source — it means real access changes in your application never reach ISC after the first load. If your export tooling genuinely can only run on-demand rather than on a schedule, that's a conversation about the pipeline, not something to work around silently.