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:
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.
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:
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. |
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:
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. Arovy provides you with Change Intelligence so you can investigate the cause of errors and prevent them from happening in the first place.
With Arovy, 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.
Arovy 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.
Arovy 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. Arovy 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 Arovy helps them work 40% faster. Want to see what you can do with Arovy? Try it for free here .