Tag Archives: Tips

Flow Tips Newsletter

Influencers and Subflows – Salesforce Flow Tips Newsletter

Hello folks,

Spring 22 is approaching fast. The release notes are out, and there are a bunch of exciting flows coming for flows. Let’s dive into those in the next issue of the newsletter, though. I will write about subflows today.

But before I dive right in, I need to tell you about something quite extraordinary that happened to me this past week: Salesforce Ben, one of the most popular publications about Salesforce, published a post that listed the top 20 Salesforce influencers for Salesforce, and to my surprise, I happen to be one of them. I heard something like this was coming, but I did not expect to be on a list of 20. I thought if they made a list of 50 folks to follow over 50, then I’d be on it. Thanks for all your support. I am grateful. You can find the full list here.

Subflows are not for everyone. They have their place in the flow architecture, and they are helpful, but there are many misconceptions around them. What they should not be used for, in my humble opinion, is as follows:

  • To get a fresh empty canvas to organize your flow better.
  • To bring all the logic for all the record-triggered flows together for one single object.
  • To circumvent governor limits, e.g., force a separate transaction.

The concept of subflows is not new in the programming world. In programming, you can have various different code logic executing the same code in multiple places. What you would typically do in that case is that you’d separate out this piece of code and call it from within your code whenever it is needed. In summary, good reasons to use subflows are:

  • Have a need to repeat the same logic within various flows.
  • Flow logic is expected to be revised over time.
  • Ease of maintenance.

What are subflows? Subflows can be autolaunched, or screen flows. Screen subflows can be called from screen flows. Autolaunched subflows can be called by every other flow type with the exception of before-save record-triggered flows (a.k.a. fast field updates, and this may change in the coming releases).

There is no setting that makes a subflow a subflow; they are essentially flows that you call from within another flow by inserting the subflow element.

For an active flow to work without problems, the subflows need to be activated as well.

Unless forced to execute in a different context, subflows will run in the same context that your main flow runs in: user, system, or system without sharing.

To understand better what a subflow is, you can think of them as aliases that call another sequence of logic that will be pasted into your main flow when it runs, and the whole logic will be executed as a whole.

Subflows often have input and output parameters. The way you set this up is like any other autolaunched or screen flow: You check input and/or output checkboxes when you set up your variables.

Subflows

Let me give you two examples:

  • Address entry screen subflow: You may have certain custom checks, validations, and error messages that you need to set up whenever the user enters an address. In most cases, you will have many different flows, sometimes the same flow in two different locations calling for an address entry. You can create an address entry subflow and pass the values back to your main flow after the user enters them correctly.
  • You may need to calculate the time it took for your organization to close cases on all cases under one single account and take an average of the duration. If you need to do this multiple times in multiple flows, it may be a good idea to build this as a subflow. You can pass the accountId to your subflow and get back an average duration number back that you can use in your main flow.

Let’s go back to my original bullet points of wrong reasons for using subflows, and play Mythbusters:

  • Fresh empty canvas: Unless you plan to use your subflow multiple times in different flows, subflows do not give you simplicity; they may increase complexity.
  • One giant record-triggered flow: This means you will do everything after-save. The outcome will be one giant flow with subflows, potentially less performant and harder to maintain. Salesforce is giving us tools to manage multiple Record-Triggered flows on one object. More on that will come in next week’s issue.
  • Governors limits: This is an interesting one. Louder for the ones in the back: Subflows do not force a separate transaction. Main flow and all subflows execute in one single transaction. There is literally nothing that helps you beat governors limits when using subflows.

Now that I got that off my chest, let me give you a few links.

Recently published content:

  • Salesforce Break website is up and running. Exciting: Your one-stop location for everything related to flows. I started posting the previous issues of the newsletter on the Salesforce Break blog. You can reach it here.
  • I posted a list of all the Salesforce blogs I follow. Please read it here.
  • I published a short video that includes a sneak peek into Spring 22 flow features. You can watch that here.

