Photo: Towfiqu barbhuiya / Unsplash
Many Salesforce orgs are not broken, they are just hard to use: too many fields, dashboards nobody believes and automation built by several admins over several years. Optimization makes the system simpler and more useful without a full rebuild.
Salesforce optimization is the work of improving an existing org so people use it and trust its data. It usually covers simplifying page layouts and processes, cleaning duplicate and incomplete data, consolidating automation, rebuilding reports and dashboards, and training users on the changes. It differs from rescue, which deals with projects that never worked.
Login, usage and field-completion data plus interviews to see where people avoid the system and why.
Leaner page layouts, fewer required fields and processes that match how teams actually work.
Deduplication, standardization and validation rules to keep data clean going forward.
Old workflow rules and Process Builder moved into maintainable Flows, with conflicts removed.
Reports and dashboards rebuilt around the numbers leaders actually use.
Short, role-based training on what changed.
What happens in each phase, what you get at the end of it, and what we need from your team.
We establish a baseline before touching anything. That means pulling login history, record creation by user, field fill rates on key objects and the age of open opportunities or cases. We sit with a few reps, service agents or managers and watch them work a real record, noting every workaround and every tab they open outside Salesforce. Meanwhile an architect catalogs automation by object and checks which reports feed the dashboards leadership reviews each week.
Findings get scored on two axes: how much friction or reporting error each one causes, and how hard it is to change safely. Hiding unused fields or fixing a picklist is cheap and visible, so those go early. Merging duplicate accounts or retiring a legacy trigger needs planning, so those get sequenced with testing time. We also agree on a small set of metric definitions, like what counts as an active opportunity, before any report gets rebuilt.
Changes are built in a full or partial copy sandbox so testing uses realistic data. Layouts get rebuilt per role with Dynamic Forms where it helps, stages and picklists get consolidated, and duplicate records are merged with rules that keep the right owner and history. Overlapping workflow rules and Process Builders are migrated into Flows one object at a time, with regression tests after each so nothing that quietly worked before stops working.
Changes reach users in planned batches with a short explanation of what is different and why. Training is by role and uses their own records, so a rep sees their pipeline in the new layout rather than a demo. For several weeks after each release we watch the same usage signals captured at the start and compare them to the baseline, then adjust anything that still causes people to leave Salesforce for a spreadsheet.
The same work can be a small project or a large one. These are the factors that decide which.
| Factor | Keeps effort down | Raises effort |
|---|---|---|
| Duplicate and dirty data | A few thousand records with obvious duplicates that matching rules can merge cleanly. | Hundreds of thousands of records, conflicting owners and duplicates spread across accounts, contacts and leads. |
| Layers of legacy automation | A few workflow rules on one or two objects that map neatly to a Flow. | Workflow rules, Process Builders, triggers and Flows all firing on the same object in unknown order. |
| Agreement on definitions | Leadership already agrees on stages, lead status and what counts as pipeline. | Each region or team defines a qualified lead differently, and every report reflects a different version. |
| Number of user roles | One sales team with a single sales process and shared page layouts. | Inside sales, field reps, channel partners and service agents each needing distinct layouts and training. |
| Reports tied to other systems | Dashboards built only on Salesforce data with standard report types. | Metrics that blend Salesforce with ERP or billing data through integrations or Tableau. |
| Appetite for removing things | Leaders are willing to retire fields, stages and reports nobody has touched recently. | Every field has a defender, so each removal needs evidence, sign-off and an archive plan. |
We price from a written scope after discovery, so these factors are what we ask about first.
When reps skip Salesforce, the instinct is to add required fields or validation rules to force data in. That usually produces junk values and more resentment. Adoption improves when the system asks for less and gives more back, such as a pipeline view reps would build themselves or a call log that saves them a step later.
A new dashboard on top of duplicates and inconsistent stages simply displays the same wrong numbers in a nicer layout. Leaders notice quickly and trust drops further. Clean and standardize the underlying records first, lock in definitions, and only then build the charts, so the first impression of the new reporting is one of accuracy.
Converting each old workflow rule or Process Builder into its own Flow keeps all the original overlap, just in a newer tool. Several automations still fire on the same save and still fight each other. Consolidating means reading what each one does, merging logic per object and deleting what no longer serves a purpose.
Optimization changes behavior, and behavior slips back when nobody is watching. If usage is not measured against the original baseline after release, old spreadsheets quietly return within a quarter. Keep tracking the same signals for a while after re-launch, and assign someone to act on what those signals show.
Optimization sits between a light admin refresh and a full rebuild, so partners pitch it very differently. Some propose a long assessment with no fixes, others start changing things on day one. Asking how they measure, decide and prove results reveals whether you are buying an improvement or just activity.
Written by the consultants delivering the work.
How to get people to actually switch to Salesforce: stakeholder mapping, the sponsor's real job, early user involvement, manager enablement, policies and their risks, handling resistance and reinforcement.
Read the full post →The usual causes are a system that asks for more data entry than it gives back, layouts built for managers rather than users, and dashboards that do not match what reps see. One manufacturer we worked with had overcomplicated its org through several admins; after streamlining it and integrating NetSuite, all 99 reps were active within 30 days.
Usually not. Most orgs can be simplified in place. A rebuild only makes sense when the data model itself is wrong for the business, which a health check will tell you.
Start with the data underneath: duplicates, missing values and inconsistent stages. Then rebuild reports around agreed definitions. A staffing firm we worked with went from broken dashboards to accurate per-rep activity visibility this way.
Optimization is a defined project with a start and end. Managed services is ongoing. Many clients do an optimization project first and then keep improving through managed services.
Pick a few signals tied to the original problem and capture them before any changes. Common ones are active users by role, opportunities updated in the last week, completion of the fields leaders rely on and the number of duplicate records created. Pair those with a simple check: are leadership meetings running from Salesforce dashboards or from exported spreadsheets? If the numbers improve but the spreadsheets persist, there is more work to do.
Sometimes. An org review often finds inactive users still holding licenses, add-on products nobody configured and third-party apps that duplicate native features. We report those alongside the adoption findings so you can decide what to reclaim or activate. The main value of optimization is usually better use of what you already have, though, so treat license savings as a possible side benefit rather than the reason to start.
Not from scratch. Most changes remove clutter or reorganize what people already see, so the core of their routine stays familiar. We release changes in batches, explain each one in plain terms and train by role on live records. Users usually notice that pages load with fewer fields, reports match what they expect and fewer steps are needed to log an activity or update a deal.
Often they do, because visibility shapes habits. A building-products manufacturer we worked with set up an automated weekly scorecard that emailed each rep their own numbers every Friday. It eliminated 1-2 hours of manual weekend reporting and drove healthy competition once reps could see each other's activity. Reporting that reflects individual effort gives people a reason to keep their records current.
Only where it blocks the goals of the project. Small model changes, such as replacing a free-text field with a picklist or adding a lookup that reports need, fit well inside optimization. Restructuring core objects, like splitting how accounts represent parent companies and locations, touches integrations and history and usually needs its own plan. A health check beforehand helps decide which kind of change you are facing.
A Salesforce Health Check reviews your org and gives you a ranked list of what to fix first, with effort estimates. It is the right starting point before an optimization project, a new cloud or an AI initiative.
Headquartered in St. Louis, working with companies across the U.S.
Request a Salesforce assessment →Tech Talk
A monthly brief for the people who own Salesforce, AI and revenue technology
What changed in Salesforce and AI this month, and what to do about it.
One email a month. Written by the consultants who deliver the work, not by a marketing team, for the leaders who make the technology decisions.
Consultant analysis, not vendor recaps. One click to leave.