Salesforce Winter ‘25 Release: How to use the updated ‘Create Record’ functionality

In this article...

It’s the most wonderful time of the year: Salesforce Winter ‘25 Release time!!

As a Salesforce Consultant who loves working with, and pushing the boundaries of, Flow this is one of my highlights of the season.

The other, more self-indulgent highlights are copious amounts of mulled wine and gorging on chocolate treats.

The Winter ‘25 Salesforce Release is jam packed full of enhancements to Flow functionality and the updated ‘Create Records’ is one feature that I wanted to give some focussed attention to.

Prior to this latest release, ‘Create Records’ did exactly what is said on the tin; it allowed you to create new Records. If a Salesforce Admin wanted to update records in Salesforce Flow, they would have no option but to use the ‘Update Record’ Element.

As part of the Salesforce Winter ’25 Release, the ‘Create Records’ Element can now multi-task; it can be used to either create or both create and update existing records. But, what does this mean in practice?

 

How do we configure the ‘Create Records’ Element?

At face value, the configuration of the ‘Create Records’ Element appears fairly straightforward with few decisions to make.

In order to update records, you need to first enable the ‘Update Existing Records’ functionality.

Next, there are three different options available to identify the records that you would like to update: you can select either the Record ID, an External ID (select an External ID Field) or a Standard Field (e.g. on an Opportunity, Opportunity ID or Name).

Finally, you are able to specify what you would like to happen if a create or an update fails. You can choose between ‘Process successful records’ and ‘process no records’:

 

 

After configuring the ‘Create Records’ Element as above you may have two questions you’d like answered:

  • Under what circumstances would a Salesforce Flow fail?
  • How would I know which records have failed to be created/updated?

 

Why do Salesforce Flows fail?

There are many reasons why a Flow could fail and below are some key examples, relevant to creating and updating Records.

  • The Flow neglected to populate a Required Field
  • The Flow met a Validation Rule requirement
  • A governor limit was hit
  • The wrong Field or Variable was used in the Flow
  • Permission errors: the Object and Field Level Security for the Running User has not been set up properly.

 

How will I know which records have failed?

If a Flow fails, and only successful records are updated, I would like to know which records have failed.

In order to answer this question we will create a Salesforce Screen Flow with the following Use Case.

As the CEO of “Hallowe’en ‘R’ Us”, I would like be able to:

  • Send a trick or treat to all Contacts of selected Client Accounts.
  • Create new Contacts associated with any Account if the Account/Contact information is out of date.
  • Send Treats only to Active Customers
  • Ensure ‘Active Contact’ is a Required Field

To ensure our Flow will fail, I have added a Validation Rule to ensure only Active Contacts  receive Treats.

 

AND(

Active_Contact__c = False,

ISPICKVAL( Trick_or_Treat__c , "Treat")

)

 

We will not add any Decision Elements or Entry Criteria to bypass the Validation Rule, omitting the ‘Active Contact’ Field will prevent those records from being created because it is Required on the page layout.

Best practice is to build a Salesforce Flow designed not to fail, utilising entry criteria and decision Elements so it only runs for records with good data.

 

 

How do we create a Screen Flow?

  1. Add Screen with:
    • Lookup Field to Account,
    • Action button to retrieve Contacts associated with the selected Account,
    • Data Table to display the associated Contacts configured to allow the User to select multiple Contacts,
    • Pickllist with the values ‘Trick’ and ‘Treat’,
    • Repeater Component to add additional Contacts,
    • Checkbox to allow for additional Accounts.
  2. Loop through each of the selected Contacts and assign the ‘Trick or Treat’ value. These are then added to the record collection ‘var_New_And_Updated_Contacts’ (see flow diagram below)
  3. Loop through each of the ‘Added Items’ in the Repeater Component with ‘First Name’, ‘Last Name’, and the selected ‘AccountId’ & ‘Trick or Treat’ values
  4. Add ‘Create Record’ Element and configure to create and process all successful records if the Flow fails, identified by their Record ID
  5. Add a Fault Path and Screen to display the Error Message.

 

 

Watch the Flow in Action

 

The Results…

 

Below are the Contact records associated with United Oil & Gas Corp. before and after we ran the Flow.

As we can see from the video, the Flow did fail, however, the records that did not hit the Validation Rule were updated. Owing to the Required Field not being assigned in the Flow, no Contact records were created.

Before Mass Update

 

After Mass Update

 

As you can see four records were successfully updated where the Contacts are active, four records failed to update where the Contacts are inactive.

Before the Winter ’25 Release, if you had tried to update all of these Contact records using the ‘Update Records’ Element, the Flow would have failed.  As a result of the restrictions of the Validation Rule,  no records would have been updated.

In contrast, if you update records using the Winter ’25 ‘Create Records’ Element, the Flow would still fail owing to the Validation Rule. However, those records that did not hit the Validation Rule would be updated! Happy days, or is it?

 

How do we know which records failed?

By adding a Screen to display the Flow Error Message, we can see four records had failed to be updated owing to a Validation Rule exception.

 

 

In terms of knowing how many records have failed to be created, the only indication is “The error occurred for these records: null” and that isn’t very helpful! 🤷‍♀️

Additional points to note:

  • There is no Failed Flow Interview Record in this instance.
  • The quantities of successes and failures are not given.

 

How powerful is the Salesforce Flow ‘Create Record’ Element?

In this example, we can see its potential, but the updated ‘Create Record’ Element is powerful and must be used carefully. With great power comes great responsibility. 🦸‍♂️🦸‍♀️

When selecting to only update or create successful records, only those that did not trigger a Validation Rule or those created without, for example, a missing Required Field will be successful.

In terms of data integrity, for this example, this is positive as it will only succeed on qualified records.

 

How do we stay safe with this new Element?

If we  are using the new ‘Create Records’ Element, we need to ensure we are:

  • Confident in our ability to define a successful record in the context of our Flow
  • Able to report on the outcome of the update.
    • Can we reconcile the number of successful vs unsuccessful record updates?
  • Adding a Fault Path to allow any further automation within the Flow to continue.
  • Even if one of the records succeeds, you will not have a Failed Flow Interview to interrogate. 😡

 

My thoughts on the updated Salesforce Winter ’25 ‘Create Record’ functionality.

Having had a deep dive into the updated Salesforce Winter ’25 ‘Create Record’ functionality there are some rather significant considerations.

When using the ‘Create Records’ Element, we can stipulate that only successful records will be updated.

However, the point of failure is the lack of transparency regarding the number of records processed successfully and those that failed.

Would I use the ‘Create Records’ Element to update records? I would most definitely use the Create Records element to create and update records. However, I would not allow it to process successful records in the event of one failure. It is important I am confident with the position I am in with regards to the data being updated and created.

I would love to know your thoughts, please message me on LinkedIn.

Work with Desynit

Looking for exceptional, professional Salesforce support?

Our independent tech team has been servicing enterprise clients for over 15 years from our HQ in Bristol, UK. Let’s see how we can work together and get the most out of your Salesforce implementation.