Demystifying Flow’s Custom Notification Action & A Possible UnofficialSF Use Case

I recently started trying out the relatively new Custom Notification action today and wanted to share my thoughts on two head scratcher inputs.

Check it out

I call out the Collections Processor package here on UnofficialSF

One neat little combo would be utilizing some of the invoked actions found on You could use the ‘Extract Fields’ action from the Collections Processor Package to do a query, run the invoked action to get a text collection of IDs, then pass that into the Recipient ID input.

Using Custom Screen Components with Conditional Field Visibility to Create Dependent Picklist Combos

This scenario is common and powerful: you have a Flow Lightning Screen Component on the screen. Perhaps its an out-of-the-box component like Address or Lookup, or maybe it’s a custom component like QuickChoice. You want to have another component on that screen use conditional visibility and make the visibility dependent on the value of the selection in your first screen component.

This works really well, but there are a couple of little tricks that it helps to know about. The main thing to know is that outputs from Lightning Screen Components are only immediately available to the Conditional Field Visibility subsystem if you use the recently introduced Automatic Output Handling by clicking off the “Manually assigned Variables (Advanced)” checkbox.

This is necessary because the checkbox activates the older manual variable system, which doesn’t get updated with changed values until the Next/Finish button is clicked. When the checkbox is off, the new Automatic Output Handling is turned on, and conditional field visibility will work.

Here’s a video demo:

When you turn off this checkbox, (which is on by default in Spring ’20 for new components, but will be off by default starting in Summer ’20), you still won’t see the component show up in Set Component Visibility until you close and reopen the screen. At that point, you’ll be able to select the value from the parent screen component as an input into the visibility expression:

Theoretically, it should be possible to chain together a huge number of these….!

Attention Flow Apex Developers: A Chance For Glory 1 :

Requesting: An apex action that converts a CSV file into a collection of records

Looking for everlasting glory? Want to put Salesforce product managers into your debt? The library of invocable actions needs an action that takes an uploaded file Blob (presumably the Content Document created by the File Upload available in Flow) and the name of an object type (like ‘Account’) and outputs a collection of records, using the Spring ’20 support for List<SObject> variables. The action should assume that the first row of the file contains the names of field names on the record.

There are probably some useful tips to be gleaned from:

Automate Junction Updates with GetChildCollection and GetLookupCollection

Peter Bender asked “What’s the best way with declarative automation to update the records on the other side of a junction object? For instance, if a change is made to an Opportunity, update a field on all Contacts related to that record via an OpportunityContactRole. “

The new Collection Actions capability in Spring ’20 provides an opportunity to attack this declaratively. We started out building collection actions to do simple collection manipulation, but working with junction objects requires collection actions that can work with relationships. To that end, we’ve added two new actions:

GetChildCollection takes a record and returns a specified collection of child records.

GetLookupCollection takes a collection of records and the name of an object related via a Lookup, and returns a collection of objects.

Let’s look at this from the perspective of the example requested above.

Suppose that, whenever an Opportunity changes to a Status of Closed Won, we want any Contacts that are associated with that Opportunity via an Opportunity Contact Role to have their field of “Needs Thanks!” set to True.

Here’s what the Flow looks like:

Starting with the affected opportunity we first call the Get Child Collection action. We pass in the Opportunity and the name of the related object type (OpportunityContactRole) that we want.

Here’s how the action is configured:

We actually have to specify the child collection twice: once at the top to ‘tune’ the collection action to output Opportunity Contact roles, and again in the childRelationshipName (at some point we’ll be able to simplify that). We need to specify the fields we want to retrieve but in this case we only need the Id field.

We next want to get all of the Contacts linked to the Opportunity Contact Roles. This is done via a Lookup relationship Opportunity Contact Role to Contact. The Get Lookup Collection action allows us to do this with one element:

Here we set the inputCollection to be the automatically generated output from the previous Get Child Records. We pass in the object that we’re looking for. Note that this version currently only works with objects that have a single relationship between them. In other words if, there were two different fields on OpportunityContactRole that both looked up to Contact, this action would grab the first one it found, which isn’t reliable (we’ll fix this).

The returned set of Contacts is then passed to Map Collection, which changes the field.

Install Collection Actions here.

Send Rich Email (Send HTML Email Action) Ver 1.33

Send Rich Email (Send HTML Email Action) Ver 1.33 has been released. It is a minor bug fix and document update release including:

  1. Updated Send Rich Email (Send HTML Email Action) documentation
  2. Major updates to the Example Flows with 5 different test/example electable flow paths that illustrate different implementation options (Flow: Send HTML Email Testflow)
  3. Enhanced parameter validation to improve usability
  4. There are now two packages, 1.33 Unmanaged sendHTMLEmail (With documentation examples and tests) and a leaner 1.33 Unmanaged sendHTMLEmail(No Tests)  which does not have the test/example Flows used in the documentation.

Managing Users’​ License Limits with​ Custom Metadata Type and Before-Save Flow

