Using Record Type Developer Name in Flow Start Criteria

Referencing the Record Type Developer Name in your flow Start Element criteria is a technique every admin need to add to their toolbox. It requires no new field or query, and it follows the lean flow design practices we always promote.

If you build automations for objects with multiple record types, such as Accounts, Leads, Opportunities, or Cases, you have likely wrestled with filtering records efficiently. In this detailed guide, we break down why you should stop hardcoding IDs, why Developer Names beat UI Labels every time, how to set up entry criteria formulas using RecordType.DeveloperName, and how to work with record type values inside your flow execution logic.

The Golden Rule of Salesforce Resource Naming Conventions

Before getting into configuring flow start element criteria, let me touch on foundational best practices: naming conventions.

When creating fields, objects, flow resources, and record types, admins are often tempted to use shorthand acronyms or quick abbreviations to save typing effort. For instance, you might label a record type “AE Account” or “SMB Opp”.

However, best practices tell us that you should refrain from using abbreviations or acronyms until running out of space in the maximum character length allowed. For example, Account Executive is a vastly superior label and name compared to AE. The acronym “AE” could mean Account Executive, Application Engineer, Account Entity, or Adverse Event. While you should always populate the Description and Help fields for every metadata item you build, remember that descriptions are not visible front-and-center when using the Command Line Interface (CLI), change sets and other deployment tools, or resource pickers.

When defining Record Type Developer Names (API Names), adhere to these core principles:

1. 1. Be explicit and descriptive: Use full, self-explanatory names like Partner_Account or Enterprise_Opportunity.
   2. Use consistent casing: Maintain PascalCase, snake_case or your preferred case-style consistently across all objects in your org.
   3. Avoid environment-specific words: Never put terms like “Test” or “Prod” in Developer Names. Remember that they will all end up in prod one day, and you should keep the name the same among different environments.

Why You Must Use Developer Name Over Label or Record Type ID

When filtering or branching by record type in Salesforce, admins generally encounter three options: Record Type ID, Record Type Label (Name), and Record Type Developer Name (API Name). Here is why Developer Name is the undisputed winner.

Hardcoded Record Type IDs Are Deployment Landmines

Record Type IDs are 15-character or 18-character alphanumeric strings (e.g., 0123x000000ABCDEAA). These IDs are org-specific. IDs in especially disconnected environments like scratch orgs can be different then production orgs. Hardcoding an ID inside a flow filter, decision element, or formula causes your flow to fail or process wrong records upon deployment. Furthermore, hardcoded IDs make formulas unreadable, providing zero context to another admin reviewing your work later.

Record Type Labels (Names) Are Unstable

Record Type Labels represent human-readable text displayed on the user interface. While labels look friendly in formulas, using labels in automation introduces serious risk. UI labels are frequently modified during re-branding efforts, localization updates, or business process renames. If an admin updates a label from “Key Account” to “Enterprise Account,” any flow referencing RecordType.Name = "Key Account" silently stops executing for new records.

Developer Names Are Built for Stability

Developer Names (API Names) are locked upon creation and designed specifically for programmatic references, Apex code, and flow formulas. Developer Names remain consistent across Sandboxes, Developer Orgs, and Production environments. API names should never be changed on critical resources like Record Types without careful testing. By using RecordType.DeveloperName, your flows remain rock-solid regardless of UI re-labeling or multi-language translations.

How to Reference RecordType.DeveloperName in the Start Element

Historically, setting up entry criteria in a record-triggered flow Start Element required selecting RecordTypeId and pasting an 18-character ID. To bypass this, admins built workaround formula fields on the object or added a Get Records element inside the flow.

Fortunately, you can reference the triggering record’s Record Type Developer Name directly in the Start Element using the formula editor inside the start element for your condition requirement.

When adding a record type name to the criteria for the record-triggered flow start element, you need to use the formula editor, since this allows you to traverse the lookup relationship to the RecordType.DeveloperName resource. You cannot refer to this cross-object field in the basic condition builder without using the formula editor.

