The 80/20 of Salesforce: The 20% of Features That Deliver 80% of Value

A few years ago I sat through a roadmap workshop where the leadership team spent the better part of an hour arguing about which AI add-on to buy next. Einstein scoring, a chatbot, some predictive thing a vendor had demoed the week before. Nobody in the room could tell me what share of their open Opportunities had a Close Date that meant anything, or why 23 of their validation rules had been switched off during a data load in 2019 and never switched back on.

That is the most expensive pattern I see on Salesforce. Not bad code — appetite. The appetite for the glamorous 80% of the feature catalogue while the 20% that actually carries the organisation sits neglected. After fifteen years on the platform I've become fairly ruthless about this. A small set of unglamorous capabilities delivers most of the value, and almost everything else is noise you pay a licence fee to ignore.

The Feature Catalogue Is Not a Roadmap

Salesforce ships hundreds of features and markets all of them as essential. They are not. Most orgs I walk into are using a fraction of what they've paid for, and the fraction they lean on hardest is almost always the plain stuff: fields, validation, a few automations, reports, and a security model that hasn't been touched since go-live.

I worked with a retailer, roughly 400 users, who had bought a CPQ add-on eighteen months earlier and never rolled it out. The reason was mundane. The product data underneath it was wrong — inconsistent units, duplicate SKUs, price book entries nobody trusted — so every quote came out broken and the sales team quietly went back to spreadsheets. Meanwhile, the thing their state managers actually opened at 8am every morning was a single list view an admin named Priya had built in an afternoon, filtered to "my region, open, closing this month." That list view was doing more real work than a six-figure add-on.

The lesson has stuck with me. The value of a feature is not what it can do in a demo. It is what people open every day and trust. Optimise for that, and most of the catalogue becomes optional.

Data Integrity Is the Feature Nobody Demos

If I could keep only one category of capability on the platform, it would be the boring machinery that keeps data honest: required fields, validation rules, duplicate rules, and a data model that reflects how the business actually works. None of it demos well. All of it compounds.

A validation rule that stops a rep closing an Opportunity for zero dollars is three lines of formula and pays for itself the first time it fires:

AND(
  ISPICKVAL(StageName, "Closed Won"),
  OR( ISBLANK(Amount), Amount <= 0 )
)

That is the whole thing. No project plan, no vendor, no model to train. And yet the amount of downstream pain it prevents — forecasts that don't reconcile, commission runs that need manual patching, executives who stop trusting the numbers — is enormous. I have never once regretted adding a validation rule. I have regretted plenty of the clever automation I built instead of one.

The data model sits underneath all of it. Get the objects and relationships right and everything above them gets easier; get them wrong and no feature on the platform can save you. This is also why I treat a migration as an architecture exercise rather than a data-loading exercise — most of the value, and most of the risk, is in the shape of what you bring across, not the tooling that moves it. I've written the honest version of that elsewhere in the data migration playbook, because it's the part teams consistently under-resource.

Reports and List Views Are the Product

For most users, Salesforce is the reports and list views. The record pages are where data goes in; the reports are where the organisation looks at itself. And the reports leadership actually depends on are almost never sophisticated. They are a filter and a grouping.

The pipeline view every sales director I've met wants is functionally this:

SELECT Owner.Name, StageName, COUNT(Id) deals, SUM(Amount) pipeline
FROM Opportunity
WHERE CloseDate = THIS_QUARTER
  AND IsClosed = false
GROUP BY Owner.Name, StageName
ORDER BY Owner.Name

A grouping and a sum. That's it. No predictive scoring, no dashboard component library, no AI narrative summary. When someone tells me their reporting is failing them, the problem is almost always upstream — the Amount field is blank on half the records, or the Stage picklist has drifted so far that "grouping by stage" is meaningless. Fix the data (see above) and the reports fix themselves.

My rule of thumb: before anyone proposes a new analytics product, I want to know which existing reports get opened and by whom. Nine times out of ten the answer reveals that the organisation is running on four or five reports and could delete the other two hundred without anyone noticing for a month.

