Skip to main content

​
Scans

A scan reads your connected CRM, runs every check that is not Off, and sorts what it finds:
  • changes your rules say to make are written straight away;
  • changes that need a decision go to the queue;
  • problems Clustr cannot fix go to the findings report.
Your rule settings apply the same way to every scan, whether you started it, the schedule did, or your AI assistant did. A scan writes the changes of every check on Do it to your CRM, a manual scan included.

​
Start a scan by hand

Click Scan now in the Runs view or in Settings, call POST /api/crm/cleaning/scan, or ask your assistant (start_crm_cleaning_scan). Only one scan runs at a time: asking for another while one is running gives you the running one.

​
Scheduled scans

Turn on Run on a schedule in CRM Cleaning settings, or the On / Off pill in the Runs header, to scan automatically. Until it is on, nothing runs by itself: no scheduled scan, no automatic clean-up when a record changes, and no weekly email. Times are in the time zone you choose, and follow daylight saving time. The app suggests Monday at 09:00 in your browser’s time zone. While the schedule is on, Clustr also checks a single contact or company soon after it changes in your CRM, with the same settings: it fixes formatting and, when enrichment is on, fills blank fields. A new record is also checked for duplicates. Every other check waits for the next scan.

​
Runs

Every scan is a run. The Runs view lists them newest first, scheduled runs included, with when it ran, its status, the changes it found, how long it took and what started it. A run is full when it reads the whole CRM, or incremental when it only looks at records that changed.

​
History

History lists every change cleaning made or proposed, across all runs, newest first, with who decided it. Filter it by outcome: You can also narrow it by:

​
Export the history

Export CSV at the top of History downloads every change that matches the filters and search you picked, not only the rows on screen. The file has one row per change: A file holds at most 50,000 rows, newest first. It opens in Excel with accents intact. A value that starts with =, +, - or @ gets a leading ' so a spreadsheet never runs it as a formula. Over the API, use GET /api/crm/cleaning/history/export.

​
Revert

Most applied changes can be reverted for 30 days. Revert writes the old value back to your CRM. Linking a contact to a company is reverted by removing the link. Revert reads the field in your CRM first:
  • If it still holds the value Clustr wrote, the old value is written back.
  • If someone edited it in your CRM since, nothing is written: their edit stays, and the revert is refused as a conflict (409 REVERT_CONFLICT over the API).
  • If it already holds the old value, the change is marked reverted without a write.
What cannot be reverted:
  • After 30 days, nothing can.
  • Phone repairs. A small number of changes repaired phone numbers a past clean-up had damaged. Reverting one would write the damaged number back, so they cannot be reverted.
  • Deal merges. Your CRM cannot unmerge deals, and a recreated deal would lose its stage history, so a deal merge has no Revert.
  • A contact or company merge has no true undo. Your CRM cannot unmerge records. Within 30 days, revert recreates the archived record as a new record with a new id and restores both records’ values, links and activity as far as your CRM allows. It may not clear a field the merge had filled, and a recreated contact can be refused if its email now sits on the surviving record. Treat a merge as permanent.
Revert is shown on applied changes, with the days left in its tooltip. It is greyed out once the window has closed, on phone repairs and on deal merges. Reverting a merge first asks you to confirm, in a Revert this merge? dialog.

​
Revert a whole rule

To undo everything one rule did, for example every phone format fix, use Revert all on that rule in History, then confirm. Each change goes through the same checks as a single revert:
  • Merges and phone repairs are never reverted in a batch. Revert a merge on its own.
  • Changes past their 30 days are skipped.
  • A field someone edited in your CRM since is left as it is, and counted as a conflict.
When it finishes, a message says how many changes were reverted and how many were left, and why. Over the API, POST /api/crm/cleaning/revert-batch takes the rule and can narrow it to one run, one object type, one field or a time window. One call reverts at most 1,000 changes, or stops after about 20 seconds, and then says there is more to do. See the API. Your AI assistant does the same with revert_crm_cleaning_batch.

​
Failed and conflict

A change is written by a background worker. Before writing, it reads the record again from your CRM. Conflict means the value in your CRM is no longer the one the scan saw: someone edited it, or filled a field that was blank. Clustr does not overwrite their edit, and nothing is written. A difference in formatting alone is not a conflict. Failed means your CRM refused the write. Clustr tries again a few times for a passing error. It stops at once when retrying cannot help: the property does not exist, the connection lacks a permission, or the value does not fit the property (for example a dropdown option that does not exist). The reason your CRM gave is shown on the change. Retry puts a failed or conflict change back in line for the worker. In the app it is on the “changes need attention” banner in Review, for the latest scan; over the API and MCP it works on any failed or conflict change.
  • On a failed change, fix the cause first, then retry.
  • On a conflict, retry reads the value in your CRM again and writes the proposed value over it. The app asks you to confirm first. Only retry a conflict when you want Clustr’s value to win. Formatting fixes are the exception: they still stop if the value in your CRM is no longer the same value.
If failures keep happening, an alert email goes out. See Failure alerts.