The Ultimate Guide to Salesforce Implementation: Best Practices, Tips, and Tricks

A Salesforce implementation is complete when the business can run its agreed processes, trust the data, control access, recover from failures, and keep improving the platform after the project team leaves. A production login screen is not that standard.

This guide explains how to plan and deliver a Salesforce implementation from business case through the first 90 days after launch. It gives you an eight-phase process, realistic planning ranges, the team and decision rights required at each stage, and the deliverables that prove the work is ready to move forward. It also reflects Salesforce’s current architecture guidance for 2026, including the new five-pillar Well-Architected Framework, the retirement of Workflow Rules and Process Builder support, and the extra controls needed when Agentforce is in scope.

Salesforce implementation at a glance

Planning question	Practical answer
How long does implementation take	About 6–12 weeks for a focused first release, 3–6 months for a multi-team implementation, and 6–18+ months for enterprise or multi-cloud programs. Scope, data, integrations, approvals, and rollout design matter more than company size alone.
Who owns the outcome	An executive sponsor funds and removes barriers. A product or process owner makes day-to-day scope and process decisions. A platform owner accepts ongoing operational ownership.
What should every phase produce	A named deliverable, a named approver, objective acceptance evidence, and a recorded decision to proceed, revise, or stop.
What causes most schedule surprises	Unresolved business rules, poor source data, unavailable test environments, integration dependencies, late security review, weak UAT participation, and no cutover rehearsal.
What happens after go-live	Hypercare, adoption measurement, backlog governance, security and data-quality reviews, controlled releases, and a 30/60/90-day value review.

 

Important read: Salesforce Implementation Best Practices

Why implementation needs more than configuration

Salesforce can be configured quickly. The surrounding business system is harder. A 2026 MuleSoft survey of 1,050 IT leaders found that the average organization managed 957 applications while only 27% were connected. Respondents also reported that 26% of IT projects had missed their planned delivery date during the preceding year and that teams spent 36% of their time designing, building, and testing custom integrations. These are survey findings, not a forecast for every Salesforce project, but they explain why interface ownership and failure handling cannot wait until the end. See the 2026 Connectivity Benchmark findings.

The people side has the same weight. Prosci reports that transformations with excellent change management are up to seven times more likely to succeed than poorly managed change efforts. That finding supports a practical implementation rule: training, communications, manager reinforcement, and adoption measurement belong in the main plan and budget. They are not launch-week tasks.

A public Salesforce customer story about U.S. Bank makes the same point from another angle. Salesforce reports a 2.35x lift in lead conversion and about 12,000 employee users after the bank expanded the platform across business lines. The implementation was tied to a business operating model and training approach, not simply to feature deployment. As John Bilden, then head of enterprise CRM, put it:

“Having a unified view of our customers enables us to deliver a more unified customer experience.”

John Bilden, U.S. Bank

Customer stories are vendor-published and should not be treated as guaranteed results. The useful lesson is how the outcome was framed: a measurable business result, a unified data model, a phased rollout, and structured user education.

What Salesforce implementation includes

Salesforce implementation is the work required to turn selected Salesforce products into a governed operating system for the business. Depending on scope, it includes:

• business goals, baselines, scope boundaries, and success measures;
• current-state and future-state process design, including exceptions and controls;
• product, edition, license, environment, and deployment decisions;
• data model, security model, sharing design, retention, and audit requirements;
• standard configuration, Flow automation, managed packages, Apex, and Lightning Web Components where justified;
• integration architecture, API contracts, monitoring, retry, and reconciliation;
• data profiling, cleansing, mapping, trial migration, cutover, and business reconciliation;
• testing across configuration, code, interfaces, security, data, performance, and end-to-end business scenarios;
• role-based training, communications, manager enablement, support, and adoption measurement;
• production deployment, rollback planning, hypercare, operations handoff, and ongoing product governance.

The scope can be narrow, but the control categories should not disappear. A ten-user Sales Cloud launch still needs an owner, a data decision, an access model, acceptance testing, training, and a support plan. The artifacts may be shorter and several roles may be held by one person.

The current Salesforce quality standard

Salesforce’s architecture standard has changed. The former Trusted, Easy, and Adaptable model is now a legacy taxonomy. The current Salesforce Well-Architected Framework uses five pillars across traditional and agentic solutions.

