Updated: 7/21/2022

In response to a call for volunteers, Josh Dayment and Karan Pant joined forces to create this great new component.

The Flow Flexcard Component presents collections of records in a neat set of actionable cards. You can populate each card with a set of actions that the user can take on the selected record. When clicked the actions pop up as flows in a modal. This provides a great combination of permanent viewability and Flow functional tools.

Here’s a great walkthrough video by Josh Dayment:

How It Works

Let’s take a look at an example flow. A Get Records returns a collection of accounts. In the custom property editor, you can see I’ve specified the specific fields I want to pass into the component, the size of my cards in px, my component label, icon, and Flex Card actions.

Working with Flexcard Actions to Allow Record Editing

In this example, you can click Update Account to edit an individual record:

When you do this, the corresponding Flow runs in a modal:

Note that it’s up to you to commit changes to the record. Here’s what Update Account looks like:

Inputs

The component has a few input variables we need to display the cards.  

1. Object Name, this is the Object API Name of the records you want to display. 
2. Select Fields, This utilizes the Object and Field Picker this will display a list of the available fields from the object selected in Object Name this can be one or multiple fields selected.
3. Record Collection, A record collection variable containing the records you wish to display in you cards. 
4. Preselected RecordId, This is the recordId of a preselected record if you choose.
5. Card Size, This sets the size of your cards the default is 300 this will set the size to 300px by 300px. So for example if you want to make them a little larger set the number to 500 
6. Header Style. String variable to hold standard HTML style tags to control appearance of card headers.
7. Component Label, This adds a label to your component it supports a string variable or text template to include rich text.
8. Icon, If you wish to display an Fallback Icon on your card header enter it here I.e. standard:account(You can also display a custom image by housing an image url on a url field on each record that field name must use the api name of src_URL__c) 
9. Display Actions as List or Menu? This decides how you actions are displayed in the card. List, This displays the subflow labels as hyperlinked urls. Menu, This will display a Menu button with each subflow as a menu item. If Menu is selected you are displayed another input to capture the Menu Label.
10. Show which flows?, This utilized the Flow Picker component you can pick one or multiple subflows from your org. The subflows must have an input variable of recordId if you want to pass the recordId from the card into your subflow. The flow labels will display in your card so be cautious of what you label your flows.
11. Are Cards Clickable? Single Select, you can select a single card by clicking on it, and the id of the selected card will be made available as an output, Multi-Select If set to true, allows for selection of multiple cards and stores recorded of selected cards into collection variable of selectedRecords. Single-select and autonavigate, when you select a card it will store the id of the selected card as an output and will cause and immediate transition to the next screen.

Outputs

This component utilized 2 main outputs

1. Value, This is utilized in either of the Single Select modes it will store the recordId of the selected card in this variable
2. Selected RecordIds, This is utilized in multi-select this stores all of the selected cards recordIds into a text collection variable.

Developer Note

“The card header and fields displayed in the card process data differently. The header is referencing field data from the get records portion of the flow itself where the data on the fields in the fields displayed is using lightning-record-view-form to populate the field values so it is actually getting those values oob vs the flow getting the fields and values. So, for example, I can get All Accounts and select the fields I get to only ‘Name’ and if I select to display multiple fields it will still display all of the fields and values I selected in the CPE. From the component library “lightning-record-view-form requires a record ID to display the fields on the record. It doesn’t require additional Apex controllers or Lightning Data Service to display record data. This component also takes care of field-level security and sharing for you, so users see only the data they have access to.” So, in short, it is working kind of as designed the fields and field values are being processed outside of the flow in the card so we can’t override sharing but the name we are getting from within the flow. The short-term solution would be to have a session-based permission until I can solution and build a way to only show the cards when there is complete data.”

Install

Flexcard is available in Flow Screen Components Base Pack. Install it here.

View Source

Source

Swarming refers to the assembly of a group of collaborators to team up to solve a problem or work an issue. The recently published Slack Actions can be combined with Record-Triggered flows to automatically generate dedicate Slack channels (think ‘deal rooms’ or ‘case rooms’) when records are created or change to a particular state.

The package provided below installs a fully functional flow-based Slack swarming solution that you can install and customize. As initially configured, it creates a channel to serve as deal room each time an opportunity is created with an amount above $100,000. And it then invites all of the Account Team Members for that opportunity’s related Account to the created channel.

