Category Archives: Flow

Flow

Scheduled Flows: Sometimes Later Is Better

You go through life, and it sometimes feels like drinking from a firehose. This is also through for systems. The current work can overwhelm the available resources. Salesforce Scheduled (a.k.a. Schedule-Triggered) flows are an excellent way to defer some of the work and give your system resources a breather. I discussed this solution this past weekend in Minneapolis at Midwest Dreamin’ but needed more time to go into a step-by-step tutorial. Let me describe the use case and the solution in detail here.

Use case:

You need to track key performance indicators for your operation daily and build a history. Out-of-the-box reporting functionality and report snapshots are not powerful enough for you. In addition, you want to perform sophisticated mathematical calculations and expand your solution in the future to include details from related object records as well. You want to leverage something other than rollups as the value of a rollup field changes dynamically. In conclusion, you decided to track these KPIs for cases daily:

  • Count of Created: Created in the previous 24 hours.
  • Count of Modified: Modified in the previous 24 hours.
  • Count of Open: Count of open cases at midnight.
  • Count of Closed on Date: Closed in the previous 24 hours
  • Max Wait Open in Hrs: Max Wait on the oldest open case at midnight.
  • Average Wait Open in Hrs: Average Wait of all open cases at midnight.

The solution has two essential components:

1) A custom object record that tracks the results

2) A schedule-triggered flow that creates a single record every night

Let me show you:
1) See the screenshot below to review all the Daily Summary Record custom object fields.

You will create this custom object to house the resulting values.

2) Flow solution: The flow solution is a very efficient one. Many don’t know that selecting an object is optional in schedule-triggered flow. For this use case, you will use a flow without an object that gets all the case records in the org. If you don’t have more than 50K cases, you won’t have a problem with governor limits. If you know you will get more than 50K cases, we will have to split this flow into several flows and/or perform multiple targeted gets. You will leverage collection filters and need only one single get.


See the screenshot below to review all the elements in this flow (click to see a larger image).


You will create the elements as follows:

  • Start element: Scheduled daily at midnight: No object and no criteria.
  • Get the previous daily summary record: This is only necessary to get the created date to filter cases processed since the last run.
  • Get all cases in the Org by ascending Created Date order.
  • Collection filter 1: Filter for created cases since the last run.
  • Collection filter 2: Filter for modified cases since the last run.
  • Collection filter 3: Filter for closed cases since the last run.
  • Assignment 1: Assign the counts of the collections to variables.
  • Filter Open Cases
  • Loop Open Cases
  • Assignment 2: Add 1 to the counter, calculate case wait, and add to the total wait variable
  • If this is the first iteration, capture the current wait as the max wait. This works because our get is sorted (see above).
  • Create one single Daily Summary Record.

Now you can accumulate this information in your Org as long as you want for reporting and audit purposes. This is a very elan record that won’t consume significant storage.


Enjoy

Standard
Flow

One Big Record-Triggered Flow or Multiple?

I will revisit one of the most popular debates on flow: Do we create one giant record-triggered flow or multiple flows? And should we use subflows?

Here is a little disclaimer: It depends. I’m not too fond of rigid rules, and I am not here claiming you are doing something wrong if you do things differently.

Now that I got that off my chest, I do have an opinion on the topic:

Asking the right question is very important. Is “How many flows should we build per object?” a good question? Generally, I don’t think so. We should ask ourselves: How can I build automation that does not waste system resources, is easily readable, and is easy to maintain?

My priority when I build my flows is that my build should not run unnecessary automation. My most important objective is not to trigger automation when it does not need to run.

In a complex Org, you quickly realize that yields multiple flows per object. When you look at the three tasks that can be performed in one big record-triggered flow, they rarely need to run all in the same scenario.

Now that I told you I heavily use my start element criteria, do I use the formula entry criteria or the line editor with AND/OR operators?

Here is my experience: I often see record-type usage in fairly complex Orgs. I’m not particularly eager to hardcode RecordType Ids in my start element criteria. I prefer to use DeveloperName or Name over Id. And these are only available in the formula editor. So I often end up using the formula entry criteria.

Some of these formulas get very big. But I will give you a simple example:

AND

({!$Record.RecordType.DeveloperName}=”Sales”,

NOT(ISBLANK({!$Record.ContactId})),

   OR(

ISPICKVAL({!$Record.Status},”Scheduled”),

ISPICKVAL({!$Record.Status},”Confirmed”)

      )

    )

 Now let’s get to the other popular topic: Subflows. I recently inherited work that another Salesforce partner did. They did a good job but used subflows in many of their flows. I found the outcome very hard to read and understand. The back-and-forth review left me confused and tired.

