(this article originally appeared in TechRepublic and was written by Simon Bisson)

Microsoft’s Inspire 2020 announcement of its low-code Dataflex application platform for Teams was thrown into some disarray when it turned out that someone else had the rights to the name and wasn’t going to give it up. A new name is due soon, but for now the data-driven service has reverted to its internal codename, Project Oakdale.

Building on the Power Platform’s Common Data Service, Project Oakdale is perhaps best compared to tools like Claris Filemaker or Microsoft’s own Access, or even the table-driven data layer in Salesforce: a tool for giving basic access to forms-based content from your line-of-business applications. That’s why it builds on Microsoft’s Common Data Model and Common Data Service, a set of standard business objects and entities that underlie not only Project Oakdale, Power Apps, and Power Automate, but also the CRM and ERP tools in Dynamics 365.

Filling out the details

Since the original announcement, Microsoft has gone into more detail on what Project Oakdale can do and how it fits into Teams. The first piece of good news is that it will be bundled as part of a Teams subscription, so there’s no additional subscription needed. However, that does entail some limits on what you can store and how.

Project Oakdale databases are available on a per-team basis, with one data environment for each team instance you have. As a single Office 365 tenant can support up to 500,000 teams, each team you have in your Teams environment can have its own Project Oakdale instance. That sounds good, but in practice it could be quite easy for a large project to quickly fill its available resources, as you have only 2GB storage available, with up to one million rows.

If your apps are going to be larger than Project Oakdale’s limits, you need to move to a full Common Data Service subscription. Here you get up to 4TB of storage, and an unlimited number of data environments, with additional connectors to line-of-business systems. You can use it to take apps out of Teams and build them into Power Apps, with more complex interactions and their own mobile and web user experiences.

You’ll have to go beyond Project Oakdale if you need to share a data environment beyond the confines of a team. A data application build for the marketing team might be useful in sales, but unless the sales team are members of marketing, they won’t have access. There will be, at least in the future, a way of copying applications and data between teams, and sharing applications without data, but for now it’s something you need to think about if you have any expectation of tools crossing the artificial boundaries between teams.

Using data in Teams

While Microsoft refers to Project Oakdale as a relational data platform, in practice you’re unlikely to be building complex queries. Instead, you approach it much as you would approach something like Access, designing your tables and views early and building applications around them. More complex query structures, like joins, can be used if necessary, but in the context of a low-code, task-specific application built into a team they shouldn’t be needed. If you get your application design right early on, you’re leaving your colleagues code that can be quickly modified and updated by adding new fields and entities to your database and quickly editing any views and queries you’re using.

Initially Project Oakdale will support basic data types, with additional support for files and for images. This way you can build quick applications that support catalogue-style applications, searching for and displaying formatted data based on the contents of a database. That might be a documentation store for a project-focused team, or a list of customer details for a sales team, or a way of sharing class data and files for an educational team. With only one Project Oakdale environment per team, you’ll need to scope what you’re storing carefully, although you do get a lot more freedom in how you display that data.

From Project Oakdale to the Common Data Model

As with Access, you can search for data, and apply filters and sorts. Much of the underlying data types and operations are based on the Common Data Service, but initially you don’t get access to the complete set of business entities that make up the Common Data Model (although the User table comes from it, as does the currency data type). That could be a problem if you’re hoping to use Project Oakdale as a way of giving teams access to data from your line-of-business systems, or are planning on making it part of application workflows.

Microsoft has said that the Common Data Model will be supported more fully in future releases of Project Oakdale. That does leave a question of how to support it in Teams today. One possible option is if you’re treating it (and the Common Data Service) as key elements of your application infrastructure, in which case you may be better off licensing the Common Data Model directly and embedding either Power Apps user interfaces or Power Automate flows in your Teams instances.

Building and sharing applications without leaving Teams

What’s most important about Project Oakdale is that it brings Teams application development into Teams. You don’t need to spend time thinking about manifests and using scaffolding tools to create a structure for HTML and JavaScript to run inside Teams. Instead, all you need to do is install Project Oakdale from the Teams application catalogue, open it up and start working in your own team’s data environment using a familiar Access-like table builder and form creator. Microsoft has said there will be ways of connecting this to other Power Platform and external applications using standard connectors – using Power Automate for workflows and Power BI for visualisations, for example.

The more we get to see of Project Oakdale, the more interesting it seems. Extending the Power Platform into Teams makes Teams a low-code development environment that lets anyone work with the data they need for their job, without leaving the Teams work environment. If you think about Project Oakdale in conjunction with other new data management tools, like Lists, we’re finally seeing some of the convergence between SharePoint and Dynamics that was promised more than a decade ago.

While there’s a lot to like in what we’re seeing in Project Oakdale, you do need to be aware of its limitations. Teams users will get access to it as part of their subscription and will want to start using it very quickly. If you’re administering Microsoft 365 you may well find yourself quickly having to open up access to more of the Power Platform and the Common Data Service, as users start to want to build and share more complex applications. Just be sure that you’re ready to justify an increased budget to your CIO!