An Admin’s Guide to Debug Logs in Salesforce

If you’ve been an admin in your org for a while, chances are you’ve experienced troubleshooting various issues at some point. One of the most common challenges admins face is diagnosing automation failures. Wouldn’t it be great if there was some sort of journal that logs everything that happened within a specific time? 

Debug logs can be an essential tool or a crucial resource for admins to identify and monitor org issues, and understanding them can significantly enhance your ability to maintain a healthy Salesforce environment. Let’s dive right in!

What Are Debug Logs?

You know how people keep diaries or journals to log daily happenings and events they’d like to capture and look back on in the future? You can think of debug logs as if they are your Salesforce org’s diary, wherein system events, errors, and execution details related to Apex code, workflows, processes, and integrations are captured. 

They can provide a more detailed look at how Salesforce executes various operations, helping admins and developers diagnose issues effectively.

Why Are Debug Logs Important?

Debug logs can help maintain a stable and efficient Salesforce environment. In a pretty complicated org with lots of automation and customizations, it can get confusing for an admin to know every little detail that was ever set up in it. What flow does which automation? Which validation rule prevents what data entry? Did that validation rule just cause an error with another automation and cause unexpected behavior?

By providing transparency into system processes, user interactions, and automation execution, analyzing debug logs can help an admin understand code behavior and how it can cause performance bottlenecks. 

Every org user would benefit from optimized performance, and debug logs can also help track how long it takes for an operation to execute. Since debug logs can also be configured to track user activity sequence, it’s easy to verify whether system interactions always align with the business’ rules.

With all that said on how they can help admins, let’s learn how to generate them.

How to Generate Debug Logs

Let’s start with enabling debug logs for a specific user.

1. Go to Setup > Debug Logs. 
2. Under User Trace Flags, click New.
3. Here is where you can customize what you want to see in the logs you’re about to generate. You can make it as simple or as comprehensive as needed. Trace flags control the level of detail captured in debug logs, so configuring them will help you in assigning appropriate debug levels. Debug levels determine the type and amount of information logged for various events, allowing you to focus only on relevant data for troubleshooting and analysis. In a trace flag, you can configure the type, start and end dates/time, and the debug level.
   • Type: We have five choices for this: User (for monitoring events on a specific user), Apex Class (for logging events that occur when a specific Apex class is executed), Apex Trigger (for logging events that occur when a specific Apex trigger is executed), Platform Integration (same with User above, but specifically for the Platform Integration User who is an internal API-only user that facilitates secure data access across Salesforce applications and integrates features between different Salesforce properties), and Automated Process (for the Automated Process User who’s responsible for background jobs). 
   • Start date and expiration date: Identifies how long you want the debug log to record events. This range is set to 30 minutes by default.
   • Debug level: Here is where you can specify what level of information you want recorded in the logs. We’ll get to the specifics in a bit.
4. Pick a Traced Entity Type, Start and End Time, then click New Debug Level.

5. Wow, that new window has so much in it! I know it feels overwhelming, but let’s start with the basics. All you’ll have to do here is to pick the debug level you want for each category. The debug levels are None, Error, Warn, Info, Debug, Fine, Finer, and Finest. Now, not all categories have these levels, but each dropdown lists your choices from lowest to highest – meaning from the simplest to most complex. Do take note that these levels are cumulative, so as you move on to a more complex level, it will also capture whatever events can be captured by the levels below it.
6. The categories will help you focus on what you’re looking for. See this table below for a simplified guide on what each category looks like:

7. Once you’re done picking the debug levels for each category, give it a name and hit Save.
8. The smaller window would close and take you back to the Trace Flag creation window. Click Save here too. In my case, I chose to create logs for a specific user.

9. To test this setup and have it generate the logs, I used my ~admin powers~ to log in as the user I selected, then created an Account record as that user. The record creation didn’t go so smoothly – I got one validation error on the Account creation page, prompting me to fill out a field before saving. When I filled out said field, the Account record was created successfully. I then logged out of that user and went back to Setup > Debug Logs as the org admin.
10. You should see some logs now generated. 

11. On the far right, you’ll see the Start Time for each log, with the latest ones at the very top. On the left, you have the option to view, download, or delete each log. 
12. I did mention in step 9 that during my testing, I got a validation error, right? Let’s view one of the logs to see if that event was captured. I’ll go ahead and select View on the /aura log for 03/06 12:31:49, which I believe was the exact time I triggered the record creation. The log should appear like below:

