Hardcoded Record IDs in Flows: The Sandbox Surprise
“Hardcoded a Record Type ID in a flow. Deployed to production. Different ID. Everything broke.”
What Happened
I had a flow that assigned a specific Record Type to new Cases. I grabbed the Record Type ID from sandbox and hardcoded it in an Assignment element. Deployed to production via change set. The Record Type existed in production but with a completely different ID. Every new Case got assigned to nothing. Took me two days to figure out why Cases were missing their Record Type because the flow wasn't throwing errors — it was just silently assigning an ID that didn't match anything.
The Wrong Way
// Assignment Element in Flow:
// Set {!newCase.RecordTypeId} = "0125f000000ABC1AAA"
//
// This ID is from SANDBOX.
// Production has the same Record Type but the
// ID is "0121g000000XYZ2BBB".
// Silent failure. No error. Just wrong data.The Right Way
// Get Records Element (before the assignment):
// Object: RecordType
// Filter: SObjectType = "Case"
// AND DeveloperName = "Support_Case"
// Store in: {!supportRecordType}
//
// Assignment Element:
// Set {!newCase.RecordTypeId} = {!supportRecordType.Id}
//
// Now it works in ANY org. Sandbox, prod,
// scratch org, doesn't matter.The Lesson
Never hardcode Salesforce IDs anywhere. Not in flows, not in Apex, not in formulas. Query by DeveloperName or use Custom Metadata. IDs are org-specific.
Enjoyed this? Get more like it.
Glen's Musings — AI, investing, and building things. Occasional. Free.
More Flows Mistakes
The Infinite Flow Loop That Ate Production
Record-triggered flow updates the same object. Flow fires again. And again. And again.
Read morePainfulGet Records Inside a Loop: The Governor Limit Speedrun
Put a Get Records element inside a loop. Hit 100 SOQL queries on the 101st record.
Read moreAnnoyingThe Flow With No Fault Path (Enjoy Your Cryptic Error)
Deployed a screen flow with no fault handling. Users got 'An unhandled fault has occurred' and I got 50 support tickets.
Read more