Salesforce Spring ’20 Release brought us a powerful enhancement – Flow Builder before-save updates.

In the following article, Gidi Abramovich demonstrates how to use this feature, along with a Custom Object, Custom Metadata Type, and a Validation Rule to:

  • Assign the proper Region per each User
  • Define the Salesforce license limitation per Region and user type

Check It Out

Getting a SessionId into a Lightning Screen Component

One of the more notorious hacks in Salesforce is the trick that needs to be used from inside Lightning to obtain the SessionId, which is not directly accessible for security reasons. The most popular approach involves creating a Visualforce page.

I stumbled today across another approach that I wasn’t previously aware of. From a Flow Formula, you can access the global variable $Api.Session_ID and simply pass it into your Lightning Component:

Items To Approve, Improved

The ItemsToApprove component can be placed on recordPages to provide a list of records that have been submitted for Approval:

This component goes beyond the Items to Approve lightning component provided by Salesforce in the following ways:

  • Restores missing columns from the Classic component, including Submitter, Submission Date, and Recent Approver
  • Add additional custom columns of your choice to surface critical information for rapid decision making.
  • Works on all lightning pages, including Home, User, standard and custom record pages
  • Support for Delegate Approvals
  • Support for Queues
  • Optionally hide the Reassign button.
  • Approve, Reject, or Reassign multiple records in a single action:


Unmanaged Package 1.1.2


  1. This lightning component is designed to be used in a Flow and not to be placed directly on the lightning page. After installing the package, you will find Items to Approve available in the Screen Builder in Flow Builder:

Create a simple flow of type Screen Flow that has a single screen, and add the Items to Approve component to that screen as shown above. The flow should look something like this:

2) After adding the component to your flow, configure it (see ‘Configuring the Items To Approve Component’ below) and Activate it (Important!)

3) In Lightning App Builder, edit the Page where you want the Items to Approve component displayed, and drag the Flow component onto the page. Make sure the flow component is configured to select the flow that you just activated. The recordId values should be left alone, as shown below, to cause the Id of the User to pass through to the flow and then to the Items to Approve component. (this example assumes you’re placing the component on a User page. See below for other Usage Scenarios)

3) When the page loads, the flow will run and render its screen and the component will retrieve the records awaiting approval from the provided ActorId.

Configuring the ‘Items to Approve’ Screen Component


In Approval Processes, ‘actor’ refers to a user who is or was assigned a pending approval process ‘work item’. The first instruction you need to give this component is whose pending approvals should be displayed, that is: who is the actor on which to focus. Provide the record Id of a User record. Note that pending approvals will be shown for that User from three sources:

  1. records assigned directly to that User
  2. records assigned to someone else who has that User specified as their Delegated Approver
  3. records assigned to a Queue that that User belongs to

If you’re not familiar with Flow, keep in mind that you need to configure two different places: 1) you need to setup a Text variable with the name “recordId” and with the “Use as Input” box checked:

and 2) you need to then assign the value of the recordId variable to the actorId input on the ‘Items to Approve’ component.


If you want to customize the displayed columns, you have to limit the table to display a single object type. Specify it here with a string (Example: ‘Account’).


If you provide an object type in the contextObjectType input (see above), you can specify a set of custom columns by providing a comma-separated list of field names from that context object type. In the example, above, the Account standard object has two custom fields: datetime1__c and textfield1__c.

Hide Reassign Button

This boolean can be set to True but defaults to false.

Usage Scenarios

You can place a flow containing this component on any kind of page, but if you don’t place it on a User page, you need to make sure that a User Id is passed in to the component by the Flow. There are different approaches to this. For example, you could place the Flow on a home page and use the Flow to first get the User Id of the running user (the user that happens to be visiting the home page) and then pass that id to the Items to Approve component.

Known Issues

  • This component lacks support for Approval Processes that contain steps that allow the user to specify the next approver themselves.
  • Reassignment does not provide any support for filtering. Right now you can select any user.
  • If the step is the first step, the Recent Approver column inaccurately shows the name of the submitter.

View Source

View Source

New Flow Webinar: Collection Actions, Before Save, Recent Extension Highlights

This is most in depth I’ve gotten on Collection Actions. I show how you replace looping structures with a single action. There’s also a great Before Save explanation and demo by my colleague Henry Liu, and a survey of recent actions and components. Also, and unusually, a full 30 minutes of Q&A. Check it out!

SOQL Builder 1.1 Adds Related Fields and More

We recently published a component that generates SOQL queries, enabling users running Flows to build their own queries at run time.

This package upgrades the component to version 1.1, adding the following functionality:

  • You can now traverse to select related fields via relationships (example: [SELECT Account.Name FROM Contact...]
  • An ‘Add All’ button lets you easily create the equivalent of a Select *
  • You can lock down the object that the query is returning by setting the attribute disableObjectTypeSelection to True. This is useful when you’re pairing this component with an Execute SOQL action, because the action has to be locked to a specific action type in the Flow Builder, and this avoids the user selecting a different action and ending up with a mismatch.

For more information, see