Resync & migration

A resync looks at the Jira links that already exist and fills the Linker fields to match them, for every work item the field applies to. You need it in three situations: you are moving from another linking app, you changed the link type or direction, or you want to fill the fields for links that existed before Linker.

Running a resync

Resyncs are started on the Fields page: open Jira Settings (gear) → Apps → Linker → Fields and choose Resync in the field's row actions (see The Fields page). The field configuration page does not start resyncs. The dialog walks you through the run:

  1. Pick the context. A field with several contexts asks which one to run. A field with a single context skips this step automatically.
  2. Read the confirmation. It lists what the run will do, derived from the saved context settings: the link type and direction, whether field values without a matching link are removed, how the delete behavior applies (including the "never delete" mode, where the run only fills fields and links always stay), the single-selection rule where it applies (when several links match, the newest one wins), and a note that no notifications are sent. A live count shows how many work items are affected. Save any pending configuration changes first, because the job always runs with the saved settings.
  3. Choose the options. Two checkboxes. Keep existing field values (links only add): with this ticked, the run removes nothing from the fields, links only add entries that are missing. Preview only (dry run): the same scan, but nothing is written, and the result reports how many work items would change, e.g. “12 of 480 work items would change”. A preview first is recommended.
  4. Run it. While the job runs, you see a progress bar, a stopwatch, a processed counter and a Cancel button; cancel takes effect at the next page boundary, so it stops within seconds. When the job finishes, the bar turns green and a summary reports processed, updated and failed.

What resync changes: read before running

Resync can remove field values. By default the job makes each field an exact mirror of the links that really exist. A work item key in the field without a matching link is taken out of the field; work items with links are added. The escape hatch is the Keep existing field values (links only add) option in the confirmation: in that mode nothing is removed; links only add missing entries. If your team uses the field as a hand-picked list that has nothing to do with links, run a resync only with that option ticked (or not at all, and turn off link creation for that context instead).
Links taken over by a resync stay protected. Linker treats them like hand-made links: in the default delete mode, removing such a work item from the field later will not delete the link. Only the mirror delete mode removes them.
Technical details

The job processes work items in pages and is idempotent. Scope resolution follows the context: space contexts iterate their spaces; the global context is bounded by work items carrying links of the configured type or a non-empty field value. Before writing, each work item's governing context is resolved, and work items governed by a different context are skipped, so a global run never writes work items that a space context owns. All field updates are written with notifications suppressed.

Migrating from another app or from Data Center

If your previous app created real Jira links (most do), migration is exactly one resync per context: create the Linker field, configure the matching link type and direction, run the resync as described above. The full walkthrough, including the concept mapping from Linksy and similar apps, the verification steps and the move from Jira Data Center to Cloud, is on Migrating to Linker.