Introducing Flow Buttons, Courtesy of Ryan Cox

Ryan Cox is a Technical Architect here at Salesforce, and he has built some very sweet Flow functionality. The FlowButton is a button that launches Flows. Simple concept, but no one has ever really shown what you can do with this.

Let’s start with what you can do when you put a FlowButton on a Lightning Page:

Windowshade Flows!

You can already add Flows to Lightning Pages either via the Flow page component or a Quick Action button. Both are powerful but both also have drawbacks. The Flow component takes up a lot of space on the screen and you can’t easily turn it on or off. The Quick Action buttons take up only a little space, but they pop up as modals in a form factor that often isn’t quite the right size.

What Ryan figured out is one of those things that seems incredibly obvious in hindsight: you could have the best of both words if you build a lightning page component that has two modes. It starts out as a small button that looks like this:

but when you click the button, it expands like a window shade and becomes an inline Flow:

If you want, you can have the flow pop up as a modal. You also get some powerful css-based formatting options for the button’s appearance:

You can insert FlowButtons into lightning components, but sadly only aura components. the lightning:flow runtime component is only available in aura, and lwc components can’t embed aura components (although I’d love to see someone experiment with doing this via an iframe).

<c:RC_FlowButton buttonLabel="Submit" 
    variant="BRAND" 
    flowToLaunch="Create_Contact" 
    showFlowInModal="true" 
/>

Controlling Flow Screen Navigation

Like the existing components Custom Footer Button and Navigation Button, FlowButton can control the movement of flow screens, triggering a Next or Previous transition:

You can have a set of these buttons that navigate to different parts of your Flow. Set this up by having the buttons update a flow variable, and then use that variable in a decision element:

Improved Dynamic Subflow Launching

Subflows are a powerful way to increase your reuse, but they have a major weakness in that the Subflow element requires the name of the subflow to be chosen at the time the flow is built, instead of when the flow is run.

Last year, UnofficialSF published a method for dynamically launching subflows. FlowButton improves on that method in two useful ways:

  • The subflow will be launched within the same screen as the parent flow
  • The parent flow only continues after the subflow has completed.

This creates a seamless experience for the user. To configure the button to be used in this mode, configure it to hide the button, automatically launch a flow on init, and progress the parent flow when the subflow completes.

If you want the master flow to transition after the subflow completes, set ‘Do Flow Action When Subflow Completes’ to true.

Example Content

There is available demo content in the full package, which is available here. The install link at the bottom of the page will only install the FlowButton component itself. (Note that to see the below example content, you’ll need to go into your profile and make visible both the Flow Components App and the Test-Flow Button Custom Tab.)

This screen shows some of the styling options:

If the button is placed on a record detail page, the recordId will be passed to the Flow.

accountPage-createContact-1.png
accountPage-createContact-2.png

Two example flows for dynamically launching subflows are the Flow Router and Case Status Router.

flows.png
flowBuilder-flowRouter.png
flowRouter.png

The Case Status Router flow is configured on the Case record page.

flowComponents-caseStatusRouter.png
flowBuilder-caseStatusRouter.png
caseStatusRouter.png

Other Examples

Some examples of how I’ve used this component in demos and VTO projects.

On a Community page

community-submitInvoice1.png
community-submitInvoice2.png

On Lightning pages

ads-createMarketingPrograms.png

In custom Lightning components on a Flow screen

weecycle-gearOrderFlow.png

In custom Lightning components within Lightning pages

This shows a modification of the Salesforce Labs Trekkr app where the steps of an onboarding trail are completed by launching a flow. More details on this are here: Trekkr: launch flows for steps

trekkr-trailStep1.png
trekkr-trailStep2.png

Install

Version 1.0 Unmanaged (component only)

Version 1.0 Unmanaged (full examples)

Source

View source (component only)

View source (Ryan’s main project)

New Automation Tool Comparison Guides

Two very substantial new guides have just been published. They are the product of a huge internal effort spearheaded by Salesforce Flow Product Managers Sam Reynard and Tim Peng. Check it Out!

Introduction to the Architect’s Guide

  1. Architect’s Guide to Building Forms
  2. Architect’s Guide to Building Record-Triggered Automation

Gidi Abramovich on Adding Validation to Standard Picklists using Flow and the new Record-Changed Trigger

