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:
- Pick the context. A field with several contexts asks which one to run. A field with a single context skips this step automatically.
- 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.
- 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.
- 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
- The job runs in the background and is safe to repeat: running it twice gives the same result.
- It never sends notifications, no matter what the notification setting says.
- It only touches work items governed by the chosen context. The run scans the context's spaces (a global context scans every work item that has links of the configured type or a non-empty field), and within that scan, work items that another context governs are skipped: a space-specific context wins over the global one.
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.