Debug logs in Salesforce

How to debug and create debug logs in Salesforce?

Debugging what is happening during the execution of a software is critical to understand if the code is behaving as expected, and it allows you to identify problems quickly.

In Salesforce you can debug essentially in two ways:

- Running the code with the Developer Console open. In this way all the trace flag logs will appear in the tab “logs” in the bottom right of the developer console.

Then, click on the row you would like to open and it will open it in a tab of the developer console.

- You can create a new debug log:

1. On the main page of your org, click “Setup”. “
2. Search for “debug logs”.

3. Click “Debug logs” and then “New”.

4. When you create a new log, you have to specify the user you would like to trace, the log’s start and end dates, and the level of the debug.

When choosing the level of the debug, if you don’t need particular lines, you can use the default one.

When you are ready, click “Save”.

The debug logs will appear on the main page.

To see them, open them one by one in the org or download them.

On these debugs you will see the “standard” trace of the Salesforce execution stack, but also all the System.debug that you’ve put in your Apex code.

Some tips to debug better in Salesforce

If you’ve never used Salesforce debug before, it may be difficult to read all the logs. That’s because most of the time debug files have many rows, and it can be hard to understand which is the one you are looking for.

What I usually do is download all the debug logs I generated in a cycle, put them in a folder, and open it in Visual Studio.

Then I start searching in all folders:

1. For the word “Exception” if I am searching for an error I am not able to find.

2. For the word I have put in the system.debug if I wrote in Apex something like

system.debug (‘My records ’+ records),I will search for “My records”.

3. If I am trying to find the life cycle of a variable I have in my code, even if I didn’t put any system.debug in the Apex code, I set the debug level at “finest” to see all the assignments of that variable while the software is running. I can search directly for the name of my variable.

Delete debug logs

When you start working with Salesforce debug you will understand that even for a little action in the org, it can generate many files.

It’s good practice to delete old files you don’t need anymore. Anyway, you will be forced to do so, since the space for logs is limited.

How can you delete logs?

There are several ways to delete debug logs in Salesforce:

1. The official guide (https://help.salesforce.com/articleView?id=sf.code_debug_log_delete.htm&type=5) says you can delete them from the developer console by querying the ApexLog table and selecting the rows you would like to delete.
2. Since you cannot delete them with a script like
3. List<ApexLog> logs = [select id from Apexlogs];
4. delete logs;, because you will have an error, some people use the REST API to do it, like in this article: https://salesforce.stackexchange.com/questions/239636/how-to-delete-all-debug-apex-logs-in-apex/239642
5. If you are working with a sfdx project, you can use the sfdx to delete them: https://lenguyensf.blog/2020/07/27/how-to-delete-all-debug-logs/ 

For me the first method isn’t good, because often the developer console gets blocked, so what I do is:

1. Using a workbench to query all the logs and export them as a CSV.

2. When it finishes querying, I download the file by clicking on the arrow:

3. After the file is downloaded, I go to “Data” after clicking on “Delete”

4. After choosing “Delete from file” I upload the CSV file that I downloaded.

Best practices with debug logs

The standard Salesforce debug logs are really useful. The only problem is that to obtain them you have to replicate the errors and all the steps with the developer console open or after you create a new trace flag.

Sometimes this is not possible because of production errors, for example.

The best way to have real logs is to create custom objects and create a record on them each time you need to trace an error or operation.

Examples of log objects:

1. Integration log: You would like to know who calls your API and also which API your software calls. In this case you can create a custom object to trace: endpoint, request, response, timestamp of the request, user’s identity, etc.

2. Error logs: These are really useful to be traced when you run into an exception on your code. If you use try/catch on your code (you should) in the catch section you can create a new record of the error log object, saving the error stack and other information you need.

Of course, it is not possible to trace all the errors or actions of the users in the org day by day, so when you project your software, you need to decide which are the important information and processes to trace and the ones that are critical for your business.