The 6 Most Common Visual Flow Errors to Avoid

Visual Flow and Process Builder have gained adoption around the Salesforce Community.   We are even allowed to Activate a Flow or Process Builder in Production without ever testing it is actually working as we intended.  This means that when we develop a Process Builder or Flow we are quite likely to run into errors.  These errors are the main mistakes that you should look out for when you are building a Flow.  I’ve hit all of these errors, and I still continue run up against some of them.  However, knowing what to lookout for will save you a headache when you do run into one!

No Access to Running Flows

This is an easy fix and you’ll only run into once (per Org that you work in).  Make sure any users that need to access a Visual Flow have the System Permission Run Flows.  If the End User lacks this permission and they attempt to access the Visual Flow they’ll receive an error.

Object & Field Level Security for running user

If you are using Visual Flow (not launched by Process Builder), this is an error you can run into.  This can cause all kinds of issues when your Lookups, Creates, and Updates all break.  This is something that you can’t really fix within your Flow, and this is strictly user permissions.  This comes down to you as the Administrator knowing the level of security your users that will be using your Flow.  So, make sure your End Users have the ability to do everything you want them to or they’ll get an error!

Too many SOQL queries

Fortunately this is a limit that usually only Admins run into.  It is rare our End Users actually preform data loads, or use an Autolaunched Flow hits this limit.  Unfortunately we don’t actually have a limit status bar as an option, and it doesn’t seem like this is coming anytime soon.

Now, when you’re building a complex Flow, you need to consider how it is going to be used.  Are you likely to hit limits on?  Are there other Workflow Rules, Process Builders, Auto-launched Flows, or Apex Triggers that will be touched by your automation and might cause a ‘loop’ of your automation?

The best advice I can offer for you with this error is to assume you will always hit it with data loads.  But, in the case when you don’t… TEST, TEST, and TEST again.  There is no magic status bar to alert you how you are tracking.

Flow SOQL.jpg

Using the wrong Field or Variable

This one is really just a User error issue.  This typically happens to me when I am working late at night.  Sometimes I might confuse the variable that I am looking for.  Often times I find this might happen when I see people creating or doing lookups to Junction Objects.  This is because we often do not use the name of the Object as our field name.  For instance, if we are tracking Job postings in Salesforce and on our Application we have the Contact lookup labeled as Applicant.  If I wasn’t paying attention, I could easily grab the wrong field to reference as my Contact Id… this plays into our next common error.


Creates with no variable as your criteria, or Updates with No Records Found

So we are excited to throw our Flow out into Production, however we didn’t realize that there might be a scenario that our Flow might get activated and one of our variables isn’t populated.  This could be for a number of reasons, but it will cause you a big problem.  This will get you one of our favorite FlowApplication error emails.

Now, the way we can attempt to solve this error is to use Decisions to validate that we actually found the variables that we expected to find.  Take a moment and read my Decisions – Your Flow’s Test Coverage.  By using this method you can hopefully avoid running into these two errors altogether!

Duplicate Value – Membership/Assignment already exists

If you are using Process Builder or Visual Flow to add a User or Contact to a membership of some sort.  The main areas you’ll run into this are:

  • Campaign Members
  • Public Group Membership
  • Permission Set Assignment
  • Queue Membership

This can be avoided by doing Lookups of the existing memberships/assignments before doing the Record Create.  This can get difficult when you are dealing with multiple records, as there is a limit to how many Lookups you can do (and the ‘speed’ of doing this).

Decisions, your Flow’s Test Coverage

Anyone who deals with Flows on a regular basis dreads the Error Occurred During Flow  (Previously the Unhandled Fault) message that we get from Salesforce.  What we thought we built to perfection – isn’t.    This isn’t very different from what we experience with an Apex trigger.  Configuration changes can cause a previously well written Apex trigger to now not work as intended.  Part of this might be that our Flow got used in a different way than we intended it to be used in.  Now this becomes a real problem comes when we have an Autolaunched Flow and we hit an error.  This stops our End Users from being able to save their record.  So, how do we deal with that? Continue reading