Data Loader is the correct recommendation here, for several converging reasons. First, volume: the Data Import Wizard is capped at 50,000 records per operation, while 200,000 records would require splitting the file into at least four separate manual runs, which is impractical for a recurring nightly job. Second, automation: Data Loader can be run from the command line, making it possible to fully automate a recurring nightly sync without any manual UI interaction, which the browser-based Import Wizard simply does not support. Third, operation type: a recurring ERP sync would almost certainly use Upsert with an External ID field to safely handle both new and previously-synced Vendors on every run, and while both tools support Upsert, Data Loader's command-line automation combined with its higher volume ceiling makes it the clearly appropriate tool for this specific recurring, high-volume, external-integration scenario.

A plain Insert operation always creates new records regardless of whether matching data already exists, meaning if the same source file or a similar sync job is accidentally run twice, every record would be duplicated a second time, since Insert has no built-in awareness of "this might already exist." Upsert, by contrast, uses a designated matching field, most robustly an External ID field, to determine whether an incoming row corresponds to an existing record, updating it in place if a match is found and only inserting a new record when no match exists. This means an Upsert-based integration job can be safely re-run multiple times, whether due to a scheduled recurrence, a retry after a partial failure, or manual re-triggering, and it will correctly converge on the same accurate end state each time rather than compounding duplicate records with every additional run, which is exactly why Upsert with External ID is the standard, safer pattern for ongoing integration work.

A Matching Rule defines the actual LOGIC used to determine whether two records are likely duplicates — which specific fields to compare and how strictly, such as an exact match on Email versus a fuzzy match combining Company Name and Phone. A Duplicate Rule defines the ACTION taken when that Matching Rule's logic finds a hit, specifying whether to Block the record from being saved entirely or to Allow the save while displaying a warning Alert to the user. A Duplicate Rule cannot function meaningfully without an associated Matching Rule, since the Duplicate Rule has no independent way to detect a potential duplicate on its own — it relies entirely on the Matching Rule's logic to determine when its configured action should even trigger; conceptually, the Matching Rule is the detection engine and the Duplicate Rule is the response policy layered on top of that detection.

No, these records cannot be recovered from the Recycle Bin at 20 days post-deletion, because the standard Recycle Bin retention window is 15 days, after which records are automatically and permanently purged regardless of any other circumstance. It is also worth noting that even within the 15-day window, recovery is not fully guaranteed if the org's Recycle Bin capacity limit was exceeded at any point during that period, since exceeding capacity causes the OLDEST records to be purged early to make room for newer deletions, potentially shortening the effective recovery window below the full 15 days even before it technically expires. Given both of these limits, recovering 5,000 records 20 days after deletion would require a genuine backup solution completely separate from the Recycle Bin — either a scheduled Data Export taken before the deletion, a dedicated backup product, or in some cases a paid Salesforce data recovery service request, none of which are guaranteed to exist unless proactively set up in advance.

This assumption conflates two fundamentally different kinds of protection. Salesforce's cloud infrastructure genuinely does provide strong protection against infrastructure-level failures — server hardware failures, data center outages, and platform-level bugs are mitigated through redundancy and Salesforce's own operational practices, and an Admin does not need to worry about these risks directly. However, this infrastructure resilience does absolutely nothing to protect against USER-CAUSED data problems, such as an Admin running an incorrect Mass Delete, a Data Loader Upsert with a wrong field mapping that overwrites good data with bad values, or a buggy Flow that mass-updates thousands of records incorrectly. These are data integrity problems caused by legitimate, authenticated actions within the org, which Salesforce's infrastructure has no reason to prevent or flag as anomalous, meaning genuine protection against these specific risks requires a deliberate backup and recovery strategy — the Recycle Bin's limited window, a scheduled Data Export, or a dedicated backup product — that the Admin must proactively set up rather than assume already exists.

The process begins with taking a backup of the target object's current data, typically via Data Export or a Data Loader export operation, ensuring a manual reversal path exists if something goes wrong, since this directly addresses the gap identified in the backup strategy discussion where infrastructure resilience alone is insufficient. Next, if a full sandbox environment is available, the entire operation should be tested there first, allowing any mapping errors, matching issues, or unexpected automation side effects to surface in a safe environment before touching production data at all. Back in production, rather than running the full file immediately, a small batch of 10 to 20 records should be split off and run first, with the results carefully verified to confirm correct field mapping and, for Upsert operations, correct matching behavior for both new inserts and existing-record updates. Only once this small batch is confirmed fully correct should the remaining full volume be run, and even then the process concludes with a verification step — spot-checking several records and confirming any dependent Roll-Up Summary Fields or reports reflect the expected results, closing the loop on the entire disciplined process.