Froodl

Salesforce CRM Consulting Services in 2026

Hire the Firm That Tells You Not to Build It

Ask a mature Salesforce customer what is limiting the return on their CRM, and the answer will often point to a missing feature. In many cases, the real problem is what is already there: 340 custom fields on the opportunity object, with only 60 carrying data; three automation frameworks running in sequence when a record is saved; eleven-page layouts that nobody maintains; and a permission model that has accumulated one exception after another.

This kind of accumulation is costly, but rarely shows up as a line item. Instead, it shows up in longer release cycles, admins leaving, conflicting reports, and a growing reluctance to make changes because no one is sure what might break. Salesforce consulting services that respond by adding more scope are addressing the symptom, not the cause.

The firm worth hiring in 2026 is the one that can look at the org and tell you what should be switched off. 

Complexity Is the Constraint, Not Capability

Salesforce has not lacked features for years. What many organizations lack is the ability to change the platform safely and at a reasonable pace. Complexity is what took that ability away.

The scale of the problem becomes clearer when you look at the broader enterprise estate. MuleSoft's benchmark research reports that organizations manage an average of 957 applications, with only 27% connected, while IT teams spend 36% of their time building and testing custom integrations. The same pattern appears inside the CRM. There is a great deal that has been built, but much less that remains connected to a business process people still use.

Three costs follow from this, and each makes the others worse.

Change cost rises because even a simple modification can require a dependency investigation. An admin who wants to remove a field may spend two days checking reports, automations, integrations, and page layouts that reference it. Eventually, the safer choice feels like leaving the field where it is.

Cognitive cost rises for users. Put 60 fields on a page when only six matter, and users learn to ignore most of them. That affects the quality of the data that downstream processes depend on. Salesforce research finds that only 53% of IT leaders fully trust their organization's data accuracy, and an overloaded CRM experience does little to improve that confidence.

License cost also grows quietly. Feature licenses and permission set licenses tied to abandoned projects can continue renewing long after the original project has been forgotten.

What Salesforce Consulting Services Should Do in the First 90 Days

A subtraction engagement should look different from a traditional implementation. The goal is not to create another build backlog. It is to create a retirement plan.

1. Inventory with telemetry: Review every custom object, field, automation, report, dashboard, permission set, and installed package. Pair that inventory with actual usage data from the past twelve months rather than relying on what someone remembers being used.

2. Map dependencies: Identify what references what, including references in integrations and Apex. This makes it possible to rank potential retirement candidates by how isolated they are and how much risk their removal carries.

3. Validate with the business: When usage is unclear, speak with the team that owns the process. Low usage does not always mean something is obsolete. A field used once a quarter may still be important.

4. Deprecate in stages: Hide the item from layouts first. Then remove it from reports, restrict access, and delete it only after an observation period. Each stage creates an opportunity to catch a dependency that was never documented.

5. Put a stop-accumulation policy in place: Define what must be true before anyone can create another field, object, or automation.

The fourth step matters because immediate deletion can quickly undermine confidence in the entire program. One broken quarter-end report is enough for people to conclude that cleanup creates more problems than it solves. Staged deprecation gives the organization a safer way to find dependencies that were missed.

The fifth step determines whether the cleanup lasts. An org that is cleaned without changing how new components are approved will start accumulating complexity again. The next cleanup will then require much of the same effort as the first.

Automation Layers Are the Most Expensive Debt

Objects and fields create visible clutter. Overlapping automation is often what creates the real delivery problem. 

Long-running Salesforce orgs can contain automation built across several generations of the platform. Add triggers and flows created by different people using different conventions, and a single record save can involve several layers of logic. Understanding the combined behavior means knowing how those layers interact and in what order they execute.

That makes even routine changes harder. Teams become cautious because they cannot easily predict what a change will affect. Defects then have a greater chance of reaching production because the full behavior is difficult to reason about during review.

Consolidation is not glamorous, but it can have a direct impact on delivery. Choose a single framework, document the order of operations, and migrate one object at a time. Write the test coverage before the migration, not after it.

The process will often uncover automation that has been failing quietly for months. Finding it is part of the value of the exercise.

There is also a result that finance and operations teams can measure: deployment lead time. Track it before and after consolidation. If a release that once took three weeks can be completed in six days, the value of the work becomes much easier to demonstrate.

Agentic AI Makes Subtraction Urgent

Complexity was once mainly a productivity problem. With AI agents operating inside the CRM, it can become a capability problem. 

An AI agent needs a predictable data model and a predictable execution path. If four automations can change the same field under different conditions, the agent may produce different outcomes depending on what else happens during the transaction. That makes organizations understandably reluctant to give the agent more authority.

The same issue appears in the data itself. If the same customer exists as three separate records, the agent may respond based on whichever record it finds. The problem is not the agent. The underlying CRM is not giving it a reliable foundation.

The commercial pressure to adopt these capabilities is growing. Gartner forecasts worldwide IT spending of $6.37 trillion in 2026, with IT services, including application implementation and managed services, exceeding $1.87 trillion. A meaningful share of that spending will go toward adding agentic capabilities to existing systems. Organizations that simplify their environments first will be in a better position to get value from that investment.

