1. Define the business selection
Start with the business condition, then translate it into a query. Record the object, filter logic, expected row count, owner, purpose, and time window. A query is not approved merely because it runs successfully.
Include only the record ID, fields needed to decide eligibility, fields being changed, and fields needed to verify the outcome. Fewer columns make review easier and reduce accidental edits.
2. Export the baseline before editing
Save an immutable export of the selected records before making any changes. Record the query, timestamp, org identity, row count, and file checksum or controlled storage location. This is both review evidence and the source for a possible rollback file.
Do not call a baseline a backup until you have verified that it contains every field required to restore the previous state and that the team has permission and a tested method to write it back.
3. Review changed fields, not only changed rows
The most useful review view shows the record ID, field API name, previous value, proposed value, and validation result. A row-level “modified” label hides too much. Field-level evidence makes accidental blanks, formatting changes, and unintended columns visible.
Use a second reviewer for high-impact fields such as owner, status, amount, entitlement, opt-out, integration key, or fields that trigger automation.
4. Execute in a controlled batch
Test the exact update pattern on a small representative set when the business process allows it. Confirm validation rules, flows, triggers, duplicate rules, sharing effects, and integration behavior before increasing the batch size.
Keep the execution receipt: org, user, time, selected count, attempted count, success count, failure count, per-record errors, and the reviewed change set. A green success total without failed-row details is not sufficient evidence.
5. Verify the business outcome and prepare rollback
Re-query the updated records using the original selection logic plus outcome checks. Verify downstream reports, automation, and integrations where relevant. Decide in advance which result triggers rollback, partial correction, or acceptance with follow-up.
Pre-update checklist
- Business selection and expected count approved.
- Baseline export stored and restoration fields verified.
- Every changed field reviewed, including blanks.
- Automation and integration effects understood.
- Execution owner, verifier, stop condition, and rollback owner named.
Where DinaSheet fits
DinaSheet for Salesforce supports spreadsheet-style selection and editing, changed-field review before confirmed updates, exports, and bounded local audit history. Those controls support the workflow; they do not replace business approval, tested recovery, or production monitoring.