Dataverse for Teams: limitations and opportunities

UPDATE 2020-11-17: Microsoft’s initial product name “Dataflex” has been replaced with “Dataverse” in the General Availability announcement. Otherwise everything announced originally in July 2020 remains the same.

After announcing the rebranding of Common Data Service (CDS) as Dataverse and the arrival of a “free” Dataverse for Teams version, Microsoft has now revealed more details about the data platform capabilities that will be bundled with MS Teams licenses.

Obviously there will be plenty of functionality that current Power Apps and Dynamics 365 customized apps have been leveraging from the full CDS platform which will still require a premium license in the future as well. Microsoft will position this as an upgrade path that customers can follow once their apps need to go beyond the limits of the non-premium environments. Many MS partners who’ve delivered traditional business applications for customers may dismiss the Teams based Dataverse offering as insufficient for building any “serious” apps and therefore default to the full Dataverse as the minimum requirement for their services.

On the other hand, there are lots of opportunities presented by this new entry level Dataverse service to simplify things for the citizen developers. When viewed from this perspective, Dataverse for Teams can actually be a better fit for the app makers who want to quickly achieve business results for themselves and their team members. It’s a fine line that both Microsoft and the customers wanting to build low-code business apps will need to walk on, to get the balance right. In this article we’ll look at some of the key dimensions where the two licensing levels of Dataverse differ from one another and examine how the coming Teams edition might reduce unnecesary complexity. The example screenshots included represent the as-is world from the premium Dataverse service, as we wait for the to-be UI of Dataverse for Teams to arrive in the near future.

Data model

A key benefit of using Dataverse over a more simplified data source like SharePoint Lists is the relational data model that can be leveraged in the apps. Views and filters that contain references across multiple database tables can be built on the Dataverse app maker UI. Delegation issues previously encountered when working with larger data sets from list based sources should be mostly gone.

Dafaverse for Teams will offer essentially an empty database, unlike what comes with the full Dataverse environment out of the box. With no support for complex datatypes, activities and many other built-in features originating from the platform’s CRM roots, the starting point will be clean slate – rather than the tens of tables that come with even a “naked CDS” today. App makers won’t have to worry about whether they should use some standard MS feature or build their own. This resembles what the design of tables has been in the Excel workbook world for them as well.

The downside is that app makers may end up rebuilding common entities like Contacts in each environment with their own variations, though. It will be interesting to see what the “coming soon” option for leveraging Common Data Model (CDM) in Dataverse for Teams will bring on this front.

Business logic

Dataverse for Teams will offer the feature set of Power Automate within the context of the app, as well as connecting to the surrounding Microsoft 365 services. What you will not get is the Business Rules or classic XRM Workflow capabilties that have been natively built into Dynamics 365. There is also no SDK or API support without upgrading to Dataverse premium.

One could argue that there is a higher barrier to implementing complex business logic when trying to use formulas in Power Apps or construcing multi-step Flows with expressions to achieve functionality that classic Workflows or Business Rules offered via a more targeted GUI for that single business app’s context. With no ability to injecting custom code into the app or integrating it beyond M365 services, more advanced logic may often be impossible to implement in Power Apps running on Dataverse for Teams.

By making the free version of Dataverse purely a no-code experience, Microsoft is able to offer a more well defined sandbox for the new app makers coming from the business side to operate in. The problem with the low-code side of traditional XRM has sometimes been that “everything is possible”, so where does one draw the line between what business requirements should & should not be attempted to be achieved in these apps? Now there will be a clear justification for the app maker to present the choice: do you want to keep things simple or do we go premium?

User interface

Initially the Dataverse for Teams experience will support Power Apps Canvas apps, but the Model-driven apps will arrive later in 2020. Even with the above mentioned limitations on business logic, this is a huge step for bringing true no-code app building experiences to the masses, since automatically generating the UI from the data model defined in Dataverse is still the quickest path to building powerful admin interfaces for the relational business data.

How about the app discovery experience then? With the non-premium Dataverse apps allowing the launching of apps exclusively from within Microsoft Teams clients, this may initially sound like a big UX limitation. However, from a non-maker perspective the path to different Power Apps on the desktop screen hasn’t exactly been optimal either. MS is in the process of deprecating the current home.dynamics.com apps list and migrating them onto a new office.com based apps home page. With such a big push going on for making Teams the central hub for all information work, it might as well become the new default path for users to launch business apps in the context of a particular process, unit or team.

Looking for building an app that doesn’t logically fall under a single Team inside your organization? Then you’re probably aiming at a business application feature set that Dataverse and Power Apps premium licenses are meant to cater for.

Security model

Thanks to its tight integration with the team in which the environment is hosted, Dataverse for Teams can derive app access rights from the team membership. There will only be thee pre-configured security roles that the app admin can assign to users: Owners, Members and Guests (the “OMG model”).

Dataverse Pro has been built to support organization-wide systems of record like CRM, therefore it contains a wealth of access level configuration options like Business Unit hierarchy and Field Level Security. As a result of this, planning which of the hundreds (if not thousands) privileges would be need to be given to the user security roles in order for the app to function properly can feel overwhelming. By abstracting away this layer from Dataverse for Teams, process of granting users access to simple apps will be much more streamlined, due to far less options available in the security model design.

With no need for supporting the advanced features that have not yet been implemented in the modern admin centers for Power Platform and Power Apps, Microsoft can also offer app makers an experience in Dataverse for Teams that will never required them to “switch to classic” and navigate the depths of features targeted at more complex enterprise applications.

Capacity

Each Dataverse environment created within Teams will be provided a 2 GB storage capacity, which MS indicates to being roughly the equivalent of 1 million rows of data in the tables. How the storage of other datatypes like files and images will be handed within this quota remains to be seen. Additional capacity cannot be bought without upgrading the environment to full Dataverse level first.

Dataverse premium capacity is managed on the tenant level. Every environment and every app is eating away resources from the common pool and there are currently no controls available for allocating quota to specific organizational units, for example. This means the IT deparment must be engaged with the environment creation process and application storage usage analysis, to ensure there are no runaway apps created by citizen developers that could inadvertently block the usage and release process of business critical systems running on Power Platform.

While there is a cap on the environment size in Dataverse for Teams, the fact that these environments can be created by app makers in specific teams without worrying about organization wide database storage quota removes much of the hassle involved in quickly building apps when the need arises. Since all makers within the team will share the same environment, though, you won’t necessarily be able to fit all the digital tools needed by a larger organizational unit into just one environment. Obviously no dev-test-production pipeline is achievable within Dataverse for Teams environments alone.

Conclusions

Looking at the feature comparison between Dataverse for Teams and Dataverse, we can see there’s a wealth of useful tools offered by the new licenses type bundled with Microsoft Teams. These will certainly help creating more robust apps on top of Power Platfotm without immediately needing to acquire premium licenses. Many of the restrictions are perfectly acceptable from the point of view of citizen developers that want to create apps for their team members without IT involvement or professional software development projects.

Balancing between how far one should attempt to go with just the Teams based no-code app development strategy vs. when it makes sense to invest in the full version of Microsoft’s low-code application development platform will surely be a hot topic for most Office 365 / Microsoft 365 customer organizations in the coming months. As the preview and GA versions of Dataverse for Teams are launched, we’ll be sure to cover them in our social feeds on a more detailed level, so keep an eye on our community content!

Read our highlights from the General Availability announcement on November 16th from this blog post: Welcome to Microsoft Dataverse for Teams.