Every mature IGA program eventually hits the same operational pothole:
A business-critical source goes into a planned upgrade window (hours… sometimes days). During that window, aggregations fail, provisioning fails, tickets pile up, and the tenant looks “unhealthy” even though nothing is actually “broken” — it’s just planned downtime. Multiple community threads show the same question coming up repeatedly: “Is there a way to pause aggregations or stop provisioning cleanly?”
Right now, the closest answers are workarounds (terminate a running aggregation, disable automated roles / LCS processing, intentionally break create-account policies, remove creds, etc.) — and even the responders call out that some of these are not recommended because they create noise and downstream failures.
This post proposes a new out-of-the-box capability I believe ISC should ship: Source Maintenance Mode — plus a practical, safe “build-it-now” pattern using existing ISC capabilities (Workflows, Event Triggers, JSONPath filtering, and (optionally) metadata).
- What “Source Maintenance Mode” should do a clear product behavior
A true OOTB “Maintenance Mode” toggle on a Source should be explicit and auditable, with predictable side effects:
A. Aggregation behavior
-
Pause scheduled aggregations for the source (without deleting schedules).
-
Allow admins to terminate any currently running aggregation (this exists today), but more importantly: prevent re-scheduling until maintenance ends.
B. Provisioning behavior
-
For the source in maintenance:
-
Block or queue provisioning (configurable policy).
-
Prevent “false unhealthy” status due to expected failures.
-
Provide a clear user-facing message in Request Center (or approver UI) that the source is in a maintenance window and when it reopens.
-
C. Governance behavior
-
Still allow review, approval, and audit to proceed, but ensure the user experience is transparent:
-
“Approved; provisioning deferred until maintenance ends”
-
Or “Denied; please retry after {time}”
-
-
Maintain an audit trail: who enabled maintenance, why, and what was affected.
D. Safety and scope
-
Maintenance mode must be time-bounded (start/end) and optionally require change ticket reference.
-
It must work with “All Sources” type lifecycle actions and exclusions — the same philosophy used in the newer Lifecycle configuration enhancements.
That’s the end-state.
Now, here’s the part you can use immediately.
2) What ISC already gives us to build a safe “maintenance guard” today
ISC has a few newer (and underrated) building blocks that make a clean implementation possible without “hacky” break-the-connector behavior:
Building block #1 — Workflow triggers for lifecycle state transitions
SailPoint added Workflow triggers specifically for lifecycle state changes, including a “processed” trigger that fires after ISC evaluates lifecycle actions.
That means you can build post-processing guardrails around joiner/mover/leaver changes and make the behavior consistent.
Building block #2 — Access request interception + workflow approval policy patterns
ISC supports access request automation via workflows and access-request actions, including approval policy behaviors tied to access request submission in workflow context.
Also, on the Event Triggers side, “Access Request Submitted” is a REQUEST_RESPONSE trigger that can approve/deny in near-real-time, with well-defined payload examples.
Building block #3 — JSONPath filtering + official tooling to validate filters
SailPoint documents JSONPath filtering for triggers and provides a JSONPath evaluator / CLI evaluation guidance to test filters before you deploy them.
Building block #4 — (Optional) Custom metadata on access model objects
If your tenant is suite-licensed and enabled, custom metadata can be used to tag roles/entitlements/access profiles with operational attributes (like “Provisioning Source” or “Operational Tier”). Note the licensing/enablement caveat is explicitly called out by SailPoint.
3) The “Maintenance Guard” pattern-works today, avoids risky hacks
Think of this as an operational “circuit breaker” that protects users and admins during planned downtime without intentionally breaking connectors.
Component 1 — A “Maintenance Registry”
You need a single, authoritative place that says:
-
Which source is in maintenance
-
Start/end time (UTC)
-
Change ticket #
-
Policy (block vs defer)
-
Notification targets
You can implement this registry in one of three ways:
-
Custom metadata on a Source (if/when available to you; many orgs use metadata on access model objects today).
-
A small external JSON endpoint (Git-backed static JSON, lightweight service, etc.) and query it from a workflow HTTP step.
-
A governance group–managed list inside your ITSM process (less ideal technically, but operationally common).
Key point: don’t rely on “remove credentials” as the control mechanism. The community itself calls out that approach creates noisy failures.
Component 2 — “Access Request Gatekeeper” (blocks requests cleanly during maintenance)
Goal: when a request comes in for access that provisions to a source under maintenance, handle it predictably.
Step outline (workflow logic)
-
Trigger: Access Request Submitted (workflow trigger) or Access Request Submitted (event trigger subscriber).
-
Normalize request:
-
Requested items (access profiles/roles/entitlements)
-
RequestedFor identity
-
RequestedBy identity
-
-
Map requested items → target source(s)
-
Best practice: tag each requestable item with “ProvisioningSource = {sourceName}”
-
If you can’t tag: maintain a mapping table in your registry.
-
-
Evaluate maintenance registry for any impacted source(s).
-
Decision:
-
If policy = BLOCK → deny with a human message including end time and ticket #
-
If policy = DEFER → approve but create a follow-up operational task (ticket/notification) and optionally notify requester that provisioning will complete after the window.
-
Example denial response (event trigger REQUEST_RESPONSE)
Use the documented response structure (approved boolean + comment + approver).
{
"approved": false,
"comment": "Request blocked: 'Corp AD' is in planned maintenance until 2026-01-10 02:00 UTC (CHG0034567). Please resubmit after the window or contact IAM.",
"approver": "ISC-Maintenance-Guard"
}
Operational note: request-response triggers must respond correctly and on time; SailPoint explicitly warns that non-responsiveness or incorrect payloads will cause request failures.
Component 3 — Lifecycle “Post-Processing Guard” (handles joiner/mover/leaver safely)
This is where the newer lifecycle triggers become extremely useful.
Step outline
-
Trigger: Identity Lifecycle State Changed
-
If the new state implies provisioning (joiner moves to Active, mover, etc.), check the registry:
-
If any downstream sources required by that lifecycle action are under maintenance:
-
Notify IAM and/or HR
-
Optionally create a ticket
-
Optionally place the identity in a “pending provisioning” operational state in your registry
-
-
-
Trigger: Identity Lifecycle State Change Processed
- After ISC evaluates lifecycle actions, you can audit what happened and alert if expected actions were skipped or failed.
This reduces the need for “guessing” whether lifecycle actions ran — you attach deterministic automation to the lifecycle engine.
Component 4 — Observability via Provisioning Completed (catch real failures vs expected maintenance)
When provisioning runs, Provisioning Completed can notify downstream systems and includes fields like sources, action, errors, warnings, etc.
That means you can route:
-
Expected failures during maintenance → informational
-
Unexpected failures outside maintenance → incident
4) JSONPath snippets you can copy (tested against documented payload shapes)
A) Access Request Submitted (event trigger) — only fire for specific access profile name
Based on documented requestedItems[] shape:
$.requestedItems[?(@.type == "ACCESS_PROFILE" && @.name == "Engineering Access")]
B) Access Request Decision — filter only when a specific item was part of the request
The community example uses requestedItemsStatus:
$.requestedItemsStatus[?(@.name == "Engineering Access")]
C) Provisioning Completed — only when there are errors
Payload includes errors array in the documented example.
$.errors[?(@)]
Practical tip
Validate filters with SailPoint’s JSONPath evaluator / CLI guidance before deploying.
5) “Ticket payload template” (copy/paste into Jira/ServiceNow)
{
"changeTicket": "CHG0034567",
"source": {
"name": "Corp AD",
"id": "<sourceId-if-you-use-it>"
},
"maintenanceWindow": {
"startUtc": "2026-01-08T22:00:00Z",
"endUtc": "2026-01-10T02:00:00Z"
},
"policy": {
"accessRequests": "BLOCK",
"lifecycleProvisioning": "DEFER",
"aggregations": "PAUSE_SCHEDULED"
},
"businessImpact": "Planned AD upgrade + regression testing. Prevent false unhealthy states and user-facing failures.",
"notifications": {
"iamOnCall": "iam-oncall@company",
"stakeholders": ["it-ops@company", "hr-ops@company"]
},
"rollBackPlan": "Disable maintenance mode; re-enable schedules; run targeted aggregation; monitor provisioning-completed errors."
}
6) Why I’m pushing for this as a true OOTB capability (not just “you can workaround it”)
Because the current state is inconsistent:
-
Community guidance explicitly says “there is no pause” and suggests mitigations that either create noise or require manual governance changes.
-
ISC is already investing in operational reliability features (Lifecycle enhancements like “Remove All Access” + “All Sources” selection, and more lifecycle triggers).
-
ISC already has the technical primitives to support it cleanly (triggers, request-response interception, JSONPath filtering, workflow actions).
A first-class “Maintenance Mode” would remove a whole category of tenant noise, reduce access-request failures during planned outages, and make IAM operations look mature instead of reactive.
If you’ve had to run a 2–4 day maintenance window on a core source, you’ve felt this pain. I’d love to see SailPoint ship it as OOTB — and until then, the “Maintenance Guard” pattern above is the cleanest implementation I’ve seen that avoids intentionally breaking connectors.