Fix a sync conflict between Current and your PSA

A conflict is logged when the two systems disagree about a field and the ownership map can't settle it silently — for example, a record edited in both systems between polls, or a Current edit that your PSA flatly rejected. Each conflict records the entity, the field, and the values involved. A push failure stores your Current value (there is no PSA value — the write never landed); an auto-resolved row stores both your value and the PSA value that overrode it. Nothing is ever swallowed. Everything on this page works identically whether your PSA is ConnectWise, Autotask, or HaloPSA — the panel and its buttons are named for your provider.

Current doesn't guess who wins. Each field has a declared owner, and the sync respects it in both directions. On a pull, PSA-owned fields always win in Current; Current-owned fields survive every pull. Conflicts only arise in the narrow gray zone where both sides legitimately changed the same thing.

For the full picture of which side owns what, read "Our methodology: your PSA stays the source of truth" and the field-mapping reference for your provider — "Autotask sync: the complete field-mapping reference" or "ConnectWise sync: the complete field-mapping reference."

The Conflicts panel on the sync health page has two tabs, and they mean genuinely different things.

• ＋Open — an edit you made in Current that never reached your PSA. The PSA rejected the write (a validation rule, a permission, a field it wouldn't accept), so the row shows only your Current value: "Current has X — this never reached your PSA." There is no PSA value to compare it against, because the write never landed. These are the ones to act on, and they're counted in the Outbox as undelivered work.
• ＋Auto-resolved — a record of where the two sides disagreed and the sync settled it without a person. When two-way sync is on, the sync only reopens a field your PSA has genuinely changed since Current last read it, so a time entry or a note on a task is not enough on its own to disturb anything you edited. Once a field has genuinely changed on both sides, your PSA's value wins unless your Current edit is provably later than the last activity your PSA recorded on that task. An edit that Current delivered to your PSA no longer re-enters this contest at all: after each push, Current checks what your PSA actually stored and records the delivery, so editing the same field again shortly after a successful push can no longer be undone by the next sync. That is deliberate: no PSA reports when one specific field changed, only when the task last changed, so when the two can't be ordered Current keeps your PSA's value rather than overwrite a change it can't prove is older. Nothing is lost. The value you had is stored on the row next to the value the PSA set, so you can put it back. When your Current edit is the provably later one it simply stays in Current and there is nothing in this tab to show, because nothing of yours was overridden; your PSA keeps its own value until somebody changes it there or you send the field across from the task. This tab also covers task dates the PSA changed that an earlier sync recorded but never applied: if a start or end date you set in Autotask kept showing the old value in Current, the PSA's date is now applied automatically on the next sync (as long as nobody edited that date inside Current), and the correction shows here with Restore my value.

1. 1
   Open Integrations → your PSA's card → Sync details, then scroll to Conflicts

   You need to be a Tenant Admin — Sync details only shows on the card for admins. Each row shows the record (linked, so you can open it), the field, the value that failed to reach your PSA, and when the conflict was logged. Newest first. When there are open conflicts, the card also shows an "N open conflicts — review" link to the same page.
2. 2
   Retry push — the usual answer

   This re-sends the record's current Current values through the same path the original edit used. If the rejection was transient, or you've since fixed whatever your PSA objected to, this delivers the edit and the conflict clears itself. Current stays the source of truth for the field.
3. 3
   Accept the PSA's value — when your PSA is right

   The button is named for your provider — Accept Autotask or Accept ConnectWise. It re-pulls the record's whole project from your PSA so the PSA's values actually land in Current, then closes the conflict. Your Current value for that field is replaced.
4. 4
   Dismiss — when neither applies

   Closes the conflict and changes nothing, anywhere. Use it when the record is obsolete or the disagreement no longer matters. Neither side's value is changed and nothing is pushed.
5. 5
   When one field conflicts across many records

   That's an ownership question, not a data question — decide which side owns the field and stop editing the other. There's no bulk resolve: each row still has to be cleared individually with Retry push, the Accept button, or Dismiss.

The Auto-resolved tab lists the last 14 days of fields where the PSA's newer change beat a Current edit (up to 100, newest first). For task fields with a write path — description, estimated hours, status, task type, department, and priority — a Restore my value button puts your value back in Current and pushes it to your PSA in the same action.

The same overrides also surface where the work happens. Open the task and its panel shows a banner naming each field your PSA changed, with Re-apply mine to put your value back and push it, and a second button, named for your provider, that accepts their value and stops the row asking again. The banner only lists overrides that still stand: a field you had left empty is never raised, and neither is a row the task has since moved past, because re-applying a value the task no longer holds would push a stale value out to your PSA. A phase move is the one row with no button on either surface — drag the task back to the phase you wanted on the project overview, which pushes the phase across the same way the original move did.

Related reading: "Reading the sync health dashboard (and fixing a stale sync)" for the rest of the page, and "PSA rate limits and dead-letter jobs" for failures caused by throttling rather than your data.