13. We know that the error that came up during account creation was a validation error. So in this log, the most basic keyword I’m looking for is “validation”. We have the following lines:

09:31:49.0 (310872)|VALIDATION_RULE|03d3t000000UtwD|Blank_Lead_Created_Date
09:31:49.0 (577616)|VALIDATION_FORMULA|AND(ISNEW(), ISBLANK( Lead_Created_Date__c ))|Lead_Created_Date__c=null
09:31:49.0 (607241)|VALIDATION_FAIL

The leftmost part of every line shows the time stamp (in the user’s time zone) of when the event occurred, along with the duration or how long it took in nanoseconds (the value in parentheses in nanoseconds).

On the first line, we see VALIDATION_RULE, indicating that a validation rule has been triggered. The validation rule’s ID is 03d3t000000UtwD, and its name is Blank_Lead_Created_Date. In an org with a lot of validation rules, this line alone is helpful in identifying which specific rule fired.

The second line VALIDATION_FORMULA shows the formula itself, which is AND(ISNEW(), ISBLANK( Lead_Created_Date__c )) in this case. It generally prevents the creation of a new Account record without a value in the custom Lead Created Date field. It’s great how this line displays the formula already – it gives you an idea of what the rule does without having to go to the validation rule in Setup. 

The latter part of this line shows Lead_Created_Date__c=null, which is the state of the Lead Created Date field at that time. It was null, and we know that this is exactly what the validation rule formula is trying to prevent.

From our analysis on the second line, we expect the Account record creation to fail because of the blank Lead Created Date field. Therefore, we see VALIDATION_FAIL on the third line. 

14. That log entry shows the moment when the validation rule error appeared, but we know that the Account record creation eventually succeeded. Let’s look at the next debug log entry to see how that translates here. I’m going back and clicking View on the log with the timestamp 03/06 12:32:04.

15. Again, looking at the entries with “Validation”, we end up with:

09:32:04.0 (298240)|VALIDATION_RULE|03d3t000000UtwD|Blank_Lead_Created_Date
09:32:04.0 (540729)|VALIDATION_FORMULA|AND(ISNEW(), ISBLANK( Lead_Created_Date__c ))|Lead_Created_Date__c=2025-03-21 00:00:00
09:32:04.0 (563233)|VALIDATION_PASS

This example was pretty straightforward, and it involves only a specific user’s Account creation and a single validation rule triggered. Debug logs are not limited to this, as they can log way more than an admin usually needs to see – understanding the content of each line or event can get pretty confusing for admins.

There is no need to understand and memorize formats and event names at this time, but check out this page on Salesforce Help when you need guidance on what specific information can be found in each event name.

Tips for Using Debug Logs

Firstly, avoid excessive log sizes by limiting to specific components. I know someone who set up debug logs and just set every single category’s level to the finest setting, thinking it would help if the logs just record everything. 

Yes, your logs would be more detailed, but that would also mean they can get more difficult and time-consuming to sift through. The trace flags and debug levels configurations are there for a reason – make it a point to focus only on what’s needed to troubleshoot a specific issue.

Secondly, logs can get pretty lengthy, and there are limits when viewing them from Salesforce/your browser. Get comfortable analyzing your logs by exporting or downloading them. The downloaded file is a text file that you can open in Notepad.

Also, be mindful of your trace flag’s time range. Sometimes, you can get so absorbed in troubleshooting that you forget the time for collecting logs has expired! Using Debug Logs from Setup has its pros and cons, and its set time range can easily be a con in this scenario. 

While this is easy to set up as an admin who doesn’t make use of the Developer Console very often, you can also check out this post for an intro to the Developer Console and a short lesson on how to do real-time debugging with it.

Lastly, make sure to clear old logs! If you’re done troubleshooting and everything’s resolved, make it a habit to remove outdated logs to avoid clutter.

Final Thoughts

Salesforce admins can find debug logs to be a very useful tool for diagnosing automation issues, understanding system behavior, and enhancing the overall performance of their Salesforce org. 

Having a basic understanding of setting up trace flags and analyzing log entries to focus on relevant data can greatly improve your capacity to identify and fix surface issues quickly, even though it may seem overwhelming at first.

You’ll develop a keen eye for spotting errors with time and practice – so the next time something doesn’t work as expected, don’t panic; dive into the debug logs and let them guide you to the root of the problem. Which part of analyzing debug logs do you find tricky as an admin? Share them in the comments below!