Showing results for 
Search instead for 
Did you mean: 
Helper III
Helper III

Best architecture to optimise performance

I'm building a flow that has many actions and the Flow editor is getting slower and slower with each action I add.


The logic has eight different scenarios and the scenario to be used is established at the top of the flow. In each scenario I need to create/or edit a SharePoint list item, edit an existing SharePoint document (properties only), and send an email.  For each of these scenarios the actual values for fields and the text of the email varies.  I need to decide which of the following approaches performs better, specifically in the Flow editor.


Approach A: use a SWITCH construct and for each of the eight cases use three actions to create/edit the list item, update the doc properties and send the email. The different values will be hard coded into the actions.


Approach B: use a SWITCH construct and for each of the eight cases populate variables with the values for that case. Then, following the SWITCH, use just one set of three actions to create/edit the list item, update the doc properties and send the email. The different values will be derived from the current values of the variables.


Both approaches are a lot of work. Which one will be easier on the Flow editor? I don't really care too much about the performance of the flow when it runs. If it runs a few seconds longer or not does not really matter, but staring at an unresponsive Flow editor for half my work day is unacceptable.


What are your insights? Any better ideas?

Community Support
Community Support

Re: Best architecture to optimise performance

Hi @teylyn1,


If you want to make your Flow could run successfully, Approach A will be better and more straightforward, although this will make your Flow extremely large.

However, if you want to achieve your Flow more dexterously, I think Approach B would be a good method. If you can elaborate on the implementation details of method 2, maybe I can make some suggestions on the implementation details in the process.

Best Regards,
Community Support Team _ Lin Tu
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

Helper III
Helper III

Re: Best architecture to optimise performance

Hi @v-litu-msft , thanks for your reply.


I have started work on approach B. Here are some implementation details


  • At the start of the flow, I initialize a truck load of variables and Compose static objects with HTML building blocks for emails.
  • In the first part of the flow, the variables are populated with their default values from properties of the SharePoint file
  • several conditions then evaluate the current state and set a key variable to one of nine possibilities
  • a SWITCH with 9 cases then sets or clears the variables to the values for this case
  • in a condition, a SharePoint list item is either created or updated and all fields populated from the variables
  • the SharePoint document is checked out and all properties are populated from the variables, then the doc is checked back in
  • an email is sent using the Compose outputs and some of the variables


I feel that this flow performs better in the editor, because each action that needs to talk to SharePoint takes up resource, whereas assigning variables, even many of them, doesn't seem to be such a performance hog.


If you have any ideas on how to improve on this, I'm keen to hear.



Helpful resources


Microsoft Ignite 2020

Check out the announcement of Power Platform content at Microsoft Ignite!


Experience what's new for Power Automate

Join us for an in-depth look at the new Power Automate features and capabilities at the free Microsoft Business Applications Launch Event.


Power Platform 2020 release wave 2 plan

Features releasing from October 2020 through March 2021

Top Solution Authors
Top Kudoed Authors
Users online (10,564)