Step-by-Step Configuration:

1. 1. Open your Record-Triggered Flow and click the Start Element.
   2. Select your target object (e.g., Account or Opportunity).
   3. Set Trigger the Flow When: to A record is created, updated, or created or updated.
   4. Under Condition Requirements, pick Formula Evaluates to True and go to your Formula Editor inside the start element.
   5. In the formula editor box, enter your entry formula traversing $Record to RecordType:

{!$Record.RecordType.DeveloperName} = "B2B_Account"

If you need your flow to trigger for multiple record types or combine additional field conditions, wrap them in standard logical functions:

AND(
    OR(
        {!$Record.RecordType.DeveloperName} = "B2B_Account",
        {!$Record.RecordType.DeveloperName} = "Enterprise_Account"
    ),
    ISPICKVAL({!$Record.Status__c}, "Active")
)

Filtering at the Start Element using a formula ensures Salesforce evaluates whether the flow needs to run before initializing flow execution, saving system limits and guaranteeing optimal performance across your organization.

Working With Record Types Inside Your Record-Triggered Flow Without “Get Records”

The benefits of this technique extend far beyond the Start Element. Once your flow executes, you often need to check record types in Decision elements or assign record types when creating or updating records. You do not need a Get Records element to inspect the triggering record’s record type inside a record-triggered flow.

Decision Elements

In any Decision element inside your flow, reference {!$Record.RecordType.DeveloperName} directly in the resource picker:

• • Outcome 1: {!$Record.RecordType.DeveloperName} Equals B2B_Account
  • Outcome 2: {!$Record.RecordType.DeveloperName} Equals Partner_Account

Accessing RecordType Id Directly

What if you need to pass RecordType Id into a subflow or assign it to a newly created child record? Because Salesforce automatically hydrates the $Record global variable, {!$Record.RecordTypeId} is already populated and accessible throughout your flow! You can reference {!$Record.RecordTypeId} anywhere without querying the RecordType object.

When You Need to Set the Record Type Value on Create or Update

When you want to create or update records in flows (not only limited to record-triggered flows), you will need to set the record type Id value. This means you will somehow hardcode the record type into your flow. Following the guidelines I listed above, you don’t want to hardcode the RecordType Id into your flow. You will get the RecordType Id using the RecordType.DeveloperName value you will hardcode and save into your flow. This is a solid and resilient approach compared to other alternatives.

I personally create a constant for everything I hardcode in the flow. This allows me to see instantly on the left resource panel what was hardcoded. I can quickly review these values and fix/revise them in one spot if it is necessary.

Build Deployment-Safe Flows With These Habits

Leveraging RecordType.DeveloperName in your flow start criteria and decision logic is one of the easiest best practices you can adopt today. To recap:

1. 1. Adhere to clean naming conventions: Avoid ambiguous acronyms (like AE) in labels and API names.
   2. Never hardcode IDs or use UI labels: Stick exclusively to DeveloperName for stable, deployment-safe flows.
   3. Use Start Element Formula Editor: Set condition requirements to “Formula Evaluates To True” and traverse {!$Record.RecordType.DeveloperName}.
   4. Skip Get Records: Access {!$Record.RecordType.DeveloperName} and {!$Record.RecordTypeId} directly from the global $Record variable.
   5. Get RecordType Id using DeveloperName for create/update.

By following these principles, you will build faster, cleaner, and more maintainable Salesforce automations.

To help tailor future guides and automations to your exact setup, I would love to hear from you:

1. 1. What object or business process in your org currently uses record types in record-triggered flows?
   2. Are you currently using hardcoded IDs or Get Records elements that we can help refactor into this clean approach?

Explore related content:

Salesforce Timezone Offset: A Native Flow Alternative to Apex

When Your DMLs Have Criteria Conditions Other Than Id

Salesforce Flow Best Practices