> For the complete documentation index, see [llms.txt](https://msplannertojira.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://msplannertojira.gitbook.io/docs/basics/editing-sync-settings.md).

# Editing sync settings: what applies to existing tasks

When you change a sync's settings, a natural question is: **will the change fix the tasks I've already synced, or only affect what happens next?**

This page explains, setting by setting, what happens to your **existing** synced tasks when you edit a sync.

There are two kinds of behaviour:

* **Applies to existing tasks** — the next sync brings the tasks you've already synced in line with the new setting, once. You don't need to open or touch each task.
* **Applies to future changes only** — existing tasks stay as they are. The new setting takes effect the next time a task or issue changes.

***

### Settings that apply to your existing tasks

When you change any of these, the next sync catches your already-synced tasks up to the new setting automatically — a one-time pass:

| Setting you change                                                              | What happens to existing tasks                                                      |
| ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| **Progress → Jira status** (which Jira status a Planner progress value maps to) | Each already-synced task is moved to the newly chosen Jira status on the next sync. |
| **Jira status → Planner bucket** (bucket-based status mapping)                  | Each task moves to the bucket its Jira status now maps to.                          |
| **Planner bucket → Jira custom field**                                          | Each task's Jira custom field is updated to the newly chosen value.                 |
| **Assignee / user mapping** (add or edit a mapping)                             | Tasks assigned to a re-mapped user get the matching assignee on the other side.     |
| **Turn on label sync**                                                          | Existing tasks get their labels filled in.                                          |
| **Turn on cross-links**                                                         | Links are added to all previously synced tasks.                                     |

> These catch-ups run **once**, on the next sync after you save. Only the tasks that are actually out of line are updated — tasks that already match are left untouched. And if you (or a teammate) changed one of those tasks by hand at the same time, your manual change is respected.

***

### Settings that apply to future changes only

For these, your existing tasks are left as they are. The new setting takes effect the next time a task or issue changes:

| Setting you change                                                           | Effect                                                                                                                   |
| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Sync direction** (for example, two-way → one-way)                          | Applies to changes from that point on.                                                                                   |
| **Which Jira issues are in scope** (JQL / project)                           | Newly-in-scope issues start syncing; existing ones are unaffected.                                                       |
| **Default values** for newly created tasks/issues                            | Used only when new items are created.                                                                                    |
| **Cross-link location** (switching which field or mode a link is written to) | Applies the next time a task changes; links already written stay where they are.                                         |
| **Turn on or edit Priority mapping**                                         | Existing Priority values stay unchanged. The mapping is used after a real Priority change on the configured source side. |
| **Turn off Priority sync**                                                   | Existing priorities remain unchanged; later Priority changes are no longer copied.                                       |

#### Mapping a brand-new field

When you map a field that wasn't mapped before (for example, adding a due date or a custom field):

* Existing **Planner** values are copied over to **Jira** on the next sync.
* Existing **Jira** values are **not** copied back into Planner retroactively — they come across the next time that Jira issue changes.

Priority is future-only in both directions: enabling or remapping it does not rewrite existing pairs. Empty, malformed, or unknown source values also leave the destination unchanged.

This keeps a single settings change from making sweeping, unexpected edits to your Planner tasks.

When Jira's priority scheme, project, or issue type changes, edit the sync and review Priority mapping. The wizard reloads Jira metadata, removes values that are no longer allowed, and prevents saving until the mapping is valid again. The running sync does not reload that metadata every cycle, so a stale Planner → Jira target may be rejected by Jira until you edit and save the mapping.

***

### A note on conflicts

If a task changed on both sides at the same time, **Planner wins** — the Planner value is the one that's kept. Catching your tasks up to a settings change never overrides an edit you just made by hand.

***

✅ In short: **some established status, bucket, assignee, label, and link settings catch existing tasks up; Priority, direction, scope, and defaults apply going forward.**