So in this next post in my series on solution architecture for the Power Platform I’d like to move onto another consideration architects should be thinking about at the platform level when it comes to designing solutions. In this post we’ll focus specifically on considering platform limitations and some of the key focuses we should be broadly aware of when designing solutions built on the Power Platform! 🚀
Why?
So let’s start by discussing the need to have this as a consideration when designing Power Platform solutions. When working with Power Platform, we’re not just provided with a completely unlimited set of resources for us to chuck our needs and requests at as we please 🙂 … there are some limits to consider!
As solution architects, its our responsibility to design solutions that either don’t hit the limits of the platform, or that are able to handle what will happen if we do hit those limits in a way that still delivers a good user experience.
API Request Entitlement Limits
So the first thing solution architects should be aware of is the entitlement limits we have to play with when it comes to interacting with the Power Platform. This covers any API calls we make to Power Apps, Â within Power Automate flows, to Dataverse and more.
Read more about the limits here
Requests limits and allocations – Power Platform | Microsoft Learn
It’s important as a solution architect you’re aware of these entitlement limits and how they’re imposed i.e. on a per user level etc so that you design solutions in a way that will support their ongoing scalability and availability.
Service limits
Other and API request limits service limits are also something architects should be aware of and relate less to user operations and affecting or imposing limits on users, and refer more to the maintenance of specific services within the platform. Read more below.
API limits overview (Microsoft Dataverse) – Power Apps | Microsoft Learn
Best practices for handling platform limits
So there’s a few things as architects we can do when designing solutions to design them in a way that takes into account the platform limitations we’ve talked about. The first thing we can do is something pro-active and that is simply to design solutions and logic in a way that minimises API calls preventing us from being more likely to reach platform limits. In the cases where we believe we may still reach limits we can implement logic in a way that handles errors we may get back for reaching platform limits. We may be able to implement things like retries and handle these so that we will deliver a good user experience even if it isn’t an excellent one.
What’s coming up?
In the next post in this series on solution architecture for the Power Platform, we’ll finish up thinking about the high level platform knowledge and considerations we need to be making by looking at solutions that need to be highly available and reliable. Stay tuned friends! 💖