Architect (not build) Flows

There are some fantastic resources to help you build Flows. To help you master the capabilities. To understand when to use certain features based on use case.

This article is not another one of those. 

It is designed to take a higher level perspective to make sure you are building the right flows, in the right way, first time. This lowers the risk, reduces your stress levels and helps you accelerate your career.

The result is less rework, faster time to benefits, and ultimately happier business users.

Apex with a GUI

Over the last couple of years Flow has matured from simple automation to a powerful development platform. It is nearly as capable as Apex, but it is fronted by an easily accessible drag and drop GUI (graphical user interface).

That means you can do almost anything with Flow, so you should treat it with respect. If not it will bite you. A bug in your Flow could cycle through every Opportunity and change the Stage, Amount or worse, delete it. 

So “With great power comes great responsibility” a phrase best known from the Spiderman comics, but that phrase was borrowed from Voltaire in 1600’s and has been repeated by politicians such as Churchill.

Think like an architect

Don’t just jump in and start creating Flows. I know there is a natural inclination to do that.  We all have it. But if you do you will probably regret it. You should design your Flows and come at the design with an architect’s mindset. There are 3 guiding principles you will find on architect.salesforce.com

Trusted solutions protect stakeholders.

Easy solutions deliver value fast.

Adaptable solutions evolve with the business.

As with any development, the business analysis is critically important. Ask the ”5 Whys” to really get to the bottom if what is required. Ensure that you perform org impact and dependency analysis to understand the risk and complexity of the changes and any potential metadata conflicts. This will help you understand the implications of making the change on other areas of the org. It will also highlight if you are making changes to metadata that another team is also changing. You can then provide an accurate estimate for the time it will take to design, develop, and test, which will help set expectations with your business users.

It is 100x cheaper to find and fix potential issues at this phase in development than when the code is in production and failing. 

Failing to do this analysis and design properly creates 3 different problems, all of which cause rework, delay the business getting benefits, and erodes the trust of the business users

• You build the wrong thing because you didn’t understand the true requirement in enough detail.  
• You have metadata conflicts in development or production, or worse you break the org requiring a rollback and the difficulty of “unpicking” the data that was changed. BTW You cannot simply restore from a backup, because you may lose changes that business users have been making whilst your Flow was causing havoc.
• You build in technical debt that is expensive to rework. This may be from different perspectives; data model, security and permissions, or performance.

Develop Flows in Production

Flows can be developed in Production. But should they? We’ve just said that flow mirrors Apex, and Apex can only be developed in a Sandbox and deployed to Production. To deploy Apex needs at least 75% test code coverage.

So even though there are no such limitations for Flow, you should impose them on you and your team. You should develop in a Sandbox and then deploy to Production. If that process is takes too long, then use this an an opportunity to reengineer your deployment processes so it is a slick machine.  

You should also design and build the Flow so that it can fail gracefully – something we call “Fault Paths”.  There is the “happy path” where the Flow is able to access the data and execute the automation.  But there may be a number of reasons why it cannot run and finish correctly; for example, the user doesn’t have access to the data. 

Ensuring that the Flow makes the expected changes to the data based on the logic in the Flow is Unit Testing.  But there is also System and UAT (User Acceptance Testing). These tests ensure that the Flow is doing what the business requirement needs it to do.

You should then build test scripts for the happy path AND the fault paths. This is very difficult to do if you do not have a design that is documented as a “flow diagram”. Simply looking at the Flow, which might be quite complex, is difficult – plus it only covers Unit Testing.

A Flow Design Documentation standard

Fortunately we can lean on the work done by the Salesforce Architect Evangelist team, They have designed a very clean, effective and elegant notation for documenting architecture diagrams. That notation can be used for Flow.

And the great news is that you can use Elements.cloud to draw the diagrams and connect the diagram back into the Flow in the metadata dictionary, and even link steps the Flow diagram to the specific metadata items that are used. For complex Flows use the Elements.cloud drill down approach. And as a Flow will evolve, you have version control built in. 3 reasons why Elements.cloud is becoming the preferred diagramming tool for architects. Even more exciting is Elements.cloud development team are researching how they can automatically document existing Flows – drawing diagrams and order of execution diagrams.

The diagram below is a simple flow that is drawn left to right, but you could also draw it top to bottom.

Step by step Flow

Whether you are migrating from WorkFlow Rules and Process Builders, or building new Flows, you should follow the following steps.

1. Analysis: What is already in the org; automations, code, objects, managed packages, Flow APIs. What is the true requirement in business terms and outcomes.
2. Design: Consider all the paths. Not just the happy path, but how could the flow fail and build in the paths so that it can fail elegantly. We call this Fault Coverage. 
3. Build: Only when you are happy with the design from a functional and architectural perspective. Then you can have fun building Flows!
4. Document: You will thank yourself in the future when you come back to update the Flow, or when you review the updates in each new Salesforce Release.
5. Test: (Unit & UAT). Testing for some but not all aspects of Flow can be supported by the new test features. UAT is testing against the original requirements and flow documentation
6. Deploy: Whilst you can develop Flow in production, you shouldn’t. You should be developing in a Sandbox and then deploying to Production when you are confident that the tests have been completed successfully.

Notice that there are 6 steps here and ONLY 1 is “Build”.  

The final word

Flow has huge potential and when they are well-architected and are developed using formal development processes, they can provide declarative developers the opportunity to deliver so much capability, very quickly. 

#expertsreact

Hear from Sandi Nuss Zellner on #expertsreact