You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nearly every configuration change in JIM that alters synchronisation outcomes would benefit from preview (impact analysis) before applying, the same way #288 previews object-level sync and #421 previews schema refresh. Today, preview coverage exists for only a handful of surfaces; this issue maps every sync-affecting configuration surface to its preview coverage, covers the gaps, and proposes a unified framework so we build one preview engine with per-surface adapters rather than N bespoke previews.
Principle: any administrator action that changes which objects project, join, flow attributes, provision, deprovision, or delete should offer an impact analysis before committing, proportionate to its blast radius.
Decision (Jun 2026): framework-first, holistic
Q3 resolved. Change Preview is a holistic solution, not a set of independently-built previews. We design the unified framework (adapter model, tiers, where computation runs, proposed-config representation) first, then implement per-surface adapters in value/severity order. This is a deliberate decision to guarantee a consistent administrator UX and an optimal, single architecture rather than divergent one-off previews.
Consequence (design gate): the per-surface preview issues, #204 (scope changes), #134 (system deletion impact), #421 (schema refresh), and #91's attribute-priority impact-analysis mode, are adapter candidates on this framework. They MUST NOT be implemented independently ahead of the framework design; doing so would produce exactly the UX/architecture divergence this issue exists to prevent. Each is design-gated by this issue.
Why now
The attribute priority design (#91) decided a three-mode configuration change propagation model (apply-only / impact analysis / apply-and-resync). The impact analysis mode is the same capability needed by #204 (scope changes), #134 (system deletion), and #421 (schema refresh). Before building any of them, we design the family once.
Object matching rule changes (ObjectMatchingRule add/remove/edit, order, case sensitivity), in both simple (per object type) and advanced (per sync rule) modes, including the Simple↔Advanced mode migration
Future joins change: CSOs join to different MVOs, or stop joining (affects projection vs join decisions, and everything downstream)
Per object type or per rule; high (mis-joins are identity corruption)
Different values flow; removed mappings stop contributing (and interact with attribute recall/priority)
Per attribute; medium-high. Note: expression syntax validation and single-sample preview exist (#193); the gap is population-level impact ("this expression change alters displayName on 4,200 MVOs")
G3
Sync rule lifecycle and behaviour toggles: Enabled, Direction, ProjectToMetaverse, ProvisionToConnectedSystem, EnforceState, InboundOutOfScopeAction (RemainJoined↔Disconnect), OutboundDeprovisionAction (Disconnect↔Delete); also sync rule creation/deletion
Mass effects: disabling a contributing rule stops flow for its population; flipping InboundOutOfScopeAction to Disconnect can mass-obsolete; flipping OutboundDeprovisionAction to Delete turns scope exits into deletions in the target system
Per rule; highest severity: the destructive toggles can cascade deletions
G4
Partition / container selection changes (ConnectedSystemPartition.Selected, ConnectedSystemContainer.Selected; also run profile partition targeting)
Deselected objects stop being imported, become obsolete, trigger recall/deprovision/deletion cascades
Per system; high: a single unticked OU can deprovision thousands of objects (related: #351)
Changing the rule or trigger systems can make large numbers of existing MVOs immediately eligible for deletion on the next sync/housekeeping pass
Per object type; highest severity
G6
Connected system schema selection and obsoletion settings: object type Selected, attribute Selected, RemoveContributedAttributesOnObsoletion
Deselecting stops import/export of types/attributes (orphaning mappings); the recall toggle flips what happens to contributed MVO values on disconnect
Per system object type; medium-high
Excluded (no sync-outcome impact, or timing only): MaxExportParallelism, schedules/run profile timing, theming, API keys, certificates, logs.
Proposed Approach
One framework, three tiers, per-surface adapters
Build a single configuration change preview framework rather than bespoke previews per surface. Each surface registers a diff adapter ("given current config and proposed config, compute the affected object set and per-object outcome deltas"); the evaluation reuses the #288 preview engine and SyncOutcome model. Results presented in up to three tiers, matching the established precedents:
Count-level impact (moderate, synchronous or short background job): "1,204 CSOs would fall out of scope; 312 MVOs would become eligible for deletion" (precedent: Implement Connected System deletion with preview #135 deletion preview)
Not every surface needs all tiers; severity drives the minimum. The destructive surfaces (G3 destructive toggles, G4, G5) should not ship preview-less: at minimum tier 2 with a confirmation that states the counts.
G5 (deletion settings) and G3's destructive toggles (OutboundDeprovisionAction, InboundOutOfScopeAction): tier 2 minimum; these are the "thousands of objects deleted by one dropdown" risks
G4 (partition/container deselection): tier 2 (count of objects leaving scope)
G1 (matching rules) and G2 (attribute flow/expressions): tier 3 is where the value is
G6 and remaining G3 toggles
Split per-surface implementation issues out of this one once the framework design is agreed.
Consistent apply-time messaging (interim, before previews exist)
Until a surface has its preview, apply the #91 "apply-only" pattern everywhere: save-time acknowledgement of consequences, recommendation to run a full synchronisation, and a "configuration changed since last full synchronisation" indicator. This is cheap and uniform, and it is the fallback UX for surfaces whose preview tier is not yet built.
How is "proposed configuration" represented for preview-before-save? Unsaved DTO passed to the preview API (as Sync rule scope management enhancements #204 envisages for scoping) vs saved-but-inactive draft config?
Summary
Nearly every configuration change in JIM that alters synchronisation outcomes would benefit from preview (impact analysis) before applying, the same way #288 previews object-level sync and #421 previews schema refresh. Today, preview coverage exists for only a handful of surfaces; this issue maps every sync-affecting configuration surface to its preview coverage, covers the gaps, and proposes a unified framework so we build one preview engine with per-surface adapters rather than N bespoke previews.
Principle: any administrator action that changes which objects project, join, flow attributes, provision, deprovision, or delete should offer an impact analysis before committing, proportionate to its blast radius.
Decision (Jun 2026): framework-first, holistic
Q3 resolved. Change Preview is a holistic solution, not a set of independently-built previews. We design the unified framework (adapter model, tiers, where computation runs, proposed-config representation) first, then implement per-surface adapters in value/severity order. This is a deliberate decision to guarantee a consistent administrator UX and an optimal, single architecture rather than divergent one-off previews.
Consequence (design gate): the per-surface preview issues, #204 (scope changes), #134 (system deletion impact), #421 (schema refresh), and #91's attribute-priority impact-analysis mode, are adapter candidates on this framework. They MUST NOT be implemented independently ahead of the framework design; doing so would produce exactly the UX/architecture divergence this issue exists to prevent. Each is design-gated by this issue.
Why now
The attribute priority design (#91) decided a three-mode configuration change propagation model (apply-only / impact analysis / apply-and-resync). The impact analysis mode is the same capability needed by #204 (scope changes), #134 (system deletion), and #421 (schema refresh). Before building any of them, we design the family once.
Foundation
SyncOutcomecausal graph model that preview results can reuseCoverage Map (Jun 2026)
Sync-affecting configuration surfaces (from a codebase audit), their blast radius, and preview coverage:
Covered by existing issues (to become adapters on this framework)
Gaps (covered by this issue)
ObjectMatchingRuleadd/remove/edit, order, case sensitivity), in both simple (per object type) and advanced (per sync rule) modes, including the Simple↔Advanced mode migrationSyncRuleMapping, source attributes, expression edits, chained source order)displayNameon 4,200 MVOs")Enabled,Direction,ProjectToMetaverse,ProvisionToConnectedSystem,EnforceState,InboundOutOfScopeAction(RemainJoined↔Disconnect),OutboundDeprovisionAction(Disconnect↔Delete); also sync rule creation/deletionInboundOutOfScopeActionto Disconnect can mass-obsolete; flippingOutboundDeprovisionActionto Delete turns scope exits into deletions in the target systemConnectedSystemPartition.Selected,ConnectedSystemContainer.Selected; also run profile partition targeting)DeletionRule(Manual / WhenLastConnectorDisconnected / WhenAuthoritativeSourceDisconnected),DeletionGracePeriod,DeletionTriggerConnectedSystemIdsSelected, attributeSelected,RemoveContributedAttributesOnObsoletionExcluded (no sync-outcome impact, or timing only):
MaxExportParallelism, schedules/run profile timing, theming, API keys, certificates, logs.Proposed Approach
One framework, three tiers, per-surface adapters
Build a single configuration change preview framework rather than bespoke previews per surface. Each surface registers a diff adapter ("given current config and proposed config, compute the affected object set and per-object outcome deltas"); the evaluation reuses the #288 preview engine and
SyncOutcomemodel. Results presented in up to three tiers, matching the established precedents:Not every surface needs all tiers; severity drives the minimum. The destructive surfaces (G3 destructive toggles, G4, G5) should not ship preview-less: at minimum tier 2 with a confirmation that states the counts.
Suggested delivery order (severity-first)
OutboundDeprovisionAction,InboundOutOfScopeAction): tier 2 minimum; these are the "thousands of objects deleted by one dropdown" risksSplit per-surface implementation issues out of this one once the framework design is agreed.
Consistent apply-time messaging (interim, before previews exist)
Until a surface has its preview, apply the #91 "apply-only" pattern everywhere: save-time acknowledgement of consequences, recommendation to run a full synchronisation, and a "configuration changed since last full synchronisation" indicator. This is cheap and uniform, and it is the fallback UX for surfaces whose preview tier is not yet built.
Open Questions
Does the framework subsume the per-surface issues as adapters, or do those land first and converge later?DECIDED (Jun 2026): framework-first, holistic. Design the unified framework, then implement Sync rule scope management enhancements #204 / Connected System Deletion: Attribute Impact Analysis #134 / Schema refresh should include a preview phase before applying changes #421 / Implement MV attribute priority #91-mode-2 and the G1-G6 gaps as adapters on it, in value/severity order. Per-surface previews must not be built independently ahead of the framework. See "Decision" above.Acceptance Criteria (pre-design)
Related
SyncOutcomemodel)