SALESFORCE TEST DATA READINESS CHECKLIST.

Salesforce test data readiness means confirming that your sample records can satisfy required fields, required lookups, record types, restricted picklists, validation rules, automation, and user permissions before UAT, imports, bulk updates, or record-creation testing begins. A good checklist helps teams avoid failed record saves, misleading test results, and last-minute cleanup during release or import work.

Many Salesforce teams prepare test data too late. They build a spreadsheet, kick off an import, or start UAT — then discover that records fail because of missing parent records, invalid picklist values, record type constraints, validation rules, automation side effects, or field-level access issues. Catching those gaps before testing starts is the purpose of this checklist.

This resource covers what readiness actually means, where test data most commonly breaks, and a numbered checklist admins and consultants can work through before UAT, sandbox testing, bulk imports, or record-creation changes.

Salesforce test data readiness is the process of confirming that test records are usable before UAT, imports, data migration, bulk updates, or automation testing. It is not just about having sample records — it is about confirming that those records can actually be inserted, updated, or used under the conditions the test is meant to simulate.

Ready test data should:

• Include all required fields for the object and record type being tested
• Include required parent lookup records before child records are created
• Use valid record types that match the scenario being tested
• Use accepted restricted picklist values for the selected record type
• Satisfy active validation rules that would otherwise block the save
• Exclude read-only, formula, auto-number, and system-managed fields from import files
• Account for Flows, Apex triggers, and automation side effects on saves or updates
• Be tested under the right user profile and permissions for the scenario
• Be documented clearly enough to support repeatable UAT

In Salesforce, test data is ready when it can be inserted or updated under realistic user permissions without avoidable save errors from required fields, missing lookup records, invalid picklist values, validation rules, or automation side effects.

Most test data failures during Salesforce UAT or import testing are predictable. They fall into a small number of categories that a pre-UAT review can surface before testing starts.

• Missing required fields. A field marked required at the object, record type, or validation rule level prevents the record from saving. Required does not always mean "visible on the page layout."
• Missing required lookup records. If a lookup field references a parent record that does not exist in the target org or sandbox, the insert will fail. Parent records need to be created before child records can be tested.
• Wrong record type. Test data built for one record type may not satisfy the field, picklist, or validation requirements of another. Choosing the wrong record type invalidates the test before it starts.
• Invalid restricted picklist values. Picklist values copied from spreadsheets, production orgs, or older sandboxes may not match the active values in the target environment — especially when record types are in scope.
• Validation rules that block saves. Active validation rules enforce business conditions on save. Test records that do not satisfy those conditions will fail, even when all required fields are present.
• Flows or Apex triggers that change record behavior. Before-save Flows may update field values, after-save Flows may create related records, and Apex triggers may enforce logic that is not visible on the page layout. Any of these can change how a test record behaves on save or update.
• Formula, read-only, and system-managed fields in import files. Including these fields in a data loader or import file causes failures that have nothing to do with the data itself.
• User permission or field-level security mismatch. A record that saves for an admin may fail or behave differently for a profile that has limited object access, restricted field visibility, or a different record type assignment.
• Sandbox data not matching production assumptions. Picklist values, record types, validation rules, and automation may differ between sandboxes or between sandbox and production. Test data validated in one environment may not transfer directly to another.
• Test records that do not represent actual business scenarios. Test data that does not reflect real-world combinations of field values, record types, and related records can produce results that look correct in isolation but miss actual UAT coverage.

Work through this checklist before UAT, sandbox import testing, bulk updates, or record-creation change work. Each item targets a category that commonly blocks test records from saving or produces misleading test results.

1. 01

   Identify the object and use case being tested

   Confirm which Salesforce object is in scope, what the test scenario covers (record creation, update, import, UAT cycle, automation trigger), and what a successful test looks like. Vague scope produces vague test data.

2. 02

   Confirm the record type required for the scenario

   Record types can change available picklist values, page behavior, and validation logic. Identify the correct record type before building test data so the records reflect the right configuration from the start.

3. 03

   List required fields for the selected object

   Review the required fields for the object and record type being tested. Remember that required can mean system-required, required on the page layout, or enforced by a validation rule — and the page layout view does not always show all three.