I only use subflows if I know I will reuse the logic in another flow.

This post was originally made to LinkedIn on June 19th, 2023.

Read the previous post: Emojis ❤️ and Dreamin’ Events 👌

Standard
Flow, Newsletter

Emojis ❤️ and Dreamin’ Events 👌

Last week I posted about the exciting HTTP Callout flow feature here. This functionality is super cool, but not everybody will need it.

I will discuss something simpler that everybody can use this week: Emojis in Salesforce. 👍

I learned about all the places I can use emojis when I attended the Florida Dreamin’ presentation in 2021 by Jonathan Linn. He delivered a presentation on Lightning configuration and showed that you could paste emojis virtually everywhere that accept text input (string) in Salesforce: Tab labels, quick action button labels, and formulas. I don’t think he talked about using emojis in flows, but a lightbulb went off with me when I saw his presentation. 💡

Here is a slide from his presentation. It still lives rent-free on Slack. 🤳

About a week ago, I received a request from Joy Fuller in the Salesforce Break Flow Support Slack Workspace:

“I would like to display a red arrow when a field value is decreased and a green arrow if it is increased. I tried using images in formula fields, but I’m trying to avoid creating two new separate fields. Is there a more efficient way to do this❔”

Leveraging the video screen-share capabilities of Slack, I recorded a video response. 🎥

I share a lot of content. It is impossible to tell what will go viral. It almost feels like spontaneous, simple content wins over polished and planned content. 📜

Here is the YouTube video of the short demo (under 2 min.).And here is the LinkedIn post that went viral. 🎉

The moral of the story is: Go to Dreamin’ events, folks. You will learn practical tips that you can easily implement to make your users’ lives easier. 🥳

This post was originally made to LinkedIn on June 13th, 2023.

Read the previous post: Shorten URLs Using the HTTP Callout POST Method

Standard
Flow

What is Flow, Really? A Feature?

I recently shared on LinkedIn that flows are getting a lot of attention. I wrote that we need a dedicated certification for flows and a flow champions program.

That post stirred up some debate. I wanted to share my thoughts about this in a long form. I will do this in a Q&A format and then drive a conclusion at the end. Here we go:

What is flow? A Salesforce feature?

One of the topics that came up was whether flow was a feature. It is not imperative to emphasize the categorization, but this topic demands clarification. For me, “account teams” is a feature, and “quotes” is a feature you can turn on on the platform. Flow is a low-code platform, or even if you refrain from this title, a group of products on the Salesforce platform that spans over clouds and products: You can use flow on Sales, Service, Community (Digital Experience) Clouds, and Field Service. Flow has several solutions available that have dedicated product teams in Salesforce. When you go to the release notes, Salesforce flow is one of the top-level pages you see. This was not the case a few releases back. But when addressing some of the topics I mentioned above, this categorization is less important than the definition of the target audience and skillset required to utilize this product to the full extent.

Can flow topics be rolled under administrator or developer headings?

Not really. Administrators do not have to use flows. In fact, there are Salesforce licenses that don’t offer flows or limit flow usage. Developers do not have to use flows, either. It would be great if they did, in any case.

What is the skillset required to use flows?

Flow skillset sits right between admin and developer. A talented admin may never make the transition to building advanced flows. However, they can still customize their Org to address the needs of the business. On the other hand, developers who work in big development teams in giant corporations do not have to master flow or admin skills to do their job. They can deliver specialized and well-documented solutions merged into bigger releases to address business needs. However, if they did master admin and flow skills, they would be super valuable.

What are the prerequisites to learning flow?

Power-user or basic admin skills are required. However, you can start learning flow without being an advanced admin. Some developers in the ecosystem argue that basic development and coding concepts should be studied before learning flows. While this study would help you with flows, this is not a prerequisite to learning flows.

What is the target audience for flows?

The target audience is admins and developers interested in using low code to customize the Salesforce platform through automation.

Flows have their own release readiness webinar separate from Admin and Developer. Jacinta Burke shared that this has been the case since 2019. She said, and I quote: “It was a no-brainer given our audience”.

Have you ever wondered why the Salesforce MVP David K. Liu named his website “SALESFORCE CODING LESSONS FOR THE 99%”? Unfortunately, code and low code are not for everybody. I taught thousands of people flow, and I will be the first to say that there will be people who will not or cannot do flow. They will be able to do simple things like email alerts, but they may not be comfortable tackling some more advanced ones.

Generally, the flow target audience is a subset of admins and developers. There could be exceptions.

Which certification should address the flow skills?

