DEV Community

Cover image for Being Sustainable on the Power Platform
david wyatt
david wyatt

Posted on

Being Sustainable on the Power Platform

We all now understanding the impact on our environment from our actions, our ever expanding need for energy is driving up our worlds average temperature. Its great to see organisations and Governments taking this serious and helping drive change, but as with everything we need to be responsible for our actions. And this is where this unlikey segway leads us to the Power Platform.

Building on the Power Platform is incredibly easy, it lowers the barrier to entry and empowers hundreds of thousands of citizen developers. And although this brings incredible benefits there are lots of unseen consequences, everything we build and run on the platform uses energy.

Its incredibly difficult (if not impossible) to get values of energy used by a flow or app, as it depends on multiple factors:

  • Data center location
  • number of actions/components
  • Connectors used
  • The efficiency of the other end of the connectors
  • Time running
  • Logging settings
  • Data storage

just to name a few.

But taking these into account it allows us to identify where we can be more efficient in our flows and apps.

1. Do you need it

This only really happens in LowCode and citizen developers, but before we start you need to ask "Do I need this/is it going to add value". Developing solutions uses energy, every save, every test run, every interaction. They all send api calls to your browser, use storage and run compute time on the server.

Just clicking create a new flow generates over 317 requests and 36.5mb of data moved.

network traffic

Make sure that there is a end goal, it could be learning or adding business value, but it should never be just an excuse to make something.

Also consider if Power Automate or Power Apps is the right solution, Outlook rules are more efficient if they can be used, and likewise Power BI can be more efficient then a Power App.

2. Develop Efficiently

I am very guilty of this, when I come to develop my solutions I often use the 'Trial and error' approach, and although it is the fundamental way we all develop it should not be the lazy approach. Take the time to complete training, read documentation, create your own documentation, and share knowledge with your colleagues. Every failed run uses energy, if we could be 1% more efficient without development the impact will be hugh.

3. Build Efficiently

This is a big one, how we make our flows/apps can have big impact.

From a flow side make sure there are no unnecessary actions, every action requires 2 compute cycles, the Power Automate/Logic App engine and the api it calls (even a condition is a api call). This can be compounded with loops, as each iteration uses a call, and if its bad at one level imagine what a loop within a loop can be:

Loop Actions Inside Loop 1 Iterations 1 Actions Inside Loop 2 Iterations 2 Actions Inside Loop 3 Iterations 3 Total Calls
1 2 1000 2000
2 1 1000 2 100 200000
3 1 1000 1 100 2 10 2000000

Quick tips for Power Automate

  • Use filter action instead of conditions within loops
  • Only have actions within loops if impacted by iteration, move everything else before or after
  • Use Compose/Select instead of loops with loops
  • Use stringfy comparison instead of comparing to lists with 2 loops
  • Use select on your api calls to decrease size of body
  • Don't use unnecessary Composes or Variables
  • Use Office Scripts for writing to Excel instead of update item action
  • Use Child flows for reusability

For Power Apps make sure you are not using unnecessary components, everyone has to be rendered on your browser, using energy. And try to use the connectors within the App when possible and not send to a flow.

Quick tips for Power Apps

  • Reuse components where possible (dynamic values)
  • Don't add unnecessary components (does that image of the logged in user add value)
  • Don't over use Timers (make sure duration isn't overly short and it ends when not needed)
  • Use showColumns/dropColumns when getting data to decrease response body size

4. Run Efficiently

The schedule trigger can be the most inefficient or most efficient way to run flows. Here's 2 use cases where a schedule could be the best and worst option.

Setting on a recurrence on every minute can drive waste if we only expect the flow to meet the right condition once a day.

Triggering a flow everytime a SharePoint file is moved, when we could wait for the end of the day and run once for all.

Picking the right trigger is critical, along with any conditions. Having a flow run only for the first action to be a condition is incredibly wasteful, as a trigger condition could have been used to stop the flow from running.

5. House Keeping

This is a big one, I see far too often unused apps and flows taking up space and impacting processes like the CoE Kit. Even worst I see flows being triggered for no reason.

I once found someone was exploring and setup a flow to run every minute, and all it did was read contents of a OneDrive file. This flow was left running for almost a year, just imagine the wasted energy.

It's so easy not to see the consequences of spinning things up, and this where a well monitored platform is key. Getting good telemetry (not as easy as it should be on the Power Platform) is important to identifying unnecessary apps and flows. These unused apps and flows add zero value and should be deleted, and if you are worried about losing them either as a minimum turn the flow off, or ideally download them.


As with most things, these small changes don't seem to make any impact, but they scale up, if every developer on the platform used 1 less action and ran every flow 1 less time a day the savings will be incredible. We don't need to sacrifice quality work to be sustainable, just make sure we consider being sustainable in everything we do.

Inspired by Bala Madhusoodhanan

Top comments (1)

Collapse
 
balagmadhu profile image
Bala Madhusoodhanan

Really cool tips.. Thanks for the mention