Hi Dominique,

if Connect already detects items moved out of scope, I'd like to have a list of orphaned items to export for creating a crossreference list for import into another connection

At Point 6) I'd like to have a choice:

1.) Update field like suggested OR

2.) Send Mail to Link-Admin and let him decide what to do. In my case I have some 1:n Jira-ALM-Links, in some n:1 Jira-ALM-Links each with multiple type rules in different Jira or ALM-Instances.

In first case I'd have another Type Rule which would lead to Defect duplication and in second it would work fine.

With Exporting and Importing Cross References it's a little pain in the butt, but it works fine

I agree this idea description needs better wording. But I believe the spirit and intent is there. And I too would like to be notified if the project key ID from 1 JIRA project changes to another project.  In my use case here is what I imagine:

1) ALM defect is created 

2) mf connect syncs defect to JIRA as bug 

3) mf connect runs again this time telling ALM defect what the newly created project key ID is BUG-1234 for example in field called “ref ID”

4) someone decides to move BUG-1234 to an entirely different JIRA project 

5) mf connect detects that the original jira project used to sync BUG-1234 changed and BUG-1234 is now really FIX-1234 inside JIRA 

6) mf Connect is smart enough to then update “ref ID” field on the original defect field to FIX-1234 to continue the testing -> defect -> JIRA bug traceability end to end. 

I think it's good that "orphaned" octane entities aren't generally deleted. Because there could be other entities linked to them, for example manual tests. If orphaned entities were automatically deleted, this would complicate the decision of how to deal with the entities that had previously referenced the orphaned entities. A list of orphaned entities would allow the user to decide how to deal with the orphaned entities on a case-by-case basis. It would be helpful if orphaned entities were marked in Octane itself via a corresponding field because this field could be evaluated explicitly using filters.

This is partially incorrect - MF Connect does detect deletes as well as items moving out of scope.
Deletions can be sync'ed, however this is disabled by default (data source setting on type level).

I'm setting this idea to "Waiting for votes" anyway due to the main idea seeming to be about listing deletes and moves and notifying about them.

You might still want to rework or further clarify the idea description, however.