Currently, Platform App Builder is the one that includes flows. It is a mixed bag, though: What do Lightning Apps/Pages have to do with flows? Very little. On the flip side, I know many people with this certification who can only flow a little. I explained above that I do not think every admin should be required to flow. So we either need to revamp the PAB certification or give flow it’s own certification.

Can flows be part of Platform Developer 1 or 2 certifications? They can be, to some extent, if this is what you want to do, but there will be a big audience who flows who never want to do coding. Therefore I think flow needs to be addressed separately.

Whether Salesforce launches a Flow Champions program is totally up to them, but I know tons of people do this already without Salesforce’s funding and support.

This post was originally made to LinkedIn on January 22nd, 2023.

Read the previous post: Why Are Assignments So Confusing?

Standard
Flow, Resources

Why Are Assignments So Confusing?

I noticed this about a year ago: The assignment element is confusing for most people.

I decided to expand my content to include more detail on the assignment element.

Read until the end to find the link to the infographic on assignments that you can download and keep.

What do they do? ⛖

The assignment element performs mathematical operations and moves data between variables.

What they don’t do 🛑

They don’t evaluate criteria to produce true/false outcomes.

Assignments run from the right side to the left side.Variable1 Add 1 will add 1 to the Variable1 value.Variable1 Equals Variable2 moves Variable2 value to the Variable1.

Popular operators ➕

  • Equals
  • Add
  • Subtract
  • Add Item (Multiselect Picklist)

Popular Collection Operations 🟰

  • Equals Count
  • Remove Uncommon
  • Remove After First (Text Collections)
  • Add At Start (Text Collections)

Pro Tips ✖

Use two consecutive assignment elements when you need one assignment to execute after another.

Build formula resources for complex statements.

Functions cannot be used directly. Instead, create a formula resource including functions.

Example Use Cases ➗

Counters: Create a number variable with no decimals, and add 1 in each loop iteration.

Blank text variables with an empty right box.

Assign error messages to a variable in the display text component for variable visibility.

Add 1/24 to date-time variables to add an hour.

Use the Equals Count operator to get the count of records in a record variable.➡️

Now head over to https://SalesforceBreak.com to download your infographic. Click on the last menu item on the main page. ➡️

This post was originally made to LinkedIn on January 8th, 2023.

Read the previous post: Hidden Gem in Spring 23: Schedule-Triggered Flow Improvements

Standard
Flow, New Release

Hidden Gem in Spring 23: Schedule-Triggered Flow Improvements

I can almost hear you! You read the Unofficial SF Sneak Preview by Adam White, and there are no Schedule-Triggered flow improvements in this next release.

So, where does this title come from? 🤔

The schedule-triggered flows are about to become immensely more helpful. Why is that?

Spring 23 is removing the 2,000 elements executed limit in flow interviews. If you followed me long enough, you will know I sparked a debate in 2021 about how schedule-triggered flows should be ideally structured. The challenge I faced was more related to record-locking issues than the 2000 limit.

What is the 2,000 elements executed limit? 🔢

When a flow executes, it goes down a particular path. It goes to a decision element, turns left, and executes 2 elements there. It then goes into a loop and processes 5 records. If there are 3 elements in the loop, that means another 15 elements are executed. All these add up to a total number for each flow interview. When a particular flow interview goes over 2,000 it throws an error. Please note the number of elements on the canvas is not what we count here; we count the elements on the execution path.

Paul McCollum, UXMC likes to live on the edge. He overcame this limit before by using platform events. You can see his session on Automation Hour here. This method won’t be necessary anymore.

The Achilles heel of Schedule Triggered Flows: 🦵

Schedule-Triggered flows are prone to record-locking issues because you cannot determine the sequence of records they will process. They randomly select what to process first.

What is a locking error? 💻

When Salesforce processes a record, it momentarily locks the related records and makes them unavailable for processing. For example, let’s say you want to update an Opportunity. Related Account and Contact records will be locked during this transaction. When you have multiple updates happening simultaneously, your updates may try to update a locked record, which will not be possible. Why are schedule-triggered flows executing multiple updates at the same time? Because they are batched.

What is batching ❔

Salesforce batches certain operations it executes in default batches of 200 unless this is a parameter you can set; you can sometimes change the batch size. Where do you see this setting? When you import 1,000 records using the Data Loader, you can change the batch size in the settings. You can also set the batch size when you build a scheduled path in a record-triggered flow. You don’t have this setting in schedule-triggered flows. If 200 or more records fit your flow’s start element entry conditions, 200 flow interviews will be batched into one transaction.

This is where the trouble starts.

