Record-triggered flow fails on Update Records element due to invalid picklist value

After updating a picklist field’s values in our custom object, a record-triggered flow started failing on the Update Records element. The flow has been working fine for months but broke immediately after we modified the picklist.

Error message:


An error occurred: INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST
Field: Project_Status__c
Value: In Progress

What we changed:

  • Renamed picklist value from “In Progress” to “In_Progress” (removed space, added underscore)
  • Updated the API name to match: In_Progress
  • The label still shows as “In Progress” in the UI

The flow’s Update Records element has a hardcoded assignment: Project_Status__c = “In Progress”. We’re not sure if we need to update this to use the new API name or if there’s a field-level consistency issue. The flow error handling doesn’t provide enough detail about whether it’s looking for the label or API name. Has anyone dealt with picklist value management issues in Flow Builder after field updates?

The root cause is the mismatch between your flow’s hardcoded picklist value and the updated field API name. Let me walk you through the complete solution addressing all three focus areas.

Picklist Value Management: When you renamed the picklist value API name from “In Progress” to “In_Progress”, Salesforce updated the field metadata but didn’t update existing references in flows. The error occurs because Flow Builder validates picklist assignments against the current API name, not the label.

To fix the immediate issue:

  1. Navigate to Setup > Flows
  2. Find your record-triggered flow and click ‘Edit’
  3. Locate the Update Records element that’s failing
  4. Click on the Project_Status__c field assignment
  5. Change the value from “In Progress” to “In_Progress”
  6. Click Done, then Save As > New Version
  7. Activate the new version

However, there’s a better approach than hardcoding picklist values.

Flow Builder Error Handling: Implement proper error handling to catch picklist validation failures:

  1. After your Update Records element, add a Decision element named “Check Update Success”
  2. Add outcome: “Update Failed” with condition: {!$Flow.FaultMessage} Is Null = False
  3. Under the “Update Failed” path, add these elements:
    • Assignment: Store {!$Flow.FaultMessage} in a text variable
    • Create Records: Log the error to a custom Error_Log__c object
    • Send Email: Notify admins with error details

This prevents silent failures and gives you immediate visibility when field changes break automation.

Field API Name Consistency: The best practice is to avoid hardcoded picklist values entirely. Instead, use dynamic references:


Flow Structure:
1. Get Records: Query PicklistValueInfo where
   EntityParticle = 'CustomObject__c.Project_Status__c'
   AND MasterLabel = 'In Progress'
2. Assignment: Set {!StatusValue} = {!GetPicklist.ApiName}
3. Update Records: Project_Status__c = {!StatusValue}

This approach queries the actual picklist metadata at runtime, so if you rename API names in the future, the flow continues working as long as the label remains consistent.

Alternatively, for simpler flows, use a formula to reference the picklist:

  • Create a formula field: Project_Status_Formula__c
  • Formula: TEXT(Project_Status__c)
  • In your flow, update using the formula field reference

Prevention Strategy: Before modifying picklist API names, always check dependencies:

  1. Setup > Object Manager > Your Object > Fields > Project_Status__c
  2. Click “Where is this used?” button
  3. Review all flows, process builders, and validation rules
  4. Update each reference BEFORE changing the API name
  5. Test in sandbox first

Additional Considerations:

  • If you have multiple flows using this picklist, create a reusable subflow that handles the picklist value logic
  • Use Flow Custom Metadata types to store picklist mappings externally
  • Enable Flow Debug Logs (Setup > Process Automation Settings > Enable Debug Logs) to capture detailed error context
  • Document all picklist API name changes in your release notes

For your specific scenario, the quickest fix is updating the hardcoded value to “In_Progress”. For long-term maintainability, refactor to use dynamic picklist references or formula fields. This prevents future breaks when picklist definitions change and ensures your flows remain resilient to field metadata updates.

I hit this same issue last month. The problem is that Flow Builder caches picklist values when you build the flow. Even if you update the picklist definition, the flow still references the old API name internally. You need to edit the flow, remove the Update Records element completely, then re-add it and reconfigure the field assignment. Just changing the value in the existing element doesn’t always work because of the cached metadata.

When you assign picklist values in Flow, you must use the API name, not the label. Since you changed the API name from “In Progress” to “In_Progress”, your flow assignment is now invalid. Open the flow, find the Update Records element, and change the literal value to “In_Progress” (with underscore). Save and activate the new version. This should resolve the error immediately.

Add error handling to your flow to prevent this in the future. After the Update Records element, add a Decision element that checks if $Flow.FaultMessage is null. If not null, create a custom error record or send an email notification with the fault details. This won’t fix your current issue but will give you better visibility when picklist or field changes break automation. For the immediate problem, you definitely need to update the hardcoded value to match the new API name.

This is a common gotcha with picklist field API name consistency. When you rename a picklist value’s API name, Salesforce doesn’t automatically update references in automation tools like Flow, Process Builder, or Apex. You have three options: 1) Update all flows to use the new API name, 2) Change the picklist API name back to match what your flows expect, or 3) Create a new picklist value with the old API name as a temporary bridge while you migrate flows. I recommend option 1 for long-term maintainability.

Use a Get Records element before your Update to validate that the picklist value exists. Query the picklist field’s metadata and check if your target value is in the valid values list. This adds a safety check before attempting the update.