Pillar	Question for the implementation team	Examples of evidence
Trust	Are people, data, integrations, and automated actions protected by least privilege and clear governance	Security matrix, data classification, permission tests, integration identities, audit design
Reliability	Will critical processes continue, fail safely, and recover at the required volume	Capacity assumptions, error paths, retries, recovery tests, service objectives
Operational Excellence	Can the team deploy, observe, support, and improve the solution predictably	Source control, release pipeline, monitoring, runbooks, incident ownership
Resource and Cost Optimization	Does the design justify licenses, platform consumption, custom work, and long-term maintenance	TCO model, license plan, capacity budget, build-versus-buy decisions
Fairness	Is the solution accessible, transparent, contestable, and appropriately supervised	Accessibility tests, human oversight, explainability, escalation and appeal paths

 

“It gives you the right questions to ask, the right patterns to consider, and a common vocabulary to use across teams.”

Salesforce Well-Architected Framework

Use these pillars during discovery, architecture review, test planning, go-live approval, and quarterly platform health reviews. A one-time design review is not enough because scope, integrations, data volumes, users, and platform features change.

Define the first release before estimating it

A credible timeline starts with a release brief. It should fit on one or two pages and answer the following questions before detailed solutioning begins:

• Which business outcome should change, from what baseline to what target, by when
• Which users, teams, regions, channels, and processes are included
• Which products, systems, data sets, and historical periods are included
• Which capabilities and user groups are explicitly excluded from release one
• Which security, privacy, compliance, accessibility, availability, and performance constraints apply
• Who can approve scope, process, data, architecture, security, UAT, and go-live decisions
• What must remain operational during cutover and what is the tolerated interruption
• Who owns the platform, support process, and roadmap after launch

Salesforce’s guidance on defining success recommends connecting initiatives to quantifiable key performance indicators. Replace broad goals such as ‘create a single source of truth’ with measures the system can influence, for example:

• Reduce median lead-response time from 18 hours to two hours for qualified inbound inquiries.
• Increase open opportunities with a verified next step and date from 54% to 90%.
• Reduce avoidable case reassignment by improving intake, skills routing, and ownership rules.
• Cut weekly forecast preparation from four hours to 30 minutes while preserving approval controls.
• Keep duplicate active account records below an agreed threshold and assign an owner to exceptions.

A practical release one scope statement

A scope statement should be specific enough that five stakeholders cannot imagine five different projects. For example:

“Release one supports North American direct sales from qualified lead through closed opportunity. It includes account and contact management, agreed opportunity stages, email integration, approval for discounts above 15%, two ERP interfaces, core management dashboards, and migration of active customers plus three years of open and won opportunities. Partner sales, renewals, territory redesign, quoting, and production Agentforce actions are later releases.”

Example scope statement

The exclusions matter as much as the included features. They protect discovery and UAT from becoming an uncontrolled request queue.

The eight phase Salesforce implementation process

Phase	Indicative duration	Core deliverables	Exit decision
1 Readiness and business case	1–2 weeks	Charter, outcomes, baseline, scope boundary, budget assumptions, decision rights	Fund, revise, or pause
2 Discovery and process design	2–4 weeks	Process maps, personas, business rules, exceptions, prioritized backlog, acceptance criteria	Approve future-state process and release backlog
3 Architecture and governance	1–3 weeks, overlaps phase 2	Solution blueprint, data model, security matrix, integration catalog, environment and release strategy	Approve material design choices and risks
4 Configure and build	4–12+ weeks	Demonstrable increments, configuration, automation, code, reports, technical documentation	Each increment meets its definition of done
5 Data and integration proving	Runs in parallel for 4–12+ weeks	Mappings, trial loads, reconciliation, interface tests, monitoring and recovery evidence	Data and interfaces meet acceptance thresholds
6 Validation and readiness	2–5 weeks	Test evidence, defect decisions, UAT approval, training, support model, cutover readiness	Business and technical owners approve launch readiness
7 Deployment and hypercare	1–4 weeks	Production release, final migration, validation log, command center, support handoff	Stability thresholds are met
8 Adoption and optimization	First 90 days, then ongoing	Adoption scorecard, value review, release roadmap, technical-debt register	Move from project governance to product governance

 

The phases are control points, not a waterfall mandate. Discovery, architecture, build, migration, change, and testing should overlap through short feedback loops. The team should still know which evidence is required before a high-risk decision is accepted.

Phase 1 Readiness and business case

The first phase determines whether the organization is ready to make and support the decisions that implementation requires. It does not need to answer every design question. It must establish why the project exists, who owns it, what release one means, and which uncertainties could invalidate the estimate.

Complete the following work:

• Name the executive sponsor, product owner, process owners, data owners, and future platform owner.
• Record the current baseline and the business measures the implementation should influence.
• Write the included scope and exclusions in business-process terms.
• List known data sources, interfaces, user populations, regulatory constraints, and blackout periods.
• Create the initial risk, assumption, issue, and dependency log.
• Choose the governance cadence and escalation route for decisions that exceed the product owner’s authority.
• Reserve business-user time for discovery, demonstrations, UAT, training, and post-launch support.

Deliverables: approved charter, outcome baseline, scope statement, stakeholder map, decision-rights matrix, initial delivery plan, risk and assumption log, and funding range.

Exit gate: the sponsor confirms the business case and funding; the product owner accepts scope authority; major uncertainties have owners and a plan to reduce them.

Phase 2 Discovery and process design

Discovery should investigate how work enters the business, how decisions are made, where handoffs fail, which exceptions consume time, and what evidence managers need. A tour of old fields and screens is not enough.

For each priority process, document three levels:

1. Outcome: what must be true when the process is complete and how the business will measure it.
2. Flow: the main steps, decisions, handoffs, systems, roles, and information required.
3. Rules and exceptions: who can act, under which conditions, what can fail, and how unusual cases are resolved.

Observe representative users completing real work. Managers often describe the official process; users reveal spreadsheets, inbox rules, copied notes, manual re-entry, and side conversations. Convert findings into user jobs and acceptance scenarios rather than a feature wish list.

Deliverables: current-state findings, future-state process maps, persona and access needs, business glossary, requirements backlog, business rules, exception catalogue, reporting needs, and acceptance criteria.

Exit gate: process owners approve the future-state happy path, exceptions, controls, measures, and the backlog selected for release one.

Phase 3 Architecture and governance

Architecture records the decisions that will shape security, reliability, cost, scale, and maintainability. It should explain trade-offs and rejected options, not merely show boxes and arrows.

At minimum, produce:

• a system context diagram and Salesforce product and edition decision;
• a conceptual and logical data model, including systems of record;
• an integration catalogue with direction, frequency, volume, ownership, security, and failure behavior;
• a persona-based security and sharing matrix;
• an automation strategy covering standard configuration, Flow, packages, Apex, and external services;
• an environment, source-control, deployment, hot-fix, and release strategy;
• data retention, archive, backup, and recovery decisions;
• non-functional requirements for availability, performance, observability, accessibility, and support;
• architecture decision records for choices that would be expensive or risky to reverse.

Design integration around ownership and failure

Salesforce’s official integration patterns distinguish data, process, and virtual integration. Select a pattern only after answering:

• Which system owns each record or attribute
• Whether the business needs data movement, process invocation, virtual access, or a combined experience
• What latency the process genuinely requires
• What normal and peak volume the design must support
• How duplicates, ordering, retries, timeouts, partial failures, and replay will behave
• Who monitors the interface and who resolves its error queue

Design security before layouts

Start from the most restrictive practical access model. Use a minimal profile and grant functional access through permission sets and permission-set groups. Give each integration its own API-only identity. Document SSO, MFA, emergency access, connected apps, record visibility, field access, data classification, provisioning, and periodic review.

Model reporting visibility with the Salesforce role hierarchy and use sharing rules for controlled exceptions. Test negative access cases. A user being able to open the right record does not prove that another user is correctly blocked.

Deliverables: solution blueprint, architecture decision log, data model, integration catalogue, security matrix, non-functional requirements, environment strategy, release model, and operational ownership model.

Exit gate: architecture, security, data, integration, and platform owners approve the material decisions; unresolved risks have mitigation, contingency, and an owner.

Phase 4 Configure and build

Build demonstrable vertical slices that complete a useful business behavior. Instead of configuring every Account field and then every Opportunity field in isolation, demonstrate a seller creating or matching an account, qualifying a contact, progressing an opportunity, obtaining approval, and seeing the result in a manager’s report.

Every story should include:

• business acceptance criteria and the relevant persona;
• security and sharing behavior, including negative cases;
• data, integration, reporting, and audit effects;
• error and exception behavior;
• configuration or code tests and deployment dependencies;
• documentation, training, and support impact.

Use a definition of done

A component is not complete because it worked once in a builder’s sandbox. A practical definition of done requires acceptance criteria to pass, security to be reviewed, bulk and fault behavior to be tested, metadata to be committed to source control, peer review to be complete, and documentation to be updated.

Do not design new automation in Workflow Rules or Process Builder. Salesforce ended support for both on December 31, 2025 and recommends migration to Flow Builder. Existing automations may continue to run, but they no longer receive support or bug fixes.

Treat metadata as a managed product. Salesforce’s DevOps Center guidance describes source control as the single source of truth. Establish named environments, review rules, automated validation, deployment ownership, dependency tracking, release naming, and a hot-fix path early. Do not wait until cutover week to discover that the team cannot recreate production from the approved source.

Deliverables: configured increments, automation and code, reports and dashboards, source-controlled metadata, configuration register, automated tests, review evidence, release notes, and updated technical documentation.

Exit gate: each increment meets the definition of done and the product owner accepts the demonstrated behavior against its criteria.

Phase 5 Data migration and integration proving

Data migration is a delivery stream, not a final weekend task. The most damaging errors are often plausible records: an open opportunity assigned to an inactive owner, a customer attached to the wrong parent, a consent value mapped incorrectly, or a historical status that distorts reporting.

A controlled Salesforce data migration plan should inventory the sources, decide what to migrate or archive, declare systems of record, define durable external IDs, document every transformation, sequence dependencies, rehearse full loads, plan the final delta, and reconcile the result.

Control	Example acceptance evidence
Counts	Target records equal the approved source population minus documented exclusions
Control totals	Pipeline amount, quantities, balances, or other material totals match approved extracts
Relationships	No unexplained orphan records; sampled parent and child relationships are correct
Ownership	Active records have valid users, queues, or approved fallback owners
Value distributions	Stage, status, type, region, consent, and other key values match approved mappings
Exceptions	Every failed record is corrected, approved as an exception, or excluded with an owner
Business sampling	Process owners validate a risk-based sample through the actual business workflow

 

Prove integrations under failure, not only during a successful demo. Test invalid records, dependency outages, expired credentials, rate limits, duplicate or replayed messages, partial batch failure, reprocessing, alerting, and reconciliation. An interface that moves data while every system is healthy is incomplete.

Deliverables: source inventory, data disposition decisions, mapping specification, cleansing log, trial-load results, migration runbook, reconciliation report, interface contracts, performance results, error dashboards, recovery tests, and owner sign-off.

Exit gate: repeatable trial loads reconcile to the approved source; interfaces meet security, latency, volume, monitoring, and recovery criteria.

Phase 6 Testing and business readiness

Testing should answer distinct questions. One broad ‘UAT’ phase cannot replace technical, security, integration, data, and operational evidence.

Test layer	Question	Evidence
Configuration and Flow	Do rules, routing, approvals, and fault paths behave correctly	Scenario results and failure-path results
Apex and components	Does custom code behave correctly in isolation, bulk contexts, and negative cases	Automated tests, assertions, coverage, code review
Integration	Do systems agree on payloads, identity, timeouts, errors, retries, and replay	Contract and end-to-end logs
Security	Can each persona do only what it should	Positive and negative access results
Migration	Did approved data arrive completely and correctly	Reconciliation and exception disposition
Performance and scale	Does the solution meet peak workload and response expectations	Workload model and measured results
User acceptance	Can named business users complete real work and accept the process	Scenario approval and defect decisions
Cutover and recovery	Can the team deploy, validate, stop, recover, and communicate	Timed rehearsal and decision log

 

Make UAT a business decision

Give named users realistic role-based scenarios, prepared data, expected outcomes, severity definitions, and a daily triage route. Distinguish defects, training gaps, and new requests. The product or process owner should be accountable for UAT acceptance; the delivery team should not approve its own solution on behalf of the business.

Train for the job

Training should show each role how to complete work, make decisions, and recover from common errors. Use process-based practice, searchable job aids, manager dashboards, office hours, and support channels. If users need a long course to understand an ordinary task, first ask whether the page, process, or automation is unnecessarily complicated.

Deliverables: test strategy, traceability matrix, test data, results, defect log, UAT approval, training curriculum, job aids, support model, stakeholder communications, readiness assessment, and go-live recommendation.

Exit gate: critical defects are closed or formally accepted; business, security, data, release, support, and change owners approve launch readiness against explicit thresholds.

Phase 7 Cutover and hypercare

A cutover runbook records sequence, owner, planned time, evidence, dependency, stop condition, and recovery action. It should be rehearsed with representative data and realistic system access.

Before the change window:

• approve the exact source version and deployment manifest;
• complete the final migration rehearsal and time every material step;
• verify licenses, permissions, endpoints, certificates, connected apps, and support contacts;
• confirm data and metadata backups plus tested restoration steps;
• publish freeze windows, continuity procedures, validation scripts, and communications;
• state objective no-go and rollback triggers;
• confirm who has final go/no-go authority.

