Using quick actions as a template in flows

Finally figured out a use case for using quick actions in flows.

They can provide consistency for when you need to do the same thing in multiple flows / processes, and want to ensure that specific fields are populated.

All required fields on the action layout are required when you use the action in a flow / process. Any optional fields on the action layout are available to be added if needed. But - any fields not on the layout are not available, so it is also a constraint.

Some use cases I can envision

My use case was a custom object called ‘integration request’ that I have setup to centralize a few callouts to external systems. Its like I imagine platform events could be used - if I understood platform events.

So there is a global action like so:
Screenshot 2018-09-04 at 1.59.25 PM.png

And in the flow, I can leverage the action like so:
Screenshot 2018-09-04 at 1.50.01 PM.png

And in a process, I can leverage it like so:
Screenshot 2018-09-04 at 1.59.59 PM.png

A thing of beauty. A few notes / caveats that come to mind:

Subflows can be used in similar ways, but they do not let you distinguish between required and optional fields. All input variables are optional.

Quick actions cannot, to my knowledge, be used in a bulkified manner - ie with a fast create and a sObject collection. They only operate on one record at a time. And that is almost always a bad thing, but…is process builder really bulkified? Will it ever be? These are questions that I leave for you, the reader, to ponder.

 
5
Kudos
 
5
Kudos

Now read this

Determining which fields are used in a page layout (in less time than it takes to brew a cup of coffee)

There is a great app called FieldTrip that will let you know which fields are actually populated in records, but deep diving into eclipse, or using brute force, have been the only way that I am aware of to see which ones are actually... Continue →