Implement Flows Like a Pro

Learning Objectives

After completing this unit, you’ll be able to:

• Understand how creating flows is a type of development.
  
• Follow risk-mitigation practices when creating flows.
  
• Build flows in a sandbox environment.
  
• Plan a flow’s development and deployment.
  

This badge is one stop along the way to Flow Builder proficiency. From start to finish, the Build Flows with Flow Builder trail guides you through learning all about Flow Builder. Follow this recommended sequence of badges to build strong process automation skills and become a Flow Builder expert.

Great Power, Great Responsibility

If you’ve completed every other badge in the Build Flows with Flow Builder trail, you’ve created a fair number of flows and are familiar enough with Flow Builder to create your own. With all that experience, you know that it’s an incredibly powerful tool. Flows can:

• Receive input from your org’s users.
  
• Create, update, and delete Salesforce records.
  
• Send emails to anyone.
  
• Interact with data in external systems.
  

All of these features (and more) are valuable, but they also carry some risk. Users can make things behave in unexpected ways, data can be lost or mixed up, emails can be mistakenly sent to customers. This is the nature of automation: It does exactly what you tell it to do, but not always what you meant it to do.

As a flow creator, you don’t just build a flow and activate it. You have a responsibility to do more to minimize risk and to make sure your flows perform as intended. You need the right mindset.

We’re all human, and we all make mistakes sometimes. It’s perfectly normal for flow creators to not get it right the first time. Even experienced flow creators rarely get a flow exactly right on the first attempt. On top of that, your flows run in a living org that changes and grows every day and affects everyone who interacts with it.

If a flow runs whenever a case is created, what happens if a user doesn’t enter the values your flow expects? What happens if you add a new case record type? A new picklist value? A new user profile? How can you design your flow to run not just in the expected best-case scenario, but in imperfect scenarios as well?

Mitigating Risk

You can employ certain risk-mitigation practices to catch errors and imperfect scenarios.

• Create a plan that defines your flow’s outcomes.
  
• Use the plan to test your flow as you’re building it.
  
• Build your flow in a safe, separate location (a sandbox).
  
• Avoid practices that cause your flow to exceed Salesforce limits.
  
• In your flow, add functionality that anticipates problems and handles them gracefully.
  
• Perform debugging runs for each type of user after you create the flow, but before you deploy it.
  

When you employ all of these practices, you can catch almost any problem hiding within your flow. But there’s something you should know: These are common best practices for developers.

If you’re a developer, these practices are probably familiar to you. If you’re an admin, don’t panic! We’ll help you learn these skills, and you won’t have to write any code. You can follow all of these practices within Flow Builder’s declarative toolset.

Using declarative tools doesn’t make you any less of a developer. Building automation is more complex than adding users and configuring apps: It’s developing a solution from start to finish. Testing, error handling, debugging, and being mindful of system limits are all practices that take you a step beyond the usual admin tasks.

In this badge, you learn about each of these risk-mitigation practices so you can be a true flowveloper! (That’s a flow developer.)

Always Build First in a Sandbox

We’ve mentioned this in many badges, but it bears repeating: Always build flows in a sandbox first. The same advice applies to changing an existing flow.

When you build flows and make changes in a sandbox, you should test and debug before making it available to your users. Even making a small change in production can be risky. For example, let’s say you need just a little tweak to fix a typo. You decide that it’s such a small change, you can do it directly in production, skipping the sandbox. That’s great… for now.

The following month, you build a new version of the flow in your sandbox, test it, and push it to production.

But the error is still present in the sandbox, so the push overwrites the fixed typo in production. Now your records, reports, and any place where the data is visible has the misspelled “Activ” value again! How embarrassing!

When you finish your work in the sandbox, how do you get it to production? We cover that at the end of the Flow Implementation II badge. First, let’s go through all the best practices before deploying to production, just as you do when building a flow.

Plan First, Build Later

We mentioned this in other badges, but it’s a really important risk-mitigation practice: Plan your flow before you start building it.

A flow plan can be in whatever form you prefer: a flowchart, a table, a diagram. What’s important is that it contains detailed information about the intended flow.

Notice that we didn’t say anything about planning the flow’s elements. Don’t worry about those details for now. Focus on the who, when, what, where, and why; the details of how will come together as you build the flow according to your plan.

Of course, no plan survives first contact. It’s natural that as you’re building the flow, you’ll discover or remember things that require you to adjust your plan, possibly after you’ve finished documenting that plan. That’s fine, go with the flow! Feel free to adjust the plan as needed, and don’t let it discourage you from making that first draft to mitigate the risk of building without a plan.

Plan a Flow

In this badge, you follow a few flow building scenarios, focusing on the best practices for building and implementation. Imagine that you’ve been asked by Support to build a flow. Here’s the request:

If a case has ever been escalated, metrics should reflect that escalation even after the status changes. Also, when a previously escalated case is closed, email the account owner.

It’s common for users to make requests for specific solutions, even though those solutions aren’t necessarily the best way to accomplish what they really want. For example, the user making this request might’ve said, “Cases should stay escalated.” But a case’s status can’t stay escalated forever, because the support team needs to close it eventually. Ask questions to find the reasons for the request, rather than just accepting the requestor’s assumed solution.

Let’s break this request down into a plan.

We have a plan, but don’t start building your flow yet! In the next unit, we talk about test-driven development, a risk-mitigation strategy that you should understand before you start building.