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.