I remember 1 of my first tasks in Salesforce before decade - provide the user screen to set some input and then run some calculations based on the input. The Salesforce person who worked with our team reference me to the visual flow, noting that it was build exactly for such process.
I read few basic guides and start implementing.
Very soon, we found out that the flow cannot display input search lookup and the only alternative was to provide dropdown selection. But since in our case there were potentially hundreds of options it made the flow not suitable for the case. Ok, next time I thought.
But it seems that this was repeating itself - every time I was trying to implement task with flow, very soon I found limitation that prevented me from using it.
New Flow
This was true until Salesforce added some huge improvements to the flow (started somewhere 2 years ago). Irrelevant elements were removed from the toolbox, bulkifying all DML/SOQL elements, support also setup objects, complex logical operations and much much more. In addition, combining the flow with Process Builder increased its usage significantly.
Today, it seems the flow can be used almost for any common task instead of apex code. Furthermore, for complex logic we can still use the flow partially and invoke from the flow apex code that we will handle the complex part.
It raise some questions regarding the Apex code usage in future.
I could write list of things that still cannot be done with flow and maybe estimate which will be too complex to be supported by flow in future, but the truth is that building application without code is not new concept (not only in Salesforce, of course). There are lots of tools in Salesforce that were build for that purpose - page layout, custom object/field, email alert, workflow (RIP), validation rules, reports/dashboards, process builder. However, it turns out that customization requests become more and more complex and in many cases those tools were not able to provide proper solution. The new flow catch up the race and can cover wider area of the requests.
Flow Sample: Merge Account with Flow
I decided to test the flow usability with sample that can point out few notes regarding its ability and flexibility.
Take for example the following request - user want to merge account records but needs option to include/exclude related lists. This cannot be done with the standard merge as the related data from the merged record always being added to the master record.
We need customization.
Can it be done with flow? (Of course it can. otherwise I wouldn't pick this sample... But when started I wasn't really sure about the complexity).
For simplicity assume the process start from the master account record page.
In the flow will have the following steps:
1.Get master account data.
2.Screen for selecting second account.
3.Get the selected second account data.
4.Show data from both master and second accounts, options to set the output for each field and checkbox option 'Merge Related Lists'
5.Update the master account with the selected values
6.If the option 'Merge Related Lists' was selected reparent the related records.
Additional decisions for simplicity:
1.I used only 1 checkbox which determine if all related lists should be merged or none. Could use several checkboxes for each entity (e.g 'Merge Contact', 'Merge Opportunities'....)
2.If user select to merge related lists I will reparent only contacts and opportunities records.
3.Merged only 3 fields: Account Rating, Type and Account Source. Could set all the other fields but for the demo it is enough.
This is how the flow will look like:
Lets focus at element 'Set Merge Output Fields'.
I added Choice option for each field that need to be merged and per each 2 choices variable: first option from the master account field and second from the second account field.
After setting the fields and clicking next the flow will assign the user selection to the master record, update it and reparent the related records only if the checkbox was checked.
Seems that's it. After activation, I can embed the flow in the record page (added as tab in this sample) and launch the flow.
Few notes worth mentioning when comparing the flow to the apex code:
- The list of fields cannot be dynamic. In future if new fields will be added to the account, it will need to be added also in the flow.
- The needs to set choice + choice options per each input might make this process exhausting if you have lots of fields on the account.
- Dynamic is missing in additional areas. Assume that we will want to allow merging more than 2 accounts in single run. We can add button 'Add Another Account' and store the accounts in collection, but seems hard to show per each field dynamic choice options that will be populated at run time. Optional we can allow up to X accounts in the merge and define in advanced choices for each.
- If you are building application you can take the dynamic concept further. What if you want to use similar functionality for merging leads or contact or any other object? Will need to build flow with similar logic per each. This won't be very efficient.
- Lack of styling options in this example was noticeable, It would be better to show the data in table where you can compare clearly compare the data from the merged accounts.
Some Conclusions
Some of the missing parts above might be supported in future in the flow. However, looking at those notes with the main discussion, we can conclude that the flow is very powerful and useful tool. It can cover lots of requests, but it reduces the flexibility.
Usually it will be good enough when the development is for internal users. When it designed for end customers you might need this flexibility and advanced options. Same goes when building applications for distribution, you want to build flexible solution and impressive UI. With the estimation that requests will keep getting more complex apex will still be needed. Most likely the require skill level from developers will increased, since simple-medium tasks can be done without development.
