Vote for official support - Idea: support standard id/ids flow variables
"How do I submit multiple records into my process?"
This sounds like an obvious job for Flow and a List Custom Button, right? We open the list view, tick a few checkboxes, click the list button… but quickly find the Selected Record IDs are nowhere to be found in Flow.
 |
 |
There are a few workarounds to inject the checked rows:
- Use code or a package to run the flow as a batch process
- Add a custom field and use mass edits to invoke process builder
- Create a VF page with
apex:interviewto inject the selected records - Use GETRECORDIDS in a JavaScript custom button (alarm bells ringing…)
How to pass Record IDs to flow from buttons
Here's the thing - the id or ids are accessible in flow already - the trick is to launch the Flow using its URL in the button content and create a variable with a special name:
Then, configure the 'Nudge Owner' flow so the posted IDs are received:
- Create a new Collection Variable resource
- Enter the Unique Name called
ids - Set the Type to
Input Only
When configured correctly, Salesforce automatically populates the collection variable with the IDs of the selected checkboxes. Now we can loop over the collection variable and perform business logic.
Note:
- This parameter isn't documented anywhere.
- The name of the
idscollection variable is case sensitive. - Remember to "close the loop" otherwise only the first ID is handled by Flow.
The same technique works on Detail Page Buttons: if an id variable exists in the flow, it is automatically populated with the current Record ID context. If you've seen this before, it's because it's the same way the standard id/ids parameters work in standard controllers:
Mass flow actions can be bulkified too, they need not be limited by iterations of the loop element. Plugins using the @InvocableMethod annotation do support collection variables - the ids list can be passed straight in.
Why start flows from URL buttons
Unlike using a Visualforce Page to launch flow, the URL button gives you access to the id/ids parameters. Then the parameters behave like an interface contract, and we can attach flows to objects using the Metadata API. Further:
- Avoiding the VF page also avoids any need to modify Profiles.
- Using a URL button prevents the Flow from becoming a dependency itself.
- Less documentation needed to explain inputs, because everyone knows what an ID is.
True, distributing flows using Visualforce Pages offers more granular access control since the entry point is restricted by its associated page - this is applicable in sites and communities or portals.
Vote for official support - Idea: support standard id/ids flow variables