Rollback must be specific. Metadata, loaded data, outbound messages, and user-created production transactions have different recovery paths. Define the last point at which full rollback remains possible, how downstream transactions will be handled, who makes the decision, and how restored data will be validated.

Hypercare should have exit criteria. Move to normal support when critical processes are stable, integration and automation errors remain within agreed thresholds, high-severity issues are closed, support ownership has transferred, and ordinary releases can take over.

Deliverables: production release, final migration and reconciliation, validation log, decision log, communications, issue command center, workarounds, support ownership, and hypercare exit approval.

Exit gate: production checks pass and unresolved issues sit within the agreed business and technical risk tolerance.

Phase 8 Adoption and optimization

Logins do not prove adoption. Measure whether each persona completes the work the implementation was designed to improve.

Measure	What it reveals
Activation by persona	Whether licensed users completed the first meaningful task for their role
Core-process completion	Whether work reaches the required stages with the required information
Data quality and freshness	Whether users can trust records for operations and decisions
Exceptions and support demand	Where automation, integrations, data, or training create manual cleanup
Time and effort	Whether the new process improves the baseline rather than merely digitizing it
Business outcome	Whether the target measure such as lead response, forecast quality, or case resolution is moving
Old-tool retention	Where spreadsheets, inboxes, or the legacy CRM still run the real process

 

Use the first 90 days deliberately:

• Days 0–30: Stabilize critical processes, correct security and data defects, monitor failures and support demand, and coach teams with low activation.
• Days 31–60: Remove repeated friction, simplify pages and validation, tune routing and reporting, and resolve recurring migration or interface exceptions.
• Days 61–90: Compare outcomes with the baseline, review license and consumption usage, approve the next releases, and assign dates to technical debt.

Deliverables: 30/60/90-day scorecard, adoption analysis, governed backlog, release calendar, platform health review, license and consumption review, technical-debt register, and legacy-system retirement plan.

Exit gate: the platform owner accepts the operating model and the executive sponsor reviews measured value, remaining risk, and the next investment decision.

How long Salesforce implementation takes

Salesforce’s own CRM implementation guidance states that smaller projects may take a few weeks while larger implementations with complex integrations can require several months. Use the following bands for early planning, then replace them with a dependency-based schedule after discovery.

Implementation type	Indicative window	Typical assumptions
Focused first release	6–12 weeks	One primary team, standard process, limited history, few interfaces, available decision-makers
Multi-team or mid-market program	3–6 months	Several personas, material migration, multiple interfaces, role-based change and training
Enterprise or multi-cloud transformation	6–18+ months	Multiple business units or regions, complex security, high data volume, many systems, phased rollout

 

These are planning bands, not commitments. For a more detailed estimator, use the DGT27 guide to the Salesforce implementation timeline. The reliable schedule comes from scope, dependencies, business availability, environment access, data rehearsals, test cycles, training, and cutover constraints.

Example 12 week plan

The example below assumes one focused cloud, limited custom development, manageable migration, and two or three interfaces. Work overlaps by design.

Weeks	Primary work	Decision or evidence
1–2	Readiness, outcome baseline, discovery, data and interface inventory	Charter and release boundary approved
2–4	Future-state process, backlog, security, data model, architecture	Process and material design decisions approved
3–8	Configuration and build in short demonstrable increments	Stories meet definition of done
3–9	Data profiling, mapping, trial loads, interface build and failure tests	Trial migration reconciles; interfaces recover
7–10	System tests, security tests, UAT, training, support preparation	Business and technical readiness approved
10–11	Cutover rehearsal, defect closure, final go/no-go review	Timed runbook and rollback decision approved
12	Production deployment, final migration, validation, communications	Production checks pass
13 onward	Two to four weeks of hypercare, then 30/60/90-day optimization	Stability and value reviews complete

 

What stretches the timeline

• Decision wait time: process, scope, data, and security questions remain open because the accountable owner is unavailable.
• Data uncertainty: sources are undocumented, duplicates or relationships are unresolved, or historical scope changes late.
• Integration access: external teams cannot provide contracts, credentials, environments, sample payloads, or support windows on time.
• Security and compliance review: identity, retention, encryption, consent, accessibility, or third-party review begins after build.
• Custom behavior: complex automation, revenue processes, portals, industry products, or high-volume code requires more design and proving.
• Business readiness: UAT users, managers, trainers, or support teams have not reserved time.
• Cutover constraints: short change windows, large final deltas, coexistence with the old system, or strict rollback requirements add rehearsal cycles.
• Agentic scope: Agentforce use cases require representative evaluation sets, permission controls, human escalation, monitoring, and consumption modeling.

