MYTHBUSTERS: Flow Edition

I often see posts in the ecosystem complaining about the direction of flows and low-code development on the Salesforce platform. While I agree with the opportunity to improve for the most part, I am tempted to give my take on a couple of recurring themes I see:

Flows are bad and Salesforce should ban them

Detail: At least the development of flows must not be allowed in production. All deployments should require code coverage.

My take: This is a valid request that can go on IdeaExchange (probably it is already there). This request usually comes from code developers who feel they are losing control of the custom development in their org. You can ban flows in your org. Why have you not done so? Do you need Salesforce to ban it for everyone so that you can make it happen?

Flows don't support good development/deployment practices

Detail: Flows don't support automated testing. Automated testing is key for an efficient CI/CD process.

My take: Many issues and opportunities exist in this area, especially related to automated testing. However, you can test flows. You can build flows in a scratch org. The process is just more difficult and slower. Remember that not all clients have a CI/CD process. Don't assume everybody is a large Enterprise.

Flows are not secure

Detail: There are documented incidents where screen flows deployed on digital experience sites were determined to be not secure.

My take: This topic has drawn a lot of attention lately. It is a critical topic and should be continuously emphasized and worked on. However, security needs to be evaluated and managed in totality. The focus on low code security is a little misdirected, especially in an era when people take uncalculated risks with LLMs. Does this mean we should only worry about low code security? What about code, integration, authentication security, prompt injections, etc? Are we good there?

Flows are slow; we should use pro code instead

Detail: Why would you use flow for triggers when Apex is faster? Just code everything all the time.

My take: Flows are slower than Apex in every category. So why would you use flow? Let me ask you this question: Why would you use batch jobs over real-time integration when real-time updates are faster? Why do we have architectural choices anyway? Let's call what the best solution is all the time and use only one single solution in every case. If you are not an Enterprise client without code developers in-house, would you want to build frequently-changing business logic inside an Apex trigger? I would not. Going back to the same point: Don't think everyone is an Enterprise client; don't think everybody has the same requirements.

You can find more of my comments on this topic in this Gearset podcast episode HERE .

What do you think? Please comment below.

Visit https://Flow-Canvas.com for Flow Canvas Academy: Get access to a free Flow Knowledge Assessment Exam.

If you ?? the newsletter, please recommend it to a friend or colleague.

#Salesforce #Flow #Automation #Development #Deployment #DevOps #Myth #Discussion