Jukka Niiranen

Tag: Dataflex

  • How naming works in the Power Platform universe

    How naming works in the Power Platform universe

    After the peculiar episode in July-August timeframe when Microsoft first tried to rebrand the Common Data Service and had to later cancel their plans, we’ve been eagerly awaiting to hear what they are actually going to call CDS from now on. Yesterday the Teams based features known as Project Oakdale finally went GA and now we know the answer. I won’t focus here on the actual features, but you can read my thoughts on them from the Forward Forever team’s blog:

    Hello Microsoft Dataverse

    The mapping of the old & new names is quite straightforward:

    • CDS = Dataverse
    • Project Oakdale a.k.a. “CDS Lite” = Dataverse for Teams

    Not all that different from their initial plans of using the name “Dataflex”, which didn’t go through since the owner of that trademark considered it to be an infringement and sued MS. Is the name “Dataverse” unique then? Not entirely, as there appears to be at least the Harvard Dataverse out there. Luckily it’s not as directly related to low-code application development platforms as the DataFlex that caused grief the last time.

    Just because there are other existing products out there in the IT space that use a particular word, this doesn’t mean new products would never appear in the market with the same name. As an example, last month a service called Microsoft Clarity was made Generally Available. Is “Clarity” a brand name that isn’t used by any other IT product? Of course it isn’t. The first thing that comes to my mind is Clarity PPM project & portfolio management software, but search engines will reveal many others. Heck even MS has acquired a BI software company called ProClarity back in 2006.

    That’s just how it goes in the real world. Coming up with a name that hasn’t ever been used before yet also means something is not an easy task. If instead of a Globally Unique ID you’re aiming for a product name that actually contains some hints about what the product does, then your choices will always be limited.

    Ah, the Choice / Choices in life…

    Which brings us to:

    Terminology updates inside the Dataverse

    Not only does the name of the technolgy itself change from CDS to Dataverse, there have been a number of terminology updates to the foundational concepts of the data platform:

    • Entity > Table
    • Field / Attribute > Column
    • Record > Row
    • Option set / Picklist > Choice
    • Multi select option set > Choices
    • Two options > Yes/No

    For a quick explanation about the scope of changes, see this short video by David Yack:

    I bet this is a bigger change for many of the professionals in Power Platform and Dynamics 365 area than the new Dataverse brand. We’ve been talking about entities ever since the birth of MS CRM and now all of a sudden the idea of “entities are much, MUCH more than a mere database table” should be replaced with “fine, they are tables”.

    Why are these changes necessary then? Largely for the same reasons why a more approachable name was needed for CDS: the target group for this technology is no longer the same – it is considerably broader. Microsoft doesn’t want the platform to be an exclusive club for those who thoroughly understand the business process management and data modeling techniques offered by their products, sometimes only after having gone through training courses and technical certifications. No, this needs to be something a power user that’s equipped with nothing more than a Microsoft Teams license can quickly figure out on their own.

    The path towards Teams as a platform brings more changes than just new names for familiar things. Previously the data model construction was a back-end task handled largely separately from configuring the app’s front-end. With Dataverse for Teams and later presumably in other UI’s, too, the interactive table editor supports both data model design and data entry all in one – much like a pre-built app á la Microsoft Lists does today. It doesn’t remove all the other functionality of entities in the underlying relationship management system, but it makes these optional at the start. You could just build a table like in Excel or Access, then later take it further as the app requirements become better defined.

    For those who have mastered the earlier XRM universe, the simplification of the terminology that was very specific and accurate to what the platform does may feel like a slap in the face. How can Microsoft tell us that we should pretend that it’s just a database table when we know the reality as well as the history? There isn’t much of an upside for these technical professionals in the new naming – at least if they don’t need to interact much with business users unfamiliar with the core concepts of CDS.

    We’ll get over it, though. Developers and even many no-code customizers will probably hold on to the entity/field terminology for quite a while – especially when on the API level everything the terms are not expected to change (at least for now). Having this dual reality of tables and entities isn’t going to present a huge cognitive challenge for those who’ve been with the platform for a longer time. The old content from pre-Dataverse era may cause confusion for the newbies, but we’ve already been through the merger of Power Apps & XRM a short while ago, which had a much more profound impact on the names of concepts in the platform. This too shall pass.

    While it may not be of much consolation, there’s one thing that we know won’t change: this changing of product and feature names isn’t ever going to stop.

    Why is this naming thing so hard in BizApps?

    I’m not going to write a four-part series on the product naming complexity just yet (like I did on the complexity of Power Platform licensing). Let’s try and keep it within this blog post for now. So, here are four reasons that make naming especially tricky in the context of Microsoft Business Applications are:

    1. Ambiguity
    2. Hierarchy of concepts
    3. Shifting product boundaries
    4. Marketing goals vs. market needs

    1. Ambiguity

    In a universe as broad as Power Platform, there can easily be overlap in naming elements of that platform that serve different purposes but really should have a fairly generic name. As an example, “a Power Apps portal” and “the Power Apps portal” are 2 different things. Excuse me, what?!? Yes, it’s all in the documentation. Power Apps portals are one of types of apps you can build, whereas the Power Apps portal is the place to create new tables and columns. People tend to refer to the latter one as the Maker Portal thanks to its URL, but it’s good to keep in mind that URLs in Power Platform do also change occasionally.

    Layout components

    This is why we now have Model-driven app forms which use the word “column” for both describing a field on a form as well as the number of adjacent containers within a tab or section. The original intentions for using easy and generic terms can sometimes create confusing results. If not in their native English language then most probably somewhere down the line when the terms get localized to a multitude of different languages.

    2. Hierarchy of concepts

    You won’t always have a clear view of what individual products and technologies will eventually be needed when pursuing a particular vision. Thinking about what CDS was called initially, it wasn’t a separate “thing”. It was embedded within the Common Data Model concept introduced in 2016. It took a year for this vision to evolve to a level where the actual data platform functionality operated by Microsoft was named Common Data Service and the earlier CDM term was dedicated to the idea of a shared schema across business apps from different vendors. It’s easy to see these should be 2 different things, but finding the right way to put them out there took a few iterations.

    Another example where things are a bit further already when a the need for redefining the terminology arises is Customer Insights. Microsoft has been shouting a lot about the booming demand for their Customer Data Platform solution (CDP, a generic term like CRM). Recently they’ve had to reshuffle the Insights deck of cards to ensure the gameplay works smoothly, so a hierarchy like this has been introduced:

    • Customer Insights: the top level concept of Microsoft’s CDP
      • Audience Insights: the features that were initially called Customer Insights, now referred to merely as a “capability” of CI.
      • Engagement Insights: announced originally as an independent product called Product Insights, now in preview as another capability of CI

    3. Shifting product boundaries

    Microsoft today excels in understanding the importance of their technology stack. You could also call it the platform approach in this context, but the point remains the same. Their products rarely get developed in isolation these days, rather there is (at least seemingly) a big push for combining elements of existing services to create new products. The problem is, though, that this game of connecting the dots isn’t ever really over.

    Survey feedback management was first brought into the Business Applications portfolio via acquiring an ISV product called Mojo Surveys that had been built on the XRM platform. After some rearchitecting and rebranding it was launched as Microsoft Voice of the Customer (VoC). The capabilities for the survey form design were quite lacking compared to the simplified UX in Microsoft Forms that had been developed internally on the Office 365 side of the house. Instead of retrofitting the form designer into VoC, MS decided to take CDS as the process and data management engine to give birth to a more structured feedback management tool, called Forms Pro. VoC was then deprecated and customers were asked to migrate to Forms Pro instead.

    In this process the technical capability of feedback management had hopped over the fence from the Dynamics side to the Office side. This was somewhat problematic from a business perspective, as well as causing confusion between the non-Pro and Pro usage of Forms. So, Microsoft ended up doing a further reimagining of EFM and rebranded Forms Pro to Dynamics 365 Customer Voice, bringing it back to the BizApps side where it started from.

    Returning to the previous example, before we had Dynamics 365 Customer Insights, the product names Microsoft used for referring to the same concept included “Cortana Intelligence Customer Insights” and “Azure Customer Insights”. The earlier Azure products that were offered in preview had to be scrapped and rebuilt as a Dynamics 365 product to finally see the GA milestone. Today it makes far more sense to have these type of packaged AI capabilities in the BizApps portfolio than in the Azure service catalog, but it wasn’t always obvious – especially back when Dynamics was just about CRM and ERP.

    4. Marketing goals vs. market needs

    Product marketing at Microsoft is in an endless pursuit of finding the best story that can sell customers a shiny new vision of what results they could achieve – if they choose the right technology from MS. Making a single purchase isn’t enough. You have to get the customers hooked on buying more from you, which leads to the invention of new things to sell. It’s easy to understand the incentives that lead to such actions, but they can sometimes end up irritating the customer who’s already made a purchase based on their own understanding of their needs.

    When Microsoft decided in 2016 that it would no longer sell a product called CRM, you could argue that their vision for tearing down the traditional CRM and ERP silos was logically a goal worth pursuing. The side effect from this product marketing goal was that when Microsoft took away the name “CRM”, they didn’t give anything new to replace it with. Reluctantly the Customer Engagement name was introduced a bit later, only to be quietly discontinued.

    The CRM systems that customers had deployed didn’t disappear anywhere of course. Companies offering professional services around them first struggled in migrating from Dynamics CRM consulting to Dynamics 365 CE consulting, and now they’re even more confused about what to call themselves.

    Microsoft’s branding changes aren’t ever exactly applauded in the partner or customer space, since renaming CDS to Dataflex to Dataverse will always cause extra work for them and give little in return. Removing an entire category like CRM has a far bigger impact than changing A to B. Redefining concepts and their boundaries is of course a very powerful way to stir things up and generate motion in the markets. I can’t say that I personally have any regrets on moving on from CRM, yet it’s easy to understand why not everyone is cheering when someone comes and says “what you’re doing is no longer a thing – time to reimagine everything!”

  • There never was a “Microsoft Dataflex”

    There never was a “Microsoft Dataflex”

    There are a lot of benefits in taking long enough holidays during the summer, like many people here in the Nordics do. Going offline for a while is a great way to reset your brain and force-close all those open browser tabs of the mind, to free up memory capacity for properly engaging in brand new tasks.

    If you were lucky enough to set your vacation time between July 21st and August 11th, you managed to dodge an unfortunate episode in software product launches from Redmond. Here are the key dates:

    • July 21st (first day of MS Inspire conference): a new brand name “Dataflex” is announced, with Common Data Service renamed as “Dataflex Pro” and a new subscription tier “Dataflex” promised for all Microsoft Teams customers. (My blog post about it is still here.)
    • July 29th: the name “Dataflex for Teams” is used for the first time to reference the previous “Dataflex” tier that’s bunlded with Teams, in an effort to make this product connection more clear.
    • August 11th: all references to “Dataflex” in all Microsoft websites are taken down. The announcement blog posts are brought back online with the terms “Dataflex” and “Dataflex for Teams” replaced with “Project Oakdale”, and “Dataflex Pro” now reverted back to “Common Data Service”.

    What happened? The answer is: litigation from the owner of the trademark “Dataflex”.

    There already was an established software product with the name “Dataflex” out there – in fact it had been around for 4 decades already. Immediately upon the launch day of July 21st several community members were quick to point this out, as indeed it was in practice impossible to miss this brand name overlap when using a search engine. Why Microsoft decided to proceed with their plans on renaming CDS into something like this is something we’ll never know for sure. Some had initially speculated that perhaps there was a preliminary agreement in place with Data Access Worldwide to transfer the ownership of the trademark, but based on the immediate legal action that the company understandably took to defend their rights, nothing like this was likely ever discussed. Our conclusion must therefore be that Microsoft knowingly and intentionally attempted to change the name of its existing technology (Common Data Service) into something that was already in use within the same domain by another software company (Dataflex) without considering the consequences.

    The end results is almost like a story taken from The Onion. Even if we are living in 2020 right now and the world appears to go mad every few days, it’s still an utterly bizarre episode in software business. I can’t recall seeing anything killed this fast after it’s announcement, which in the case of Microsoft Dataflex was only 21 days. Neither can I think of an example where something with such a clear potential for software product naming conflict would have been attempted. It is indeed similar to as if MS would have launched “PlayStation 6”.

    It’s of course not unusual for Microsoft to pull a product name between its announcement and the planned GA. Remember Dynamics 365 Business Edition, for example? Just because we see something presented on slide decks aimed at MS Partners as guidance for building their business around it, that doesn’t guarantee it will ever see the light of day. Shift happens, plans change and a lot of the partners have already become accustomed to this risk as simply the cost of doing business in this ecosystem. This time the product itself is not pulled, though. The need for coming up with a new brand will most likely delay the commercial roll-out of CDS features for Microsoft Teams based apps, but it’s important to keep in mind that this is all still happening. CDS will most likely become a mainstream data platform to replace use cases where SharePoint Lists have previously been used.

    SkyDrive is another example of a Microsoft product brand that suffered from the conflict with an existing trademark and had to be renamed OneDrive as a result. BSkyB as a media broadcaster and digital services provider wasn’t entirely in the same business as Microsoft with it’s personal cloud storage that was following in the footsteps of Dropbox, yet the end result of that case showed that at least between large enterprises such near misses with strong brands can become costly. Even features of a product like the “Metro UI” with Windows 8’s modern user experience had to be avoided due to objections from German reltailer Metro AG. Both of these are examples where it wasn’t obvious to an outsider if a trademark was actually violated, though. With Dataflex the evidence was in plain sight for everyone.

    Lucky for us, MS had not yet made any public preview or a commercial subscription of the new Dataflex branded services available by the time they had to call the whole thing off. It was only the early adopters in the partner field and the passionate community members a.k.a. #PowerAddicts that lost some of their work hours due to the branding incident. Yeah, I had to go back and edit a number of web pages, rewrite presentation decks, revert our service documents etc. to recover from the erraneous information that had been published on July 21st. The majority of people out there in the MS ecosystem probably didn’t yet even get a chance to understand what Dataflex meant or how it was different from CDS, so they will have dodged the bullet when it comes to loss in productivity.

    There is, however, a much greater loss here than the “Find and Replace” activities needed for changing product names. It is the loss of credibility that Microsoft’s Business Applications specifically suffered from this very unfortunate product naming incident. The worst thing is that there has not been any explanation presented to the genereal audience on what’s going on, rather we’ve just seen the word “Dataflex” disappear and get replaced with “Project Oakdale” or CDS. Microsoft at this point is facing legal action from the owner of the Dataflex trademark, which we all know from the many Hollywood movies we’ve watched that “anything they say can and will be used againts them in a court of law”. It is at moments like these where it would be crucial for companies to have a voice, to be able to reach out to their most important audience (customers) and explain what happened & what are they going to do about it.

    I can tell you that it would honestly be a full time job keeping up with A) product naming and B) product licensing of Microsoft Business Applications. It’s not full time for me (luckily), but since I also do it as a hobby / community activity, I can say I’m pretty well educated on what the “right” answers in this area would be at any given time. For anyone who actually IS covering the actions of Microsoft full time in a professional manner, Business Applications is an area they usually openly admit to struggle in.

    At the end of the day, what matters to each and every one of us the most in this MS ecosystem is how the end customers react to what they see & hear. While the marketing machine at Redmond surely is capable of capturing the attention of IT professionals worldwide with their news and campaigns, what it does not seem to be very good at is explaining “what does this really mean to you”. As the cloud platforms grow and become an ever larger pool of individual apps that form a spider web of integrations underneath the user interface, the need for someone to cut through the marketing speak and explain the customers what’s really happening here seems to be growing exponentially. What we all could do with the Power Platform is simply magical, yet the understanding of A) through which products, B) based on what technology, with C) what levels of effort and D) for what license cost – this level of understanding is lacking pretty much anywhere I look. I’m not talking about the “how to” instructions of building apps but rather the higher level discussion of where business decisions get made. It is here where the damage from confusing messaging is, in my opinion, holding this ecosystem back.

    To close things off for now, as we wait for the new product names that Microsoft has said they will be giving to the technology briefly known as Dataflex, let’s recap where we are right now. “Project Oakdale” is the codename that is for the time being used to refer to the “Lite” version of CDS that will be made available to all Microsoft Teams customers at no charge. Common Data Service is what we will continue to use as the term (for now) when talking about the full capabilities of data management, entities, solutions, Model-driven apps and many other advanced features in Power Platform. This post on the Power Apps blog (originally from July 29th) is still valid in every other aspect, apart from that one “D” term that got removed on August 11th.

    It’ll all work out in the end, I’m sure. This time next year there will probably be a whole number of other product names that we’ll be using when discussing the latest turn of events in the crazy & exciting world of Microsoft Business Applications. Dataflex and Oakdale will live on as one of those trick questions in the pub quizzes run by the community. No one died as a result of this episode.

    In a way, us #PowerAddicts simply got a taste of what the BizApps whirwind must at times feel like for the end customer who isn’t involved with this technology of ours, all day, every day.

  • Dataflex is more (and less) than CDS

    Dataflex is more (and less) than CDS

    It’s that time of the year again when big announcements have been lined up for Microsoft Inspire, the (virtual) conference for the MSFT partner ecosystem. Last year the Inspire announcements gave us a wealth of changes for the way how the Power Apps, Power Automate and Dynamics 365 licensing model worked, but all the product names remained the same (as far as I recall, at least). This year from Inspire 2020 the Business Applications part of Microsoft’s cloud is getting a bit of both. Say hello to Microsoft Dataflex!

    I have written an introductory post over on Forward Forever blog, “What is Microsoft Dataflex and who is it aimed at”, which you can check out to understand the impact from a customer organization perspective. Here on my personal blog I’m exploring the topic when viewed through the eyes of a long-time XRM professional.

    Abort mission!

    Microsoft will NOT use the name “Dataflex” to refer to the services described here, due to a blunder they’ve made with trademarks. Read this post for more details: There never was a Microsoft Dataflex.

    Dataflex Pro is the new CDS

    Let’s face it: “Common Data Service” wasn’t exactly the finest product name invented at Redmond. Originally it was introduced as Common Data Model, then later this name was switched to reference only the open source schema of CDM whereas the application platform and data management features became a service called CDS. In March 2018 the v1.0 of CDS was effectively put to rest as the far more established platform behind the Dynamics CRM / Dynamics 365 Customer Engagement apps, known as XRM, was rebranded to be “the new” Common Data Service (without the “new” or “v2.0” labels, of course, because why make things precise complicated). Actually it was called “Common Data Service for Apps” (CDS-T), since there was originally supposed to be a “Common Data Service for Analytics” (CDS-A) alongside the transactional platform. There never was, as CDS-A was rebranded as “Power BI dataflows” before GA, so we only had one Common Data Service left to talk about. Whew!

    After these adventures in the great platform shuffle of 2018, we did have some product name related announcement in 2019 as well, like the deprecation of Customer Engagement in the cloud, rebranding Microsoft Flow into Power Automate (where you still create Flows), and finally the “space program” for making PowerApps be spelled as Power Apps instead. In 2020, it had been eerily quiet in the product brand front, so I guess everyone was already expecting to see something once FY21 kicked off. As of today, July 21st, CDS is no more and the Dataflex chapter has begun.

    “Microsoft Dataflex” is not perhaps the most exciting name ever, but it’s certainly a better choice than Common Data Service. In part 4 of my series on Power Platform licensing complexity, I wrote that CDS should have rather been called “Power Platform”, due to its central role as the glue that ties the various MS low-code tools into a coherent platform. It’s a very unCommon service and it does a lot more than just host application data. Now, Dataflex on the other hand plays with the words “flexible” and “-plex”. The latter, when used as a noun combining form is described in Wiktionary as having the following origin:

    From the Latin past tense of plectere (“to weave, braid, twine, entwine”).

    Yes! That’s exactly what this technology does! It’s a platform that allows you to weave a set of processes, interfaces and data together, into an intertwined whole that is greater than the sum of its parts. It offers every developer flexible, no-code/low-code tools for achieving this. That’s how at least I intend to explain the meaning of Dataflex from now on, unless MS product marketing comes up with something even more compelling.

    Oh, there is of course one tiny detail to keep in mind: it’s actually Dataflex PRO. What Microsoft announced today at Inspire is a new service called Dataflex that is a subset of what CDS always used to offer. So, everyone who’s using CDS today is already on the Dataflex Pro version, whereas we’re about to get a preview of the non-Pro Dataflex in the coming weeks.

    Application platform for the masses: Dataflex (with Teams)

    If you’re coming from a Dynamics 365 background, the introduction of a “lite” version alongside the CDS/XRM platform capabilities might not sound so exciting at first. After all, from a pure functionality prespective Microsoft is taking away capabilities from the existing platform, to establish the baseline offering of Dataflex that customers can then upgrade to Dataflex Pro when needed. Some might dismiss it as just another licensing hurdle to worry about when trying to develop apps.

    From a commercial perspective, Dataflex is possibly the biggest thing that has ever happened to the platform formerly know as CDS/XRM. Biggest in terms of the number of potential app makers that will now have the possibility to build Power Apps on top of a true relational database instead of the dreaded SharePoint Lists. This is obviously the major immediate benefit from the announcement of Dataflex non-Pro, since in the previous licensing model the lines were drawn in a way that discouraged the use of CDS (or Azure SQL) databases for any Power Apps designed for light use scenarios – unless you had already acquired the full Power Platform license for your entire organization. With Dataflex usage rights bundled into Microsoft Teams at no extra cost, any user (internal or guest) with the necessary Office 365 / Microsoft 365 base license can now access Power Apps that leverage the true powers of a modern low-code application platform.

    You won’t get everything that CDS used to offer with just a Teams license now, of course. For starters, the only place from where you can access these app built on the non-Pro version of Dataflex is from within Microsoft Teams. None of the existing “players” for Power Apps will be supported, neither is embedding the apps to other UIs like SharePoint pages. Data types, security model, business logic, integration points, ALM… All of these will be far more limited on the “free” Dataflex than with the “real” application platform that is Dataflex Pro. For small apps aimed to be used by small-ish teams, though, I bet the Dataflex version will be good enough for a large percentage of use cases. It certainly is more advanced than SharePoint Lists, although the restrictions on app access points is more limited with the Teams based approach.

    Limitations can sometimes be a good thing. Dataflex is a simplified version of what CDS was, not just in terms of features but also the maker & admin experience. Do not underestimate how important this aspect can be in getting the citizen developers to make the right choice. Experienced CDS/XRM professionals may have been reluctant to move over to the new Maker Portal that is still missing features from the classic Solution Explorer. The new generation of app makers who have never even heard of these acronyms will most likely be happier within the Teams embedded app creation experience and give a higher NPS score to Power Apps as a result. Less is more, as they say.

    There’s going to be one Dataflex environment per Team that you can create, and the users will then map to the members of that Team, with a simplified user security role structure of Owner-Member-Guest (a.k.a. OMG). No business units or custom security role privileges to worry about, nor any complex data types like activities, polymorphic lookups, currencies etc. Yes, I know, most of the apps you’ve built already probably depend on those, but remember that this is not aimed at you! Dataflex Pro will have all of it and the non-Pro environments can be promoted to full capabilites, at which point they will require the same licenses as CDS does today.

    This is still a Big Deal. With the “free” Dataflex included in Teams, Model-driven apps can soon be created by an equally large crowd as Canvas apps before. Eventually it might no longer be an awkward moment when you need to talk about “that Power Apps app type that looks like Dynamics, not like all the other apps you have”, since every app maker can generate those beautiful, structured UIs on top of the database tables they’ve added into Dataflex. Since Model-driven apps are so metadata driven, I’d imagine this route would actually be a lot easier for many power users of Excel that haven’t necessarily been comfortable with building pixel-pefect mobile UIs in Canvas apps before.

    Despite of everyone having the possibility to store app data inside Dataflex, it’s not by any means imperative that a single database is established as the place for all business data. That is the traditional CRM approach of doing things, but with the modern tools like Power Apps and Power Automate the source and target of data operations could be a number of different systems if needed, thanks to Connectors. However, I’ve understood that Premium Connectors will still not be included with the Teams license, so the options for data connectivity will be more limited here. This may again be perfectly fine for the simple apps that the non-Pro Dataflex is aimed to serve.

    One thing the free access to Dataflex should make ubiquitous is the usage of solutions for app packaging and ALM. As the solution framework is a concept from the XRM era, replacing the earlier standalone .zip packaging of apps and Flows required that everyone would get access to this layer in the underlying platform. From an administration perspective it should be a clear step forward to standardize all the work to be done with Dataflex tools. There is also the promise of further deployment options being introduced with the Teams app store and its “single click” app installation, so this is an area for everyone to keep an eye on.

    The business impact of Dataflex

    The launch of non-Pro Dataflex can be expected to generate a wealth of questions from those professionals who’ve been working with CDS based solutions. What is & isn’t supported in Dataflex, where do the license and capacity limits actually get drawn, how are they enforced, where can apps be created for different Dataflex environment types, what admin controls are available on the tenant level, and so on. It’ll be confusing initially, but in the end I bet it’s gonna be woth it for all parties in this ecosystem.

    One year ago I wrote a blog post examining the possible growth directions for Power Platform. This launch of Dataflex + Teams now broadens the scope of the platform both on the Citizen Developer dimension (number of potential app makers) but also in the “Other MS products” axis. Earlier I’ve enjoyed making the joke that one day Microsoft would build the next version of SharePoint on top of CDS. Well, that hasn’t quite happened yet (and most likely never will), but we did see a major step now in Power Platform catching up with the mainstream productivity apps in Office. After all, every time you create a new Teams team, a new SharePoint site is provisioned for it. We’re now at a point where technically each team could also have a Dataflex environment provisioned at the same time. Knowing this, what’s stopping future Teams features from being built on top of CDS Dataflex?

    As we can see from Ryan’s example, there are interesting synergies between Power Apps and Teams that are made possible by having Dataflex “on by default”. From a partner ecosystem perspective, over 500.000 organizations around the world who use Microsoft Teams just became a potential target for no-code solutions that could be dropped inside various teams. I’m saying no-code here instead of low-code because presumably the non-Pro Dataflex environment wouldn’t support custom code. Anyway, there’s a lot to investigate here with the Dataflex public preview coming in August and GA planned for September timeframe, so I will definitely be returning to cover the topic more closely once detailed feature lists are publicly available.