A Debug Log is used for System Process, record database operations, and errors. The errors will occur when executing the transaction or running unit tests. Using Debug Logs, we can find detailed information about your running processes when they complete. We will discuss below as to how to troubleshoot the process using debug logs. The information from actions triggered by time-based workflows do not include in the debug log.
To navigate to Debug Logs or Debug Levels:
Setup [Symbol] Logs [Symbol] Debug Logs or Debug Levels.
- After creating the process, set up the Debug Logs and Debug Levels filter in “Finer” level for Workflows.
- Next, create a record for that object
- Then, go to Debug Logs. Under the Debug Logs, click “View” next to the Username.
Before troubleshooting the process using Debug Logs, consider the following:
- Each Process created in the Process Builder, it appears as flow and workflow rules in Debug Logs.
- If the action fails in the middle, following actions might not run.
- The scheduled actions will be executed after a Wait element.
- WF_CRITERIA_BEGIN and WF_CRITERIA_END refers the workflow rule criteria. It is always set to true.
- Following are the Process Builder elements for the Flow Debug events.
|Process Builder Element||Flow Debug Event|
|Create a Record||FLOW_ELEMENT_…|
|Post to Chatter||FLOW_ACTIONCALL_…|
|Submit for Approval||FLOW_ACTIONCALL_…|
Inspecting the Debug Log Sections:
For Example, here I have created a process for a Custom Object with the evaluation criteria as “only when a record is created”. While creating a new record, if a custom field is empty then it should automatically save the record with the Custom Value what I have declared in the process. When the conditions are met with my process, the debug log will create like below.
- The Process starts with a version and after that the Debug Levels are displayed in the first line of the Log.
2.The second line of Log starts with the USER_INFO that refers the User ID, User Name and continues with the Organization time zone.
3.Then, the execution is started with EXECUTION_STARTED event.
4.The above image shows that after the EXECUTION_STARTED. Then, the code unit starts with the event CODE_UNIT_STARTED.
5.CODE_UNIT_STARTED refers the process as Workflow with the Custom Object Id.
6.WF_CRITERIA_BEGIN and WF_CRITERIA_END is always set to true.
7.WF_CRITERIA_BEGIN indicates the Custom Object Name (Profile Test) and Record Name with record Id.
8.Here, my Process Name is “ProfileTestsProcess”.
9.Finally, it includes when the process will start. Here, I have chosen only when the record is created. Its looks like in the Debug Log as ON_CREATE_ONLY.
Above image shows the details of following Flow Debug Events.
- WF_FLOW_ACTION_BEGIN indicates that the flow transaction is started.
- WF_FLOW_ACTION_END indicates that the flow transaction is ended.
- FLOW_CREATE_INTERVIEW_BEGIN event creates our process to execute. It includes our process’ number which is automatically appended to the end of our process name.
- FLOW_CREATE_INTERVIEW_END event indicates our process name.
- These two events are used to create our process.
- FLOW_START_INTERVIEW_BEGIN event indicates that it is beginning of the process.
The above image shows whether our process criteria rule is true or not.
- FLOW_RULE_DETAIL event indicates whether our rule criteria is met or not. If our rule criteria are met with the condition what we declared in our process, it will show true or false.
- If our rule criteria are true, then next the FLOW_VALUE_ASSIGNMENT event shows our value assignment by indicating true or false.
- The above image is an example for true condition.
- The below image is an example for false condition.
5.If our FLOW_RULE_DETAIL event is true then the FLOW_VALUE_ASSIGNMENT also will be true.
6.If our FLOW_RULE_DETAIL event is false then the FLOW_VALUE_ASSIGNMENT also will be false.
7.Then our process will be end by indicating FLOW_START_INTERVIEW_END event.
8.Then, finally our code unit and the execution also will be finished.
Advantages of using Process Builder:
- We can do the Parent to Child updates as well as Child to Parent updates.
- If we want to make some changes in WORKFLOW, we can edit and use the WORKFLOW, but we cannot maintain the history; however, in PROCESS BUILDER, if we want to make some changes in our process, we can clone and make any changes. At the same time, in Process Builder we can maintain the old version and the new version what we did the changes.
- We can troubleshoot our process using the Debug Logs as we discussed above.
- As I explained above, the list of Flow Debug Events is used to troubleshoot the process.
- We can troubleshoot the process with the Flow Debug Events whether the rule criteria is true of false.
- We can check whether the value is assigned or not using the Debug Logs.