Salesforce Implementation Best Practices, By Leverage

Most best-practice articles list ten items of equal weight. They are not equal. A handful of decisions made in the first three weeks control most of what happens afterwards, and the rest is good hygiene that matters far less than its position on the page suggests.

What follows is ordered by leverage: how much of the outcome each practice actually determines. Each one states the principle and points to where the mechanics live, because a practice you cannot execute is a slogan.

Decision rights set in week one control more than any other practice

Name one decision owner per workstream, with an agreed response window in business days, before any requirement is gathered.

This is first because it is the only practice that is free, immediate and compounding. Projects rarely fail at the decision itself. They fail in the queue in front of it, and queued decisions are invisible in a status report because every task shows as in progress while the team builds against assumptions that later reverse.

Measure it rather than assume it. Log every question requiring a business decision with the date raised and the date answered. Two weeks of that log gives you your organisation’s actual figure, and it is usually worse than anyone expects.

Data profiling precedes scope sign-off

Profile the source data before the object model is fixed, not after.

Migration carries the widest estimating variance of any workstream, and almost all of it comes from assuming quality rather than measuring it. Profiling early converts a mid-project surprise into a scoping decision made while the object model is still cheap to change. It is the single highest-return sequencing change available on most projects, and it costs an afternoon.

The narrow version is better than the thorough one. Profile the fields in scope for the process being built rather than the whole org, which turns a six-week exercise into a same-week one.

Ranked requirements enable design decisions

Collect requirements, then rank them, then close the phase. A list without a rank offers a design team nothing to trade.

This is why design workshops end without decisions and the same conversation repeats three times. Every design choice is a trade-off, and trading requires knowing which side is worth more. The phase-by-phase mechanics and the exit condition for each stage are in the plan and template.

Blocking checks differ from advisory checks

Decide which verifications stop the project and which can carry a documented gap.

A checklist where everything is mandatory gets abandoned the first time a project needs to move, and one where nothing is mandatory was decoration to begin with. Separating the two is what keeps verification enforceable, and it makes exceptions a recorded decision rather than a silent one. The full item list with completion tests is in the implementation checklist.

Agent scope and consumption belong in the contract

If agents are in scope, state which ones, and state who pays for the metered usage after go-live.

This practice did not exist three years ago and is missing from almost every template still in circulation. Agent actions are billed by consumption rather than by seat, so the cost continues after the project team leaves and grows with adoption rather than headcount. A client who discovers that after go-live remembers that nobody mentioned it. How the product layer and the delivery layer differ, and why they need separate treatment, is set out in the AI-first implementation guide.

Configuration and agents validate separately

Run user acceptance testing for the configuration and scored validation for the agents, with different owners and different sign-off criteria.

Conventional testing asserts an outcome and returns a pass. Agent behaviour is scored across quality dimensions, which means the release gate is an agreed threshold rather than a signature. Folding the second into the first produces a UAT cycle where business testers are asked to judge something no one gave them criteria for. The UAT mechanics live in the UAT guide.

The operating model precedes project closure

Establish who owns the backlog, the environments, the release calendar and the consumption trend before hypercare ends.

A project that delivers and leaves without handing over an operating model has stopped rather than finished, and the org begins accumulating debt in week one. This is the least glamorous practice on the list and the one that determines whether the implementation still looks like a success two years later. The handover items and the two lifecycles involved are covered in the implementation lifecycle guide.

Measure the org before changing it

For an existing org rather than a greenfield build, read the configuration before designing on top of it.

Allocation consumption per object, automation density and unused fields all change what is buildable, and finding out during build is expensive. This practice moves up the list sharply for any org more than three years old. The measurement approach is in the technical debt guide.

Practices ranked by what they control

Read the cost column. Six of the eight cost less than a week, which is the argument for doing them rather than debating them.

Salesforce best-practice advice goes wrong in six ways

For the specific ways implementations go wrong rather than the practices that prevent it, the failure patterns to avoid covers the diagnosis side.

Practice and the Salesforce platform meet at the release cycle

Salesforce publishes its own CRM implementation guidance, and it is worth reading alongside this because it describes the platform’s expected sequence. What it cannot tell you is which practices carry the most weight in your situation, since that depends on whether your org is new or ten years old, whether agents are in scope, and how fast your organisation makes decisions.

Agents apply high-leverage practices without a long programme

The first two practices are free and the rest are cheap, yet they are the ones most often skipped, because each requires someone senior to be present early rather than assigned later. That is the structural problem, and it is not solved by a better document.

GetGenerative.ai addresses it by putting a Forward Deployed Engineer alongside the decision owner from week one, with the agents handling the analysis and artifact work inside the pod so the senior time goes to the decisions rather than the documentation. If that division of labour is the part you are missing, the AI-native delivery team covers how the pods are structured.

Questions teams ask about Salesforce implementation best practices

What are the most important Salesforce implementation best practices?

Name decision owners in week one, profile source data before scope closes, and rank requirements rather than only collecting them. Those three cost almost nothing and control more of the outcome than any other practice on a typical list.

What is the Salesforce implementation methodology?

There is no single official methodology. Salesforce publishes a sequence, most partners run a variant of discovery, design, build, test and deploy, and the differences matter less than whether each phase has a defined exit condition and an owner.

Do best practices differ for an existing org?

Substantially. On an existing org, measuring the current configuration moves near the top of the list, because allocation limits, automation density and accumulated debt all constrain what can be built. On a greenfield build that practice does not apply at all.

How do best practices change when AI agents are in scope?

Two additions. Agent scope and consumption ownership belong in the contract, because metered usage continues after go-live. And agent validation runs as a separate track from user acceptance testing, because agent behaviour is scored against thresholds rather than passed.

Which best practice is most often skipped?

Establishing the operating model before the project closes. It has no deadline pressure attached, nobody is measured on it, and its absence only becomes visible months later when change requests have nowhere to go.

Is training a best practice or an afterthought?

It is the cheapest line to cut and the most expensive to skip, which is why it appears in every list and is missing from most plans. Adoption problems surfacing a quarter after go-live are almost always a training and change management decision made during a budget conversation