“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:interview to inject the selected records
  • Use GETRECORDIDS in a JavaScript custom button (alarm bells ringing…)

Here’s an easier way to access Selected Record IDs

After clicking multiple checkboxes in any list view, the selected records are accessible – the key is to launch the Flow using its URL in the button content:

Then, configure the ‘Nudge Owner’ flow so the posted IDs are received:

  1. Create a new Collection Variable resource
  2. Enter the Unique Name called ids
  3. 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.


  • This parameter isn’t documented anywhere.
  • The name of the ids collection 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. For want of a better term, these “standard parameters” act the same as 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.

Benefits of standard flow parameters

Standard flow parameters eliminate the need for Visualforce Pages to arrange input records. They behave like an interface contract. ISVs can automatically deploy surgical, self-contained customizations more easily with the Metadata API. Further:

  • Avoiding the VF page also avoids any need to modify Profiles.
  • Using URL custom buttons avoids hard dependencies on packaged Flows.
  • Documentation isn’t required to explain how to set context sensitive inputs.

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.

Otherwise, any reason not to do this?

Update: vote for official support! Idea: support standard id/ids flow variables