There here are two ways you can mitigate the locking error risk:

1️⃣ Decrease the batch size

2️⃣ Sort and process the records related to the same record together.

When executing a schedule-triggered flow, you don’t have these methods available.

What can you do? ✅

You can set up your schedule-triggered flow to run on the parent record rather than the child. This will ensure that you process all the opportunities related to one account together.

Why was that not feasible before? ❌

When you looped through the related records and sometimes went one level further and looped through the related records of those records, you were almost guaranteed to hit the dreaded 2,000+ elements executed error. This used to be a typical use case where I recommended you go to an Apex code solution. Now you don’t have this problem.

Where is this useful? 💡

You can set up complex roll-up summaries that you don’t need to update immediately. Instead, run these at night when the kids are sleeping.

You can create and update custom object records to flatten your data for reporting ease. For example, if you could not get specific data to show next to each other on dashboards or create complex comparisons in reports, you can now facilitate this via a nightly scheduled-triggered flow job.

The schedule-triggered flow you see above looped through more than 1,000 opportunity records in one flow interview: That’s 2,000+ elements executed.

This is complex territory. I may have left out important points and even made errors in my evaluation. So please comment below and help me get a fruitful debate started.

This post was originally made to LinkedIn on December 13th, 2022.

Read the previous post: What Is The Vision For Flow Testing?

Standard
Flow, New Release

What Is The Vision For Flow Testing?

You showed great interest in flow testing when I wrote about it a few issues back. One of my concerns about this newly introduced GA functionality is that there is little documentation about it. 😟

When I shared this concern in Trailblazer communities, the Product Director for Flow Testing in Salesforce, Henry Liu, reached out. Henry and I had an open discussion on Zoom, and I asked him all the questions I had about testing. Please remember that this information is subject to the standard forward-looking statements disclaimer of Salesforce. Here is the recap of the questions I asked and the answers I received: 💡

  • Is flow testing for admins? Absolutely.
  • Will tests calculate coverage at some point? That is the vision.
  • Will a lower limit on test coverage be required before you can deploy flows to production? Salesforce asked admins this question, and the response they got was that this needs to be decided at the Org level. The vision is that this will be optional for the admin to decide.
  • Does flow testing show us that the flow will run without errors in production? Not exactly. Flow testing does not execute the actions inside the flow, for example. You can test whether the flow followed a certain path, but you won’t know that the flow action won’t yield errors when executed.
  • What should admins study to understand the principles of testing before tackling flow tests: Code testing and Apex test classes.
  • Where do you see this functionality will take us? What is the grand vision? In a couple of years, we should have an automated testing functionality that can test everything custom in Salesforce Orgs, including code.

I think the last point presents a potential future career opportunity for admins. Please note that we should expect Trailhead content on flow testing in the future. Here is a blog post by Jennifer W. Lee on this functionality.

I would like to thank Henry for his time.

This post was originally made to LinkedIn December 5th, 2022.

Read the previous post: Are You Using the Cut Functionality?

Standard
Flow

Are You Using the Cut Functionality?

I use the flow canvas in autolayout mode. 🤖

Before the last release, I went back to freeform whenever I added a decision element in the middle of my flow. When you do that, you get a decision element with multiple empty outcomes, all leading to the next element in flow. 🤦♂️

That means you need to rearrange your elements: a few of the existing elements need to go under various outcome branches, and often a few new ones need to be added. I tried reconnecting the outcome branches to the existing elements to get what I wanted, but this did not work very well in most cases. 😤

I went to freeform to delete connectors and reconnect them the way I wanted. Sometimes I could go back to autolayout; some other times, this did not work. In those cases, I had to continue in free form.

Now we have a new powerful tool in the autolayout mode; cut element functionality. I am not positive you all use this. Therefore, I wanted to make sure I remind you that it is there for you to use. ✂️

Instead of playing with the connectors and rearranging them you can now point to an existing element in your flow, cut it, and then paste it on one of the decision paths. 📢

Some of you may say, we had copy and paste, what is the big deal? This is partially true. You can use copy and paste to create a copy of the current element, but copy and paste renames the element and its components because the original ones are still on the flow canvas. The names have to be unique. Even if you delete the original one, you end up with an unnecessary renaming job you have to complete. 😫

If you have yet to try cut and paste elements, give it a try now. And if you are still using freeform, give autolayout a try; you will like it. I hardly ever go to free form now. 🙏

This post was originally made to LinkedIn on November 14th, 2022.

Read the previous post: Do We Know How Scary Flows Are?

Standard
Flow

Do We Know How Scary Flows Are?