4. 04

   Identify required lookup fields and parent records

   Confirm which lookup fields require a parent record to exist before the test record can be inserted. Create or confirm parent records in the target org or sandbox before running the test. Common examples include Account, Contact, Owner, and related object references that vary by business process.

5. 05

   Confirm accepted values for restricted picklists

   Retrieve the accepted values for any restricted picklist fields on the test object, filtered by the record type in scope. Values that existed in a prior sandbox or production environment may not be active in the target environment. Do not copy picklist values from old spreadsheets without checking.

6. 06

   Remove formula, roll-up, auto-number, and system-managed fields from import files

   These fields are read-only from the API perspective. Including them in a data loader file or import payload will cause errors. Review the field type for every column before running an import.

7. 07

   Review active validation rules that may block saves

   Identify validation rules active on the object being tested. For each rule, understand the condition it enforces and whether your test records will satisfy or intentionally violate it. Test records that hit unexpected validation rules produce errors that look like data problems but are actually configuration gaps.

8. 08

   Review active Flows that may run on create or update

   Before-save Flows can update field values before a record is committed. After-save Flows can create related records, trigger notifications, or update other objects. Know which Flows are active on the object and what they do so your test results are interpretable.

9. 09

   Review Apex triggers on the object

   Apex triggers may enforce logic that is not visible anywhere in the Salesforce UI. If Apex triggers are present on the test object, confirm what they do and whether they can affect save behavior, related record creation, or field updates during the test.

10. 10

    Confirm the running user has the right object permissions and FLS

    Test the records under the user profile that represents the UAT scenario, not a system administrator. Object-level permissions, record type access, and field-level security can change what a user can see, edit, or insert — and those differences are often the point of the UAT.

11. 11

    Create a small test batch before loading larger data

    Before importing a full data set, run 5–20 representative records through the target org or sandbox. A small batch surfaces blockers before a full import or UAT cycle is disrupted. See the section below for a structured approach.

12. 12

    Document expected automation side effects

    If Flows or Apex triggers are expected to create related records, update fields, or send notifications when test records are saved, document those expectations before testing. Expected side effects that do not occur — or unexpected ones that do — are findings, not noise.

13. 13

    Prepare rollback or cleanup steps

    Plan how test records will be cleaned up or reversed after the UAT cycle, especially in sandboxes shared with other teams or in full-copy environments. Unplanned test data left in a sandbox can affect subsequent tests.

14. 14

    Capture unresolved blockers before UAT begins

    Document any readiness items that remain unresolved before UAT starts — missing parent records, unclear validation rule behavior, unconfirmed picklist values, or permission gaps. Known blockers tracked in advance are easier to address than blockers that surface mid-test.

Required fields and required lookup fields are one of the most common reasons Salesforce test records fail. A record may need a parent Account, Contact, Owner, Record Type, or other related record before it can be inserted — and that parent record must already exist in the target org or sandbox.

A few things worth remembering about required fields before building test data:

• Required does not always mean "visible and marked required on the page layout." Some fields are system-required and enforced at the API level regardless of layout configuration.
• Lookup requirements can depend on business process, record type, and validation rules — not just the field definition.
• API imports can fail on required fields even when the UI guides users through layouts that handle the same fields automatically.
• Test data should include valid parent record IDs or lookup references, not placeholder values that exist in one environment but not another.

Impact Awareness can surface required-field and required-lookup signals for selected objects so admins have a starting point before imports or UAT. It reviews available metadata and configuration — it does not simulate runtime save behavior or guarantee all save outcomes.

Record types can change available picklist values, page behavior, and validation logic. Restricted picklists reject values that are not defined as active for the field or for the selected record type. Both are common sources of test data failures that are straightforward to prevent.

• Choose the record type before building test data — picklist values, required fields, and validation behavior may all depend on it.
• Validate picklist values against the active values for the target record type, not a general list of all values ever used.
• Watch dependent picklists — if a controlling field value is set incorrectly, the dependent field options will be wrong too.
• Do not copy picklist values from older spreadsheets or prior environments without confirming those values are still active in the target org or sandbox.
• Different record types may need separate test records — a single test data set often cannot cover scenarios that span multiple record types.

