At Southeast Dreamin’ 17, I delivered a presentation called “So, You Want to Go With the Flow But Don’t Know How?” In that presentation, I reviewed 10 tips and tricks for those who are starting out with visual workflow.

Here they are…

1. A flow can only perform an operation if the running user has permission to do so.

Flow runs in the context of the user, not in system mode, when invoked from a button/link, visualforce or Lightning page so you need to ensure that if your flow has a step to create, update or delete, the user running the flow has permission  via their associated profile or permission set assignment to do so otherwise, the user will get a flow error.

Note: Process builder runs in system mode (i.e. you have permission to perform all actions) so if you invoke flow from process builder, the entire automation (process builder and flow) will run in system mode.

2. Plan before you build. Document/map out the details of the business process.

I cannot stress how important it is to understand and document the business process before you configure your process. It is so much cheaper to make changes to a process on paper (or electronically) than it is after you point and click configured it or built custom code. Get alignment on the documented process with the user before you spent time doing the buildout.

The below is an example of a complex process that I would ultimately build out.

I also used this to perform my testing of the different scenarios. Another plus!

3. Build in a test environment.

While it may be tempting, DO NOT, let me repeat, DO NOT build your flow directly in Production! Chances are pretty high that you will not nail your flow in one version. You do not want to be testing your flow in Production and accidentally change records incorrectly because your flow was not configured correctly. You should always configure your flow and test it out in a sandbox before deploying into Production.

4. Save often.

Unlike programs like Microsoft Word or Google Docs that perform periodic saves while you work, Salesforce does not. So, as you are working on your flow, click the save button often. I’ve done this a few times where I spent time working on a flow and accidentally closed the cloud designer and only after I closed it, did I realize I didn’t save my changes so I had to redo everything all over again.

5. Think like a developer. Safeguard your flow from faulting.

Think of Cloud Designer as a visual interface to building code behind the scenes. You need to think of not only the happy flow, when all goes right, but also what can potentially go wrong and safeguard your flow. Otherwise, when your flow goes to run and it runs into an issue, your user will see a not user friendly flow fault error and your process will fail to run. Here are a few best practices…

When you do a record lookup or fast lookup, there may be situations in no records are found from your query. If your process is expecting that record(s) are found to do something else with it and there are no records, Salesforce “throws a fit.” So, to prevent this, if no records found, assign null values to the variable(s) by checking the below setting.

Another example is if your process runs on a field that is not required and if the process runs and the field is blank on the record, then the flow will fault. To prevent this from happening, add an additional condition that the field is not blank (i.e. field is null = false).

6. Decisions, decisions…

Continuing along the lines of #5, you should perform null checks in your process. Before you perform a record/fast update or delete, make sure there are record(s) in memory for you to take action on. Or, to avoid duplicate records, confirm that no records were found. When it comes to Decision elements, it’s always ‘the more the better.’

Here is an example of a decision to confirm that the variable varUserCallCenterId has a value (i.e. {!varUserCallCenterId} is null {!$GlobalConstant.False}.

7. Never hardcode ID references. Lookup the ID or use a custom label, custom metadata type or custom setting.

The reason why you want to avoid hardcoding Salesforce IDs is that when the new record that your configuration item is referencing is created in a sandbox, and then created in every sandbox leading up and including Production, that new record’s Salesforce ID will never be the same. You will need to update each reference of this hardcoded Salesforce record ID in every sandbox or production. As a result, you have different versions of your flow in your regions. A maintenance nightmare!

Where possible, rather than using the ID, reference it by something that is the same in all regions and less likely to change, such as the API name or field label.

Alternatively, you can maintain the ID outside the flow in a custom label, custom setting or custom metadata type. Please read my blog post on this topic for more information on how to use this configuration.

 

8. User needs run flows permission to execute flows.

If this is the first flow you are implementing in your org, you will need to ensure that the users who are will be interacting with flow will need the system permission “Run Flows” or else the flow will not run. This permission can be granted either via the profile or a permission set.

9. Use the fault element.

When Salesforce performs a database action (update, lookup, create or delete), or what is called DML (data manipulation language), there is a chance that it may not be successful. If it does, the system will show a fault message to the user and send a flow fault email to the last person who updated the flow.

It is best practice to configure your fault connector (this is the connector with the word “FAULT”) to send an email to the production support team that something did not go as planned.

Below are links to posts that will walk you through how to configure the fault connector and email.

• Configure Every Fault Path to Send You an Email (Best Practice)
• Customize the Error Message for Running Flow Users (Best Practice)

10. Find flows as “flow definition.” They deploy to a sandbox or Production inactive.

In Salesforce changesets or Dreamfactory’s Snapshot, you will find your flows under the category “Flow Definition.” Flow, like process builder, will deploy to the target sandbox or Production inactive. You will need to manually activate the flow in order for it to run.

Go on and let it flow!