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….!

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.

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

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:

Installation

Unmanaged Package 1.1.2

Setup

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

actorId

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.

contextObjectType

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’).

fieldNames

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