For example: a Case record for one process may allow different Type, Reason, or Status values than a Case record for a different process. Test records built for one scenario may fail immediately if the record type is changed or mismatched.

Even when field values look correct, automation can change what happens when records are created or updated. Reviewing active automation before UAT or import testing is part of test data preparation, not something to do after failures appear.

• Validation rules may block saves based on combinations of field values, not just individual fields. A record that satisfies each required field individually may still fail if a validation rule checks multiple fields together.
• Before-save Flows may update field values before the record is committed. After-save Flows may create related records, update parent objects, or trigger further automation.
• Apex triggers may enforce logic that has no visible representation in the UI. If Apex is present on an object, the trigger behavior should be reviewed before bulk imports or UAT scripts run.
• Automation should be reviewed for active items first — active Flows and triggers are the immediate concern for test data. Inactive items matter for documentation and context but are not the primary blocker risk.

Impact Awareness reviews available metadata for validation rules, Flows, and Apex trigger signals on selected objects. It does not simulate business logic execution — findings from the workbook should be verified in the target org or sandbox before UAT or import work begins.

Test data readiness also depends on who is testing. A record that saves for a system administrator may fail or behave differently for another user profile because of differences in access configuration.

• Object permissions determine whether a user can create, read, edit, or delete records on the object
• Record type access determines which record types a user can create — which affects the picklist values and validation logic available to them
• Field-level security can make fields invisible or read-only for specific profiles, even when those fields are required for the record to save
• Permission sets can grant access that the base profile does not have, or may be missing for UAT users who should have additional access
• Automation may run in user context or system context depending on how it was built — understanding the context matters for predicting behavior during UAT

For access-specific review before UAT, see the Permission & FLS Audit — a read-only diagnostic that surfaces object permissions, field-level security, and access patterns by profile and permission set.

Running a small representative batch before a full import or UAT cycle reveals blockers before they become time-consuming mid-test cleanup. This approach works for data loader imports, manual record creation UAT, and bulk-change scenarios.

1. 01

   Pick 5–20 realistic records

   Choose records that represent the main scenarios in scope — not just the cleanest or simplest ones.

2. 02

   Include each major record type or scenario

   If the UAT covers multiple record types or process paths, include at least one representative record for each.

3. 03

   Include required lookup records

   Confirm that parent records exist in the target org or sandbox before inserting child records.

4. 04

   Use accepted picklist values

   Validate picklist values against the active values in the target environment for the selected record types.

5. 05

   Run the import or save test in a sandbox first

   Do not skip sandbox validation before production or full UAT runs. A sandbox run surfaces configuration differences before the full test cycle.

6. 06

   Review validation and automation errors

   Any save failures or unexpected automation behavior are findings. Determine whether they reflect data problems or configuration gaps.

7. 07

   Fix the source data or configuration assumptions

   Correct the test data file or address the configuration issue before scaling to a larger batch.

8. 08

   Re-test before the larger import or UAT cycle

   A passing small batch does not guarantee a full import will succeed, but a failing small batch is a clear signal to investigate before proceeding.

KeelCadence Impact Awareness is a read-only diagnostic that reviews selected-object readiness signals before imports, UAT, test-data setup, or bulk-change work. It surfaces required fields, required lookups, record types, restricted picklists, validation rules, Apex triggers, Flow metadata where available, formula fields, import-readiness items, and test-data readiness considerations in a review-ready XLSX workbook.

You can run the diagnostic, review a free on-screen summary, and decide whether to download the full workbook. No package install, no Connected App setup, and no Salesforce writes.

Related Resources

• Salesforce Import Readiness Checklist — what to review before loading records or running bulk imports
• What to Do When You Inherit a Salesforce Org — first-pass checklist before cleanup, UAT, or import work
• How to Document Salesforce Automations — inventorying Flows, Apex, validation rules, and approval processes
• Security model — read-only, no Salesforce writes, no package install
• IT & security review — resources for IT and security teams evaluating diagnostic tools