Small admin decisions compound. A sharing rule set too broadly, a validation rule added without testing edge cases, a permission set built for convenience instead of least privilege — none of these look expensive on day one. Two years later, they show up as security exposure, failed audits, or a boardroom conversation about why the numbers in three different reports don’t match. Here are five configuration mistakes I see most often in enterprise orgs, what they actually cost, and how to catch them before they compound.
1. Over-permissioned profiles instead of permission sets
The path of least resistance when someone needs access to one more field or object is to widen their profile. It works immediately, and it’s invisible until an audit — or an incident — forces someone to explain why a support rep can edit opportunity close dates.
Impact: security exposure that scales with headcount, and audit findings that take weeks to unwind because nobody can say confidently who has access to what, or why.
Fix: build a least-privilege baseline profile for each user type, then layer access on top with permission sets. Permission sets are additive, auditable, and — critically — easy to revoke without touching a profile that dozens of other users depend on.
2. Validation rules that silently block legitimate edge cases
A validation rule that made sense for the 95% case gets rolled out org-wide, and the 5% of legitimate exceptions — the enterprise deal with an unusual approval path, the record migrated from a legacy system with a null field — get stuck. Users don’t file a ticket; they find a workaround. They enter a placeholder value, or they stop using the field, or they route around Salesforce entirely for that transaction type.
Impact: data quality gets worse, not better, because the rule punishes the exception instead of handling it — and the org loses visibility into exactly the edge cases that most need visibility.
Fix: test validation rules against real historical edge cases, not just the happy path, before activating them org-wide. If an edge case is rare but legitimate, build an explicit exception path rather than letting users find their own.
3. Automation logic duplicated across Flow, Process Builder, and legacy workflow rules
Most enterprise orgs older than a few years have automation logic spread across three or four different tools, added by different people at different times, with no documented execution order. When something breaks, debugging means reconstructing which of four systems fired first — and that reconstruction usually happens under pressure, during an incident, not calmly during a planning cycle.
Impact: unpredictable execution order, duplicate field updates, and a debugging process that costs hours for problems that should take minutes to diagnose.
Fix: consolidate to Flow — Salesforce’s own direction of travel — and document execution order explicitly, including which automations are expected to fire in sequence and why.
4. Sharing rules layered on ad hoc, without a documented model
Sharing rules accumulate the same way automation does: one exception at a time, each one reasonable in isolation, until nobody can explain the aggregate. "Why can this user see that record?" becomes a question that takes an afternoon to answer instead of a lookup.
Impact: a support and compliance burden that grows every quarter, and — worse — a real risk that sensitive records are visible to people who shouldn’t see them, discovered only when it’s already a problem.
Fix: design the sharing model as a single documented decision — who owns what, and why — rather than a series of one-off exceptions layered on top of each other.
5. Reports and dashboards built on inconsistent field definitions across teams
Sales defines "closed-won revenue" one way. Finance defines it slightly differently, for good reasons specific to their process. Nobody wrote either definition down, and both teams built dashboards against their own version. Six months later, a leadership review surfaces two different revenue numbers for the same quarter, and the meeting becomes about reconciling data instead of making decisions.
Impact: decisions get made on numbers nobody fully trusts, and every cross-functional reporting conversation starts with a reconciliation exercise instead of analysis.
Fix: agree on field definitions and a single reporting data source before building dashboards — not after two teams have already built competing versions.
The pattern
None of these five mistakes are dramatic on their own. Each one is a reasonable shortcut taken under normal delivery pressure. The financial exposure isn’t in any single decision — it’s in the compounding: two years of small shortcuts add up to an org nobody fully trusts, where every change is riskier than it should be and every report needs a caveat. Catching these early is cheaper than any audit finding.
If any of this sounds like your org, a 30-minute call is usually enough to tell you which of these five you’re dealing with — and roughly what it takes to fix.