I've gone into detail about the assessments and review every Power Platform solution should go through, all but one the Impact Assessment. Not all organisations uses an Impact Assessment, but for me they are critical, especially for automation tools like Power Automate.
- Intake Assessment
- Architecture Review
- Security Review
- Design Review
- Power Apps Code Review
- Power Automate Code Review
- Office Script Code Review
So what is an Impact Assessment, well its kind of in the name, it looks at the impact your flow/app will have on the systems it interacts with, this covers:
- Platform API Limits
- Licenses
- Connector Limits
- Platform Setup
- Platform Administration
1. Platform API Limits
Power Platform API limits are something that are going to impact more and more makers. Every action in a flow, a set variable, condition, Get Items, uses an API call, and that includes multiplying actions within loops by the length. The limits use to be 5k Power Automate Plan 1 and 15k for Power Automate Plan 2, with 15k kind of being a sweet spot for most. That has now been replaced with Power Automate Free 6K and Premium Licenses 40k. Add in the complexity of Apps that call flows using the users API allowance it can be hard to understand and plan.
This is why the Impact assessment is key, it helps understand the limits that will be hit by taking into account all flows owned by that Maker/Service account. To help mitigate these limits the assessment can look at:
Optimisation
Looking at more advanced techniques like Office Scripts and 'Expression First' approaches could limit the API calls. This would instigate a more in-depth design review with senior engineer.
Scheduling
If there are peaks and troughs over the week can it be paused till next day. This could be by a tracker or a time window.
Low Balancing
This could be achieved in 2 ways, first ensuring that the Service Account/Maker has the right selection of flows to ensure it is under the limit. If they are going over they could move/swap with another account. The second is to split single processes over 2 accounts by setting up trigger conditions (i.e. time window or an odd/even reference).
Off Loading
This is similar to Optimisation but focuses on pro code solutions, and it can be full or partial. A full would look at moving the flow to Logic Apps, as this may be more cost effective, though this is normally picked up during Arch Review. The partial offload moves a chunk of complexity, Office Scripts are a simple version of this, but the pro code would rely on something like a Azure Function app.
Licenses
Our old favourite, if you cant get there by any other way that you can use a Per Flow License, which gives you 250k API calls per day. The problem with this is it as expensive, and per flow (so you can't use all of the calls in one flow/solution then you waste them).
2. Licenses
Rolling nicely into the second consideration, licenses. What licenses will the flow/app need. So does it have premium functionality, is there licenses available to reuses, available spare licenses, or is a procurement required.
The impact of licenses can move the process from a good ROI to a net negative, apps can be impacted more, does the user base have the license already, are there more premium use cases?
Then there's the legal side to consider. If a flow uses premium functionality then the receivers of the benefit should also have the license. This is very hard to quantity, does the reviewer of an automated email get value, well no, but what if the flow covers 4 peoples work, do they all need licenses 🤷♂️
Finally what about the other systems you are integrating with, do they allow RPA, do they require different licenses?
This all has to be considered and understood during the impact assessment.
3. Connector API Limits
This could potentially be the most important as it expands beyond the Power Platform. Each system you interact with will have its own API limits and storage limits, these are split into 2 main buckets.
Personal
The Graph API is a great example of this, as each user has their own limits, if they go over them they are throttled.
The limits are normally tiered over time, with a per minute, per session, and per day limit.
Its easy to think that you will not get near the limits, but automation often works faster then usual and then the numbers look low.
- SharePoint 600 per minute
- Excel 100 per minute
- OneDrive 100 per minute
- Outlook Send Emails 30 per minute
I recommend taking full look at Outlook here
Those limits could easily be hit, especially with concurrency turned on for either a loop or flows.
Tenant
The good news with Personal limits is only the user is throttled, but with Tenant limits the entire organisation can get throttled.
This throttling would cascade across the organisation and potentially bring down multiple systems. And every system you interact with will have its own limits, so it is important to understand them, the flows requirements, and the potential impacts of going over.
4. Platform Setup
Does the flow/app require changes to the platform, this includes things like:
- New environment
- New connector
- DLP update
- New environment feature turned on
Depending on your organisation these could quick admin jobs or a full approval process.
5. Platform Administration
Every solutions has its own requirements, as shown in the platform setup but this also covers maintenance of the solution.
If your platform is not automated then this can be very labour intensive, examples are:
API Key Rotation
OAuth is the way to go when you can, but some systems only allow API keys, and these keys can often have short rotation windows. This means an administrator might have to go in and update the connections every month or more.
Configuration Updates
With tight change management controls admin files and environment variables may require approvals and admins to update. If the flow requires constant updates this can take up considerable time for the approvers and platform admins.
Rapid Deployment Schedule
If the flow has a rapid update schedule, with a release per sprint as an example. Understanding the impact of the platform admins who have to complete the manual deployments.
As you can see Impact assessments can deliver huge benefit, critically they ensure that every solution is stable, it does not impact any external systems, and required resources are available.