The Salesforce implementation team

Not every role requires a separate full-time person. Every accountability still needs a named owner, and roles that should challenge one another need an independent review. The builder should not be the only security approver, tester, and go-live authority.

Role	Accountable for
Executive sponsor	Business outcome, funding, cross-functional barriers, and final decisions outside the product owner’s authority
Product or process owner	Release scope, priorities, process rules, acceptance, and value review
Project or delivery manager	Plan, dependencies, risks, decisions, resources, and communication
Solution architect	End-to-end design, non-functional requirements, architectural trade-offs, and technical integrity
Business analyst or functional lead	Process discovery, requirements, acceptance criteria, demonstrations, and traceability
Salesforce admin or consultant	Configuration, automation, documentation, tests, and operational handoff
Salesforce developer	Apex, components, complex automation, automated tests, review, and supportability
Data owner and migration lead	Disposition, quality rules, mapping, migration, reconciliation, and approval
Integration lead	Interface patterns, contracts, identity, failure handling, monitoring, and recovery
Security and compliance lead	Identity, access, data controls, audit, privacy, accessibility, and required approvals
QA or test lead	Test strategy, environments, traceability, defect management, and evidence
Change and training lead	Impact assessment, communications, manager enablement, training, adoption, and feedback
Release and cutover lead	Environment flow, deployment, cutover runbook, rollback, and command center
Super users	Real-work feedback, UAT, peer support, and local adoption signals
Platform owner	Support, releases, roadmap, technical debt, licenses, health, security, and value after launch

 

A simple deliverable RACI

RACI means Responsible, Accountable, Consulted, and Informed. Keep one accountable owner for each deliverable. More than one ‘A’ usually means nobody can make the final decision.

Deliverable	Accountable	Responsible	Consulted	Informed
Charter and outcomes	Executive sponsor	Product owner and project manager	Finance and process owners	Delivery team
Future-state process and backlog	Product owner	Business analyst	Users, architect, data and security leads	Sponsor
Solution architecture	Solution architect	Technical leads	Product, data, security, operations	Project manager
Data mapping and reconciliation	Business data owner	Migration lead	Product owner, admin, integration lead	Sponsor and QA
UAT approval	Product owner	Named business testers	QA, process owners, delivery team	Sponsor
Go-live decision	Executive sponsor or delegated authority	Release lead	Product, architecture, security, data, support	All affected teams
Operations handoff	Platform owner	Admin and support lead	Architect, release, product owner	Sponsor and users

 

Time commitments to protect

The following are planning assumptions, not universal staffing rules. They are useful when a project plan lists a role but gives that person no time to do the work.

Role	Planning assumption during active delivery
Executive sponsor	Weekly steering decision plus rapid availability for escalations
Product owner	Roughly 30–60% of working time for a focused implementation; more during discovery, UAT, and cutover
Process and data owners	Scheduled workshops, mapping decisions, demonstration reviews, UAT, and reconciliation approval
Super users	Recurring demonstrations plus protected UAT and peer-support time
Platform owner and admin	Participate before build ends so support and governance knowledge is transferred gradually

 

Salesforce implementation deliverables

Deliverables are useful only when they support a decision, operation, or audit. Avoid documents that repeat generic methodology without recording the choices made for this implementation.

Category	Required deliverable	Acceptance proves	Primary owner
Strategy	Charter, baseline, target outcomes, scope, exclusions, funding assumptions	The business knows why the project exists and what release one includes	Sponsor and product owner
Governance	RACI, steering cadence, decision log, risk and dependency log, change control	Decisions can be made and traced	Project manager
Process	Future-state maps, business rules, exceptions, backlog, acceptance criteria	The solution supports approved work, not a screen wishlist	Product and process owners
Architecture	Context diagram, data model, ADRs, non-functional requirements	Trade-offs and quality requirements are explicit	Solution architect
Security	Persona matrix, sharing model, integration identities, test evidence, review schedule	Human and system access follows least privilege	Security lead
Integration	Catalogue, contracts, mappings, failure design, monitoring, reconciliation	Interfaces can be operated and recovered	Integration lead
Data	Inventory, disposition, mapping, cleansing, trial loads, cutover, reconciliation	Migrated data is complete, correct, related, owned, and usable	Data owner and migration lead
Build	Configuration register, source-controlled metadata, code, tests, technical documentation	The delivered org is reproducible and supportable	Technical lead
Quality	Test strategy, traceability, results, defects, UAT approval	Business and technical behavior has evidence	QA lead and product owner
Change	Impact assessment, communication plan, training, job aids, readiness and adoption measures	Affected people understand and can perform the new work	Change lead
Launch	Cutover runbook, rollback, go/no-go scorecard, validation and communication plans	The team can deploy, stop, recover, validate, and communicate	Release lead
Operations	Support model, monitoring, admin guide, release calendar, roadmap, health and value scorecard	The organization can own the platform after the project	Platform owner

 