Let’s discuss whether flows are scary for new learners this week, fresh after Halloween. Grab your pumpkin spice latte, and follow along: 🎃I recently had a meeting with Salesforce where I invited them to survey my community of new learners to understand the challenges for most folks. During that discussion, I realized, or remembered again, that Salesforce does not know how scary the flow canvas is for most admins.

Late October, I was in Orlando at Florida Dreamin’, taking a break after presenting my session, when an experienced admin approached me. “Is there a Flow for Dummies Book?” they asked. I said there was none, and I proceeded to ask questions to understand the background better. 📚This person was an experienced admin. However, they defined themselves as not that good with formulas. And they wanted to learn flow really bad and thought flow canvas was very scary for them. Throughout our discussion, I realized how emotionally charged the topic was for them. This was a very stressful situation.

😱I am sure many out there feel the same, but they don’t express it.

There is nothing wrong with expressing distress around learning a new topic. ✅

I firmly believe that everybody can learn flow to some degree and extend their admin skills. However, depending on your skills, you may never be able to tackle the advanced flows. Or it may take you seemingly forever to master just the record-triggered flows.

Everybody’s learning journey is unique. And that is OK. ✅

I appreciate this interaction immensely because I clearly remembered the target audience for my Salesforce Break site, my YouTube channel, and my Udemy course. My objective on these sites is to teach the majority how to flow and make the canvas less scary. My challenge is to gradually build your skills at an acceptable pace so that the impostor syndrome does not creep in when you follow along with the curriculum. 🧄

This post was originally made to LinkedIn on November 8th, 2022.

Read the previous post: Flow Testing Is Here: Exciting News!

Standard
Flow, New Release

Flow Testing Is Here: Exciting News!

Salesforce recommends developing custom code and custom low-code in Sandbox Orgs and performing thorough testing before deploying them to production.

For code, Salesforce enforces test coverage: You need to run tests and ensure 80% or more test coverage for all your custom code before you can push your code to production. This means your test classes have to cover 75+% of the custom code lines in your Org.

For flows, there is no such requirement. You could develop in production or deploy flows without testing first in the Sandbox. However, this approach is not recommended.

Until now, there was no easy way to run and rerun prebuilt tests for your flows similar to the test class functionality for code.

With Winter 23 Release, you received the flow testing functionality (GA) that gives you this feature for record-triggered flows.

Why would you use flow tests?

  • Flow tests make rerunning the tests by you or your colleagues much easier and faster. ⏩
  • When you build new automation, you can now run/rerun all existing tests in your Org. ♻️
  • Before Salesforce releases, you can retest your existing flow automation running on the new API version for release readiness purposes. 💻

How does it work? How do you create flow tests in Salesforce? There are two ways:🧪 “Convert to test” button: Run a debug and convert the successful debug run to a flow test.🧪 “View tests” button: Open the tests screen and create a test using the wizard.

There are three main components to a flow test in Salesforce:1️⃣ Set test details: Set parameters such as Create/Update, and Immediate/Scheduled Path.2️⃣ Set triggering record: Set the field values for the test record, including values for after update if the test is for update.3️⃣ Assertions: Set the expected outcome and custom error messages if the expected outcome is not observed.

What are assertions? Assertions are logical statements that can evaluate as true or false. They are intended to test the expected outcome of the flow automation to decide whether the flow passed the test or not. A good example is “Does Opportunity Stage equal Qualification?”: True/False.

Observations:

  • Test records: When you create your test, you can point your test to a record. As a result, the test inherits the field values from this record. However, you can modify these field values before finalizing your test. Your test is not linked to this record but contains and uses its field values.
  • Decision outcomes automatically create boolean variables. The variable is set to true when the flow goes down the associated path.
  • Actions in flow may create output variables. You can check the value of this variable. Some actions may not have any output variables. Then it becomes a difficult task to check whether the action was completed successfully. Email Alerts seem to auto-create a boolean variable with the same name. I assume this means the action was completed successfully, but I am not sure. I am still researching this topic.
  • You can use the “Was Visited” operator to evaluate whether a particular element was visited on the executed flow path.

Limitations:

  • There is limited information out there about flow testing. The release notes site for Winter 23 has a dedicated page that contains only a brief paragraph. This is not sufficient.
  • Update: Followers reported tests are visible in change sets (Check the comment by Yumi below). /*I don’t believe you can deploy these tests via a change set. If you are working with change sets, this is a significant limitation. You will refresh your Sandbox eventually, and you may lose the tests in it.*/

This post was originally made to LinkedIn on October 24th, 2022.

Read the previous post: Migrate to Flow Best Practices

Standard