Common mistakes to avoid during Salesforce deployment
Salesforce deployments tend to slip for the same reasons, whatever the size of the organization. The good news is that most of these problems are visible weeks in advance if you know where to look.
1. Requirements that describe screens, not outcomes
“Add a checkbox for approval” is a solution, not a requirement. When requirements describe what the business needs to achieve, such as “managers must approve discounts above 15% within one business day,” the team can choose the right design and test it properly. Ask “what decision or outcome does this support?” for every request.
2. Underestimating data migration
Migration is usually the riskiest part of a deployment and the most often scheduled last. Legacy data contains duplicates, missing values and formats that don’t match the new model. Start profiling and cleaning data early, run at least two full trial loads in a sandbox, and reconcile record counts and key totals before cutover.
3. Skipping a realistic sandbox strategy
Building and testing in the same environment, or testing with a handful of sample records, hides problems until production. Use separate environments for development, integration and user testing, and test with realistic data volumes so performance and sharing issues surface early.
4. Automation that overlaps
When workflow rules, process builders, flows and triggers all act on the same object, the order in which they run becomes unpredictable. Records update twice, emails send three times, or limits are hit under load. Map every automation per object before go-live and consolidate where possible.
5. Treating user acceptance testing as a formality
UAT is where real users find the gaps between how a process was described and how it actually works. Give testers written scenarios based on their daily work, enough time to complete them, and a clear way to log issues. Decide in advance which issues block go-live and which can follow in a later release.
6. Training too late, or too generic
A single all-hands demo the week before launch rarely changes behavior. Role-based training, short reference guides and in-app help for the first few weeks make a far bigger difference. Identify a champion in each team who can answer everyday questions.
7. No plan for the day after go-live
Launch is the start of operation, not the end of the project. Plan a hypercare period with the build team available, a simple way for users to report issues, and a backlog for improvements. Track adoption from the first week so small problems don’t become workarounds.
Before you set a go-live date
- Requirements are written as outcomes and signed off.
- Data has been loaded in full at least twice, with reconciliation.
- Automation is mapped per object, with no unexplained overlaps.
- UAT scenarios are complete and blocking issues are resolved.
- Training, support contacts and a hypercare plan are in place.
If any of these is still open, the date is a hope rather than a plan.