Here are lessons learned you will take away from this blog post:

• As a best practice, include a Send Flow element for each record action (lookup, create, update and delete) to send a notification to the production support team when an error occur.
• Avoid “hardcoding information” in visual workflow, especially information that can be different in each region of a related org. This would cause updates to the visual flow in each region, making for different versions of the same flow.
• Maintain information that are referenced in multiple visual workflows outside of flow. Increase ease of maintenance. If the information needs to change, it is only changed in one place.
• New use case for custom metadata type.
• Data records associated with a custom metadata type are deployable via a changeset. You can locate the data records by looking for the custom metadata type’s name under the Component list. Do not look for it under Custom Metadata Type.

For those of you who are regulars to my blog, you know that I include a Send Email flow element step in visual workflow implementation. As a best practice, where there is a DML action (fast or record create, update, delete or lookup action) in a flow, you should also include notification of a flow fault. In those examples, I list out a single Send Email flow element with the recipient email address listed in each.

You can see over time, how that may not help ease maintenance. What if Addison Dogster leaves the company or there are others who need to receive the email? A System Administrator would need to go into each flow and update the email recipient and deploy the change to Production.

We can remove the specific email addresses from within the flow and maintain them outside of the visual workflows. If the email recipient needs to change, update it once and it updates it in all the flows. This also allows the System Administrator to be able to change the email recipient to her/his email address in the sandbox region as they build/troubleshoot a new visual workflow and not clog the emailboxes of the production support team.

We can also add enhancements to the fault email function, such as including the region that the email was sent from.

While we can solution this with custom settings, we will be using custom metadata type instead.

Quick sidebar on custom metadata types, this is a great feature to add to your admin toolset! If you like custom settings, you will REALLY like custom metadata types.

Custom metadata types are new to Salesforce, introduced in Winter 16.

Custom metadata is customizable, deployable, packageable, and upgradeable application metadata. First, you create a custom metadata type, which defines the form of the application metadata. Then you build reusable functionality that determines the behavior based on metadata of that type. Similar to a custom object or custom setting, a custom metadata type has a list of custom fields that represent aspects of the metadata. Unlike custom settings, the record data is metadata and can be deployed with the custom metadata type in a Change Set. No more exporting the related data and importing it to the destination org as you would do when deploying a custom setting.

For more information on custom metadata types, visit Salesforce Help & Training.

To make this piece more flexible, easier to maintain, this will require updates to your existing workflows. I can hear the big sighs now. Sorry! If you have many workflows, perhaps consider deferring the tweaking until the next time you touch the visual flow for other purposes.

Implement the following steps in each of your visual flows to retrieve the email recipients and the current Salesforce region to be pulled into the Send Fault Email flow element.

Business Use Case: Addison Dogster is a system administrator at Universal Container. She has implemented several visual workflows in her organization. Her team has grown over time and there is now a team of individuals who need to be notified when there are issues with visual workflow. When a fault email is sent from a sandbox, there is no indication which sandbox. She now needs to come up with a solution to easily maintain and enhance these fault emails.   

Solution: Addison was able to address these enhancements via declarative actions, no code. Her solution involves a creation of custom metadata type and a changes to visual flow.

Quick Steps:

Step 1. Create a Custom Metadata Type (Develop | Custom Metadata Types), click on the “New Custom Metadata Type” button.

A. Provide the label name, label name in plural, description and click the “Save” button.

Best Practice Tip: Don’t forget to provide a description so you and other/future admins know what this custom metadata type is used for.

The resulting page looks very similar to a standard/custom object in terms of standard, custom fields and page layout.

B. We will create a new custom field to hold the email recipients.

Best Practice Tip: Don’t forget to provide a description so you and other/future admins know what this custom field is used for.

C. We will create another new custom field. This one will hold the org-region name.

Best Practice Tip: Don’t forget to provide a description so you and other/future admins know what this custom field is used for.

D. Let’s update the Fault Email Page Layout. Move the unnecessary fields to the System Information section and make the Information section one column. Save the changes.

E. Let’s create the custom metadata type data record that stores the specific fault email information.

Click on the “Manage Fault Email Addresses” button.

Provide the Master Label (name of the data record), Email and Org-Region Name. Note: the Object Name will be populated with the Master Label value. Save the data record.

Step 2. We are now going to make the following highlighted updates to your existing visual workflow. Go to Create | Workflows & Approvals | Flows.

A. Create these two variables. They will store the email and org-name values pulled from the custom metadata type data record created in the previous step.

B. Create a Record Lookup. This will lookup the custom metadata type and pull in the email recipients and org-region name in the variables created in Step 2A. Lookup: Locate the Custom Metadata Type API name

We will use MasterLabel of the Custom Metadata Type data record as the criteria.

C. (If updating an existing flow – open the Send Email flow element) Select the Send Email flow element that is listed under Static Actions, not under Quick Actions.

Configure the body to show the fault message, subject and email address(es).

Body: Fault Message: {!$Flow.FaultMessage}

Subject: {!varOrgRegionName} Error – <Name of the flow>

Email Addresses (comma-separated): {!varEmailRecipients}

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this send email element is supposed to do.

Note: You will need to draw a FAULT connector line between each Fast/Record flow element to the Record Lookup for the Fault Email Recipients and then a regular connector to the Send Email element.

Can’t seem to get the fault connector to appear? Create a temporary flow element (circled below), draw your first connector to that temporary flow element. Then, draw another connector to the send element. This connector has the word “FAULT” in it.  

Once that is completed, delete the temporary flow element you created. This is the end result.

Deployment Notes/Tips:

• The custom metadata types and associated data record and visual flow can be deployed to Production in a change set.
• You will find the custom metadata type information under the Custom Metadata Type in the Component Type dropdown. However, locate the data records for the custom metadata types by looking for the custom metadata type names in the Component Types dropdown.
• You will find the visual workflow components in a change set under the Flow Definition component type.
• Activate the visual flow after they are deployed in Production as it is deployed as inactive.