Enjoy your flow learning journey.

P.S. Originally published on 01/09/2022.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.

Standard
Flow Tips Newsletter

Create and Update Elements – Salesforce Flow Tips Newsletter

Hello folks,


What about create and update elements? Create and update elements perform DML operations. In other words, they write your data to the Salesforce database.

This is the type of element that you need to be most careful about. There are several reasons:

  • When you write data to the database, the changes are often irreversible, you may be doing a destructive change that you did not intend to do.
  • Salesforce governors limits are most strict about the number of DML operations you can perform. Especially combined with loops, you may hit limits in your transactions, which means you will experience faults/errors.

There are several ways of creating or updating records. You can create/update records one by one or in a collection. When creating/updating records one by one, You need to specify the object type you are working with, and you can set the field values one by one or use a record variable to set all field values in one shot.

One important tip here is related to the recordId(s):

  • Your create element does not accept a recordId as input. It will give you a recordId as output, and this will belong to the newly created record.
  • When you create a record using a record variable, or multiple records using a collection record variable, the recordId field must be empty. If you have any recordId value assigned to any record variables, your create element will fail.
  • When you update records using record variables or collection record variables, your recordId fields must have a valid matching value.
  • When you update records to set field values one by one, you don’t always have to specify a recordId; you can use filter criteria to determine one or more records that will be updated instead.

You can use fault lines to catch any errors you may experience when executing these elements. In addition, you can use your debug log, fault email, or failed flow interviews screen to review the debug logs and to view the failed interviews on flow canvas. This view shows the path your failed flow interview took highlighted on canvas.

Live session announcement:

Don’t Migrate Your Automations to Flow – Rebuild them instead: Salesforce plans to provide a migration tool to move Workflow Rules and Process Builders to Flow but, is that a good idea? What are the recommended next steps? Terry Miller and I discussed this topic live at 4:00 PM ET on Monday 11/29/2021. Watch the recording here:

Click here for the Youtube link

Click here for the LinkedIn link

Enjoy

P.S. Originally published on 11/28/2021.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.

Standard
Flow Tips Newsletter

Get Element – Salesforce Flow Tips Newsletter

Hello folks,


Let’s dive in to get elements this week. Get elements, a.k.a. SOQL queries, get one or more values from the Salesforce database. These values can be used later in our flow.

Before we go deeper into the get element, we need to talk about variables. Variables are containers in Salesforce that keep values for us temporarily until we use them. This is kind of like writing something on a napkin rather than in the address book. To save values permanently, we write them to the database; in other words, we write them in a record and save/commit to call and use them later. On the other hand, variables are available only in the flow we are in, and they vanish after we complete our flow interview.

In Salesforce flows, we create variables on the left panel in the resource manager, and some others are automatically created for us.

When we get a complete record, for example, Salesforce creates a record variable automatically and saves all the values of the get element in this variable.

Let’s assume we find only one opportunity record match in our get step labeled as “Get Account”. Salesforce auto-creates a get element record variable with all the field values that are available under that record. As flow makers, we can refer to one or more field values in that variable when we are building our flows – in this case {!Get_Account.Id} – for the recordId.
What are the parameters we need to set to execute a successful get step?

Typical scenario: We would like to find all Accounts with the name ACME.

Setup: Tell your get step you want to get a record of Account object type.

Set the filter condition as Account Name equals ACME.
What are the possible outcomes here? We may find:

  • No records
  • One record
  • More than one records

Let’s look at these possibilities:

No records: Your get step won’t fail. However, you will get a record variable automatically created with the value null assigned to it.

One record: You will have one record in your record variable complete with its recordId, name, and all other field values. You can use these later in your flow.

More than one record: You have options here. First, you can tell the get element whether you need to sort these records according to one field value. Then you can decide whether to get and assign the first record to a record variable or assign all the records to a collection variable (this means N number of containers of the same type). All these are auto-created for you.

One important tip here is to catch the “No records” outcome. If you don’t do that and use the record variable later in your flow, you will receive an error message, and your flow will fail.

