What Current writes back to HaloPSA (and when)

Current pulls a lot from HaloPSA, but it also writes back — task schedules, status changes, comments, time (as Halo actions), and CRM activity all flow the other direction once you allow them. This page lists exactly what triggers a push, the gates in front of every write, how a Halo write physically works, and the hard boundaries Current never crosses. For the full pull-side field reference, see "HaloPSA sync: the complete field-mapping reference".

1. 1
   Only HaloPSA-synced projects ever push

   A Current-native project makes no Halo calls at all, and a project synced to a since-disconnected PSA is frozen — the engine refuses cross-provider operations outright (a job that reaches the wrong engine fails closed rather than writing to the wrong PSA).
2. 2
   The two-way sync switch governs task fields

   Integrations → HaloPSA → Manage. It controls the task-field pushes and field-by-field conflict resolution. Its position is per workspace — check it deliberately as part of your go-live plan.
3. 3
   CRM write mode governs every CRM write

   Off by default — no CRM writes at all. Test mode allows writes only against companies whose Halo name starts with "ZZ-Current Test" (older "ZZ-Cascade Test" names still count); live mode is an explicit admin action, taken after test writes have landed correctly.

Halo has no separate update call — you write a record by POSTing it, and Halo decides create-vs-update from whether the record carries its id. That makes the id the safety property: every update Current sends carries the mirrored Halo id it stored when the record was first created or pulled, so Halo updates the existing record instead of quietly creating a duplicate. A create returns the new record, and Current stores that id immediately, so a retry can never make a second copy.

After every push, Current reads the record back from Halo and compares what landed against what it sent. A write that Halo accepted but quietly adjusted — a clamped date, a defaulted field — is reported as a residual, not swallowed. And if a push fails, the error surfaces Halo's real message, never a generic "sync failed."

• ＋Time is logged as a Halo action on the ticket. Current writes a new action and never edits or deletes one that already exists in Halo — every push is claimed once and confirmed by Halo's response, so a retry can't create a duplicate.
• ＋An invoiced action is untouchable. Once a Halo action is attached to an invoice, Current treats it as final — it will not edit, delete, or retry it, because no write can succeed on invoiced time.
• ＋Prepay is protected. Logging billable time against a Pre-Pay contract draws down the client's prepaid balance in Halo, so Current's claim-once, confirm-by-response rule is exactly what stops a retry from double-charging or over-drawing prepaid hours.
• ＋After a push, the action's billed hours and invoice status are read back on a cycle — and Current only ever promotes an entry toward billed and invoiced, never demotes one. Billed hours can differ from logged hours because Halo's rate engine applies its own minimums, increments, and multipliers; that's Halo working, not an error.

• ＋Retryable failures — Halo's rate limit (429), timeouts, temporary Halo errors — retry automatically with increasing delays, and a write is never blindly re-sent (see the time-entry rule above).
• ＋After repeated failed attempts, a job is marked dead-letter and stops retrying on its own — it needs a person to look at it.
• ＋Validation errors and permission errors are never auto-retried — these need a fix, not a delay.
• ＋CRM pushes notify your sales leadership once a push has dead-lettered, so it doesn't sit silently.

• ＋Contracts, recurring invoices, and anything else in your billing structures — read-only in every direction.
• ＋Invoiced actions, and hours already billed and posted.
• ＋The product catalog — charges reference catalog items; they never create or reprice them.
• ＋Halo's own computed rollups — project completion percentage and the like are read for display, never written back.
• ＋Records outside your API application's permission scope — Halo's own permissions are the final gate.
• ＋Anything at all while the relevant gate (two-way sync, CRM write mode) is closed.

This boundary is intentional: billing accuracy depends on Halo staying the single source of truth for anything that touches an invoice. See "Reading the sync health dashboard (and fixing a stale sync)" for where failures surface.