Ask an implementation partner to show the artifacts

A proposal can sound disciplined while the actual delivery method remains vague. Ask the partner to show anonymized examples of an architecture decision record, security matrix, mapping specification, migration reconciliation report, test strategy, cutover runbook, and operations handoff. Then ask who creates each artifact, who approves it, and whether it is included in the quoted scope.

Agentforce and AI implementation decisions

Do not include Agentforce in release one only because AI appears on the product roadmap. Include it when a bounded job, reliable grounding data, least-privilege access, human escalation, evaluation method, monitoring owner, and consumption model exist.

Treat an agent as a digital user that can act. Define:

• the job, audience, allowed topics, actions, systems, and records;
• the knowledge sources and the owner of their accuracy and freshness;
• permissions for the agent user and identity propagation to external systems;
• requests that must be refused, confirmed, or handed to a person;
• normal, ambiguous, adversarial, unsafe, out-of-scope, and escalation tests;
• quality and policy thresholds plus the human who approves production readiness;
• session tracing, quality monitoring, incident response, deactivation, and rollback;
• usage assumptions, testing consumption, retries, growth, and budget controls.

Salesforce’s Agentforce testing guidance explains that generative behavior adds variables that may sit in instructions, actions, data, or permission sets. The platform supports preview testing and testing at scale, but the implementation team must still define its own representative cases and production thresholds.

If the agent is not ready, the first release can prepare for it by cleaning knowledge sources, tightening permissions, improving APIs, making Flow and Apex actions reusable, and establishing observability. That foundation has value even if the AI use case changes.

Common implementation failures and the control for each

Failure	What it looks like	Control
Starting with features	Workshops ask for fields and dashboards before defining the outcome	Begin with measurable outcomes, process decisions, and failure points
No release boundary	Every request becomes release one	Approve explicit exclusions and use value, risk, dependency, effort, and maintenance cost to prioritize
Copying the old CRM	New screens reproduce old fields and workarounds	Redesign the process and migrate only behavior and data with a current purpose
Security designed late	Broad access is granted to protect the date	Approve persona access and negative tests during architecture
Successful import called validation	The job completed but relationships, ownership, and totals are wrong	Use signed reconciliation across counts, totals, relationships, values, exceptions, and samples
Happy-path integration tests	Interfaces work only when every dependency is healthy	Test outages, timeouts, limits, replay, partial failure, alerts, and recovery
Production is the source of truth	The team cannot reproduce or audit the org	Use source control, peer review, controlled releases, and a hot-fix path
One training event	Users attend a tour and return to spreadsheets	Train by role and process, reinforce through managers, and use adoption data for follow-up
Agent without governance	Broad access and subjective acceptance are treated as readiness	Define scope, permissions, escalation, evaluations, monitoring, cost, and deactivation
Project ends at go-live	Resources leave while defects and habits are still forming	Fund hypercare and a 30/60/90-day product plan

 

When to use an implementation partner

Use an internal team when it has the Salesforce skill, delivery capacity, decision access, data knowledge, and operating model to own both implementation and support. Use a partner when independent experience reduces material risk or fills a capability gap. A hybrid model is often strongest: internal owners keep process, data, risk, and product decisions while specialists provide architecture, migration, integration, complex development, testing, or release engineering.

Before selection, ask for:

• the named delivery team, role seniority, location, availability, and expected time allocation;
• examples with comparable clouds, data, integrations, security, user volume, and rollout design;
• assumptions, exclusions, acceptance criteria, dependencies, and change-control method;
• the approach to environments, source control, peer review, documentation, monitoring, and technical debt;
• knowledge transfer to the future product owner, admin, support team, and architecture owner;
• post-launch support, response expectations, warranty boundaries, and handoff criteria;
• any license, referral, package, or product incentives that could influence the recommendation.