So insert a decision step right after your get element and check whether {!Get_Account} is null true. If that is the case, stop all operations and exit the flow gracefully. In screen flows, you can insert a screen element to show the user a message explaining what happened.

Use the filter criteria wisely because if your get element returns more than 50K records, you will hit the governor limit, and your flow will fail.

This wraps up everything I wanted to write about the get element this week:

Recently published content: How do you extend upsell/crosssell offers using a screen flow on a Lightning page. Click here to this Salesforce San Francisco User Group Video on the Salesforce Break Youtube Channel to learn.

Do you need to see advanced use case flow applications for inspiration? Click here to watch the short video on a Loan Application Use Case.

Enjoy

P.S. Originally published on 11/22/2021.

Read the previous issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.

Standard
Flow Tips Newsletter

Decisions – Salesforce Flow Tips Newsletter

Hello folks,

This is the first of many weekly “Salesforce Flow Tips” weekly emails that you will find in your inboxes in the coming months.

Today I will focus on decision elements and how they work in flow. I have done a comparison of two flow images on Twitter and Linkedin before and the post attracted a lot of attention. It turns out Zuckerberg had the right idea originally, and people do like to compare two images and decide which one is hot and which one is not.

Emailing back and forth is such a boomer thing to do, so we won’t do that. Instead, I will give you links to my posts with the same exact content, and I encourage you to think about the topic and comment your take on one of the platforms where this is posted. Here we go:

What you see in these pictures is two versions of the same use case implemented. These flows just capture the decision outcomes when an Opportunity Stage changes from Prospecting to Closed Won or to Closed Lost.

You can find this post on Twitter, Linkedin, and Slack. Just click on the platform name.

I will give you my take next week after I learn from all your posts and digest a final evaluation making me look more clever than I really am.

Another topic I want to touch on is the naming convention inside your flow for resources.

A few tips on naming your flow resources:

If you are using search in your toolbox resource manager, it may make sense to use the type of resource you are creating in the resource name. I don’t like to abbreviate personally, so my resources will have choice, formula, and variable in the resource name, such as YesChoice and ResonPicklistChoice.

If you use the resource manager to visually look for the resource by scrolling down, you will find that your resources are grouped by type under the relevant section.

I like my resources sorted by what they do rather than their resource type; therefore, I do not use a prefix in the name; I append the type to the name. This depends on your personal preference. I will have two resources that start with the same word that explains the use, like ReasonPicklistChoice and ReasonOtherTextVariable.

This naming convention also makes the best use of autogenerated API names out of labels in your screen flows. You append the resource type to the autogenerated name, and you are done.

You can abbreviate variable in the name and use var, for example. This is also your personal preference; folks prefer this because long names get cut off sometimes when they are displayed in the UI.

If you cannot be consistent with abbreviations, the long version is better than the short version.

And finally, you see from the examples I gave above that I like to use CamelCase, but this also depends on your preference. When the API auto-creates a name with _ characters, I leave them in. Please give me your feedback under the relevant post on Twitter, Linkedin, Slack, or Youtube channel. Please do not send a connection request on LinkedIn; follow my profile instead. You can certainly reply to this as well; this would be my least preferred channel.

Please remember that there is a giant team of one person behind the Salesforce Break group of activities. If you like this email, please forward it to others. Also, if you received this email from somebody else, you can subscribe to the flow tips newsletter here. You are receiving this email because you gave me your email address when you signed up for a free Salesforce Flow live session either on Superpeer or Eventbrite, or you filled out the “Contact Me” form on Salesforcebreak.com. Your email was added to an email list on a professional email newsletter platform just for this educational newsletter. If you do not want to receive this email, please unsubscribe below, and you won’t be bothered again.

Enjoy

P.S. Originally published on 11/07/2021.

You can read the next issue of the newsletter here.

You can subscribe to the weekly educational Salesforce Flow Tips Newsletter here.

Standard