u/kloud_fusion

Not because it's bad at Salesforce.

Because it's getting really good at making changes to Salesforce.

“Just build a Flow for this.”

“Add an exception.”

“Make it update this other object.”

“Actually, add a field for that too.”

All of a sudden, the thing that used to take a developer half a day takes 20 minutes.

Which is great.

Until six months later when someone asks:

“Why does this Flow exist?”

And nobody knows.

I wonder if we're about to get really good at creating Salesforce technical debt faster than we're getting good at cleaning it up.

I don't mean what feature you like the most. I mean the feature your org has become so dependent on that removing it tomorrow would cause absolute chaos.

For some orgs, I'm guessing it's Flow.

For others, it might be reports, validation rules, Apex, a particular integration, or some ancient piece of automation that nobody wants to touch anymore.

It got me thinking about how much of Salesforce architecture is built around dependencies that aren't always obvious until something changes.

The scary part isn't necessarily losing the feature.

It's realizing how many other things were built around it.

What's the one Salesforce feature your org absolutely could not live without?

And if you've ever actually had something deprecated or removed, what happened?

Salesforce has changed a lot.

Flow has changed.

Profiles have changed.

Packaging has changed.

Even the clicks vs. code conversation isn't what it was five or ten years ago.

What's a piece of Salesforce advice that you think has outlived its usefulness?

"Well, this is going to be interesting."

Mine was finding three automations updating the same field.

What's yours?

Mine:

"I already changed it in Production." 🥲

I've inherited a few orgs where there's one custom object that nobody can really explain. Nobody remembers why it was created. Nobody knows what would break if it disappeared. The people who built it left years ago. Everyone is just afraid to touch it.

What's that object in your org?

A couple of comments on my last post caught my attention. One person said their sales reps mostly work through Claude. Another mentioned most of the interaction happens somewhere other than the Salesforce UI.
That would've sounded ridiculous a year or two ago.
But now I'm wondering if we're slowly moving toward a world where Salesforce is just the backend, while people work from AI assistants, Slack, Teams, Outlook, or whatever tool they're already in.
Not saying that's good or bad.
Just curious.
Are you seeing this happen, or is it still mostly hype?

I once saw someone keep an Excel sheet open all day because updating Salesforce "took too long."

They'd work entirely from Excel.

Then spend 20 minutes before going home copying everything into Salesforce.

At that point, Salesforce had basically become the nightly backup.

What's the most creative workaround you've seen?

I'll start.
The ones that are so restrictive users end up with an entire playbook of fake values just to get around them.

Required phone number? 123456789
Required email? test@testdotcom
Required reason? N/A

At that point, the validation rule is doing exactly what it was built to do and the data is somehow even worse.
What's the worst validation rule you've inherited?

Every CRM project I've been on seems to have a meeting where someone says, "We'll just migrate everything and clean it up after go-live."

I don't think I've ever seen that actually happen.

Once the system is live, everyone's attention shifts to adoption issues, bug fixes, change requests, and the next priority. Data cleanup quietly falls to the bottom of the backlog.

The funny part is that the migration itself usually isn't the hard bit.

The hard part is getting the business to agree on things like:

• Which duplicate account is the real one?
• Which contacts are still active?
• Who actually owns this customer now?
• Which custom fields are no longer being used?
• Which picklist values can finally be retired?

Those decisions are what make data clean, not the migration.

Maybe I've just been unlucky, but I can't think of a single project where a proper cleanup happened after go-live instead of before.

Has anyone here actually seen it work? If so, what made the project different?

That probably sounds backwards, but hear me out.

Leadership is great at explaining how the sales process is "supposed" to work. The people using the CRM every day are usually the ones who know how it actually works.

They're the ones who'll tell you things like:
- Nobody uses that field.
- We always export this report to Excel because it's easier.
- That approval process takes too long, so we just message the manager directly.
- Technically we're supposed to update the Opportunity here... but nobody does.

None of those are complaints to ignore. They're clues.

Most workarounds exist for a reason. Sometimes it's because the process changed and the CRM never caught up. Sometimes it's because the original design made sense on paper but not in practice.

I've found that one conversation with the people doing the work can uncover more useful information than hours spent reviewing process diagrams.

Has anyone else found that the biggest implementation insights came from end users rather than the people designing the process?

Something I keep running into: company buys Salesforce, hands it to IT, says "set it up."

