I was reading this really interesting article about Tenant0, and how crazy the Power Platform was in Microsoft and what they had to do to make it governable.
Top line numbers were (but I highly recommend you read the whole article):
- 100,000 Users
- 65,000 Canvas apps
- 12,000 Cloud flows
- 5,000 Copilots
Am I the only I the only one shocked there are more Canvas Apps then Cloud Flows, never mind all the Model Driven Apps too
What I found the most interesting though was that even though Microsoft was finding it hard to govern the platform, they still built it that way. Surely they would have planned this, foreseen some of these issues? So here's how I would have built the Power Platform, before Tenant 0 existed, Tenant -1.
Adoption
Microsoft from the get go wanted mass adoption, so we can not approach this from a IT fully governed stand point, it needs flexibility, it needs the Default environment.
But my Default would have been a little different.
First it is not the place for other Microsoft teams to cut corners and dump stuff in. SharePoint team want to use Canvas Apps in List Forms, fine but that has its own environment. Project needs to store some syncing flows, yep own environment. These environments can then be hidden from users through the make. urls and have more controls. As example no Apps in Project environment, no custom/CDM Dataverse tables in the SharePoint environment.
Default Limits
The next thing it needs is a limit, a hard ceiling. We want people to build in there, but within the confinements of this can't be business critical. It has to be small scale, personal/team, not department or organisation. So there would be the following limits.
Cloud Flows
1. Maximum 50 actions per flow and no Child flows
This is to stop flows becoming overly complex, simple problems should have simple solutions. If it requires a complex solution it isn't a simple problem and should be completed in a more managed way.
2. Only 5 Flows per user
This stops users working around the max actions limit. It also ensures one maker can't become a single point of failure for multiple systems.
3. Only 10 runs per day per Flow
This could be a maximum of 2500 API calls per user per day, but then we could stack them on one flow. Why a limit of runs, well again its around scope and impact. A flow that is running hundreds or thousands time a day is impacting something, and if it stopped then its impact would be scaled by all those runs.
4. Can't share (only change owner)
Connections are as close to a password as can be without actually being. Sharing them allows people to access your accounts, and by calling them 'connections' instead of something like 'keys' or 'secrets' we are encouraging users to break security policies. Normal processes make it harder to share, not easier. So I would ban sharing flows, if its important enough to run when the owner is off then it should not be in the Default. You can still hand the Flow over, changing the owner, but that also requires changing the connections to the new owner.
5. Microsoft connectors only
There is lots you can do with just Office 365 and SharePoint connectors, and that should be the limit. As soon as you want to integrate with other systems there are lots of security considerations, all of which should have external review.
Canvas Apps
1. Only share with up to 20 users
Apps by there very nature scale very quickly and very easily. It works, people use it, they tell their colleagues, and bam it goes viral. So now it went from not business critical to critical. 20 users should cover a normal team size, anything bigger impacts to many users.
2. No group sharing
Same as above, groups allow easier adoption, which is not want we want in the Default.
3. No on-behalf of connections
This one is an interesting one, but I don't think users should be sharing permissions to their account without any oversight. You want to send an email from my mailbox, then I want someone independent to have checked the code first. By enforcing the app to use the owners connections we ensure that the owner can't miss use other people connections.
4. 50 Visits per day per app
If multiple people are visiting the app multiple times a day then this flags that if the app was down then the business would be impacted.
5. Microsoft connectors only
See Flows for reason.
6. Limited screens and components
Inline with Flows have action limits to ensure it only solves simple problems we do the same with apps. This time we limit the number of screens to 3 and components per page to 20 (as else we would end up with creative workarounds leading to 1000 component screens).
7. Max 5 apps per user
This stops users working around the max sharing, visits and component limits.
Copilot Studio
1. No Gen AI
Gen AI is something organisations are still trying to grasp, they are introducing things like AI Boards, and AI Intakes. So the thought of anyone spinning up Gen AI with no oversight is just not acceptable (for now at least).
2. Only share with up to 20 users
See Apps for reason.
3. No group sharing
See Apps for reason.
4. No on-behalf of Connections
See Apps for reason.
5. 50 Sessions per bot per day
See Apps for reason.
6. Microsoft connectors only
See Flows for reason.
7. Limited topics and actions
Again see Apps and Flows for why, I would look at something like 5 custom topics and each having max 10 actions.
8. Max 5 bots per user
See Apps for reason.
Power Pages
Just no, its external facing, no, no, no. I love Power Pages, but not in the Default.
Dataverse
Again no thank you. I don't want users storing all sorts of data in there. Never mind the risks of sensitive data being stored there by makers with no idea about security roles (I know how to fix access, share with everyone). There is also so much data governance and regulations you are bound to break something. Even as simple as the right to know what data you hold on me requests would not be compliant.
So I would remove all custom and CDM tables and only allow system tables.
Model Drive Apps
See Dataverse, so that's a no.
This may all seem like too much, it will stop innovation and the citizen developers. But I don't think it will, it will walk the line of allowing users to add business value without business risk. Plus working to limits drives some crazy creativity and innovation 😎
Analytics
When you are working with 'access by default' software you need good metrics. There is no way to limit/validate access, so there is no way to ensure users do the right thing. So from day one we need good analytics, admins need to see what people are making and running. They need to see what data is flowing through the platform and what systems it is connected too.
And what about value, the Power Platform is not free (got to love those licenses), so we really need an easy way to show value. I want to be able to track flow runs easily and app sessions. I also want to be able to either set value metrics (per session = £5 saving) or even better for the platform to estimate based on connections, the users role in the organisation, and how long they are in the app.
Additionally I would want built in alerts, I want to be able to look for unusual patterns across the entire platform. A production apps usage changes suddenly (down to 0 = outage, x2 calls = potential hacking attack).
I would also say this data should be integrated with existing Microsoft admin portals like M365 or Pureview. Having its own admin/analytics is great and needed, but that's more for when it scales, when it first starts you want the data showing up in existing work streams.
Separate Platform From Itself
Although I personally have loved the fact the platform is built on the platform, as it allows me to automate it, its not a good practice. If the platform has an issue then the analytics etc might not be able to show it (imagine the system down alert is completed by the system that is down).
Things like security roles for accessing environments etc should not be in the same place as security roles to access a Dataverse Table. Allowing Flows to be manipulated because they are stored in a Dataverse table that is designed to be easily edited is only going to end one way.
If you really want to use the platform to manage the platform, it needs to be fully segregated. Stored in its own environment, which has tight controls on what can be done in the environment.
Built for ALM
The platform needs to be built with ALM in mind, yes we want the Default but what happens when our users out grow it (and we really want them to out grow it).
So that means a few things:
First we need proper developer environments. This means that the environment is not only limited as to what the user can do on the platform, but also the connections that can be created in the environment. I want to be able to enforce access only to a non-production tenant, no access to my emails, no access to real SharePoint sites. This is the only way to really stop pseudo prod and protect the developers from accidentally impacting production systems.
Next proper versions, I don't want to be able to edit my solutions version number, it should by the very minimum blocked from going lower, ideally blocked to just system changes. These versions should also be fully version control with rollback capability.
Simple, built in automated deployments. Manually exporting and importing solutions is not scalable and should be a back out plan not by design.
And finally ownership, once we get into ALM we need to separate the maker from the solution. The amount of unnecessary Service Accounts is crazy (think of those license costs), add the complexity of swapping them during deployment and managing them through a 'Separation of Duty' process is even more ridiculous. I would have gone by a 'owned' by the environment approach. That way any developer can pick up any solution in Dev (its a non-prod connection tenant remember so no risk), and in Test & Prod we have Service Accounts/SPN's in a platform key vault. Connections are then assigned to flows and monitored centrally.
And that's how I would have done it. A foundation of accessibility to enable adoption, but limits to reduce risk. A enterprise focus on ALM and analytics to ensure that the platform can grow in a scalable and stable way.
Hindsight is a wonderful thing, add in the technical challenges and the speed to market approach of leveraging Dynamics then my approach is even less practical, but hey, I still think it would have been cool.
Top comments (0)