Salesforce Trigger Flows Coverage

Flows and low code solutions are the future of Salesforce. That’s a fact. The clear vision of the Salesforce company is to be more friendly for people who have business knowledge instead of development skills. That’s a fact too. Unfortunately when I am writing this article (Feb 2023) the flows are still immature and in many aspects should be threaten more as MVP than a fully delivered product.

One of the most annoying issues with flow is a flow coverage. Indeed it is not a spelling mistake. To be able to deploy flows as active, these flow have to be covered by APEX UNIT TESTS . Yes you read it right. The solution that is promoted as „No Code” that can be „clicked” by functional analysts requires developer who has to cover it by unit tests. If you do not believe, (I did not believe when I heard about it for the first time) feel free to read Salesforce documentation here. Of course somebody might say that you can deploy flows as inactive and then activate them. Yes you can, but your continuous integration solution unfortunately can’t.

The funniest aspekt of this problem is the fact that there are point and clicks test for flows but these point and click solutions DOES NOT PROVIDE COVERAGE.

Fortunately you are able (for now) to decrease required percentage of flow coverage that is required to deploy active flows.

However we do not know if this option will be there in the future. In that case, if the coverage is not created from the beginning it will generate a huge technical debt that has to be paid off, therefore as for my customer’s best practice we agreed that we should keep 75% as suggested by Salesforce.

The strangest aspect of the flow coverage is an algorithm how Salesforce calculates this percentage. In opposite to Apex coverage where the algorithm is simple:

For the flow coverage we have:

It means that at least one element per flow covered by unit tests is enough, therefore writing the unit tests for flows is quite simple.

Summary

As you can see the idea of trigger flow coverage is strange and in some aspect inconsistent. It really shows that flows are still immature and Salesforce experiments to find out the best solution. Are they able to achieve that? I am very positive, because I can recall the first version of Aura. Development in this framework was disaster and almost all developers missed Visualforce. Fortunately Salesforce is fast learner and they introduced LWC and now almost nobody remembers about both Visualforce and Aura. I hope that based on knowledge that Salesforce will gain in next couple of years they will introduce new version of flows  that will be a real alternative for Apex code. 

Author: Bartosz Borowiec