Summer ’20 provides a new trigger: Start your Flow when a record is created or changed, just like Process Builder. Gidi’s post shows how you can use this to prevent unexpected values from being set on picklist fields.

Note that Gidi’s solution features a workaround that allows the Flow to use ‘IsChanged’ functionality:

Check it out!

Sneaking Dynamic Data into Email Templates with Send Rich Email

As discussed in the Email Templates section of the Send Rich Email action, Salesforce Lightning Email Templates have an ability to merge data in dynamically, but it’s limited. You can only merge in fields from a core set of supported Standard records: Lead, Contact, User:

What if you want to merge in additional dynamic data? You can do it using Flow.

The basic idea is that you create one or more custom fields on Lead, Contact, or User to serve as temporary holding pens for dynamic data. Then in the same Flow that you use to send the email, you update the record with your dynamic data. After you send the email, you can choose to erase the data from the custom field.

Example: you want to add a Price quote to an Email that’s sent to Contacts. You add a custom field to Contact. You could be specific and call it PriceQuote__c but we’ll be more general purpose and call it FlowMergeField1__c so we can use it for different purposes. Over in Lightning Email Template, add the field to your email body or subject:



In the Flow, take the contact record and do an Update Records setting the value of FlowMergeField1__c to the price you want inserted in the email.

You then need to make sure that the database commits your change before you call Send Email. Any Screen will cause a commit, so you could insert a screen that says “Click next to send”, and it would commit your update. You can eliminate that step with the Commit Transaction action if you’re using a Screen flow, and with a Pause element set to a zero time duration if you’re using an Autolaunched flow. Without this step, it still might work some of the time, but do this for reliability.

Then call your Send Rich Email action, passing it the ID of the template.

New Guide on Automation Tools

Michael Schmidt-Korth from Salesforce has published a nice updated comparison, complete with updated polar charts. Check it Out!

Get Group Info: User Emails and More

You can provide Send Rich Email with a collection of Email addresses, but how do you get that information out of a Public Group? This new GetGroupInfo Flow action takes a group name or Id and returns a list of information about the Users in that group (and in any of the child groups that are in that group).

One of the return values is a collection of email addresses that can be handed straight to Send Rich Email.

Returned information includes:

List<String> userEmailAddresses;
List<String> userNames;
List<String> userIds;
List<User> users;

Installation

Version 1.0 Unmanaged 6-15-20

Source

View Source

Convert Record Data into Tables for Email Automation With ‘Generate Collection Report’

Suppose you have a set of records and you want to insert them into an email message. To do this, you can use the updated GenerateCustomReport action to generate a chunk of HTML suitable for adding to the Body of an email action that supports rich text, like Send Rich Email.

You pass in a comma-separated list of the fields you want to show in the table. Make sure to use the full api names, including ‘__c’ for custom fields.

You can also decide whether or not to show a Header row with the names of your fields.

You can style your table. The styling support is powerful but primitive. You can pass in a css Style string for each of three sections: the overall Table, the Header, and the Rows. Because style strings are a little fussy, I like to use Text Templates for them.

Here’s a sample configuration:

Here’s an example of styled output on a Flow Screen:

Keep in mind that if you want to provide the data in a form on the flow screen that can be manipulated, selected, sorted, etc, you should instead use the Datatable component. The action described here is mainly intended for when you want to output the data through email or into a Quip page.

Styling

You can add styling information directly to an input, or put it in a Text Template and pass the Text Template into the input. Here’s an example of one of the Text Templates used to generate the above table:

This is conventional css, and everything you can do in a <style> html tag is available to you. For more information on styles you can use, consult a resource like W3Schools.

Usage Note: if you use Text Templates, you MUST change the menu button from View as Rich Text to View as Plain Text before making any change to your text. If you don’t extra html tags will be inserted and your formatting won’t work properly. We’re working on a fix for this.

Using with Email

Finally, here’s the result in an email message:

In this case, I’ve simply routed the output from my action to the HTML Body input of the Send Rich Email action:

Note that you can use another Text Template to provide boilerplate text:

And the email result is:

The key concept to understand is that at the end of the day, a rich email body is just a single string full of html tags. Each instance of this action will spit out one such string, and the text templates also spit out strings. You can combine them together using formulas or another text template (see the video for an example of this) or an Assignment element.

Creating Headers and Parent/Child Reports

