Salesforce Debug Logs

There’s a serious shortage of skilled Salesforce developers. In fact, job openings outpace available talent 4:1. As a revenue operations leader you’re likely feeling the pain of this as your  Salesforce developers quickly become buried under support tickets.  Not to mention the bottlenecks that occur when a workflow breaks or a new field is registered as invalid— it takes time to investigate the cause and push out the fix. The reactive work that follows, like finding and fixing bugs in your Apex code, slows your GTM team’s down and could ultimately impact the bottom line.

Salesforce debug logs can allow you to reverse engineering processes to identify where errors occurred. But there are some limitations of the feature. In this blog we’ll cover the basics of Salesforce debug logs. We’ll also show you how additional third party systems may complement your Org to help you investigate (and prevent) errors and be more productive.

Salesforce debug logs record events that occur within your Salesforce org. Debug logs tell you the status of a transaction, when it occurred, how long it took, and other pertinent information about Salesforce activity. They include:

• Database changes
• Apex errors and resources used
• HTTP requests
• Start-end time
• Automated workflow processes, such as:
  • Workflow rules
  • Assignment rules
  • Approval processes
  • Validation rules

Salesforce debug logs are triggered by trace flags. Trace flags allow you to configure Salesforce to log transactions undertaken by a particular user. You can configure trace flags in Salesforce’s Developer Console or in Setup. Each trace flag includes a debug level, start time, end time, and log type (which can be ERROR, WARNING, or DEBUG).

After the trace flags are set up, Salesforce will generate the debug log when a user performs the transaction. 

What is the difference between a system log and debug log in Salesforce?

Debug logs are often confused with system logs. The system log captures all system related information, whereas the debug log only contains information related to transactions by user.

To access Apex debug logs, follow these steps:

1. In the Setup area, use the Quick Find box to search for “Debug Logs.”
2. Select “Debug Logs.”
3. Click “View” next to the debug log that you want to view.
4. Click “Download” to download the log as an XML file.  

The debug level determines which information is included in the log. Setting the debug level allows you to capture the data you need to investigate issues and exclude superficial information. 

The information in the debug logs is divided by the following categories:

Debug Log Categories

While Salesforce debug logs are key for troubleshooting, they do have some limitations. They can be difficult to read, since debug files often contain a lot of data in large spreadsheets. Plus, Salesforce places some limits on debug logs:

• File size: Debug logs can’t be any larger than 20MB. If they exceed 20MB, Salesforce automatically removes older log lines. 
• Availability: System debug logs are only maintained for 24 hours. Monitoring debug logs are maintained for seven days. 
• Restricted use: Salesforce disables trace flags if you generate more than 1,000MB of debug logs in a 15-minute window. 

Maximum capacity: After you generate more than 1,000MB of debug logs, Salesforce prevents you from adding or editing trace flags. You have to delete debug logs to regain access to those features.

Considering the limitations of Salesforce debug logs, it’s a good idea to augment Salesforce’s debugging and troubleshooting tools with something else. Sonar provides you with Change Intelligence so you can investigate the cause of errors and prevent them from happening in the first place. 

With Sonar, you’ll be able to automatically document every change made to your Salesforce org. Change Timelines will provide visibility into which changes were made, when, and by whom. You’ll also be able to  see the before-state of a change so you can reverse engineer issues.

Sonar also helps prevent errors from occuring in the first place. Potential Issues lets you hone in directly on potential errors with your validation rules. As you make changes to your tech stack, you can use the Potential Issues feature to see which errors it may cause and which systems would be  affected. 

When you’re planning to make a change, use the Blueprint feature to see how fields, automations, and dependencies connect with one another. You can visualize the impact of change—in Salesforce and across your tech stack—before you make it. You can also see how a field uses an APEX class to prevent unintended downstream issues. 

Sonar is also more dynamic than the static XML spreadsheets generated by the debug log. This allows you to hone in on the information you need to find quickly.

Your Salesforce admin’s time is valuable– and it shouldn’t be spent reverse engineering breaks.While Salesforce debug logs can help, it may miss the mark for all your needs. Sonar allows you to reduce reactive work so admins can spend more time improving the architecture of your Salesforce org. 

It’s one of the reasons our customers say Sonar helps them work 40%  faster. Want to see what you can do with Sonar? Try it for free here.