Loading
Because the usual import is a mapping screen and a button. It succeeds, it reports a row count, and the damage is found three weeks later by somebody wondering why 400 owners are blank.
Import maps a CSV to fields on any object and bulk edit applies a change to a selected set — both showing a full diff of what will change before anything is written.
Every import and bulk change produces a diff: rows created, rows updated field by field, rows matched as duplicates and rows rejected with the reason. Nothing commits until that is approved, and the commit is one audit entry.
A 12,000-row migration from a previous CRM surfaced 340 duplicates and 51 rows with unmappable dates at the diff stage. All 391 were resolved before commit, which is why the migration was boring.
It will not undo a committed import as a single action. The audit trail records everything it did, which makes a correction possible — but approving the diff is the safety mechanism, not a rollback button.
Duplicate detection runs inside it, custom fields are mappable targets, the audit trail records the commit, and record permissions determine what a given person may change in bulk.
Yes, before commit, as part of the diff.
Yes. A segment is a selection like any other.
They are returned with reasons, so they can be fixed and re-run rather than lost.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.