This is the second of three posts on Troubleshooting Visual Flow & Process Builder. You can checkout the first post on using the Fault Emails here. The Fault Emails are great and solve close to 90% of the Flow and Process Builder errors that I have. However, sometimes it just isn’t that simple.
A Quick Recap … When I’m looking to fix a Flow there are typically three routes that I use:
- Fault Email
- Debug Logs
- Screen Elements & an Assignment Element (I’ll be covering this in its own post after I present on it for my Salesforce Automation Hour Presentation — so register now and see it first!!)
As I mentioned in my previous post, I think overall #1 and #2 are the most common ways that people will test and debug their Visual Flows (and Process Builder, since there are no screens or variables). This post is going to be an overview on how you walk through the Debug Log, and go over some basic reasons why you would want to use the Debug Log.
Why do I typically drag the Debug Log out when I hit a tricky problem with my Flow or Process Builder?
Debug Logs gives you the full view of what is going on.
I was recently assisting a friend with a Process Builder issue they had. We walked through the different Criteria, and everything seemed to be setup perfectly. We went to test the automation, but nothing happened. There were no emails, because nothing was broke in Salesforce’s eyes. However, something wasn’t right. Was our Process Builder’s Record Update setup incorrectly? Did our test record not meet the criteria? Those types of questions can be difficult to answer without the Debug Log.
I imagine that I’m not alone in this situation of wondering why a Process Builder or Flow isn’t running as intended. If your process is large, it can be very time consuming to walk through everything and re-validate multiple times as you try to find the cause. It takes a lot less time for you to setup a quick Debug Log and truly see what is going on.
New to Debug Logs? Take a look at this article: Set Up Debug Logging
Debug Logs allow us to to see everything that happened during the Save process of a record. Need a refresher on what the Order of Execution is, check it out here. You’ll find Processes as #13 on that list. That means by reading the Debug Log I am able to see if my Process actually was triggered or if it didn’t meet the criteria.
That is just one scenario when a Debug Log will come in and save the day. My second example is if you are hitting an error, but the Fault Email doesn’t give you the full picture of what exactly is causing the error. You need insight into seeing all of the Validation Rules, Workflow Rules, APEX, and other events that occurred when the Process Builder and/or Flow ran. I’ve had a headache before due to a Workflow Rule I didn’t realize was overwriting my Flow’s field update. The cause will be different based on the Org and Object, but typically this happens more often on your busier Objects or processes that create/update multiple Objects.
If you’re new to the Debug Log, start with Info and then move to Fine or Finer if you’re not getting the information you need.
Reading a Debug Log might seem complicated at first. Salesforce put together some great documentation for you to understand what each Event Name means. I would highly suggest giving this documentation a read. I’ll give you the two big ones around Flow to remember:
- WF_FLOW_ACTION_BEGIN
- Tells you that you’re starting the flow transactions (#13!)
- WF_FLOW_ACTION_END
- Tells you that you’ve exited your flow transactions (on to #14!)
The rest of your Events between those two will house what is going on with your Flow/PB. Do a quick search/find in your Logs on either of those two Event Names, and you’ll get to where all your Flow Events are located. There are a total of 38 of these different Flow Events – so I’m not going to go into detail here of what each Event means.
I hope to get this updated (in the near future) with some images of the debug logs. They were hard to read, so I removed them for now.
RECAP: If you want to take your debugging skills to the next level (and save yourself tons of time), learn to use the Debug Log. Hopefully you have a better idea of when you’d want to look to use a Debug Log to troubleshoot your Flow. Don’t restrict this to just your Process Builders and Flows… this works on troubleshooting everything you’re configuring!
Salesforce Sidekick 