Designing Process Builder Criteria to Handle Record Types with Old Data

I haven’t blogged in forever… I have an excuse. Here she is:

DR-82-255.12.full

My beautiful girl, Teagan Elizabeth Goerke

I had to give you all a good reason for being absent for so long. Now that the cute stuff is over, let’s get down to business. Process Builder business that is.

I recently ran into this scenario and you might run into it too. I’ll share how to fix it.

Business Scenario: Old records have no Record Type associated with them but more recent records do have a record type assigned

Error: Process fails with “The flow failed to access the value for [example] because it hasn’t been set or assigned.”

The more relevant error in our scenario is this:

Error element myDecision (FlowDecision).
The flow failed to access the value for myVariable_current.RecordType.Name because it hasn’t been set or assigned.

When records don’t have a record type assigned they technically do. It’s called the Master Record Type and each object gets one when it’s created, even standard objects. You just can’t see it. So, it’s odd that this error would come up with this scenario. I would expect it if we were working with a lookup variable that wasn’t required. But I didn’t expect it for Record Type. But it seems Process Builder can’t see the Master Record Type either. Bummer.

We have two fixes:

  1. Update all our records with a Record Type – Somewhat impractical for some situations
  2. Design our Process Builder to work with blank Record Types – Much more practical

I’ll focus on #2.

You should read this article as it describes the fix: https://help.salesforce.com/articleView?id=Process-fails-with-The-flow-failed-to-access-the-value-for-example-because-it-hasn-t-been-set-or-assigned&language=en_US&type=1

But here’s a walk through:

Screenshot - 8_26_2017 , 7_25_16 AM

No Record Type

Now our Process

In our first design we only accommodate for the Record Type:

Screenshot - 8_26_2017 , 7_29_19 AM.png

But this design will cause errors for blank record types.

A better design is to first check for a blank record type as well as a specific record type. Like this:

Screenshot - 8_26_2017 , 7_32_41 AM

It’s important to note that you should always put the blank Record Type criteria step as always before any additional Record Type criteria evaluation against other values. It doesn’t have to absolutely be first but it needs to be before all the other Record Type references.

As a best practice from a Design perspective, if your Object contains records with blank Record Types then you should build your Processes to accommodate those records or your users will get errors and no one likes flow errors.

Multi-Select Picklist Formulas

Business Problem:

Most Salesforce Administrators have run into this issue from one time or another.  A Multi-Select Picklist is not accessible in formulae.  This is frustrating because Multi-Select picklists are great choices for data quality and user experience and it’s not always known at the planning stages that you will need to utilize the field in question for a formula.  
 
Formula Solution:
 

IF(
INCLUDES(Multi_Select_Picklist__c , “A”), “A”,
IF(
INCLUDES(Multi_Select_Picklist__c , “B”), “B”,
IF(
INCLUDES(Multi_Select_Picklist__c , “C”), “C”
, NULL
)
)
)

A while back, Salesforce.com released the use of the INCLUDES()function which is a function that checks a text based value and returns a boolean (true/false) value.  Since the database result of a Multi-Select Picklist is a text based value we can utilize the INCLUDES() function.  By database result, I mean how the value is actually stored in Salesforce.com.  When you save a Multi-Select Picklist it’s values are saved as text with comma’s separating the values you selected.  In the example above, If I selected all the values the value that is stored is actually “A, B, C”

But… what if I select more than one option in my Multi-Select Picklist?  In this case, you must build in each option included in a AND() Function.  Here’s an example:

IF(
AND(
INCLUDES(Multi_Select_Picklist__c , “A”),
INCLUDES(Multi_Select_Picklist__c , “B”)
)
, “A; B”, NULL
)

Tricks all Salesforce Admins Need part 6 of 7 – Change Management Process #ForceFriday

So you want a Change Management Process eh?

Change Management is a huge topic and could encompass a few books worth of content, even just covering Salesforce Change Management. The scope is far too much for a single blog post. Suffice to say I have no intention of trying to tackle that topic in this post so you can safely continue reading knowing that there will indeed be an end.

What I did want to call out in this post is one significant reason why a Salesforce Change Management Process is needed and why you as the Salesforce Administrator should be using one.

Why you need a Salesforce Change Management Process

Have you ever heard the phrase “What gets measured gets done”? Its true.

If you aren’t measuring yourself then who is?

Ask yourself how you are managing Salesforce changes now. Through Email requests? Sticky Notes? Colleagues walking up to your desk or casually mentioning user requirements to you in the bathroom?

XqFmdnM - Imgur

If you aren’t tracking and measuring your changes within Salesforce then they aren’t really happening. Tracking them in a formal way allows you to measure how much time you are spending making these changes, what changes are being made, who requested them, who approved them, etc. Additionally, there is an often overlooked measure of change management that can be tracked in Salesforce which is the net affect of the change itself. Being able to quantify a changes value in perpetuity goes a long way in measuring your impact and value to an organization.

Here’s an example:

Durham Doughnuts Sales Staff spend an average of 10 seconds on each opportunity finding and selecting the correct Pricebook. The Sales Staff consists of 5 Sales Reps and each generates an average of 6 Opportunities a day. The Pricebook is defined by the Type of customer on the Account so often times the Sales Rep has to navigate to the Account to verify the Account Type.

Our System Administrator logs the entry in her Salesforce Change Management system and proceeds to use the Process Builder to default select the correct Pricebook for each Opportunity. This change effectively saves an average of 5 minutes (10 Sec * 6 Opps * 5 Reps) per day or about 21.66 working hours per year (260 working days * 5 Min).

This is a simple example but it does show how a simple change can go a long way. Now, imagine you never tracked this change or its effectiveness and I asked you what impact you made for your organization last year. If you didn’t track the change and measured its effectiveness your answer better be zero, otherwise I’m going to ask you to prove it.