Troubleshooting with Salesforce Debug Logs and Sonar
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.
What are debug logs in Salesforce?
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.
How to to check debug logs in Salesforce
To access Apex debug logs, follow these steps:
- In the Setup area, use the Quick Find box to search for “Debug Logs.”
- Select “Debug Logs.”
- Click “View” next to the debug log that you want to view.
- 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
|Database||Data manipulation language (DML) statement or inline SOQL, or SOSL query for database activity.|
|Workflow||Workflow rules, flows, and processes.|
|Validation||Names of validation rules and whether they’re evaluated as true or false.|
|Callout||The request-response XML that the server sends and receives from an external web service.|
|Apex Code||Log messages generated by DML statements, inline SOQL or SOSL queries, the start and completion of any triggers, and the start and completion of any test method relevant to the Apex Code.|
|Apex Profiling||Cumulative profiling information, such as how many queries were executed and how many emails were sent.|
|Visualforce||Include serialization and deserialization of the view state or the evaluation of a formula field in a Visualforce page.|
|System||Information about calls to all system methods such as the system.debug method.|
Limitations of Salesforce debug logs
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.
Augment your Salesforce troubleshooting capabilities with Sonar
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.
Conclusion: Do more with limited resources
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.