Nobody sits down first to document how work actually happens versus how leadership assumes it happens.

And those two things are almost never the same. The sales process on the org chart and the sales process reps actually run are often barely related. Usually because someone found a faster way to get deals through 2 years ago and nobody ever updated the "official" version.

The workarounds are the part people skip past, and they're the most important part. If a rep is exporting to a spreadsheet at some stage, or looping in a manager over Slack instead of using the approval process that's "supposed" to be there, that's not laziness, that's a signal something in the designed process doesn't match reality. Build the CRM around the workaround-causing gap, not around the org chart version of the process.

Before locking in a build, this is worth documenting:

-What actually triggers a stage change (not what's supposed to trigger it)
-Every manual workaround currently in use, and why it exists
-Who actually touches the record at each stage, not who's listed as "owner"

Skipping this step is the single most common thing I see go wrong in the first 90 days of a CRM build.

For a mid-size sales team, this is maybe 1-2 weeks of legwork. Bigger or messier orgs, it's longer, but it's still cheaper than the rebuild you'll do without it..

Still surprises me how often it gets skipped in favor of just... building the thing.
Anyone else seen a "process" that only existed on paper?

Ran into this again last month and figured I'd write it up before I forget the details.

The trap with validation rules is that they fire before flows do. Sounds obvious once you say it out loud, but I don't think I actually internalized it until it broke something.

Here's what I've started doing differently:

-Map out where the validation logic actually lives; field-level vs record-level. Sounds basic but half the confusion comes from not knowing which one you're dealing with.

-Order matters. Figure out what triggers first before you go debugging blind.

-Document your exceptions. There are always exceptions. Always. Future-you will not remember why.

-Test with flow-created records, not just manual entry. This is the one that gets people — a rule can behave totally fine when a human fills out the form and then silently block automation.

Real example: we had a validation rule quietly blocking Salesforce from auto-updating a Status field through a flow. Took us 3 days to debug because nobody had documented that the rule even existed. Three. Days. For one field.

Quick formula example if you want a sanity check pattern:

AND(

ISCHANGED(Status__c),

NOT($Permission.BypassValidation),

ISBLANK(Reason_for_Change__c)

)

Basically, only fire if the field changed, the user/process doesn't have a bypass permission, and there's no reason logged. Worth noting: ISCHANGED() only fires on updates to existing records, not on creation, so this specific pattern is for catching automation quietly blocked on record updates, not inserts.

If you're running into weird blocking behavior on record updates and can't figure out why, this is probably why.

Anyone else have a validation rule that quietly wrecked an automation? Curious to know what your worst one was.

Been thinking about this after a recent project. We got the CDP-CRM sync working, data was technically unified, and... almost nobody used it. Turned out the real problem was never the "360" part, it was that sales and service still weren't entering consistent data to begin with. We ended up ripping out half the fancy stuff and starting with basic checklists instead.

Curious if this is just a me problem or if everyone's 360 view secretly looks like this behind the demo.

Not trying to start an Agentforce war here.

But every time I log into LinkedIn, watch a keynote, or read release notes, it feels like everything is AI now.

Meanwhile half the orgs I come across are still dealing with:

-duplicate records

-poor adoption

-flows nobody wants to touch

-reports nobody trusts

Maybe I'm just seeing a weird sample.

But if a company handed me $100k tomorrow and said "improve our Salesforce org", AI honestly wouldn't be the first thing I'd spend it on.

Would it for you?

Genuine question.

After working on quite a few Salesforce implementations, these five issues seem to show up over and over:

1. Over-customizing before understanding the business process:

Teams start creating custom objects, fields, and automations before they've fully mapped how people actually work. Six months later nobody wants to touch the setup.

2. Migrating historical data without cleaning it first:
Bad data doesn't magically improve when it enters Salesforce. It just ends up in reports, dashboards, and automation.

3. Building validation rules before the Flow strategy is finalized:
I've seen validation logic block automations and create problems that didn't need to exist.

4. Creating dozens of fields and picklists without thinking about reporting:
Everything seems fine until someone asks for a report and you realize the data isn't nearly as consistent as you thought.

5. Not documenting formulas, Flows, and automation logic:
Six months later someone asks why a field exists, and nobody knows.

Most of these don't hurt in month one.

They show up later when reporting becomes unreliable, adoption drops, and people get nervous about making changes.

What would you add to the list?