Summary

When deleting a Connected System (connector space), give the administrator a choice of how the metaverse and downstream systems are treated:

1. Teardown (current behaviour): bulk-delete the system and its objects and sever the now-dead references, leaving the rest of the metaverse untouched.
2. Synchronised deprovisioning (proposed default): process each Connected System Object (CSO) through the synchronisation engine's normal obsoletion path, so attribute recall, metaverse object deletion rules, and downstream export evaluation all run exactly as they would during a normal sync.

This issue is to ideate and design that choice, balancing JIM's data-integrity obligations against giving users a flexible, predictable feature. It needs design agreement before implementation.

Background

The deletion path is currently a fast, raw-SQL bulk delete (DeleteConnectedSystemAsync). A recent fix (branch fix/delete-connected-system-syncrulemapping-columns) made it atomic and corrected its foreign-key handling, and deliberately deferred attribute recall: metaverse attribute values contributed by the deleted system keep their value with the contributor link (ContributedBySystemId) cleared.

Today the orchestration layer (ConnectedSystemServer.ExecuteDeletionAsync) already performs one synchronisation-semantic step before the bulk delete: MarkOrphanedMvosForDeletionAsync, which marks fully-orphaned MVOs (the deleted system was their only connector) for housekeeping deletion. What it does not do, for surviving multi-connector MVOs, is:

• Attribute recall: remove the values this system contributed and re-evaluate attribute-flow precedence so another contributor can take over (per-object-type setting RemoveContributedAttributesOnObsoletion, default on).
• Downstream export evaluation: queue pending exports so other connected systems are notified of the recalled or changed values.

So deleting a system that contributed to shared identities currently diverges from what disconnecting each of its objects through sync would do.

Terminology (replacing the loose framing)

The capability in question is the synchronisation engine's connected-system-object obsoletion processing (ProcessObsoleteConnectedSystemObjectAsync, and the out-of-scope variant HandleCsoOutOfScopeAsync). Processing a CSO as obsoleted/disconnected performs three things:

1. Attribute recall with attribute-flow precedence re-evaluation (gated by RemoveContributedAttributesOnObsoletion).
2. Metaverse object deletion-rule evaluation (ProcessMvoDeletionRuleAsync / MarkOrphanedMvosForDeletionAsync).
3. Export evaluation (pending exports to downstream connected systems).

Proposed shape

Present two options on the delete Connected System action:

• Teardown (current): fast, no downstream effects; surviving metaverse objects keep this system's values with provenance cleared, and no other system is notified. Suitable for decommissioning a system whose data is no longer authoritative or relevant.
• Synchronised deprovisioning (proposed default): each CSO is processed through obsoletion handling, so recall, precedence shifts, MVO deletion rules, and downstream exports all happen properly. Suitable for the common migration case where another system should take over, or where downstream systems must be corrected.

Integration with #134

#134 (Connected System Deletion: Attribute Impact Analysis) is the preview side of this: a read-only analysis of which attributes would be recalled, which would shift precedence, and which downstream exports would fire. If we offer synchronised deprovisioning, #134's preview becomes the validation step the user runs before committing to it, i.e. a dry-run of the same evaluation the execution then performs. The two should be designed together: #134 previews the impact, this issue executes it. (Note: #134 references docs/CONNECTED_SYSTEM_DELETION_DESIGN.md, which no longer exists and should be re-created or dropped as part of this work.)

Ideation required / open questions

• What is the right default? Synchronised deprovisioning is safer for data integrity but has side effects (exports to other systems) that an admin may not expect when "just deleting a connector". Is default-safe-with-explicit-confirmation the right call?
• Data-integrity obligations vs flexibility: when, legitimately, would a user want teardown (no recall, no downstream effects)? For example removing a misconfigured or test system, or a system whose contributions should be abandoned rather than re-flowed.
• Scale: synchronised deprovisioning is per-CSO sync-engine work, not a bulk SQL delete. At 100k to 1m objects this is a different cost class and belongs in the worker/background path. How do we bound, report, and (optionally) sample it?
• Partial failure / atomicity: the bulk teardown is now a single transaction. Per-object sync processing cannot be; how do we make the synchronised path resumable, and how do we surface progress and failures (RPEIs / Activities)?
• Where it lives: execution should sit in the worker deletion path (ExecuteDeletionAsync), reusing the existing obsoletion processors rather than duplicating recall logic.
• Existing settings: does it honour RemoveContributedAttributesOnObsoletion per object type, or override it for the deletion case?

Acceptance criteria (pre-design)

• Agreed design for the two-option model (naming, default, confirmation UX) and how it integrates with the Connected System Deletion: Attribute Impact Analysis #134 preview.
• Decision on execution path (worker/background), progress and error reporting, and scale bounds.
• Follow-up implementation issues split out from the agreed design.

Related

• Connected System Deletion: Attribute Impact Analysis #134 Connected System Deletion: Attribute Impact Analysis (the preview/validation for this).
• Recent deletion FK/atomicity fix (branch fix/delete-connected-system-syncrulemapping-columns), which deferred recall to this issue.