A Clean Security Model Compounds Quietly

Security is squarely in the valuable 20%, and it's the part most orgs let rot. A coherent permission model is invisible when it works and catastrophic when it doesn't, which is exactly why it never makes the roadmap until an auditor or a breach puts it there.

The compounding is real. Every clean permission set you build is one you can compose and reuse; every profile someone clones "just for this one team" is a future spreadsheet nobody trusts. I've walked into orgs with 25-plus profiles that were supposed to be identical and had quietly drifted apart over years of ad-hoc changes. Untangling that is slow, unglamorous work, and it's some of the highest-leverage work you can do — which is the whole argument for moving from profiles to permission sets before the mess gets any larger. It is one of those things that only gets harder the longer you wait.

You will never get budget approved for "tidy up the permission model." You should do it anyway, in the margins of normal delivery. It sits under everything.

Restraint Is an Architecture Decision

Here is the opinion that gets me the most disagreement: most of the automation in a mature org belongs in the 80% you could delete. Not because automation is bad, but because it accretes. Every quick fix becomes a Flow, every Flow becomes a dependency, and five years later nobody can change a field without something firing three subsystems downstream.

On one org I traced actual executions across a month and found that 47 of their active Flows had never fired at all. They weren't doing anything — they were just risk sitting on the object, waiting to interact badly with the next change. Deleting them was the single most valuable "feature work" we did that quarter, and it shipped nothing.

The other side of restraint is not rebuilding what the platform gives you. This is the kind of thing I find and delete:

// A "rollup" someone hand-rolled: SOQL inside a loop,
// recalculating a total the platform can maintain for you.
for (Account acc : scope) {
    AggregateResult ar = [
        SELECT SUM(Amount) total
        FROM Opportunity
        WHERE AccountId = :acc.Id AND IsWon = true
    ];
    acc.Total_Won__c = (Decimal) ar.get('total');
}

That is a governor-limit fault and unnecessary complexity in the same eight lines — a query per account, guaranteed to fall over on a bulk update. The valuable version does less: one grouped query, or a declarative rollup, kept boring on purpose. When there genuinely is complex orchestration to own, I put it behind a trigger framework that actually scales so the complexity lives in one predictable place rather than scattered across forty Flows. The framework is a safety net, not a mandate. The default should always be to build less.

When the Boring 20% Isn't Enough

I want to be honest about where this thinking breaks, because "just do the fundamentals" can curdle into an excuse to never build anything ambitious.

The 80/20 lens is a prioritisation tool, not a ceiling. There are organisations where the genuinely differentiating capability is in the other 80% — a real-time integration that is the product, a pricing engine that no declarative feature can express, an experience layer that a competitor doesn't have. If the fundamentals are already solid, chasing that edge is exactly right. The mistake is only ever sequencing: reaching for the differentiating 80% while the load-bearing 20% is still broken underneath it.

And sometimes you don't get to be disciplined. On that retailer project we didn't fix the product data properly. We patched the worst of it, shipped a data-quality dashboard so at least the mess was visible, and moved on because the CPQ rollout couldn't wait another quarter. Two years later the underlying model is still wrong and still on the technical debt list. It's been working well enough that everyone has stopped asking, which is its own kind of answer.

What I'd do differently is spend the fundamentals budget earlier, when it's cheap, rather than retrofitting it under a deadline. If you want a second pair of eyes on which 20% is actually carrying your org, that's the kind of review I do — usually it takes an afternoon to find, and a lot longer to talk anyone out of buying the next add-on instead.

The orgs that thrive on this platform are rarely the ones with the most features. They're the ones where the boring 20% is genuinely solid, so the exciting work has something to stand on. Everyone wants to build the differentiating layer. Almost nobody wants to first make the data honest — and that, far more than any feature you can buy, is the difference between an org that compounds and one that quietly grinds to a halt.