> 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.

### Checking permissions

In **Configure**, choose **Permissions** under the Jira project to see its requirements. Automated syncs normally need **Browse Projects** to read issues and **Edit Issues** to store sync metadata in Jira issue properties, even for Jira → Planner synchronization. Missing permissions appear beside the project with **How to fix** and **Recheck permissions**. A successful project check does not guarantee access to every individual issue.

User access is checked only when **Map assignee** is enabled. If Jira or Microsoft user access is missing, recheck after correcting it or turn off assignee mapping to continue. Administrator details are available inside that warning.

Project permissions are checked when you create, save or enable an automated sync, and when you choose **Recheck permissions**. Scheduled cycles do not make an extra project-permission request. If rights change later, ordinary read/write requests still report their failures; some changes may already have been applied before a failure is discovered.

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)                                     | Eligible unlinked issues can enter the sync according to the selected task source. Linked pairs pause outside the filter and resume on the same link after re-entry.                                                           |
| **Add tasks to this sync from** (Planner / Jira / Both)                      | Controls which unlinked items can create counterparts on subsequent runs, including items that already exist. Linked pairs keep updating both ways. Links and field mappings are preserved; unchanged fields are not replayed. |
| **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.**

### Editing Jira creation defaults

In the field-mapping step, **Defaults for new Jira issues** shows the saved values for required and optional Jira fields. Add, change, or remove a value, then check the effective defaults on Review.

Changes apply only to Jira issues created by later runs. They do not change existing linked issues, reparent them, restore removed markers, or require Start fresh. Changing the Jira project or issue type clears the previous defaults because those values belong to the previous selection. Correct or remove any saved value that Jira reports as unavailable before saving.