AppColl account syncing - better Connections syncing

[ChristianS9906]

Right now, if you Sync Connections from one account to the other, the existing Connections are overwritten in the recipient account. Clients are usually the ones requesting and receiving syncs from their OC; this causes issues since clients are usually also using Invention Manager, which creates IDF records that are then "connected" to the eventual application(s) that they spawn. OC, however, don't usually have Invention Manager and don't have records of their clients' IDFs. As a result, OC's connection data doesn't have the IDF linkages.

This presents a problem when OC syncs connection data to a client, as the current sync causes a wholesale replacement of the client's connection data (for all connections) to be overwritten with the OC connection data. Thus, connections that the client has between IDFs and applications will get overwritten and lost.

It would be a nice if AppColl could be set up so that users that receive syncs could specify what level of syncing should be performed on connections, e.g.:

• Sync priority connections (y/n)?
• Sync subject matter connections (y/n)?
• Sync IDF connections (y/n)?

AppColl would then only sync connections that match the connection types selected. For example, if an account owner specified "y" for priority connections only, then AppColl would, when syncing, only remove and replace connections that are "priority" connections. It would leave any "subject matter" or IDF connections alone.

Since we are not Invention Manager users, I don't know if IDFs have a separate connection type--if they are also "subject matter" connections, it might be nice to allow users to treat them differently from other non-IDF subject matter connections, so I broke them out as a separate category above.

Is this something that could be implemented?

Without it, it makes the Sync feature for connections data pretty much unusable.

Best,
Christian

[gregg_appcoll]

Hi Christian,

Protecting existing subject matter connections is certainly import. We're looking into this. Thank you for pointing this out.