Hard Coded IDs

Why are hard coded IDs bad?

Oh boy, this is a big one. Hard coded IDs in a flow makes it riskier to deploy. Record IDs will likely vary across environments, which will cause the flow to fail when deployed to other environments. Finding hard coded IDs can be very difficult because there are so many places they can sneak into a flow.

What can be done to avoid using hard coded IDs?

Since there are a number of places where hard coded IDs can surface, we'll give you some patterns to follow in those most common cases.

Start element for a record-triggered flow

This one was hard to avoid before the Summer '22 release, but with that release came the ability to use a formula as entry criteria in record-triggered flows. This opened up the capability to get fields from the parent record in a lookup relationship in the context of the start element.

For instance, let's say we only want to run a record-triggered flow on person accounts, which translates to the PersonAccount record type. Instead of hard coding the record type ID, we can use a formula to use the name of the record type.

1. For condition requirements, select Formula Evaluates to True.
   
2. Use the resource picker to navigate from the record through the record type to use it's name
   

In the body of the flow

Hard coded IDs can surface in the body of a flow in many places, but there is one pattern that should help take care of all of those cases. Instead of hard coding the IDs, you can simply query the records and use their ID from that record reference. Yes, this even works for things like profiles and record types.

Let's take the use case where we want to change the record type to be a Person Account. Instead of hard coding that record type ID, you can query for the record type ID instead and use that record reference.

1. Get Records element to query for the record type record
   
2. Use that record type record to update the account