Use Case: Mass Update Records From Related List #1

Have you heard of inline editing? This is my favorite feature that I use EVERYDAY! Though amazing as it is, there are still limitations. For example, you can only edit records with the same record type, and it is only available in the list view but not in the related list. So today, we will introduce a mysterious “ids” variable to mass update records in related lists! It will not be as flexible as inline editing, but better than nothing I would say. (Or let’s all upvote this idea :D)

Why mysterious you wonder? This ids variable is similar to recordId. If your flow has this variable, Salesforce will also auto-populate it, but with multiple ids! What?! However, there are some important notes:

The Magical “ids” Variables
  1. This variable is not documented officially, so you can only know when you are in an exclusive club. (Joking. I did a lot of searching.)
  2. Because of reason 1, there is a risk that it can break. (My first testing didn’t work at all)
  3. It only works with related lists/list views that have checkboxes in the front.
  4. The setup of the variable has to be EXACTLY like below.

Let’s dive in on how to set this up!

* Big thanks to Jaime from Viajes BIDtravel for sending in the case, and to Peter from Findock for sharing his thoughts!

Lulu Mobile uses the standard Account and Case object to keep track of their customers’ cases. Sometimes there can be many cases under one account, and they want to be able to mass edit the cases right from the related list to boost productivity.

Even though we can get multiple ids at once, they still exist as a collection variable. To edit each record, we will have to use loop to unpack the collection. That means we have to choose between two outcomes:

  1. Mass update the same fields with the same value for each record
  2. Update the record one record at a time on the screen

We will introduce outcom#1 in this article and have a separate article about outcome#2. Lastly, we will launch the solution as a List View button, and it works on both related list and list view.

Please wait while flipbook is loading. For more related info, FAQs and issues please refer to DearFlip WordPress Flipbook Plugin Help documentation.

Comparison for the two flows:

See the pros and cons of two flows and choose the one that suits you the best.

Flow#1 (This Article)Flow#2
Pros+ Less elements in Loop so better performance
+ Can skip the Done Screen and use retURL
+ Can see the current value of each field
+ Can modify each record separately
Cons– Cannot redirect back to original Account page– Longer process time and more screens
Comparison for different solutions when there is only one record:

This solution can work even if you only want to edit one record. Then it will be similar to the solution in this article – Add Clone Button To Related List. Here is the comparison of two different methods:

List View Button (This Article)Formula
Pros+ Good looking UI
+ Can handle multiple records
+ Easier to reach
+ Can have other field values fed to input variables
Cons– Always has to use Loop even for one record only– Can be confusing as it is a field on object

Screen FlowAssignmentVariable/Collection
LoopUpdate RecordsInput Variable
Screen Element

Does the solution solve your problem? If not, write us what your problem is and we will build the flow for you!

Official Salesforce Help Article On Flow

Notify of
Newest Most Voted
Inline Feedbacks
View all comments

Hello, Melody! Does using the “ids” variable mean that you have to give users the “Manage Flows” permission to enable them to run the flow? Or are they able to run it with just the “Run Flow” permission? I created a flow similar to yours, except instead of mass updating records, they are being mass submitted for approval. The only way a user can run the flow is if they have “Manage Flows” on their profile. “Run Flow” is not enough, and I am wondering if that’s due to the “ids” variable. What is your experience? Thank you in advance!

Alexis Kasperavicius

Nice trick! Note I’ve found even better results by using URLFOR within the button code. It returns the user back to the Account on flow completion instead of a generic case listing and works well in classic or lightning.

Using your example, the button code would be: