Salesforce admin work in 2026 looks nothing like it did five years ago. You're managing more automation, more integrations, and more data volume — while your org accumulates technical debt faster than you can clear it.
The result: most orgs carry at least two or three categories of systemic problems right now. Not edge cases. Patterns that show up consistently across hundreds of org diagnostics: Flows with no fault paths running silently in production, duplicate records corrupting pipeline reports, permission sets that should have been cleaned up two org cycles ago.
This guide gives you a systematic troubleshooting framework across the five categories where org problems accumulate: Flow errors, duplicate records, permission hygiene, validation rule conflicts, and unused schema. Work through each section in order or jump to the category causing you pain right now.
1. Diagnosing Salesforce Flow Errors
Flow errors are the most dangerous category of org problems because they fail silently. A broken Flow doesn't throw a banner in Salesforce — it logs to the Flow Interview object, sends an email to the running user (which is often a system account nobody monitors), and continues. Nobody knows until a deal doesn't close or a case doesn't route.
How to find Flow errors in your org
Start with the Flow Interview log. In Setup, navigate to Environments → Logs → Flow Interview Log. Filter by Status = "Error" for the past 30 days. Sort by LastModifiedDate descending. Any Flow that appears here more than twice in a week is a recurring failure — not a one-off.
For programmatic access, run this SOQL in Developer Console:
Quick SOQL: Find failing Flows in the last 30 days
SELECT FlowVersionViewId, InterviewLabel, StartInterviewTime, CurrentElement, ErrorMessage FROM FlowInterview WHERE Status = 'Error' AND StartInterviewTime = LAST_N_DAYS:30 ORDER BY StartInterviewTime DESC LIMIT 200
The CurrentElement field tells you exactly which element caused the fault — that's where your missing fault connector is.
The three most common Flow failure patterns
- Missing fault paths on Update/Create elements — Record creates and updates can fail due to validation rules, duplicate rules, or required field violations. Wire a fault connector to every element that writes data.
- API callout timeouts with no retry logic — External service callouts have a 10-second timeout. Without a fault path, a slow third-party API silently breaks your entire automation chain.
- SOQL inside loops hitting governor limits — Flows that query inside a loop will eventually hit the 100-SOQL-per-transaction limit. Bulkify by collecting IDs first, then running a single query outside the loop.
Once you've identified failing Flows, the fix is usually straightforward: add a fault connector from each risky element to a dedicated error-handling subflow or screen that displays a user-friendly message and logs the failure.
2. Detecting and Merging Duplicate Records
Duplicate records are a slower-moving problem than Flow errors, but their impact on reporting and forecasting is more severe. A sales leader running a pipeline report doesn't know whether the 47 "Acme Corp" accounts represent 47 real opportunities or 12 real ones with 35 duplicates. That ambiguity breaks confidence in Salesforce data — which breaks adoption.
How to detect duplicates systematically
The first step is understanding your duplicate landscape before you start merging anything. Run a SOQL GROUP BY query to find obvious email-based contact duplicates:
Quick SOQL: Find Contact duplicates by email
SELECT Email, COUNT(Id) cnt FROM Contact WHERE Email != null GROUP BY Email HAVING COUNT(Id) > 1 ORDER BY cnt DESC LIMIT 100
This surfaces your worst-offending email addresses. Run separately for Account (by Name + BillingCity) and Lead (by Email + Company) to get a full picture.
Native Salesforce Duplicate Rules and Matching Rules handle prevention going forward, but they don't clean up what's already there. For existing duplicates, you have three options: the native Merge tool (manual, one pair at a time), Data Loader + a deduplication script, or a third-party tool that can batch-merge with field-level winner selection.
Merge strategy before you touch data
Before merging anything in production, establish which record wins on a field-by-field basis. The rule of thumb: keep the record with the most recent LastModifiedDate as the master, then copy over the oldest CreatedDate from the losing record so you don't lose attribution history. Always run a merge in a sandbox first with a representative sample — merged records can't be unmerged natively.
- Enable Duplicate Management in Setup to prevent net-new duplicates from entering
- Set Matching Rules to Alert (not Block) initially — blocking creates user friction before you've cleaned existing data
- After bulk merge, run the duplicate report again to validate reduction rate before switching rules to Block mode
3. Auditing Permission Sets and Profiles
Permission sprawl is the most underestimated security risk in Salesforce administration. Orgs accumulate permission sets over years of projects — each one created for a specific initiative, assigned to a handful of users, and never revisited when the initiative ends. The result is a permission model that nobody fully understands, with access nobody explicitly intended to grant.
The permission audit workflow
A permission audit has three phases: inventory, rationalization, and cleanup. Start with inventory — you can't rationalize what you haven't mapped.
Use the Permission Set Usage report in Setup to see which permission sets have zero assignments. These are your first targets. Then query for sets with five or fewer assignments and review each one manually — most can be merged into a broader set or deprecated entirely.
Key signals of permission sprawl
These patterns indicate over-granting that needs rationalization:
- Profiles with "Modify All Data" assigned to non-system-admin users
- Permission sets granting View All on multiple objects (often legacy data migration sets)
- Zombie profiles — profiles assigned to 0 active users but still carrying field-level security overrides
- Permission set groups that duplicate profile permissions rather than extend them
The rationalization phase involves grouping permissions by job function rather than by project. Every permission a user needs should come from their profile (baseline) or one permission set group (role-specific extension). If a user has more than three standalone permission sets, that's a signal the model is fragmented.
Cleanup: before revoking any permission set, query for its current assignments and cross-reference against active users. Never remove a set without first confirming with the assigned users' managers that the access is no longer needed.
4. Resolving Validation Rule Conflicts
Validation rule conflicts are one of the most common sources of user support tickets — and one of the hardest to diagnose without systematic tooling. A rule that makes perfect sense in isolation can break a critical workflow when combined with other rules, required fields, or Flow-driven record updates.
The most common conflict pattern: a validation rule fires on a record update that was triggered by an automation, not a user. The automation is updating field A, the validation rule checks field B (which the automation didn't touch), and the rule fires because B happens to be empty or in the wrong state. The user sees an error that has nothing to do with what they did.
How to map your validation rule landscape
For each object with validation rules, export the full list: rule name, active/inactive status, error condition formula, and error location (field-level vs. top of page). Look for rules that reference the same fields — these are conflict candidates. Pay particular attention to rules that use ISCHANGED() or PRIORVALUE() without also checking $Profile.Name or $Permission to allow system-triggered updates to bypass them.
- Deactivate rules one at a time to isolate conflicts — never deactivate a group simultaneously
- Test in a sandbox with representative records before making any change in production
- Add a $Profile.Name = 'System Administrator' bypass clause to rules that shouldn't fire for automation users
- Document the business requirement behind each rule — rules without documented requirements are candidates for removal
The bypass pattern that prevents automation conflicts
For any validation rule that should only apply to user-triggered saves (not automation), wrap the error condition:
AND(NOT($Profile.Name = 'System Administrator'), NOT($Permission.Bypass_Validation_Rules), [original condition])
Create a custom permission Bypass_Validation_Rules and assign it to the integration user profile. This lets automations write records cleanly while keeping the rule active for all human users.
5. Cleaning Up Unused Custom Fields
Unused custom fields are the administrative equivalent of technical debt that nobody talks about until it causes a real problem. They slow down page load times. They clutter page layouts. They confuse users who wonder why a field exists. And they make migrations significantly more complex when you eventually need to move or restructure data.
Identifying unused fields
Salesforce doesn't expose field-level usage data in a single native report, but you can triangulate from multiple signals: Field History Tracking, report column usage, and the Field Usage by Object report in the Optimizer tool.
The most reliable signal: if a field has no Field History Tracking, appears in zero reports in the last 90 days, is on zero active page layouts for active profiles, and has a null rate above 95%, it is almost certainly unused. That combination rarely has a legitimate counterexample.
- Never delete a field immediately — set it to inactive on page layouts first and monitor for user complaints for 30 days
- Check for formula fields that reference the candidate field before deleting — Salesforce will warn you, but it's better to find dependencies proactively
- Export field values to a CSV backup before deletion in case the data is needed for historical audits
- Batch deletions in groups of 10–20 fields per cycle, not hundreds at once
Building a Repeatable Troubleshooting Cadence
One-time diagnostics are useful. A recurring cadence is what separates well-maintained orgs from ones that accumulate years of compounding debt. The goal is to catch problems in the "warning" stage — before they become incidents.
A practical cadence for most orgs:
- Weekly: Review the Flow Interview Error log. Any new recurring errors get a ticket and an owner. Five minutes, every Monday.
- Monthly: Run duplicate detection on Contact and Account. Review newly created permission sets and validation rules. Check for Flows modified in the last 30 days without corresponding test coverage.
- Quarterly: Full permission set audit — map assignments against active users, deprecate unused sets, review zombie profiles. Field usage report — flag fields with 95%+ null rate for the 30-day monitoring window.
- Before each Salesforce release: Run a full org diagnostic. Major releases surface hidden problems in validation rules and Flow behavior. A pre-release diagnostic gives you time to fix issues before they hit users.
The single metric that predicts org health
If you can only track one number, track your Flow error rate — the percentage of Flow interviews that end in an error state. Healthy orgs keep this below 0.5%. When it crosses 2%, something systematic is broken, not just a one-off failure.
A rising Flow error rate is almost always the leading indicator of a broader org health problem: schema changes that weren't propagated to all Flows, a new validation rule that's blocking automated updates, or a third-party integration going unstable.
The admins who keep orgs clean aren't spending more time on maintenance — they're spending less, because they catch small problems before they become emergency escalations. A 30-minute weekly review replaces a 3-day incident response.
If you're starting from a position of accumulated debt across multiple categories, prioritize in this order: Flow errors first (they break users' work in real time), duplicate records second (they corrupt reporting), permission hygiene third (security exposure that's harder to quantify but real), then validation rules and field cleanup on a rolling basis.
Get the Full Benchmark Report
See how your org compares to 400+ others across every troubleshooting category — data quality, flow health, permissions, and more.