I once got a midnight call from a sales manager: reports stopped, leads vanished from queues, and the team could not close deals. I felt the pressure—downtime was costing the business real money and the customer experience was at risk.
I dug into the system and used Setup diagnostics, Login History, and validation logs to find the root cause quickly. That approach let me separate harmless quirks from showstoppers.
In this guide, I explain how platform limits (SOQL/DML caps, heap and CPU thresholds) and messages like FIELD_CUSTOM_VALIDATION_EXCEPTION or System.LimitException map to practical fixes. I show how to bulkify code, avoid DML in loops, and use selective queries so your org stays healthy.

Key Takeaways
- I prioritize fixes that unblock revenue-driving business processes and protect customer outcomes.
- Built-in diagnostics help surface actionable information fast, so you don’t guess.
- Watch for validation failures, permission gaps, non-selective queries, and governor limit breaches.
- Bulkify logic, use batch or queueable processing, and avoid queries or DML inside loops.
- Document changes, preserve data integrity, and verify the system end-to-end before rollout.
What I watch for first: high-impact symptoms that signal a real problem
The first thing I look for is whether a live business process has stopped working for people right now. Quick checks save time and surface the issues that actually block value for the team.
Broken business processes and stalled user operations
I ask whether a user can’t create or update a record, or if a rep cannot complete a sale. When a critical operation is blocked, I treat it as urgent.
Login denials from wrong passwords, IP range blocks, or restricted login hours show up in Login History and are an easy example to verify fast.
Data integrity warnings vs. system exceptions
I separate save failures caused by validation rules from platform exceptions like System.QueryException or System.SObjectException.
Validation messages mean the data needs correction. Platform exceptions point to design or code problems and often require refactoring to avoid governor limit issues like Too many SOQL queries.
I run a few light checks—try another browser, clear cache, test the same action on a different record, and compare results across profiles—to decide the best way to fix the root cause.
Common salesforce errors I fix for admins and users
When a user reports they can’t complete a routine task, I start with the quick access checks. That fast triage separates locked accounts and simple UI problems from deeper system faults.

Login problems: passwords, IP ranges, and hours
I check Setup > User > Login History to see failed attempts and exact reasons. I also verify Password Policies and lockout settings so the account is not blocked.
Permission and visibility
I inspect profiles and permission sets for object and field-level access. Enabling Manage Profiles and Permission Sets lets me adjust rights and test with the target user to confirm record visibility.
Missing or hidden field
If a field seems absent, I check page layouts and FLS first. Conditional visibility or omitted fields in SOQL can make a field look invalid even when it exists.
Validation failures and transient system hiccups
I read the exact validation message to find required value or format issues, then correct the data or refine the rule. For internal server messages I ask users to refresh, clear cache, or try another browser while I review session health.
Guarding list and record access
I prevent System.ListException by checking list size before accessing index 0 and by validating query results. Finally, I document the fix in setup and ask the user to retest the full process for value confirmation.
Developer-side exceptions that break workflows and how I resolve them
A tiny omission in code can stop a business process cold — I focus on that first. I triage developer-side exceptions by reproducing the failure and isolating the transaction that caused it.
FIELD_CUSTOM_VALIDATION_EXCEPTION & REQUIRED_FIELD_MISSING
I catch REQUIRED_FIELD_MISSING by ensuring every required field is set before DML. If FIELD_CUSTOM_VALIDATION_EXCEPTION appears, I either adjust the data or refine the validation so the process can save valid records.
Null pointer and safe access
A NullPointer shows up when code dereferences an uninitialized object. I add null checks, initialize references, and use safe access patterns so the application never assumes data that might be missing.
List and query safeguards
To avoid System.ListException I check list size before reading index positions. For QueryException, I query into lists, verify size, and use selective, indexed filters so single-row assignments never throw no-rows errors.
Mixed DML and field selection
I separate setup and non-setup DML into different transactions or use Queueable/@future. And when a SObject is missing a field, I add that field to the SELECT so System.SObjectException is resolved.
My rules: validate required fields, guard nulls, verify lists, make queries selective, and back changes with unit tests.
Governor limits and performance errors I never ignore
I pay attention the moment a transaction takes too long or returns a limit message. These cap messages point to design or data problems that can stop critical processes and frustrate users.