The sequence matters. Simplifying the data model, consolidating automation, and rationalizing permissions should happen before agent deployment. These are prerequisites, not separate workstreams. Salesforce CRM consulting that proposes agents without first addressing these issues is selling a demonstration rather than preparing the org for real use.

What Retirement Looks Like on a Real Object

Complexity is easier to understand when you look at a real object rather than an abstract list of recommendations.

Take an opportunity object with 340 custom fields. A usage query might show that roughly 60 fields were populated on more than half of the records created in the past year. Another 80 were used occasionally, while the rest were effectively empty. 

Dependency analysis gives that last group more detail. Some fields may still be referenced by a report that someone opens. A few may appear in Apex. Others may not be referenced anywhere.

The fields with no references should go first. Their removal carries little risk and immediately reduces clutter in page layouts and in the field creation dialogue that admins use every day.

The report-referenced fields require a conversation with the report owner. That conversation often reveals that the owner inherited the report and no longer uses it. Fields referenced in code take longer because their removal requires a code change and deployment.

That sequence highlights two important points.

First, progress is not linear. The easy half may account for most of the fields but only a smaller share of the actual problem. The fields tied to code and integrations are often the ones that continue to block change.

Second, usage data changes the conversation. A business owner may defend a field when asked about it in general terms. It is harder to defend when the data shows that it has been populated only four times in fourteen months.

The same approach works for reports, dashboards, permission sets, and installed packages. Salesforce CRM consulting services that bring usage telemetry into the first workshop can move the discussion away from opinions and toward evidence.

How to Buy Subtraction Without Buying Scope

The commercial model can make subtraction difficult to buy. Consulting revenue has traditionally increased with the amount of work delivered. A recommendation to remove work can therefore look like a recommendation to bill less.

That makes a firm willing to recommend removal worth paying attention to. It may indicate confidence in the longer-term relationship or simply a disciplined approach to consulting. Either is a positive sign.

Four questions can help buyers distinguish between firms.

Ask what the firm would remove first. Give them a two-hour look at the org and ask what they would target. A credible answer should identify specific object types, fields, or automation patterns. A vague response may indicate that the firm plans to discover the scope during a paid discovery phase.

Ask how they measure success. Deployment lead time, admin hours per change, license count, and field usage ratios are useful measures. The number of stories delivered is not a meaningful success measure for subtraction work.

Ask what happens to the fee if the assessment finds less work than expected. A salesforce consulting partner whose commercial model depends on a larger scope may have little incentive to recommend the smaller one.

Ask who actually performs the retirement. Some firms complete an assessment, produce a spreadsheet, and leave the client to carry out the difficult work. Confirm whether the engagement includes staged deprecation or only the recommendations.

There is another useful signal during the sales process. A Salesforce consulting firm that asks for read access to metadata and usage data before quoting is trying to understand the actual environment. A firm that relies mainly on a capability deck is more likely to apply a standard template.

The difference becomes clear after the engagement starts. A template eventually runs out of relevance. An evidence-based plan can continue identifying retirement candidates as the team works through the org.

Where Salesforce CRM Consulting Earns Its Fee

The strongest engagements should produce four measurable outcomes.

The first is a shorter change cycle. Deployment lead time is one useful measure, as is the number of changes an admin team can complete in a sprint without escalation.

The second is a smaller technical surface. That means fewer fields on the layouts users actually work with, fewer automations per object, fewer active permission sets, and fewer installed packages without a clear owner.

The third is a lower recurring cost. Retired feature licenses, reduced storage, and integrations that can be switched off all contribute to this.

The fourth is a documented estate. That may sound administrative, but good documentation reduces the time a new architect or admin needs to understand the environment and become productive.

A Salesforce consultancy services proposal should be able to say which of these outcomes it expects to affect and provide a reasonable estimate of the change. Vague statements about business benefits usually indicate that the current state was never measured.

Preventing Re-Accumulation

The cleanup is only half the job. Keeping the org clean requires a few simple practices that become part of normal governance.

Start with a creation standard. Every new field or object should have a named owner, a defined business process, and a review date. If those conditions are not met, it should not be created.

Next, establish a quarterly usage review. Generate a list of fields, reports, and automations that have seen no activity during the period and send it to their owners. Make retirement the default unless someone has a reason to keep the item. A review that requires someone to actively request removal will usually result in very little being removed.

Finally, introduce a change budget. Whenever a new automation is added to an object, review at least one existing automation for consolidation. The point is not the exact ratio. The point is to force the question at the time the new automation is introduced, rather than waiting two years for another cleanup project. 

A Salesforce consulting company that puts these practices in place leaves the client with something more valuable than a cleaned-up org. It leaves behind a way to prevent the same problems from returning.

Salesforce consulting services deliver the most value in 2026 when they remove what has accumulated instead of adding more to it. A simpler org is easier to change, costs less to maintain, and provides a safer foundation for the agents organizations want to deploy.

0 comments

Log in to leave a comment.

Be the first to comment.