Don’t let the size of this little subflow fool you. Yes, it is short and sweet, but it is one of those handy little power house routines that you simply must have in your tool chest because you’ll use it all the time. All the time!
Overview of the Lookup RecordTypeId Flow
The basic gist of this flow is to receive two strings, the Object name and the Record Type name, and return the Record Type Id in 15- and 18-character formats.
The four main variables are ObjectName, RecordTypeName, and the two RecordTypeId variables. All are of type text. ObjectName and RecordTypeName are Input variables, RecordTypeId15, RecordTypeId18 and FaultMsg are Output variables, and TempVar is Private.
There is only one formula:
How it Works Step-by-Step
Two strings are passed into the flow variables ObjectName and RecordTypeName. In this example the string values (“Contact” & “EmployeeRecord”) are simply typed into the Source fields in the call to the subflow, although you could use constants or variables that house those values as well.
“Contact” is the object name. If the object was a custom object the value would be something like “CustomObjName__c”.
“EmployeeRecord” is the record type API name of the record type who’s Id is being looked up. In my naming convention I very often remove the underscores from the API names, but many administrators and developer’s conventions do not which would leave the “Employee_Record” as the API name.
Now for inside the flow
The Record Lookup
To get the record type Id you’ll do a lookup to the RecordType object.
The most important thing to note with this lookup are the field names of the RecordType object. The field that holds the object name, “SobjectType”, makes sense, however the field that holds the record type name, “DeveloperName”, isn’t as intuitive. Even thought in the record type definition the label says “Record Type Name,” the field that holds the record type name is the DeveloperName field.
Finally, the Id of the record that matches your criteria is stored in the private variable, “TempVar”.
Assigning the Output Variables
The second and last step (don’t you just love these simple and straight-forward solutions?) is to assign values to the two output variables:
Why Return Two Different Lengths?
The outputs for the flow are two record type Id’s–one that is 18 characters long and the other 15 characters. Why two different lengths? In most situations I just use the 15-character Id and it works just dandy, but every so often I need the 18-character Id, such as when I’m looking for a match to a formula field that has a CASESAFEID for its value.
The Fault Handler
Just in case there is a fault during the Record Lookup, I have a very simple fault handler that assigns the fault message to the output variable “FaultMsg”:
The reasoning behind handling the fault in this way is to allow the calling routine to decide how to handle the error if a fault occurs. The default value for “FaultMsg” is the empty string global variable, so the calling routine would just need to make sure that the value received from this variable is still an empty string to know that the Id lookup was successful.
And there you have it!