A partner cannot own the customer’s business decisions. If you need external support, review DGT27’s Salesforce implementation services and compare the proposed work against the deliverables and exit gates in this guide.

Salesforce implementation checklist

Strategy and readiness

• ☐ Executive sponsor, product owner, process owners, data owners, and platform owner are named.
• ☐ Baselines, target outcomes, release-one scope, and exclusions are approved.
• ☐ Decision rights, risks, assumptions, dependencies, and funding boundaries are explicit.
• ☐ Business-user time is reserved for discovery, demonstrations, UAT, training, and launch.

Design and build

• ☐ Future-state processes include exceptions, controls, reporting, and ownership.
• ☐ Product, edition, add-on, package, and AI decisions trace to requirements and TCO.
• ☐ Data model, systems of record, integration catalogue, and security matrix are approved.
• ☐ Environment, source-control, peer-review, release, hot-fix, and documentation standards exist.
• ☐ Stories include security, error, data, reporting, test, and support criteria.

Data and integration

• ☐ Data disposition, keys, quality rules, mappings, owners, and reconciliation thresholds are documented.
• ☐ Trial migrations are repeatable and approved by business data owners.
• ☐ Interfaces have contracts, identities, retries, monitoring, reconciliation, and named error owners.
• ☐ Secrets are not stored in code, and integration users are not shared human accounts.

Validation and launch

• ☐ Configuration, code, integration, security, migration, performance, UAT, regression, and recovery needs are covered.
• ☐ Critical defects are closed or accepted by a named authority.
• ☐ Role-based training, manager reinforcement, job aids, support, and communications are ready.
• ☐ Cutover, validation, stop conditions, rollback, and communications have been rehearsed.
• ☐ Go/no-go authority and objective thresholds are explicit.

After launch

• ☐ Hypercare dashboards, triage, ownership, and exit criteria are active.
• ☐ Adoption measures track meaningful work and business outcomes, not only logins.
• ☐ A 30/60/90-day value review and release calendar are booked.
• ☐ Technical debt, architecture decisions, license usage, consumption, security, and data quality have owners.
• ☐ Legacy tools have approved retention, access, and retirement plans.

Frequently asked questions

Can a small business implement Salesforce without a partner

Yes, when the process is standard, data is manageable, integrations are limited, and someone can own administration and releases after launch. A short architecture, data, or security review can still reduce risk. Do not outsource business ownership.

How long does a Salesforce implementation take

A focused first release may take 6–12 weeks. Multi-team programs often take 3–6 months, while enterprise or multi-cloud transformations may take 6–18 months or longer. A credible commitment requires discovery of data, interfaces, approvals, testing, and cutover constraints.

Who should own user acceptance testing

The product or process owner should be accountable for UAT acceptance. Named business users are responsible for executing realistic scenarios. QA structures evidence and defect management, while the delivery team fixes defects and explains behavior.

Should all legacy data be migrated

Usually not. Move the information needed for active work, service, reporting, compliance, and approved history. Archive, retain, or delete other data under an approved policy. Every category needs an owner, retention rule, and access decision.

Is Flow always better than Apex

No. Flow is the strategic declarative automation tool and should be considered first when it remains understandable, testable, bulk-safe, and supportable. Apex may be the better choice for complex transactions, high volume, reusable services, or behavior that needs finer technical control.

Should Agentforce be in release one

Only when the use case is bounded, its data and knowledge are trustworthy, permissions follow least privilege, humans can supervise or receive escalations, representative tests and thresholds exist, monitoring is funded, and consumption is understood.

What happens after Salesforce goes live

The organization moves from project delivery to product operation. The platform owner runs support, releases, data quality, security reviews, adoption, license and consumption management, technical debt, architecture decisions, and value measurement.

How should implementation cost be estimated

Build a year-one model covering licenses, add-ons, implementation labor, data, integrations, custom work, environments, security, backup, training, change, post-launch operation, and contingency tied to identified uncertainty. The DGT27 Salesforce implementation cost guide provides a fuller model.

Final takeaway

A strong Salesforce implementation makes important decisions visible, assigns each decision to an owner, and produces evidence that the next person can accept. Discovery ends with an approved process and release boundary. Architecture ends with recorded trade-offs and control models. Migration ends with reconciliation. Launch readiness ends with test evidence and a rehearsed runbook. Adoption is shown by real work and business measures, not by login counts.

If a phase cannot show its deliverables, approver, and exit criteria, it is not complete. Build that evidence while the work is happening. The result will be more than a configured org: it will be a platform the business can operate, trust, and improve