Too many SOQL queries: 101 — bulkify and consolidate
A “Too many SOQL queries: 101” error usually means a query ran inside a loop. I move queries outside loops, build maps keyed by Id, and let one query serve many records.
Too many DML statements: 151 — stage and commit in bulk
A “Too many DML statements: 151” error means DML ran repeatedly. I collect sObjects in a list, then perform a single update. That one change prevents iterative updates and reduces heap use.
Apex CPU time limit exceeded — trim logic and go async
CPU limits (roughly 10s sync, 60s async) show when code spends too much processing time. I simplify complex logic, add selective filters, and move heavy work to Queueable or Batch jobs so user actions stay responsive.
Too many query rows and heap size issues — filter, page, and batch
When queries return over 50,000 rows or heap size spikes, I add WHERE clauses, LIMIT/OFFSET, or switch to Batch Apex. I also query only needed fields to keep memory small and speed the system.
My rule: design for scale — balance synchronous steps for immediate needs and asynchronous work for large data sets. That way I avoid repeat error types and keep account and record operations reliable.
My step-by-step troubleshooting workflow to keep records and processes healthy
My first move is to recreate the failing action so I can see the problem play out in real time. Reproducing the issue gives me concrete information I can use instead of guessing.
Reproduce and capture logs. I run the action with debug logging enabled to record SOQL and DML counts, stack traces, and any validation messages. That information tells me whether the error is data, code, or platform related.
Check access in setup. I inspect the user’s profile, permission sets, sharing, and field-level security so the tool grants necessary access without exposing sensitive data.
Review validation, layouts, and queries. I scan rules that demand certain fields or formats and verify queries are selective and include required fields so no SObject row-not-queried issues appear.
Refactor to respect limits. I remove SOQL or DML from loops, bulkify triggers, and move heavy work to Queueable or Batch jobs. That keeps operations fast and avoids repeat error types.
Test as a real user and verify data. I use a least-privileged user for an example run, confirm records save correctly, and check data integrity across target objects. Finally, I coordinate with my team, document findings, and share with the community so fixes hold in daily operations.
Conclusion
Conclusion
Quick action keeps the platform reliable and protects customer outcomes. I act fast on validation failures, permission gaps, and governor limit messages like 101 SOQL or 151 DML so the business can keep moving.
I use Setup diagnostics (Login History, Password Policies), bulkify code, apply selective queries, and move heavy work async. I also add defensive checks to guard against QueryException, SObjectException, ListException, and NullPointer.
Clear the cache for transient internal messages, test with a least-privileged user, and document the fix. Small guardrails—validate a field before save or limit query size—stop repeating issues and keep the user experience steady.
FAQ
What should I look for first when I suspect a serious platform issue?
How do I distinguish data integrity warnings from system exceptions?
What are the most frequent access problems I fix for admins and users?
Why does a required field seem present but still block a save?
What causes validation rule failures and how do I approach them?
How do I fix intermittent internal server errors or cache-related problems?
What are FIELD_CUSTOM_VALIDATION_EXCEPTION and REQUIRED_FIELD_MISSING during DML, and how do I handle them?
How do I prevent null pointer issues like Attempt to de-reference a null object?
What causes list index out of bounds and how can I guard against it?
How do I handle System.QueryException like no rows for SObject or non-selective queries?
What is the mixed DML operation error and how do I resolve it?
How do I avoid hitting the 101 SOQL queries limit?
What steps prevent reaching the 151 DML statements cap?
How do I reduce Apex CPU time limit errors?
What causes too many query rows or heap size issues and how do I control them?
What is my step-by-step workflow when troubleshooting record or process issues?
How do I test fixes safely without impacting production users?
Author Bio
Co-Founder & CMO at Merfantz Technologies Pvt Ltd | Marketing Manager for FieldAx Field Service Software | Salesforce All-Star Ranger and Community Contributor | Salesforce Content Creation for Knowledge Sharing

