Debug log monitoring

Debug logs are used for live troubleshooting and are usually used by developers when debugging Apex code. There is no reason why an administrator shouldn't also use debug logs for debugging flows, workflows, process builders, or just to better understand why a business process is working in a way that we don't understand.

Debug logs could also be useful for reverse engineering scenarios: the lack of documentation might sometimes be a real problem for your organization and you can easily troubleshoot  issues by using  debug logs.

Let's say we have a workflow rule that sets the account's Rating field to Hot if its annual revenue is greater than $100,000.

After enabling debug logs (we'll shortly see how logs are enabled), if we create or update an account record by setting its annual Revenue field to $15M, we will be able to read how the workflow rule evaluation runs and see when the account Rating field is updated to Hot:

45.0 APEX_CODE,NONE;APEX_PROFILING,INFO;CALLOUT,NONE;DB,INFO;NBA,NONE;SYSTEM,DEBUG;VALIDATION,INFO;VISUALFORCE,NONE;WAVE,INFO;WORKFLOW,INFO
. . .
19:03:01.20 (20286522)|USER_INFO|[EXTERNAL]|0051i000001AZCS|advanced.admin.book@enree.co|(GMT+02:00) Central European Summer Time (Europe/Rome)|GMT+02:00

19:03:01.20 (20307561)|EXECUTION_STARTED

19:03:01.20 (20310551)|CODE_UNIT_STARTED|[EXTERNAL]|Workflow:Account

19:03:01.20 (26000808)|WF_RULE_EVAL_BEGIN|Workflow

19:03:01.20 (26040581)|WF_CRITERIA_BEGIN|[Account: Super Gnite Ltd. 0011i000007K2LE]|Set Account Rating |01Q1i000000btDQ|ON_ALL_CHANGES|0

19:03:01.20 (26296080)|WF_RULE_FILTER|[Account : Annual Revenue greater than 100000]

19:03:01.20 (26327532)|WF_RULE_EVAL_VALUE|15000000

19:03:01.20 (26333214)|WF_CRITERIA_END|true

19:03:01.20 (26622520)|WF_SPOOL_ACTION_BEGIN|Workflow

19:03:01.20 (30492959)|WF_FIELD_UPDATE|[Account: Super Gnite Ltd. 0011i000007K2LE]|Field:Account: Rating|Value:Hot|Id=04Y1i000000XZzj|CurrentRule:Set Account Number (Id=01Q1i000000btDQ)

19:03:01.20 (30526240)|WF_ACTION| Field Update: 1;

19:03:01.20 (30532098)|WF_RULE_EVAL_END

19:03:01.20 (40699861)|WF_ACTIONS_END| Field Update: 1;

19:03:01.20 (40717805)|CODE_UNIT_FINISHED|Workflow:Account

19:03:01.20 (40724015)|EXECUTION_FINISHED
. . .

In this (apparently) messy debug log, we can have a look at the following pieces of information about our last account update:

  • The user that triggered the update (advanced.admin.book@enree.co)
  • The code unit about to be executed (Workflow:Account)
  • The account in the scope of the workflow (Account: Super Gnite Ltd. 0011i000007K2LE) and the rule that is going to be evaluated (Set Account Rating)
  • The criteria (WF_RULE_FILTER|[Account : Annual Revenue greater than 100000])
  • The evaluated value (WF_RULE_EVAL_VALUE|15000000)
  • Whether the criteria have been matched (WF_CRITERIA_END|true)
  • Any action related to that workflow rule (WF_FIELD_UPDATE...Field:Account: Rating|Value:Hot)
  • The total number of actions executed (Field Update: 1;)

Imagine that you have tens of workflow rules or process builders and you need to understand in which order they are evaluated. This is possible with debug logs, although you need to be used to the log format (don't you want to become a developer-admin, or dev-min?).

To be able to retrieve a debug log, you need a trace flag, which enables the system to create debug logs for a given user, and a debug level, which is needed to filter out the required data.

To create a new trace flag, navigate to Setup | Environments | Debug Logs and then click the New button in the User Trace Flags section:

Creating a new trace flag

Look up the user who you want to debug (it could be your user or any other user on your organization), along with the start and end date for tracing, and finally, the debug level. Create your own debug level by clicking on the New Debug Level button (or look up one if you have already created it):

Setting up a new debug level

This complex list simply states what level of verbosity you need in order for each resource to be tracked live. In this screenshot, I've removed anything related to Apex, Visualforce, or Apex Callouts.

Note that enabling debug logs can slow down overall system performance (especially when you have a lot of automation), so activate these features only when needed.

Now that everything is set up, we can start collecting our debug logs from the Debug Logs page. Any time we create/update a new record, a new debug log will be created:

Debug logs list view

Click on the View or Download link to get a debug log. After every action on the organization by the tracked user, you'll see various entries that are related to Salesforce items that are loaded on your user interface (for example, Lightning components on the record's page that you actually don't want to debug).

If you have different entries for the same start time, open your logs and figure out which debug log you  are looking for (for example, by searching for the object's ID or a given workflow rule name you are sure has been triggered).

There are a few limitations regarding debug logs:

  • Each log can have up to 5 MB of data. If this is exceeded, Salesforce removes some lines, so the log may not be complete (to avoid this, reduce some of the filter accuracy).
  • Logs are retained for 7 days.
  • We can have up to 250 MB of debug logs in our organization. To remove them, click on the Delete All button in the Debug Logs section.
  • If a trace flag creates more than 250 MB of logs in 15 minutes, it is disabled, and an email is sent to the last user that changed that trace flag, informing them that it can be re-enabled in 15 minutes.

Don't you feel like a developer now that you know the secrets of debug logs?

When dealing with long debug logs, I suggest using some syntax highlighting text editors, such as Sublime Text or Visual Studio Code, as shown in the following screenshot:

Debug logs displayed with  highlighted syntax
上一章目录下一章