This post is part of a technical series to help Salesforce Admins automate business processes using Flow.
Just about every automation you build in Salesforce Flow needs to modify and update records at some point. It may be the most common Flow use case. However, as with many things in Flow, the options and nuances can make it a little daunting at first. We'll walk you through it.
Here's what's on the agenda:
- The Update Records element
- The Assignment-Update pattern
- Mass updates in one step
The Update Records element
Click the + button in your Flow under the Get Records you just added, scroll down and select Update Records.
The Update Records element has two modes [1,2] under the clumsy label of "How to Find Records to Update and Set Their Values". Clearly Salesforce quite didn't know what to call these either. Depending which you select, the bottom section  changes. We'll get to that in a minute, but first let's demystify each option:
- Use the IDs and all field values from a record or record collection - This is a lot like what happens when you edit a record in the Salesforce UI and click Save. You load up a record detail page (Get Records), make a set of pending changes (Assignment) and then click Save (Update Records) to save all of them at once.
- Specify conditions to identify records, and set fields individually - This option allows you to get records and make changes in one operation. There's really not anything in the Salesforce UI to compare it to. It's most similar to a SQL Update statement. It can, however, save you a bunch of work when dealing with collections of records.
Which should you choose? Most of the time, you'll use Option 1. Option 2 is only useful if you need to set the same fields to the same values for a collection of records. If you do need to do that though, it's very useful because it saves you from having to build a loop.
The Assignment-Update pattern
Most often you'll find yourself getting a particular record (either by Get Records or automatically with a trigger), doing some field assignment using the Assignment element and then using Update Records. Let's go through an example.
Suppose your partner team asks you to assign every new Lead that comes in with source of "Partner" to one of their two BDRs, Fiona or Brian. Texas is your biggest market so everything in Texas goes to Fiona and everything else goes to Brian.
Set up the trigger
To set this up we'll use a Record-Triggered Flow with Auto-Layout. We'll set up the start element to only fire when the record is created. We'll also want it to fire only for Lead objects where the LeadSource field is set to "Partner".
Assign a value to OwnerId
Now, let's use a Decision element to figure out what region this lead is in.
We label this Decision "Choose Region" and use "Choose_Region" for the API Name. We name our first outcome Texas  and give it an API Name of "Choose_Region_TX" . We use the special trigger variable called $Record which represents the Lead that triggered this Flow and ensures that the $Record's State field  is equal to "TX" . Then we name the default outcome to "Other" .
The Decision you created will give you two paths labeled "Texas" and "Other". Under the Texas path, we add an Assignment element to set the OwnerId to Fiona's Id. Let's assume we already know her Id 005000000000000001.
Under the "Other" outcome, we add an Assignment to set the OwnerId to Brian's Id which we know is 005000000000000002.
Here's what it looks like so far.
We've done the "Assign" step in the Assign-Update pattern. Nothing's saved just yet. That's what the Update step is for.
Update the record
Where the two paths of your decision come together, click the +, scroll down and select "Update Records".
We're using the first option  in the Update Records element and using the special $Record variable  that represents the Lead that triggered the Flow. That allows us to update the Lead record after doing the ownership assignment.
Here's the final flow implementing the Assign-Update pattern.
You'll see this pattern play out again and again in flow. You might use it in a trigger like this example or possibly preceded with a Get Records to get a record to operate on.
Now let's turn our attention to a different approach enabled by Update Records: doing mass updates in one step.
Mass updates in one step
As we mentioned above, Update Records has an "Option 2" that you can use to update a set of records that meet some criteria. This allows you to do an update en masse with minimal effort.
Here's a common example where this comes in handy: ensuring that all the Contacts associated with an Account have their owner change every time the Account owner changes.
Set up the trigger
This time we set up a Record-Triggered Flow that fires whenever an Account is created or updated.
Check for owner change
We add a decision to check that the Account owner has changed.
Note that we're making use of another special variable Flow provides, $Record__Prior . This contains the values of the Account before the trigger fired. This means we can compare a field from $Record__Prior with field from $Record  and see if it's changed. That's exactly what we're doing here to see if the OwnerId has changed.
Mass update related contacts
Click the + button on the True path of the "Owner Changed" Decision element, scroll down and select "Update Records".
This time we select the second option . We tell the Flow we want to update only Contacts  related to our Account $Record  and that we want to set the OwnerId on the Contacts to the same OwnerId as our Account $Record .
Here's the full flow:
This will update the OwnerId of all the Contacts associated with the Account in one step. Pretty neat, huh?
Where to go from here
In many cases you'll want to use the Assign-Update pattern by looping over collection of records and then saving them. Take a look at our Flow loop tutorial for that.