5+1 Admin Tips: Troubleshooting Emails and Process Builders
5+1 Admin Tips: Troubleshooting Emails and Process Builders

5+1 Admin Tips: Troubleshooting Emails and Process Builders

04/30/2020 by Mario Di Genio
In this post we’ll take a look at how an admin can troubleshoot some of the most common issues with emails and Process Builders in Salesforce.

Many times, while implementing your processes, no matter how straightforward, you just can’t figure out why they aren’t working. You review them over and over again and no dice. These roadblocks might seem simple, but left unchecked they can end up taking a lot of time, not to mention a toll on your confidence.

In this post, we’ll visit some common ways to troubleshoot email issues. Your email should come out of Salesforce, but you’re not getting anything, so what should we do?

Tip 1: Check email deliverability

From Setup, enter “Deliverability” in the Quick Find box, then select “Deliverability”.

When you create or refresh a sandbox, email deliverability is set by default to “System email only”. This means that Salesforce allows only automatically generated emails, such as new user and password reset emails, to be sent. Any other emails, such as the ones from workflow rules or process builders, will be blocked.

This is the first step to take when setting up your testing to work in a fresh sandbox. Skip it and you’ll be running in circles for a while all because of one tiny setting. You may want to check this help notes article regarding setting up sandboxes Sandbox Setup Considerations as well.

Tip 2: Update account and contact records’ email addresses and phone numbers

If you are working with a partial or full copy sandbox, there will be data in there that is copied from the production environment you departed from. When it comes to user records, the emails are all scrambled, usually having the “.invalid” suffix, and other users would not be able to use the sandbox unless explicitly given access.

But the rest of the records will be an exact copy from production, namely the email addresses and phone numbers of all contacts and accounts. This means that if you are testing anything in your sandbox that sends emails to contacts or accounts, you may be sending them to real people and companies of your organization. A good practice when you start working on your fresh sandbox is to make sure that you mask all contact or account email addresses and/or phone numbers. You can do this by downloading all contact IDs, email fields, and phone fields with data loader.

Then in the .csv exported you can work with Excel formulas to create new random values or put the same fake email and phone number in for all Contacts. Then, finally, update the records.


When you go to the org you will see the changes and can use those contacts safely, knowing no real contacts will get any random emails from you.

In addition, if you have an org that has a lot of customizations on contacts, such as triggers, process builders, workflow rules, etc., you may want to momentarily deactivate some of them to ease up the update process and not trigger any errors due to other existing processes.

Deactivating a trigger in a Sandbox is easy for a System Administrator, just go to any Apex trigger that executes on the Object Type “Contact,” edit it, and uncheck the Active. Remember to reactivate it after you finished updating the contacts by checking the Active box again.

Tip 3: Working on a process builder

So you checked the email deliverability, and your contacts and users have the right email addresses, but your process builder is still not sending the emails it’s set up to send.

First, and this might sound dumb, but happens so frequently it’s worth mentioning, make sure your process builder version is activated. Since every time you make a change you need to create a new version of it; you may be anxious to test out your change and forget that activation is necessary every time for your changes to take effect.

For workflow rules, once they are activated, if you make a change, the change immediately takes effect. This will never be the issue for your emails to not go out, no need to deactivate and reactivate with every modification.

Tip 4: Debugging a process builder

Here's a way to easily debug your process builder if you have doubts it’s actually executed.

Is the PB firing at all?

Add a decision step (0:21 in video) at the very beginning that always executes (with "No criteria—just execute the actions!"). Within that decision step, add a record update action that always executes on the record that triggers the process builder and in a text field of your choice add a text. This way if after the process builder is supposed to fire the text field changes to the text you entered, that means the process builder is at least firing, and likely not executing other actions because the other conditions in the decisions are not met or something else.

If it’s not firing, then check the conditions on the object that triggers the process. You may be trying to fire it when you are updating the record, but you selected the option “only when a record is created”.

Is the PB entering in a certain decision?

At the decision step in question (0:32 in video), add a record update action that always executes on the record that triggers the process builder and in a text field of your choice add a text. This way if after the process builder is supposed to fire the text field changes to the text you entered, that means it's meeting the condition and entering that decision branch and its other actions that are not executed for some other reason.

If it’s not entering the step, review the conditions in it. You can create a formula field of type checkbox in the object with the same criteria and see if it shows true or false.

If it’s false, there might be something in your step conditions or in the record that you are using for testing that is not set up correctly.

Tip 5: Check email templates

Email templates cannot be marked as not “Available for Use” when an Email Alert makes reference to them. So that’s never going to be the issue. When you try to make them unavailable Salesforce will not allow you to and show you where the template is referenced from:

But if you are using a Visualforce Email Template an additional issue may happen. When deleting a field, if that field is referenced in a Visualforce email template, Salesforce does not warn of possible references, and instead automatically changes the code to something with the id of the deleted field like:

<apex:outputField value="{!relatedTo.00N60000002yu4p}" id="test"/>

In some cases, this can cause an error in execution time because it's referring to a field that no longer exists. This may cause your email to not be sent out.

Extra Tip: Deploying Process Builders

To deploy a Process Builder to another environment you don’t have to manually reproduce it. You can use change sets to simply push your latest version to the target org.

  1. Go to Setup > Outbound Change Sets.
  2. Click New and enter the Name of your Change Set and a description if you want to.
  3. To include the Process Builder in your Change Set click Add.
  4. Select the Component Type you want to add.
    1. Here’s a tip that will save you some time: you will not find your Process Builder under “Process Builder” or “Lightning Process” or anything similar, all Process Builders appear along with Lightning Flows under the item “Flow Definition”.
  5. Select your Process Builder.
    1. Note that if you changed the name in versioning the Process Builder will still show here as the original name.
  6. Click Add To Change Set.
  7. Click Upload.
  8. Select the target org.
  9. Click Upload.
    1. Here’s another tip: the last version of your Process Builder will be uploaded, whether it’s the one active or not. So if the version you want to upload is not the latest one, make sure you delete the later versions to make your current version the last.
  10. Log into your target org and go to Setup > Inbound Change Sets.
  11. Your change set should appear within 30 minutes of uploading and you can click Deploy to deploy it.
  12. After Deploy go to Setup > Process Builder and make sure your Process Builder is active.
Conclusion

Patience. Breath. There is no recipe you can follow to troubleshoot issues. It’s a process of trial and error and learning every step of the way. Hopefully, this post will leave you with some ideas on how to debug your own processes using admin tools and save you a couple of hours of research (and some drops of sweat).

Resources

Here are some interesting articles, ideas, and exercises related to the topics we touched:

Do you have your own memorable lessons from your own trial-and-error? Tell me all about it in the comments below, in the Salesforce Trailblazer Community, or tweet directly at me @mdigenioarkus.





More by
Mario Di Genio