When both sides are right

In many organizations the filing decision has long been made. The e-file is set, it is bound to retention rules and procedural requirements, and nobody wants a second document repository beside it. At the same time an ISMS needs evidence: policies, records, documents that belong to requirements and have to be findable there.

Having both at once only works if the same document sits in two places. And that is where the real question starts.

The easy case

If only one side changes, reconciliation is unspectacular. A new version in the e-file, so it is adopted. New evidence in isidaten, so it is filed. Folder pairs are configured once, and the rest runs.

How you know both have changed

It gets interesting when two people work independently. For that to be noticed at all, the connector does not remember its own last state but the state both sides agreed on at the last reconciliation: a checksum of the content.

If only the local checksum differs, the change happened here. If only the far side's change marker differs, it happened there. If both differ, it is a conflict. Without that shared reference point, every second change would be a silent overwrite.

Three answers, none universally right

There is no conflict resolution that fits every organization. So it is configured per folder pair:

• Manual: the sync touches nothing and marks the item as a conflict. For folders where a wrong decision is expensive.
• Far side wins: the version from the e-file is adopted. Sensible where the leading editing happens there.
• Own side wins: the isidaten state is uploaded. Sensible for folders driven from here.

The counting in the code is worth noting: an adopted conflict is booked as both, a conflict and an adoption. That keeps it visible in the log that a decision was made here, not merely an update.

What reconciliation must not do

One rule stands above the others: nothing is deleted in the e-file. Disposal there is a decision backed by retention rules, not a side effect of a data sync. Vanished counterparts are therefore marked as orphaned, not removed.

A second self-restriction goes with it: a mapping is a folder pair, not a tree. Subfolders are counted but not entered. Anyone who wants one included creates a mapping for it. That looks cumbersome but keeps conflicts and deletion rules manageable instead of running them across a structure of unknown depth.

The trap in versioning repositories

In systems such as PDV VIS-Suite a document gets a new object identifier with every new version. Remembering that identifier means losing the document on the next save and filing it a second time as apparently new. What is stable instead is the version series, and that is what gets recorded.

For failures too there is a rule that comes from operations: an error on a single document does not end the run. Otherwise one problem case holds up all the others indefinitely.

More on the CMIS connector page.