Synchronization is one-way
Changes flow from Confluence to SharePoint only. Nothing is written back to Confluence.
What happens on a repeated migration run
- WikiTraccs recognizes its database lists by a marker in the list description (
wt-database-id:...). Renaming the list is safe; WikiTraccs finds it again. Do not remove the marker from the list description, otherwise WikiTraccs creates a new list on the next run. - The list is reconciled with the source database: rows are matched by their Confluence entry identifier. Changed rows are updated, new rows are added.
- Rows that were deleted in Confluence are deleted from the list. Only WikiTraccs-managed items are deleted; see below. As a safety measure, deletions are skipped when the source data could not be read completely.
- New database fields add new list columns.
- Changes to the user mapping list are not picked up on their own. The person columns are written only when the database itself is migrated again. An update run skips a database that is unchanged in Confluence, so changing the WikiTraccs user mapping list alone does not refresh the person columns. The next migration that includes the database applies the then-current mapping to all rows.
Manual changes in SharePoint
- Do not edit WikiTraccs-managed rows while further migration runs are planned. A managed row (it carries a source entry identifier) is overwritten with the source values on the next migration of that database. While migration runs are still happening, treat the generated list as a read-only mirror. Once the migration is finished, the list is a normal SharePoint list and all rows can be edited freely.
- Rows you add yourself are safe. Items without a source entry identifier are never modified or deleted by WikiTraccs.
- Safety guard: WikiTraccs only writes to lists that carry both its description marker and at least one WikiTraccs column (internal name starting with
WT_). Copying the marker into an unrelated list does not make WikiTraccs write to it.