Watch the Video

Key Element – Using Account Team Members in Flow

You can query for Account Team Members in Flow using the standard Get Records. Traditionally, you might loop over the records and use their corresponding userIds to retrieve User records. This flow uses a couple of installable flow action extensions to eliminate the need for a loop.

How It Works

Part 1: Triggering on Opportunity Creation

The Opportunity Creation trigger uses the Launch Flow Dynamically action to call the separate Generate Deal Room flow. Later this year it will become possible to do this all in a single flow instead of in 2 flows.

Part 2: The Main Deal Room Generation Flow

This flow uses Slack Actions from the Slack Actions extension and also calls a subflow to convert Account Team Members to Users:

Part 3 : Getting Users from Account Team Users

This small flow uses actions to turn Account Team Members into User Records. These elements could have been folded into the above Generate Deal Room flow, but it’s a good practice to try and create reusable subprocesses.

The solution

Installation

1) Turn ‘Account Teams’ On

The org this is installed into must have Account Teams activates (See Setup –> Account Teams)

2) Install Prerequisite Extensions

The org needs the following extension packages, if you don’t already have them installed. They should be installed in order:
Install: Flow Actions Base Pack
Install: Flow Screen Components Base Pack
Install: Datatable
Install: Launch Flows Dynamically
Install: Slack Actions
Install: Collection Actions

This is the most dependencies I’ve yet seen on a Flow extension! It’s a pain to have to do them all at once, but once one of these is installed, you don’t have to do it again unless you choose to update it to a newer version.

3) Setup Account Team Members

Currently, if you create an Opportunity and it doesn’t have an associated Account that has at least 1 Account Team Member, the flow will fail and the deal room will not be created. So make sure that you are creating an Opportunity that has an Account and that that Account has an Account Team with at least 1 member.

4) Make Sure that the Users have SlackIds

For each Account Team Member that you want to enable, make sure they have a SlackID on their User object. If necessary, create a text field on User called ‘SlackId’. Slack ID’s are available here:

You can also discern them by running Salesforce Slack Administrator flow in debug log and seeing what the result is in the log when you try inviting a user to a channel

Install

Working on making this available as a package.

Source

View source

The Collection Actions package of utility actions now has a new action that takes a collection of recordIds (i.e. a List of Strings) and returns the corresponding records. It carries out a SOQL query and obtains the fields that you specify by name.

In this example, I start out with a collection of AccountTeamMembers to whom I want to send emails. To get their email addresses, I need to obtain the User records that correspond to each AccountTeamMember. I can do that by pairing these two actions:

The first action is Extract Strings from Collections, which is also available in the Collection Actions package. I use this to convert the AccountTeamMembers into a List of User Ids. Then I ‘hydrate’ the User Ids into User records.

Learn more about Get Record from Ids.

Install Collection Actions here.

Jonathan Gillespie created a nifty action that lets you Create and Update Custom Metadata records from within Flow – something not possible out of the box. Check it out over at his GitHub account: https://github.com/jongpie/CustomMetadataSaver 

When do you use Custom Metadata?

Custom Metadata is an extremely powerful feature that lets you control core logic from code and automations declaratively. Here is a great article/video from 2018’s Dreamforce that shows how you can utilize Custom Metadata in Flow and when you should use it: https://admin.salesforce.com/blog/2018/advanced-automation-with-flows-and-custom-metadata-types-webinar-recap 

From the article – Use Custom Metadata when:

• Application or Org data are referenced in multiple places in your org
• Manage mappings like a ‘State → Tax Rate’ or the DeveloperName/Email address of a specific user/Group
• Manage information that is subject to change or will change frequently
• Store frequently used text like a task descriptions, chatter description, or notification contents
• Store environment variables (URLs, things specific to each Salesforce environment)*

I can see two key use cases for this action:

1. Giving power users and key decision makers the ability to control business logic without admin intervention and without giving them ‘Customize Application’ access. 
2. Creating custom metadata records with complex logic – perhaps based on record data 

For mass-creating CMT records from Flow from a CSV file I recommend trying Narender Singh’s action posted last week.

Install & Setup

To install, use the ‘Deploy to Salesforce’ button in the README section of the repo. NOTE: Jonathan is working on email alert notifications for when the deploy succeeds or fails: https://github.com/jongpie/CustomMetadataSaver/pull/9

Check out a video of it in action