You can combine multiple instances of this action to create richer report structures. Here’s an example that uses an output string from an Account record and a second output string from a collection of Contact records:

To accomplish this effect, the HideHeader input is set to true on the parent Account Generate Collection Report action and it’s given a font-size style string to make it larger. On the second Generate Collection Report action that displays the child contacts, the style ‘margin-left’ is applied at the table level (not the row level) to achieve the desired indentation:

See the above video for more information.

Working with Multiple Parent/Child Combinations

You can create a large report in Flow with many Parents that have many children, but you may have to take some steps to avoid triggering the 100 SOQL Queries Limit, because you need to carry out a Contact query for each Account and this normally will all be done in a single transaction. If your parent list is around 100 records or larger, you’ll need to break up your flow from a transaction point of view. To solve this, the flow below uses the ‘new’ Commit Transaction action which forces the transaction to close on each iteration through the loop:

This allows you to create large reports:

Be aware, though, that bypassing the normal transaction unification process in this way can result in flows that take a long time to run.

Installation

This action is part of the Collections Action package and the features described here are available starting in version 1.18 of that package.

Use the ‘Commit Transaction’ Action to Get More From Your Screen Flow Limits

CommitTransaction is a simple Flow Action that works in Screen Flows and simply causes any open DML transaction to close. This is the same thing that happens whenever a Screen element executes or when a Flow ends. Having it in the form of this action allows you to close transactions in places where you might otherwise violate limits.

Consider this Flow:

This Flow highlights the ability of the Flow Action Generate Collection Report to create attractive output out of lists of records:

Note that in order to generate this report, the set of related Contacts has to be queries for each Account. This is done in a Loop, and if the initial set of Accounts is near or over 100, you’ll get this error:

This is happening because the 100 passes through the Loop are all being aggregated into a single transaction. This makes sense in general as a system efficiency technique, but it’s not what we want here.

If we insert a CommitTransaction action into this loop, it becomes 100 individual transactions, and the flow finishes properly:

Here’s where I inserted it:

You can see this in action in the video on this post. Keep in mind that the grouping of activities into a single transaction makes slow things run more quickly, so if you place Commit Transaction into big, busy loops, it may take a lot longer than you’re used to.

FAQ

How does this work?
If you look at the code, you’ll see that this action is actually an empty Local Action. Local Actions, by dint of their architecture, close open transactions.

How is this different from the ‘zero-duration Wait element’ approach?

Probably nothing. This is just a little more straightforward to implement, at least once you have it installed in your org.

Does this work in Autolaunched Flows?

Sadly, no. For those, use a Pause element and give it a time of 0 to get the transaction to close.

Install

Version 1.0 Unmanaged 6-13-20

Source

View source

Convert Process Builder Processes to Flow Builder Flows

Starting with Summer ’20, some Process Builder processes (which are technically Flows with process type ‘Workflow) can be converted to Flows of process type ‘Autolaunched’. The new flow shows up in Flow Builder and takes advantage of the new Record Change trigger that Flow Builder now supports.

The package here will install into your org a flow called Convert Processes to Flows. it allows you to select a Workflow:

It will then retrieve the workflow metadata from your org using the new Transfer Metadata screen component, then pass the metadata to a flow action called ConvertFlowMetadata.

Here’s a video:

Flow Builder’s ability to do the things Process Builder does is a little limited in Summer ’20. Most notably:

  1. Flow doesn’t have Scheduled Action support
  2. Flow doesn’t support related field references like myVar.Owner.FirstName
  3. Flow doesn’t support the ISCHANGED, ISNEW, PRIORVALUE functions

If you select a workflow with any of these characteristics, the Flow will report the error and stop.

Here’s an example of a Process Builder workflow:


And here’s what it looks like after conversion:

It’s recommended that you only run this on Sandboxes for the time being.

Considerations

The converter automatically creates a unique name for the new flow by taking the Process Builder name and adding ‘-Converted’. It does not change the label or interviewLabel (used for paused flows). Keep in mind that you’ll now have two processes, one in Process Builder lists and one in Flow lists, with the same Label. If this turns out to be a problem we can add logic to automatically create a modified label.

Install

(We recommend that you only install this in sandboxes for now)

Version 1.01 Unmanaged

Old Versions

Version 1.0 Unmanaged

Source

View