Power Platform | another Project Oakdale Review

After Ignite announcement many #PowerAddicts started their Project Oakdale journey and familiarized themselves with the new capabilities – both from Maker perspective, as well as from Governance perspective. Did you recognize the controls offered being in Microsoft Teams style? In fact you can even switch on to use the classic controls as well, if you don’t like to use the Teams shaped controls. Well today is not about the Power Apps Studio experience.

In my previous article, I already tried to outline some significant topics to help with when to consider running apps on Project Oakdale or Common Data Service. Microsoft also came up with this helpful comparison. In todays article, I´d like to drill a little deeper with the help of these two documentation:

• https://docs.microsoft.com/en-us/microsoftteams/limits-specifications-teams
• https://docs.microsoft.com/en-us/power-platform/admin/about-teams-environment

I was pulled into a conversation the other day around Enterprise Application rollout and the question, if those apps should be based on Project Oakdale or what the customer described as a ‚high-priced‘ low-code development platform. Setting aside the pricing and licensing discussion for a moment, the first visual I came up with to explain the constraints and possible step-ups is shown here.

On top you can find the overall given limits for Project Oakdale in terms of max environments and max overall storage in a tenant. If any of these seems problematic first hand, a possible way of step up is considering the classic Common Data Service being used to host app security and/or data.

At bottom level on the right side you recognize each Microsoft Teams Team provisioned Project Oakdale sizing limits. And again, this environment database can be provisioned to a classic Common Data Service at any time while other environments will remain as-is. Furthermore on the left you do find the security ‚auto-pilot‘ settings that come with any Project Oakdale inside Teams summarized for the main user roles. For further details, please follow the documentation links shared above.

If any more granularity is needed for an app in terms of security, it’s probably a good idea to consider Common Data Service capabilities out of the box.

Additionally, to center area you do find the step up to classic Common Data Service, if any of your apps would require more complex fields or you wish API access to database services, such as offered with CDS.

As Charles Lammana outlined in this video shared on Twitter, there’s a true step-up option for those who don’t know yet about an app becoming more complex, shared more broadly or being in the need of more capabilities. Yes, all this comes to an additional pricing, if you now want to take this into account. As you can mix and match you can best decide when to go with Project Oakdale or Common Data Service. Or as a rule of thumb you can now think of three easy step-up rules:

1. More complex field types or specific API access needs
2. Storage requirements for file and data
3. Granular Security model requirements

Hope, same as this visual helped driving the discussion in above mentioned conversation, it will help shape your decision matrix. Until then…