# Salesforce Implementation Checklist: From Scope to a Working Release

A Salesforce implementation checklist should connect each business requirement to an owner, a tested configuration and release evidence. Define the first useful workflow, confirm access and data dependencies, rehearse migration, test as real user roles, then release only the version that passed. Training, recovery and operating ownership belong in the implementation scope from the start.

Canonical URL: https://www.martechdevs.com/blog/salesforce-implementation-checklist

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder at [Martechdevs](https://www.martechdevs.com) and [Growth and Analytics Partners](https://www.growthandanalytics.com)

[LinkedIn](https://linkedin.com/in/jafrinalo)

Last updated: 2026-10-25

Next step: [Salesforce Implementation Mistakes That Break Revenue Operations](https://www.martechdevs.com/blog/salesforce-implementation-mistakes)

## What should the first Salesforce release actually deliver?

Deliver one complete business workflow with a measurable operating result. A first release might take an accepted lead through qualification, opportunity creation, approval and a verified handoff to delivery. The scope should explain what happens when the customer, owner or commercial decision changes, not just which screens will exist.

Write a short release statement: who uses the system, which records move through it, what decisions it supports and which outcomes are deliberately deferred. Record the current baseline, such as unassigned leads, missing next actions or time spent reconciling pipeline. Do not promise revenue lift from an implementation test that only proves a process works.

Salesforce's rollout guidance recommends defining goals, metrics and milestones, including users, configuration, data import, useful features and training. It explicitly treats the timeline as business-specific. Use those milestones as planning inputs rather than adopting a universal four-week promise. [Sales Cloud rollout planning](https://trailhead.salesforce.com/content/learn/modules/sales-cloud-rollout-strategy/chart-your-course)

Separate a new rollout from a repair of an existing org. A repair must first identify the automation, integrations, permissions and reports already in use. The [Salesforce implementation mistakes guide](https://www.martechdevs.com/blog/salesforce-implementation-mistakes) diagnoses those failure mechanisms; this checklist sequences the work needed to deliver and operate a release.

For [Salesforce and CRM implementation](https://www.martechdevs.com/crm-lifecycle), bring the required workflow and its exceptions before choosing a package. Confirm the [edition and API entitlements](https://www.martechdevs.com/blog/salesforce-pricing) before a connector or custom build makes them a late commercial surprise.

## Who owns each implementation decision?

Assign one accountable owner to each decision and identify who supplies the evidence. The person building a feature should not have to invent the commercial rule it implements.

| Workstream | Accountable owner | Required output | Acceptance evidence |
| --- | --- | --- | --- |
| Business scope | Sales or revenue operations lead | Release boundary and stage definitions | Business owner approves representative outcomes |
| Data model and identity | CRM architect or administrator | Object, field and identifier map | Records and relationships resolve correctly |
| Access | Administrator with business data owners | Role and permission matrix | Allowed and prohibited actions pass |
| Migration | Data migration owner | Extraction, mapping and reconciliation plan | Rows, relationships and totals reconcile |
| Integrations | Named owner for each system boundary | Field ownership and recovery contract | Retries and failures preserve the intended result |
| User acceptance | Representatives of the actual roles | Task-based test cases | Users complete work without administrator privileges |
| Cutover and recovery | Release owner | Ordered runbook and recovery decision | Rehearsal passes within the agreed operating window |
| Ongoing operation | Internal platform owner | Support, monitoring and change process | Another operator can resolve a sample incident |

The executive sponsor resolves scope or priority conflicts. The implementation team supplies options and tradeoffs. Finance owns accounting definitions; sales owns the agreed commercial stages; neither should casually overwrite the other's authoritative facts.

Set a change rule before development starts. A new requested field may be simple, but its access, historical backfill, reports and integrations can add work. Record the effect on acceptance tests and release scope before treating it as an invisible addition.

## What must be ready before configuration begins?

Prepare the environments, access model and data definitions before building automation. An administrator's successful demonstration does not prove that a seller or integration identity can perform the same job.

Reserve [Salesforce API capacity](https://www.martechdevs.com/blog/salesforce-api-limits) for the integrations and backfills that must operate alongside normal CRM use.

Salesforce sandboxes provide separate environments for development, testing and training. Their behavior and copied contents can differ from production, so select the type and data preparation that support the actual test. A nearly empty test org cannot demonstrate a relationship-heavy migration simply because its fields match. [Salesforce sandboxes](https://help.salesforce.com/s/articleView?id=deploy_sandboxes_parent.htm&language=en_US&type=5)

Review outbound effects before loading test data. New and refreshed sandboxes default to System email only, which permits automatically generated messages such as password resets. Verify the current Deliverability setting instead of assuming it prevents every external effect; integrations, credentials and destination environments need separate checks. [Sandbox email deliverability](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_email_deliverability.htm&language=en_US&type=5)

Define access at three levels: object actions, fields and individual records. Salesforce treats object and field permissions separately from record sharing, and broad View All or Modify All object permissions can override record-level restrictions. [Salesforce data access](https://developer.salesforce.com/docs/platform/salesforce-record-access-under-the-hood/guide/uth-intro.html)

Make the access matrix concrete. A seller might edit their opportunity's next action, a manager might approve a discount, and finance might update payment state. Test that each can perform the required action and cannot perform a prohibited one. Include a record owned by another team, not only records created by the test user.

Write the field contract alongside the access matrix:

- Which entity and business fact the field represents.
- Which system and role may change it.
- Allowed values and the meaning of missing data.
- Whether a change should trigger work elsewhere.
- Which reports and integrations depend on it.

Use [CRM property ownership](https://www.martechdevs.com/blog/crm-property-ownership) for the cross-system rules and the [Salesforce field-permission guide](https://www.martechdevs.com/blog/salesforce-field-permissions) when a visible field still behaves differently for a report, API or user role.

## How do you prepare data and rehearse the migration?

Prepare a repeatable migration with stable keys, explicit create/update rules and a reconciliation ledger. Start with representative difficult records before loading the whole population.

For an asynchronous CSV load, use the [Salesforce Bulk API 2.0 guide](https://www.martechdevs.com/blog/salesforce-bulk-api) to define the external key, archive row results and prepare a controlled exception retry.

Inventory objects, relationships, owners, attachments and required history. Preserve source-system identifiers separately from names and email addresses. Choose a canonical customer identity and keep its Salesforce mapping; two similar company names are not enough evidence to combine their records.

The Data Import Wizard supports specified objects, including accounts, contacts, leads and custom objects, with CSV imports up to 50,000 records at a time. Salesforce recommends a small test file and says not to run simultaneous wizard import jobs. The object and operation matter as much as file size. [Data Import Wizard](https://help.salesforce.com/s/articleView?id=sf.data_import_wizard.htm&language=en_US&type=5)

For API-based upsert, a missing external-ID match can create a record; one match updates it and multiple matches fail. The documented `updateOnly` option prevents creation when that is the required behavior. Configure the operation deliberately before allowing a source feed to create customers. [External-ID upsert](https://developer.salesforce.com/docs/platform/api-rest/guide/resources-sobject-upsert-patch.html)

Rehearse in dependency order. Resolve parent identities before loading their dependent relationships. Record which source records were intentionally excluded and why. If a parent fails, hold the related child rather than guessing another account.

Salesforce's bulk tooling exposes successful records and separate failure files, with unprocessed results where available. A job finishing is therefore only the start of reconciliation. Retain the returned IDs and inspect destination state for the intended values. [Bulk data results](https://developer.salesforce.com/docs/platform/sfdx-dev/guide/sfdx-dev-data-bulk.html)

| Migration check | Evidence to retain | Failure that should stop dependent work |
| --- | --- | --- |
| Population | Source IDs and intended inclusions/exclusions | Unexplained missing or duplicated source rows |
| Identity | Source-to-Salesforce crosswalk | Multiple Salesforce records for one intended entity |
| Relationships | Parent and child IDs after loading | Contact or opportunity attached to the wrong account |
| Important values | Totals by currency, owner and period | Offsetting errors hidden by one grand total |
| Changes after extraction | Applied change boundary and exceptions | New source updates missing from the destination |
| Recovery | Repeated import and correction results | Retry creates duplicates or overwrites newer facts |

Do not label held exceptions as successfully migrated. A verified cohort can be released if its boundary is explicit, but the remaining population stays visible. Use the [migration mapping and cutover guide](https://www.martechdevs.com/blog/salesforce-to-hubspot-migration) for additional reconciliation patterns, adapting the destination-specific steps to the actual move.

## How should configuration and integrations be tested together?

Test a complete business transaction through all its systems, including retries and conflicting updates. A field saving in Salesforce does not establish that the downstream customer workflow completed.

For website enquiries, [generate and verify a Web-to-Lead form](https://www.martechdevs.com/blog/salesforce-web-to-lead), including validation, record creation and owner fallback.

For a billing integration, [test the Stripe billing sync before go-live](https://www.martechdevs.com/blog/salesforce-stripe-integration) with both an ordinary payment and a replayed update.

For every integration, specify the owning system, match key, permitted operation, expected delay and recovery owner. Keep invoice, payment and refund state under the appropriate financial authority. Define whether an opportunity correction updates a delivery record, creates a revision or stops for review.

Use a stable logical reference for an action that should happen once. A lost acknowledgement can cause a retry after the destination already completed the action. The test should prove that the retry finds the existing result rather than duplicating delivery work.

Build the deployment inventory at the same time. Salesforce change sets carry customizations, not customer records, and work between affiliated orgs through deployment connections. Metadata deployment and business-data loading are separate tasks even when they belong to one release. [Change sets](https://help.salesforce.com/s/articleView?id=sf.changesets.htm&language=en_US&type=5)

Include dependencies and access components. Salesforce notes that adding a custom object to a change set does not automatically include all its fields, and permissions require deliberate inclusion. Validate the actual package in its target environment before relying on a release slot. [Change-set best practices](https://help.salesforce.com/s/articleView?id=sf.changesets_best_practices.htm&language=en_US&type=5)

Inventory actions that remain after deployment: credentials, endpoint settings, environment-specific values, scheduled work and activation choices. Do not put production secrets into a portable checklist. Record who configures them and how the result is verified without exposing the values.

For a HubSpot boundary, the [HubSpot–Salesforce sync guide](https://www.martechdevs.com/blog/hubspot-salesforce-sync) covers the separate ownership and conflict decisions. For other systems, use the same discipline while checking the connector's actual behavior.

## What belongs in user acceptance testing?

User acceptance testing, or UAT, proves that the intended roles can complete real tasks with the release candidate. It should cover the exceptions that change the customer outcome, not merely a tour of the screens.

Include [Lead conversion mapping and destination checks](https://www.martechdevs.com/blog/salesforce-lead-conversion) for new customers, existing Contacts and the no-opportunity path.

Use a hypothetical lead-to-delivery release as an example:

| Test case | Expected outcome | Evidence |
| --- | --- | --- |
| Qualified lead belongs to an existing customer | Correct account is used under the agreed matching rule | Resulting record IDs and relationship |
| Opportunity needs an approval | Only the authorized role can approve | Successful and denied role tests |
| Delivery owner is missing | Handoff remains visibly incomplete | Exception with a responsible owner |
| Destination succeeds but its acknowledgement is lost | Retry does not create another delivery project | One destination ID after both attempts |
| Integration updates an unrelated field | Completed handoff does not restart | Unchanged logical-action count |
| Customer changes an authoritative fact during migration | Latest approved fact survives | Source change and destination read-back |
| Ordinary seller opens a restricted account | Access remains denied | Result from the seller identity |

Record the release version, role, inputs, expected result, actual result and evidence location. A screenshot without the tested identity or version is difficult to reuse during sign-off.

Keep deployment tests and UAT distinct. Salesforce's CLI supports different Apex test levels. With `RunSpecifiedTests`, each deployed class and trigger must meet the stated 75% coverage requirement; `RunLocalTests` is the default for production deployments containing Apex and excludes tests from installed managed and unlocked packages. Neither a coverage percentage nor a deployment success proves the customer journey passed. [Salesforce deployment test levels](https://developer.salesforce.com/docs/platform/salesforce-cli-reference/guide/cli_reference_project_deploy_start.html)

If custom Apex is involved, review its actual API versions and security behavior rather than assuming an old global default. The field-permission and implementation-mistakes guides linked above provide that deeper technical boundary.

## How do you rehearse and approve production cutover?

Rehearse the ordered runbook against the intended release candidate, including the time and evidence needed to recover. Separate configuration rollback, data repair and completed external actions; they are different recovery problems.

| Cutover stage | Operator action | Gate before continuing |
| --- | --- | --- |
| Prepare | Confirm version, owners, backups and authorized access | Required artifacts can be retrieved and understood |
| Control changes | Apply the agreed source-edit and integration policy | New work has a known owner during the transition |
| Deploy and configure | Apply the validated package and environment settings | Required deployment and configuration checks pass |
| Apply data changes | Load the final scoped changes and reconcile | Identity, relationships and important totals pass |
| Run pilot transactions | Exercise actual roles and downstream outcomes | No unresolved blocking failure in the pilot |
| Expand access | Release the approved cohort and monitor | Operators can detect and resolve exceptions |

Time the rehearsal rather than estimating solely from record count. Import throughput, relationship repair, access recalculation and business review can affect the operating window differently.

Define the stop conditions before production work begins. Examples include unexplained financial differences, unauthorized access, lost current preferences or a duplicate customer-facing action. Decide which owner may stop the release and who approves a corrected attempt.

Returning an earlier configuration does not automatically undo records created by an integration or messages already sent. Before recovery, reconcile completed external work and new source changes. The recovery objective should say which future actions stop, which records need repair and what the team can safely resume.

## How do you decide whether a release can proceed?

Require passing evidence for the release actually being considered, plus named operating owners. A completed test spreadsheet containing failures is not an approval.

This original release register uses eight controls. Keep the IDs stable so evidence and follow-up work remain connected.

| Control ID | What must pass | Accountable evidence |
| --- | --- | --- |
| `scope` | Required workflow and deferred scope are agreed | Business approval for this release |
| `access` | Allowed and prohibited role actions | Role-specific results |
| `migration` | Scoped records, relationships and changes reconcile | Reconciliation and exception disposition |
| `integrations` | Ownership, retries and downstream results | Whole-transaction outcomes |
| `uat` | Representative users complete the required tasks | Accepted UAT cases |
| `cutover` | Ordered release steps and pilot work | Successful rehearsal and operator review |
| `recovery` | Failed release or partial external work can be handled | Tested recovery procedure |
| `handover` | Another owner can operate the system | Operating pack and incident exercise |

The following local helper identifies missing, failed or stale evidence records. It does not connect to Salesforce or decide whether the evidence itself is truthful. Use it to keep the register complete; the accountable owners still review the underlying results.

```python
REQUIRED = ("scope", "access", "migration", "integrations",
            "uat", "cutover", "recovery", "handover")

def release_holds(register, candidate):
    if type(register) is not dict:
        raise ValueError("register must be a dictionary")
    if not isinstance(candidate, str) or not candidate.strip():
        raise ValueError("candidate must be a nonempty release identifier")
    if set(register) - set(REQUIRED):
        raise ValueError("register contains an unknown control ID")
    holds = []
    for control in REQUIRED:
        row = register.get(control)
        if not isinstance(row, dict):
            holds.append(control)
            continue
        complete = all(isinstance(row.get(key), str)
                       and row[key].strip()
                       for key in ("owner", "evidence"))
        if (row.get("result") != "pass" or not complete
                or row.get("release") != candidate):
            holds.append(control)
    return holds
```

For example, if seven controls pass for release `pilot-a` but the access result belongs to `pilot-old`, the helper returns `['access']`. If the migration control is marked failed, it remains a hold even when its owner and evidence fields are complete. An empty result means this local completeness check passed, not that a production deployment is authorized automatically.

![Agree scope and owners, build and rehearse the candidate, then require passing checks for that candidate. Readiness failures return to rehearsal. A pilot is released only when cutover, recovery and operators are ready; incorrect pilot outcomes pause expansion and reconcile completed work before another attempt.](https://www.martechdevs.com/assets/blog/salesforce-implementation-checklist.svg)

Diagram connections:

- Agree scope owners and required evidence to Build and rehearse the release candidate. 
- Build and rehearse the release candidate to Required checks passed for this candidate?. 
- Required checks passed for this candidate? to Repair the failure and rerun affected checks: No. 
- Repair the failure and rerun affected checks to Build and rehearse the release candidate. 
- Required checks passed for this candidate? to Cutover recovery and operators ready?: Yes. 
- Cutover recovery and operators ready? to Complete the operating rehearsal: No. 
- Complete the operating rehearsal to Build and rehearse the release candidate. 
- Cutover recovery and operators ready? to Release the approved pilot cohort: Yes. 
- Release the approved pilot cohort to Pilot outcomes correct?. 
- Pilot outcomes correct? to Pause expansion and reconcile completed work: No. 
- Pause expansion and reconcile completed work to Build and rehearse the release candidate. 
- Pilot outcomes correct? to Expand and hand over monitored operation: Yes

## What makes handover and adoption complete?

Handover is complete when the internal owner can explain the process, find a failed transaction and follow the recovery procedure. Training attendance alone does not establish that the team can operate the release.

Train each role using its actual tasks: assign a lead, correct a relationship, request approval, review a forecast or resolve a failed sync. Include a negative case so users learn what the system intentionally prevents and how to request help.

Track adoption through useful behavior and data quality. Review ownership completeness, required next actions, exception age and whether the approved workflow reaches its destination. Login counts can indicate access, but they do not establish a usable pipeline or accurate report.

Agree a stabilization period with its response expectations, defect criteria and change-request boundary. An omitted requirement is not automatically a defect; a broken agreed behavior should not quietly become a new billable feature. Record outstanding work and its owner before the implementation team leaves.

## Checklist

- [ ] The first release has a clear workflow, owner and measurable operating result.
- [ ] Required licences, environments and access have been confirmed.
- [ ] Source identifiers, relationships and field ownership are documented.
- [ ] Migration has been rehearsed and its exceptions remain visible.
- [ ] Configuration dependencies and environment-specific settings are included.
- [ ] Integrations pass retry, conflict and partial-failure cases.
- [ ] Real user roles pass both allowed and prohibited actions.
- [ ] Deployment validation and business UAT are recorded separately.
- [ ] Cutover, recovery and pilot stop conditions have been rehearsed.
- [ ] The internal owner can operate the release and review future changes.

Get the [$99 martech audit](https://www.martechdevs.com/pricing) to establish which gates are missing from an existing implementation. For a new rollout, [request a detailed CRM scope](https://www.martechdevs.com/crm-lifecycle#offer) with the workflow, source data, integrations and acceptance cases. That gives the implementation team a result to price and the business a result to approve.

## Frequently asked questions

### How long should a Salesforce implementation take?

Build the schedule from dependencies, available capacity and the acceptance work. Configuration can run alongside data preparation, but migration rehearsal needs the relevant model and access in place. Include business review, training and recovery testing rather than dividing estimated hours by a nominal full-time team. A credible schedule identifies what can run concurrently and which unresolved decision can delay release.

### Can a small team implement Salesforce without a partner?

Yes, when an accountable internal owner can configure and maintain the required process and verify the data, access and integration boundaries. Start with a limited workflow and test it using ordinary user roles. Bring in specialist help for work the team cannot confidently design or operate, such as complex history migration, cross-system recovery or custom code with material security implications.

### Should all historical CRM data move into Salesforce?

Move the history required for ongoing relationships, operating decisions and agreed retention obligations. Archive other permitted history in a retrievable form with its definitions and identifiers. Do not import obsolete records just to match the old system's row count, and do not discard useful evidence without an owner approving the decision. Reconcile intentionally excluded records separately from failed imports.

### Does a sandbox test prove production will behave the same way?

No. It provides important evidence, but production can differ in data volume, permissions, credentials, integrations and environment settings. Record those differences and include target validation and a controlled production pilot. Test data should represent the difficult relationships and roles. A clean sandbox with administrator-only tests can conceal the exact access or dependency problem ordinary users will encounter.

### What should happen if a critical test fails just before launch?

Hold the affected release or cohort and identify what the failure invalidates. Repair it, rerun the relevant tests and reassess dependent evidence for the actual candidate. Do not carry forward an old pass after changing the behavior it tested. If some scope is deferred, make that a new approved release boundary rather than quietly treating a failed required case as complete.

## Sources

1. [Sales Cloud rollout planning](https://trailhead.salesforce.com/content/learn/modules/sales-cloud-rollout-strategy/chart-your-course).

2. [Salesforce sandboxes](https://help.salesforce.com/s/articleView?id=deploy_sandboxes_parent.htm&language=en_US&type=5).

3. [Sandbox email deliverability](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_email_deliverability.htm&language=en_US&type=5).

4. [Salesforce data access](https://developer.salesforce.com/docs/platform/salesforce-record-access-under-the-hood/guide/uth-intro.html).

5. [Data Import Wizard](https://help.salesforce.com/s/articleView?id=sf.data_import_wizard.htm&language=en_US&type=5).

6. [External-ID upsert](https://developer.salesforce.com/docs/platform/api-rest/guide/resources-sobject-upsert-patch.html).

7. [Bulk data results](https://developer.salesforce.com/docs/platform/sfdx-dev/guide/sfdx-dev-data-bulk.html).

8. [Change sets](https://help.salesforce.com/s/articleView?id=sf.changesets.htm&language=en_US&type=5).

9. [Change-set best practices](https://help.salesforce.com/s/articleView?id=sf.changesets_best_practices.htm&language=en_US&type=5).

10. [Salesforce deployment test levels](https://developer.salesforce.com/docs/platform/salesforce-cli-reference/guide/cli_reference_project_deploy_start.html).