Have you ever migrated your Salesforce data or fields into another org? Do you develop your new features in a Sandbox first? (And if not, WHY?)
If you answered “no” to both of these questions, ask yourself if you can safely say you will NEVER do so.
Chances are that any given admin will, at some point in their admin career, have to either migrate at least some part of your Salesforce, or at the very least be REQUIRED to build something complex in the Sandbox first, so as not to impact current process. If your company gets acquired, there’s a very good chance you’ll have to merge orgs. One way or another, you’re probably going to be beholden to this fact of life. The business world necessitates preparedness for just such an eventuality.
Previously, I had thought this would never be a problem. I’d never had to release anything that was so impactful that I couldn’t build in production and delay its effect (pardon me a moment while I slap my own wrists). I didn’t anticipate a full org merge with another Salesforce org, though I really should have. So I didn’t foresee the pain that would be, the horror known as: HARD-CODED RECORD TYPE IDs.
You may think that using hard-coded IDs is not a big deal, and if you only have one or two uses, it’s probably not. But over time, the practice can become pervasive in your admin methodology, and it will then grow well beyond those happy few. I mean, let’s face it, most of the time it’s a lot easier to deploy than other solutions, right? Just referencing a single ID is a lot simpler than writing the formulas, workarounds and methods needed to not use them, right?
The trick is, this trap has two kinds of cheese. The first is the fact that it’s usually easier, but the second is the fact that we as admins and developers often come to the conclusion that there is no workaround. Years ago this used to be the case, but today we have a lot more tools at our disposal, and many of the cases where we would be forced to use a hard-coded ID are not actually cases where we are truly forced, if we just keep working and digging at a solution.
Then I had an org merge to work. Because of our long-standing practices in our 5-year-old org, we had hundreds of single hard-coded IDs in our system. The trap had closed. In order to merge our system into theirs, we would have to reconcile ALL of those. We had a mountain of work ahead of us, because we had not looked ahead.
In working on solutions, I have developed a way to avoid hard-coded Record Type IDs in Visual Workflow. This has traditionally been a place which is widely considered to be inescapable for hard-coded IDs, but today I say thee NAY. There is a way!
(UPDATE: I had previously published a kludgey way of doing this, but it turns out there is a better way to do it that Salesforce has provided! Special thank you to MVP Aiden Martin for pointing out this exists!)
Create a Record Lookup, and when choosing what object you’re looking at, choose “RecordType“. Many an admin have glossed over that picklist choice, not even realizing it’s there, but this is an object usually referenced by Apex or API for the purposes of finding RecordType information. Because it’s in the API, we can use it in the Flow!
In your filters, choose “SobjectType” and set this to the object whose record type you are looking up. To determine which record type to use, I recommend using DeveloperName instead of just Name; the Name is the equivalent to the Record Type’s label, and is more likely to change. By basing it on the DeveloperName, you’re less likely to have issues with the name changing and breaking your flow.
Assign the Id value into a variable for use later and BOOM! You now have your Record Type ID stored in a variable for using later in your flow, and you didn’t have to manually enter it into the Flow. If the Record Type changes to a different ID in the future (and odds are it will), you will not be screwed. I REPEAT: you will NOT be screwed.
This is a great idea but instead of querying object records, why not query the RecordType object and get the appropriate id. It would be more efficient and not rely on dummy data being in production.
Your posts on Flows have been great.
That’s awesome, I did not know that was there before! I gonna have to rewrite this post for that! Thanks for pointing it out!
That was awesome, thanks!
When I run this from a site that uses Authenticated Website, I get an error.
caused by element : FlowRecordCreate.Create_Reporting_Request
caused by: UPSERT — UPSERT FAILED — ERRORS : (INVALID_CROSS_REFERENCE_KEY) Record Type ID: this ID value isn’t valid for the user: 012L00000009EjNIAU — for SFDC record with ID : null,
Sorry for the delay on this! It sounds like the user doesn’t have access to the Record Type you are trying to define. If there is an authenticated user profile that the user is on, you should make sure they have create or edit access (as needed) on the object. You can also add the Record Type access itself on the profile, though I had previously thought that Record Type restrictions only apply to using the UI, and not on a deny-access kind of level.
Hi, I am just not seeing where I would put the dev name of the record type. It seems like no matter what I do I am being asked to create a new variable but at no point am I given the option of enter the value or selecting it somewhere.
Am I not looking at this correctly? I feel like I am waaaay off track here.
Creating the variable is the first step, and it is a complete step in and of itself: just create it and hit save. The variable then is created and ready to be used. You can then use a Record Lookup to find the ID, using the Dev Name as criteria, and you’ll be given the option of where you want to save your data. You can then select the variable, and choose to apply the Record Type’s ID to it.
Great Work! Solved my problem by getting involved with custom settings.
Thank you for the help.!