Jukka Niiranen

Tag: Power Platform

  • Year 2021 in Power Platform

    Year 2021 in Power Platform

    Time to start wrapping up another eventful year in the Microsoft Power Platform ecosystem. Here are the highlights that came to my mind when reflecting on 2021, looking at my own articles and social media posts.

    Power Fx: a programming language for low-code

    This is an announcement from 2021 that will grow up to be a much bigger deal in the years to come. When Microsoft launched Power Fx in March, the only thing we initially had was a new name for the formulas that Canvas app makers had already been working with for years.

    The more impactful side of Power Fx is the grand vision of an open source language built specifically for the low-code app makers and solution developers. Power Fx is a sign of things to come: a world where the concept of code is democratized and any unnecessary barriers for people to act as developers are actively torn down by the platform providers.

    Building Power Fx based command bar buttons was the most fun topic I had to blog about in 2021 (see posts one, two and three). Much of the functionality in modern commanding is still way too early for production use, yet the progress that’s going to happen on this front is inevitable. This is how the business logic that goes beyond the options available via a GUI will largely be written in the near-ish future.

    CoE Starter Kit: the admin product on top of the platform

    It never ceases to amaze me how something like the Center of Excellence Starter Kit can be built purely on top of the Power Platform – to administer and govern that very same platform. In 2021 CoE was updated to be compatible with Dataverse for Teams, which is a small miracle on its own. All you now need is one premium license to unlock the vast feature set of The Kit.

    Officially it of course still isn’t a Microsoft product, rather the CoE Starter Kit is delivered as a template on GitHub that is actively maintained by the Power CAT team. Yet in many ways this is a much better model than what “real” Microsoft software products have. There’s a public backlog of potential and upcoming features, you can get notified of the monthly releases, plus the team is incredibly responsive on triaging the reported issues. This level of transparency gained via working through open source tools and methods is something you can only dream of having for the commercial MS products for Power Platform or Dynamics 365.

    Teams as an application platform

    Dataverse for Teams was launched in late 2020, so 2021 was its first year for us to see the impact from empowering every Microsoft Teams user to build Power Apps with a Dataverse back-end.

    Today there are 10 sample apps from Microsoft that any team member can easily provision from the Teams app store. They’ll end up creating a new Dataverse for Teams environment in that process, which is certainly going to put some governance pressure on your Power Platform environments in general.

    I don’t think we’ve yet seen a huge explosion in more advanced apps being built on top of Dataverse for Teams. However, due to its attractive price point (“free!!!”), it has definitely become an option we always need to evaluate before deciding on full Dataverse or (*gasp*) SharePoint Microsoft Lists.

    With Microsoft Teams being the hub for teamwork in most organizations using MS tools, there’s growing pressure for all business app developers to understand how their solutions should exist and operate within the Teams context. The very least you should do is to consider how Teams can be leveraged for publishing your apps to end users.

    As for the Teams + Power Platform story on a commercial level, we didn’t yet reach a point in 2021 where partners could distribute their Power Apps based products via the public Teams app store. In fact, it is explicitly called out that you shouldn’t submit any such apps to the Teams team to evaluate. Let’s keep an eye on this in 2022 and see how the Teams app store will align with the traditional AppSource channel (that didn’t receive much love in 2021).

    Pay-as-you-go licensing

    You asked for it – you got it! There have been constant demands coming especially from people working on Azure based app development that we should have a way to pay for Power Platform resources on the same Azure bill. The announcement of PAYG for Power Apps app passes and Power Platform capacity was therefore the biggest news that came from November 2021 Ignite event.

    Is the PAYG model going to replace the earlier prepaid licensing options in real life, though? Probably not on a wider scale, since committing to a certain number of Power Apps seats upfront is naturally going to give you a better price point in your Microsoft licensing negotiations. The 100% premium in the Per App price when using PAYG highlights that this model is aimed at serving those app scenarios where the actual consumption volume isn’t well known yet. Great for new experiments, maybe not so great for established app usage patterns.

    With the 30 day minimum duration for the once activated Per App passes, PAYG as it stands today isn’t yet very close to a pure consumption based pricing model like raw Azure services are using. Still, it may be flexible enough to convince customers that the licensing risks in building Power Platform based apps aren’t that high anymore, compared to the more rigid MS Business Apps based model that used to be the only option.

    50% price cut for Power Apps

    As if the PAYG model wasn’t enough, in 2021 we also saw a rare moment when Microsoft slashed the price of Power Apps Per User and Per App licenses in half. In that process, the latter was also redefined to mean “Per 1 App” and not “1+1+1 Apps”, but that just made perfect sense in order to clarify the terminology. You could say in most scenarios the list price for running premium apps got reduced by 50%.

    Those of us who’ve worked with Power Platform on a daily basis have always known the crazy value for money that you could get from the platform, already before this price cut. When it comes to convincing the customers in large organizations that they should license every user with Power Apps premium, in the same way they’ve bought Microsoft 365 licenses, there’s probably been a need to move the price point a little lower still to make such deals happen.

    Looking at the global playing field of low-code application platform vendors, customers’ concerns over pricing and licensing are a common issue listed for all leading vendors in Gartner’s Magic Quadrant. MS may not be able to completely alleviate these concerns, yet it certainly helps to have a list price that isn’t an obstacle for starting the talks with anyone.

    Hello Azure Synapse, bye Data Export Service

    OK, so this doesn’t actually affect pure Power Apps environments but rather Dynamics 365 customers. However, since DES has been so widely utilized as the mechanism to gain SQL style access to the Dataverse tables for building reports, the announcement of its deprecation has to be considered one major event for the year 2021.

    This deprecation will mean many customers need to re-architect their reporting solutions, even when existing reports are happily running in production and possibly meeting all the current business requirements already. Thankfully you can still push the Dataverse data into the same SQL database. Using three Azure products (Synapse, Data Lake, Data Factory) instead of one DES can feel like more complexity to achieve the same results, though.

    There’s a bright side to this change, though. The old DES was always just a stop-gap solution that MS had to put in place, to address (primarily) the reporting concerns that CRM customers had when moving to the cloud. The new Azure Synapse Link, on the other hand, is a critical element for Microsoft’s vision of how customers will make better use of their business data via a multitude of new and future services in Azure. The incentives for maintaining and expanding such a service are obviously much higher. This should lead to positive outcomes for both customers and solution developers in the long term.

    Fusion Teams story

    The term “Fusion Team” in itself doesn’t tell very much at all, but in the context of Power Platform I would categorize pretty much all the integrations between Azure developer tools and Power Platform app maker tools under this umbrella. Much like the PAYG licensing model, this movement is crucial in evolving low-code development techniques beyond the citizen developer domain. People with an XRM background already know the enterprise level capabilities within the platform, but Microsoft needs to convince everyone that also pure Power Apps are credible in this territory.

    In 2021 we saw a Microsoft make a big push in promoting the techy side of Power Platform to the traditional software developer audience. Not only did we get the Power Fx programming language in isolation, there were also plenty of examples shown on how this will support source code versioning and manipulation inside VS Code. Screenshots of command-line interfaces became a regular part of product team blog posts. Supporting the pro-dev workflow via CI/CD pipelines in Azure DevOps remained a high priority, with still no signs of any citizen-friendly ALM story.

    The role where Microsoft seems to want the professional developers to focus on at the start of their Power Platform journey is in connecting to new data sources and custom APIs. This is what their Fusion Development e-book emphasized at least, which ended up becoming my tweet with most impressions in 2021:

    Inevitable complexity of low-code

    This leads us into the last topic I wanted to mention, which is more of a top-of-the-mind phenomenon rather than any individual event that happened in 2021. When we put together all these different growth directions of Power Platform (from Teams to Azure) and its expanding capabilities (from governance to software development), one can rightfully ask: at which point will all this spiral out of control?

    We have a broad variety of audiences that this platform wants to cater to. In one corner we have those heroic citizen app makers who’ve been empowered by the Power Apps & Automate icons found under the Office 365 menu, allowing them to solve business problems via new digital tools that no one expected them to deliver. In another corner we have the folks actually tasked with delivering enterprise wide software solutions – now looking for ways to keep the amount of custom code somehow manageable, by leveraging low-code alternatives where they’re a good enough replacement. More and more corners of this arena will get populated as ISVs and other players will join Microsoft’s low-code game.

    Creating your first apps and flows will remain an easy task. The problem is that the boundaries for what you can’t do and what isn’t supported with Power Platform keep moving further and further out. The rising complexity of apps built on low-code can already be seen everywhere and it will just keep growing in 2022. We need to stop endorsing the misconception that these would be “easy tools for creating simple solutions”. While low-code apps are easy to approach and can delivery quick results, in the end we’ll be faced with the same key task as with any business application landscape – managing the inevitable complexity.

    Could we expect to see some new innovation come along to help us address this growing pool of low-code complexity? Following the familiar People-Process-Technology framework, the biggest requirement I see out there in the real world is establishing the right kind of organization structure around low-code. Once we have people with dedicated roles in place, planning the delivery, admin and governance processes will then become possible. Finally, this will allow the new advancements in technological innovation – to bring better visibility into our growing app portfolio, reduce manual/duplicate configuration work, automate the recurring process and alert humans when their attention is required to address new exceptional events.

    As an example, by turning the low-code of Power Apps canvas apps into actual source code managed in GitHub repos, Microsoft has a chance to feed all this data to their machine learning algorithms. Things like GPT-3 from OpenAI may one day become smart enough to analyze what on earth all these millions of apps are trying to achieve and then offer suggestions to us mere mortals on what modifications and updates we should apply.

  • A Power Platform newsletter from our team

    A Power Platform newsletter from our team

    UPDATE 2023-01-03: After Twitter decided to shut down the Revue newsletter service, the Forward Forever newsletter was migrated to Ghost. The content remains available at the same forwardforever.news domain.

    Back in Spring 2020 when we launched Forward Forever, one of our guiding principles was to openly share with the outside world the new knowledge we gain when working with Microsoft Power Platform tools on a daily basis.

    Team FF has been quite active in community contributions, with content regularly shared both on our team blog as well as personal blogs like the ones written by Timo, Antti and myself. Sometimes when I’ve been looking at our social feeds, I’ve wondered “are people actually able to keep up with all these updates our team is sharing?”

    Now there is a place that brings together these streams of new Power Apps, Power Automate and Power BI related information: The Forward Forever Newsletter. This monthly email newsletter is available for anyone to subscribe to at forwardforever.news:

    To quote our team’s announcement of the newsletter:

    That’s what the Forward Forever Monthly newsletter is all about. A summary of both our own writings as well as the best bits from the Power Platform community. No ads, no hard sales push. Just the most relevant content that our passionate team of Power Apps, Power Automate and Power BI experts has discovered.

    Our newsletter runs on the Revue engine (recently acquired by Twitter). You might already be familiar with it, since there are at least a couple well-known weekly Power Platform related publications on that newsletter platform:

    We don’t intend to compete with these community driven newsletters, because they do such an awesome job already. Many of the FF team member blog posts have been covered in the issues over time. Recently PP Weekly celebrated its first full year in operation and I wrote a bit about the importance of such content curation initiatives over on LinkedIn:

    I encourage all customers and community members interested in the latest events around especially Power Apps, Power Automate, and also Dynamics 365, to add themselves as subscribers to these publications.

    There is no shortage of great blog posts, podcast, videos and free tools to cover in this ecosystem. What I do think we have a shortage of is ways take control of our precious attention and consume information at our own pace. A monthly email digest that doesn’t scroll past in your real-time feed may offer a calmer way to stay in the loop.

    Subscribe to Forward Forever Monthly

    Just one email per month on cool Power Platform things we’ve come across.

    Yes, let’s do this!
  • Power Platform licensing, November 2021 updates

    Power Platform licensing, November 2021 updates

    The second Microsoft Ignite event of 2021 included several important updates on a topic that I cover regularly on this blog: Microsoft Business Applications licensing. The biggest announcement of course was the pay-as-you-go licensing model (PAYG) for Power Apps:

    Here’s a few thoughts and observations on what was announced & updated on the licensing front.

    PAYG and Azure

    Despite of its name, the biggest impact from the Power Apps pay-as-you-go plans isn’t necessarily the pricing model. Rather it’s the currency in which you pay for it: Azure money. This is something that most larger organizations will already have in their virtual cash reserves, which makes it considerably easier to spend on services.

    Licensing agreements are both an enabler and a blocker for Microsoft cloud services, especially on enterprise level. Getting something new like Power Apps premium licenses included into the IT portfolio available to the business users can take a lot of time and effort. Once it’s included, though, there’s plenty of practical benefits for using these as opposed to some fancy new cloud service that might come along.

    Having an official “exchange rate” that converts these new low-code tools managed on the Microsoft 365 side into tools and terminology compatible with the pro-dev work already done in Azure is key step in selling the Fusion Teams story to organizations. Even if the PAYG model wouldn’t be cheaper in practice, having Power Apps license costs show up in existing reports on Azure Cost Management side will make it less of an unfamiliar beast to IT and developers. Also the discounts customers may have negotiated based on their Azure spend will presumably apply to Power Apps, too.

    PAYG and apps

    PAYG is specified on environment level, by defining a billing policy and selecting which environments are included in it. However, you can exclude specific apps from the model and require their users to have a Power Apps Per User license instead. Mixing PAYG with Per App subscription plan isn’t allowed, though.

    I believe that underneath the covers the PAYG Per App plan and the regular Per App plan are mostly identical. The major difference is that at the end of the month, the PAYG pass is removed from the user until he/she opens the app again. With the regular Per App subscription plan, the pass allocated upon the initial app sharing to the user and isn’t revoked until the app is explicitly unshared.

    So, which one should you go for then with your Power Apps that use premium features? Subscription model or PAYG? First we must keep in mind that the recent 50% price drop in Power Apps subscription plans took the price of a Per App license down from $10 to $5. At the same time the Per App entitlements were updated to cover a single app, rather than up to 3 different apps (existing customers have been compensated with 3x passes). Now with the new options, you can either pay $5 per user per app per month in the subscription model, or pay $10 for the exact same features but only for those months when a user opens the app.

    If there was a quick & easy way to assign, unassign and report on the Per App subscription licenses, it would clearly be tempting to save 50% and pay with the old model rather than PAYG. In practice, Per App licensing management remains a nightmare that has surely cost customers (and partners) lots of money in time spent figuring out who’s got access to apps, why someone doesn’t, and how much licenses are actually being used. It’s been over 2 years since the Per App plan was launched and we still don’t have a report in Power Platform Admin Center that would give customers the information needed for managing this process.

    If the PAYG mechanism can both automate the assignment and removal of licenses, as well as provide detailed reporting in Azure Cost Management, then it could well be worth the price premium for process efficiency and cost visibility. For any smaller app experiments that you’re not yet entirely sure on how widely they will be used, starting with the Azure subscription based billing makes a lot of sense. You’ll be able to cut down on the initial admin hassle and get real data on the app usage to base your future licensing decisions on, whether to use PAYG or committed subscription passes/seats in the long term.

    PAYG and capacity

    It’s important to understand that the PAYG model doesn’t completely transform Power Platform into a pure consumption based model like Azure. After all, a single app launch during a calendar month will cost you the same as 1000 launches by the same user, and using 2 different apps will double the cost regardless of how much load you generate to the cloud services. Think of it more like buying a monthly pass for public transportation in your local area vs. taking an Uber and paying in proportion to the actual duration and length of your rides. If you travel to another city not covered by your current pass, you’ll need to purchase another pass. In the case of Power Apps, there aren’t any per hour or per day tickets sold, so the monthly pass is the minimum charge for the Power Apps per app meter billing rules.

    Having said that, there is also the concept of pay-as-you-go capacity when it comes to Power Platform licensing. API capacity is something that Microsoft says a normal user shouldn’t have to worry about, since there is bundled capacity included with the app/user licenses. At Ignite an announcement was made that increased the request limits for both licensed users and non-licensed users (check out Gustaf’s blog for details). If you do run out of requests, though, there will soon be a PAYG Power Platform request meter that can be used to pay for the overage.

    Something that does already exist today and is a much easier concept to approach than API consumption is the storage capacity. Unlike the traditional subscription licenses that are paid upfront, the PAYG model doesn’t have any storage capacity accrued per each user or app pass. This makes sense, since those numbers are only known as-you-go by the end of the month, whereas data storage is something a lot more persistent.

    Whenever you activate PAYG for an environment, it means it no longer draws from the tenant’s common capacity pool. The environment does get 1 GB of “free” Dataverse database capacity + 1 GB file storage capacity, but after that you’ll pay for everything based on what the Dataverse capacity meter shows. These rats are slightly higher than subscription based capacity prices, at $48 and $2.4 per GB respectively (note that log capacity is always paid for at $12/GB). If you’re used to leveraging the tenant level capacity accrued from user subscription licenses for your storage needs (coming from Dynamics 365 users, for example), then this can be a surprising additional cost when activating the Azure based billing policy for your environment.

    There’s one gotcha in the current way how PAYG storage capacity can be used. You see, in order for you to assign a PAYG billing policy to an environment, the environment must first be provisioned. What this means is that the tenant will need to have a minimum of 1 GB database capacity available for the environment creation to succeed. So, you’ll need non-PAYG capacity from elsewhere (such as a paid Power Apps or Dynamics 365 plan) before you can use an Azure subscription to start paying for the capacity instead. Presumably Microsoft will fix this issue in the near future, since it’s in no one’s interest to block PAYG as the sole billing method.

    While storage capacity has been reported and technically enforced for a while already, Power Platform requests are still something that exist on paper but cannot be reported on nor paid via actually assignable licenses. In the FAQ section of their documentation page, there is now a new answer to the following question: What are the timelines for Power Platform Request limits?

    The concept of limits was first introduced in late 2019 and documented limits were substantially increased in late 2021. Generally available reporting for Power Platform Requests is expected in the first quarter of calendar 2022. Any potential high usage enforcement wouldn’t start until six months after reports have been made available. Assignment of add-on capacity packs should be aligned to high usage enforcement.

    Let’s assume that the reports would be launched in March 2022, after which there will be a 6 month grace period before the technical enforcement kicks in. This would mean that the October 2019 licensing changes that started all this confusion around what the platform can & cannot be used for will have taken full 3 years to truly come into effect. That’s a long, long time. Yet I do think it’s encouraging that Microsoft haven’t rushed into enforcing a rule that might have caused way too much collateral damage if not thought out well enough.

    Power Automate licensing updates

    There isn’t a PAYG model available for Power Automate. Sure, you can use premium connector cloud flows within the context of a Per App licensed app (although I’ve found this to be difficult/impossible in practice). The nature of a background process automation is fairly different from the interactive usage of an app UI, so it kinda makes sense why new options haven’t been introduced. Besides, if the Power Automate licensing model doesn’t work for your scenarios, then moving to the consumption based Azure Logic Apps is already a good option to consider.

    While there weren’t any major Power Automate specific licensing changes announced at Ignite, there was a wealth of new documentation released on the topic during the event. The flow licensing FAQ contains some interesting answers when it comes to what we would have traditionally considered to be multiplexing. I’m one of the few people who have ever dared to blog about multiplexing, yet it seems that there are things I haven’t fully grasped about the topic either. This infromation in the FAQ caught me by surprise:

    A common question is, “If a flow is triggered when a SharePoint list item is updated, and many users interact with that list, will there be a cost for each user?” The answer is if the flow does not use a premium connector such as calling Dataverse in the full production environment (not the Microsoft Teams environment), having an Office 365 license is enough. If the flow uses premium connectors, since the trigger is an automated trigger, only the owner needs a premium license.

    Having a web form that any user could submit to create a lead record in Dynamics 365 used to be the scenario where I’d say “sorry, you’re violating the licensing terms”. Now, Microsoft explicitly calls out that if a user enters data into a SharePoint list and that in turn triggers an automated flow that uses a premium connector to push the data into Dataverse, it’s enough for the flow owner to have the premium license.

    This little change opens up many scenarios where recording entries into Dataverse / Dynamics 365 may have previously been considered too expensive. Using a SharePoint / Microsoft List as the intermediate data storage is now officially a supported method to reduce the need for Power Automate premium licenses when using automated flows. I personally find it hard to understand how this statement wouldn’t contradict Microsoft’s core definition of multiplexing, but what can I say? Other than: welcome to Business Apps licensing!😂

    AI Buider

    One more small but significant change: there will now be AI Builder capacity included with Power Apps Per App plan (250 credits) and Power Apps Per User plan (500 credits).

    How much AI that will actually give you depends on the usage scenarios, which you can try and estimate with the AI Builder calculator.

    Why is this a big deal? Well, for some mysterious reason, Microsoft had earlier decided that the starting price for buying AI Builder capacity was $500/month for 1 million credits. Need just a few runs for your little cloud flow every month? “Sorry, we can’t be bothered to support anything below 1M.“

    This was a prime example of how not to price cloud services for citizen developers, as they should be given the chance to focus on building apps instead of building business cases for software licenses. The starter capacity will now make it possible for app makers to leverage AI models in small solutions and experiments beyond just a 30 day trial.

  • Did Power Apps really leak your customer data?

    Did Power Apps really leak your customer data?

    Recently Power Apps made the headlines in a way that Microsoft would have liked to avoid at all cost:

    The news headlines today aren’t exactly the most neutral source of information, but luckily we also have access to the full report from the security research team at UpGuard. Here’s what happened according to them:

    The UpGuard Research team can now disclose multiple data leaks resulting from Microsoft Power Apps portals configured to allow public access – a new vector of data exposure. The types of data varied between portals, including personal information used for COVID-19 contact tracing, COVID-19 vaccination appointments, social security numbers for job applicants, employee IDs, and millions of names and email addresses.

    UpGuard

    Sounds serious, and it certainly shouldn’t be sweapt under the rug by anyone working with Microsoft Power Platform. We have a lot to learn from an incident like this and the concerns it may bring up along with it. As these low-code technologies become more widely used across different industries, not all publicity will be positive.

    There have of course been some concerns raised by IT practitioners already before this Portals incident on what’s the general impact that low-code platforms will have on business solutions development. How to secure customer data and to build proper governance practices around these tools is a topic that is often covered when talking about Power Platform with customers.

    I personally already used the above headline as an example in a governance workshop with a customer on the very next day after the report was published. The discussion was quite neutral and it served well in acknowledging both the important role that Power Platform tools can have in business processes, as well as the need for practices that allow them to be safely used in developing new solutions.

    The other alternative where such a topic would not be proactively addressed in a transparent manner could instead lead to more controversial reactions down the road. Some people may have negative experiences in their past that might lead to seeing these new events as an enforcement of their existing beliefs.

    It’s hard to prevent people from drawing the wrong conclusions based on incomplete information if we don’t bring all the relevant pieces into light. To help in such examination of the evidence, in this blog post I’ll present some fictitious statements that could potentially be made based on reading the news headlines. Then I’ll offer my own perspective on whether they would be justified or not.

    “Bugs in Microsoft’s software caused the data leak!”

    This wasn’t an actual bug, rather an unfortunate feature. As the report title from UpGuard hints, it was “by design” when examined from a technical perspective. Also, that was the initial response from Microsoft’s side, as shown in the report:

    The above response is in my opinion the biggest mistake from Microsoft in this whole incident. Being tone deaf when presented with something that had already proven to be a pattern leading to unintended disclosure of confidential customer data via numerous Power Apps Portals out there is… Well, it’s what happens in large corporations, unfortunately.

    What was this “by design” feature then? In the state that the Portals configuration experience was at the time of the investigation, there wasn’t any strong push from the product side to make the data tables used in the portal as private. It was a neutral platform built specifically to take records from your organization’s internal Dataverse tables into a public website, then giving you the choice to either show all the contents to anyone, or limit the visibility through a very granular security model to only a small subset of records.

    As an example: you could show all the available locations where COVID-19 vaccinations were being offered (public table). Then you’d give the logged in user the ability to create an appointment record (private table with access control). Both are an integral part of the business process managed via a portal, yet the rules for showing them to the website visitors are directly opposite. The technical platform has to cater to both these requirements.

    As it happened, there was a way through which the portal developer could forget to enable the table permissions that the private data should have in all areas where it was used. Now, the reason why this mistake wasn’t immediately obvious was that the Power Apps Portal product included a feature that allowed publishing this data as OData feeds. These would not be visible in the website pages necessarily, but they were technically available as long as you knew the right path from where to search for them.

    In our example, a public OData feed of locations could have been useful for integration purposes. For reservations made by private individuals, an unauthenticated feed would never be a good idea. Yet the platform didn’t know what the developer wanted.

    After this incident was reported by UpGuard, Microsoft changed the defaults and made it require more conscious effort to publish the feeds for unauthenticated consumption.

    “Poor default settings in the Portal product were dangerous!”

    There’s no denying that discovering more than a thousand Power Apps Portals misconfigured to expose confidential data to unauthenticated users is a big number. Yet the total number of Portals out there is… well, let’s just say it’s certainly multiple times that.

    As part of their research, UpGuard enumerated through the various available powerappsportals.com and microsoftcrmportals.com subdomains to programmatically scan the sites with potential unintended OData feeds published. Many were found through this method, but still this problem affected only a small subset of all Portals websites out there.

    The majority of Portals developers will have been aware of the setting that must be enabled for any data that you don’t want to be publicly available on your website. Nick Doelman explains the “Enable Table Permissions” setting very clearly in his excellent blog post. It’s not really fair to claim that this would have been impossible to notice while building your Portal app:

    If it has been news to you and you have built websites with Power Platform tools, then I seriously recommend you to take advantage of this generous offer by Nick and enroll for his Power Apps portals Security Deep Dive course:

    Update 2021-08-31: you should also check this video from George Doubinski about the Portals behaviour before & after the default setting change:

    “Microsoft should prevent such things from happening on their cloud service!”

    Power Platform is a suite of low-code tools that allows you to build your own apps. Whatever business logic the published app contains is ultimately the responsibility of the app creator. Same goes for the data you manage with that app. Technology providers can’t easily stop people from building unfit solutions with their products.

    There’s a great analogy in George Doubinski’s blog post “How to secure Power Apps portal from making the news” that I’ll repeat here. If you’re a company selling nail guns and a few unfortunate customers of yours shoot themselves in the foot – what should you do about it? Sure, your product probably came with all kinds of instruction manuals and warning signs that try to explain the importance of learning how to use such power tools. Similar to how Microsoft now shows a banner saying “table permissions should be enabled for this record or anyone on the internet can view the data”, to try and warn people not to hurt themselves.

    Let’s look at an example from another area of Power Platform that I cover frequently in my blog: licensing. Any customer could easily use this platform to build an automation that is a clear violation of the multiplexing rules of the very same platform’s licensing terms. Just create a Power Automate cloud flow that automatically pushes all new opportunities from your Dynamics 365 Enterprise Sales app into a SharePoint list accessible to your whole organization with no Dynamics licenses assigned to them. Congratulations, you’ve again used the powerful tool to hurt yourself in a way that the vendor couldn’t have stopped.

    “I knew citizen developers couldn’t be trusted to build real business applications. So much for low-code!”

    Did you look at the types of customers that suffered from this data leak? If not, I’ll list some of them from the UpGuard report here, to give perspective:

    • American Airlines
    • Ford
    • State of Indiana
    • New York City Municipal Transportation Authority
    • Microsoft

    These don’t sound exactly like the kind of organizations where a lone citizen developer who discovered a neat tool in his Office 365 app launcher just went ahead and built a portal on top of millions of rows of contact records and other sensitive data. If I had to guess, I’d assume there has been a proper development team working on many such customer facing services – not just citizens.

    The above picture is an example from the report’s contents that was captured via the unsecured OData feeds. It is from the Global Payroll Services Portal for Microsoft employees, built (presumably) by professionals working with software. Despite of all the resources and knowledge behind these, the misconfiguration of a Power Apps Portal still went into production sites.

    Although not directly related to this incident, on the very same week there was also another unfortunate data leak reported concerning the Microsoft cloud. Only this time it was around CosmosDB and the database primary keys that got leaked, exposing private data from thousands of Azure customer organizations. The misconfiguration seems to have been carried out by Microsoft software developers while they were integrating Jupyter Notebooks with CosmosDB to provide a new platform feature to customers.

    Regardless of whether you are clicking through low-code configuration pages or writing your own lines of custom code, mistakes can happen.

    “Suites like Power Platform are becoming way too complex for anyone to keep track of all these features & settings that can cause harm!”

    This is certainly true in the sense that a single person will not have an A-to-Z understanding of Power Apps in Canvas/Model-driven/Portals flavor, Power Automate in the cloud and on the desktop, Power Virtual Agent, Dataverse, AI Builder, Power BI and its data platform back-end… It’s way too much for anyone to consume as documentation, let alone master in practice.

    We should be asking where the assumption actually comes from that an app maker or developer should have end-to-end knowledge of the whole Microsoft low-code stack? Whether you’re a customer or a partner, it’s very important for you to not be blinded by all the flashy product demos and testimonials on “how company X digitally transformed themselves, using software suite ABC”. It doesn’t all happen thanks to this one mythical app hero who can take on any challenge – rather it’s the result of the right person finding the right tool to solve one specific problem at a time. Repeatedly, at scale.

    Low-code is a team sport and you will increasingly see the fusion development approach be promoted by Microsoft. This emphasizes the fact that an optimal mix of business domain expertise and technical software development skills is a better approach to achieving long term business value with low-code than relying on lone superheroes to do it all. In the end, just because you’re not writing as much code as earlier doesn’t mean the resulting systems would be simple:

    Low-code tools may be easy to approach, but the solutions you create with them can be as complex to manage as custom software.

    The data leak was the result of a feature built into the platform that the persons developing the customer specific solution were not aware of. They didn’t purposefully create the OData feeds, rather the software product generated them based on the underlying logic of how it was meant to streamline certain app development tasks. The best chances for having awareness of all these moving parts in the end solution is to ensure people have a realistic opportunity to focus on their primary tools and continuously sharpen their skills.

    “This incident proves you need product X / service Y from partner Z to be safe with Power Platform!”

    Events like these are bound to inspire companies working in the Microsoft ecosystem to try and gain exposure of their own by riding on the news wave. It never hurts to sprinkle a little FUD tactics on top of your marketing message, right?

    Now, I have to be transparent and admit right away that we are in the business where the questions and concerns coming from Microsoft customers are addressed via our advisory services. Even though we educate organizations on governance best practices and have delivered a few Power Apps Portals solutions to them, I would not make any statements like “buy from us and you’ll never have these kind of problems”. There’s two reasons for this:

    1. Our aim is to help customers take ownership of their digital tools, not to be the ones who build everything for them & maintain it. New app makers will make mistakes as they learn & grow, they just need a safe space for this (read: not a public website).
    2. I know how hard it would be to build a technical solution to audit every little detail that could go wrong in the various use cases where Power Platform is be used.

    Let’s examine the details of this particular data leak. First of all, to have any technical level protection, you would need a service that can tap into Power Apps Portals specifically. Running something that monitors only Canvas Apps or Model-driven Apps won’t help you here. Even the Power Platform Center of Excellence (CoE) Starter Kit from Microsoft only has the Portals data inventory as a backlog item as of now. If no public APIs are available to tap into a Microsoft cloud service, then you’re unlikely to find any software to do the required tricks for you.

    Even if we’d have the same level of telemetry data access as Canvas Apps do, what’s the likelihood of the specific setting in question (Enable Table Permissions) to be exposed and monitored? Well, it is data stored inside Dataverse tables and could be queried via Advanced Find as showed by Nick, so in retrospect we could technically have audit tools built for it. But why would someone built such a third-party product when Microsoft already offers Portal Checker to all customers?

    So, there’s unlikely to be an easy & all encompassing solution out there that would address all your Power Platform security and governance concerns. I could even bet that some of the Portals websites that suffered from the OData leak will have been reviewed by security professionals from outside the Microsoft ecosystem and still the issue was not discovered. Probably because they didn’t know where to look.

    Because it’s an ever evolving cloud platform, it was possible for Microsoft to quickly react to the incident via a change in their original design, as well as by notifying the customers potentially affected by it. Today the risk of unintentional data exposure is technically lower and the public awareness of such possible misconfiguration among the Power Platform app maker community is much higher.

    Yet we have no way to guarantee what will happen tomorrow. Something similar may be discovered in a different part of the platform that will again require attention and action. I think all we can really do is to keep our eyes open and be ready to learn from the new discoveries shared by the network around us.

  • Power Apps pricing drops by 50%

    Power Apps pricing drops by 50%

    It’s not that common to see Microsoft make an announcement where the price of existing products is cut in half. Today, however, is a special day where we heard that the prices of Power Apps licenses are going to be reduced by 50% :

    • Power Apps per user: from $40/month to $20/month
    • Power Apps per app: from $10/month to $5/month

    Note that this is the new list price – not a temporary campaign price. Using Microsoft’s low-code application platform is therefore becoming considerably cheaper for all customers (eventually).

    More revenue via lower pricing

    What’s the story behind such a dramatic pricing change? Was Microsoft struggling with selling the platform to customers at the old price point? Well, we will of course never know the full details behind the business planning decisions and the calculations MS has been performing in their own Excels.

    My own interpretation is that there certainly hasn’t been any shortage of interest towards Power Apps from the customers’ side. What’s probably happening here is that the high ambitions Microsoft has set for scaling up the broad commercial coverage of Power Platform technologies within their customer base haven’t quite been met with the current pricing model introduced in October 2019. I can easily see how the speed at which low-code is taking over the world isn’t well aligned with the slow licensing agreement negotiation cycles around enterprise software. These are both a blessing and a curse for MS, compared to more nimble competitors in the low-code / no-code space.

    To address this need for pricing agility, Microsoft had already launched a promotional offer at the end of 2020 to give volume discounts on per user and per app licenses: $40 > $12 and $10 > $3 respectively. This offer basically made the previously confidential discount levels publicly available, giving a much better indication to larger customers about what the expected true cost level of Power Apps licenses would be. Since there are so many different potential user groups for low-code apps within a typical enterprise organization, it’s problematic if every team does their own business case calculations based on list prices. That doesn’t really deliver the optimal outcome for Microsoft who’d want to sell the one platform for the whole organization through a single high volume deal.

    Based on my discussions with customers, it’s pretty obvious that most of them are already confident with the technical abilities of Power Platform. What they are not very comfortable with is the complexity of how the platform has to be licensed. All the confusion and uncertainty is quite understandable, given the many moving parts and the licensing model that appears to have been in flux during the past couple of years.

    Any temporary campaign price isn’t necessarily going to alleviate the concerns customers have for the long term costs of licensing Power Platform premium features. Therefore I think Microsoft is looking to provide a clear signal that they’re targeting a very wide scale adoption of these low-code tools – not just for large business critical apps for specific audiences.

    Licensing implementation details

    Due to how the licensing contracts and MS price lists work, the new Power Apps license prices aren’t yet reflected in the public pricing site, as they’ll only come into effect on October 1st 2021. Any contracts made after that will get the new prices. Same for contracts that are renewed after October 1st. For any ongoing subscriptions the new price points are not applied automatically, because for good & bad, the prices for a customer are locked via these contracts. Keep that in mind when counting the near term costs of Power Apps for your users.

    The SKU (stock keeping unit) of the per user plan won’t change, the list price will just come down to $20. For the per app plan we’ll see the old SKU become discontinued and a brand new SKU launched on October 1st. This is because there is more to the changes than just a new figure on the price tag in the per app model.

    There’s been this peculiar twist in the original entitlement that allowed a single Power Apps per app pass to run 2 apps & 1 portal within a single environment. While the reasons for allowing both Canvas and Model-driven apps to be used in a single business scenario probably made sense in theory, this has been in practice very difficult for customers to comprehend. It must have also been a huge headache for MS to incorporate into their license reporting and technical enforcement within the platform. Changing the new per app license to cover a single app is therefore a very logical & welcome update. If you really need 2 apps, then just buy 2 per app passes for $10 – the total price is not increasing here, after all.

    These changes announced today are specific to Power Apps, which means that the Power Automate price points for per user and per flow remain untouched. This isn’t very surprising, since I believe Microsoft would rather see customers adopt both the app side and the automation side – not just run “invisible” flows behind the scenes. The Power Apps per user plan now gives you these for a small additional cost compared to Power Automate per user plan ($20 vs. $15). As for the other plans, the use cases for per flow process automation or the RPA capabilities are very distinct, in my opinion, so not much pressure should arise from this Power Apps pricing change for those.

    What about Dynamics?

    Two years ago when the per app plan was launched at $10, there was a lot of discussion on how this might cannibalize the Dynamics 365 products. Paying $95 for an Enterprise Sales license seemed pretty steep in comparison when you could build your own CRM on top of the same Power Platform tools and run it for a fraction of the cost. Well, it looks like the tribes of low-code cannibals didn’t take over the world and Dynamics 365 business has been growing nicely regardless of this move. There certainly is a growing number of “DIY CRM” type of solutions being used now via Power Apps, but one could argue that these customers and their scenarios might not have landed on MS cloud (or stayed there) if the lower priced option didn’t exist.

    During the past 1.5 years, after founding a company focused 100% on Power Platform and taking some distance from my prior Dynamics related work, it’s been eye-opening to talk with customers without wearing a CRM hat. Low-code application platforms are a discussion that concerns everyone, regardless of what systems they are using for managing their sales, marketing, service processes. You don’t really need to mention the word “Dynamics” at all in these discussions – unless the customer happens to be running them already. Whatever their CRM or ERP systems are, the Power Platform story is equally compelling when viewed from the broader Microsoft cloud perspective.

    When Ryan Cunningham, Power Apps product lead at MSFT, introduces the new pricing model announcement with the title “apps for everyone” – that should give you an idea of where the goals are set. You can’t sell Dynamics 365 to everyone, hence the higher pricing of these products. As for Power Apps, there aren’t many valid reasons why someone could not be target customer for them.

    The price will never be “right”

    Even with this 50% price reduction, I’m not expecting all customers (or even MS partners, strangely enough) to be happy with the licensing model for Power Apps premium features. As long as everything isn’t free, someone will always complain how the low-code platform pricing model of charging by app usage is “wrong” (instead of paying money for app development work and infrastructure operations).

    I don’t think we should expect that the full premium feature set of Power Apps would ever become a free bundle within Microsoft 365. More and more of these high value features like Dataverse for Teams are already “free” for existing customers. They help build up the scale of app usage (see the Teams as a platform story), but there has to be an upsell story to paid Power Platform services somewhere down the line. If there wasn’t, we wouldn’t see such huge investments into low-code capabilities from Microsoft.

    Platform licensing is the end game, not per app. Once customer organizations unlock the possibility for all their employees to run & build unlimited apps on the platform, that’s when the real transformation begins. There’s undeniable business value waiting behind that door, and that’s why it needs to have a price tag.

    Read more about Microsoft Business Applications licensing

    Check out my earlier blog posts in the licensing category.

  • Dataverse for Teams as your CoE platform

    Dataverse for Teams as your CoE platform

    If you’re serious about leveraging Power Platform low-code tools in your organization, then you definitely should be using the Power Platform Center of Excellence Starter Kit (CoE) from Microsoft. This is the best way to get an understanding of what happens in all the environments across your tenant – ranging from small experiments by citizen developers to enterprise wide systems running on Dataverse, like Dynamics 365 Customer Engagement apps.

    The latest CoE update is a big milestone, since it enables the installation of these tools into any Dataverse for Teams environment (DV4T). Why is this a big deal? Because it removes a few licensing blockers that might have previously stopped organizations from deploying the CoE or making the most of its capabilities.

    The first upside is you no longer need to consume Dataverse storage capacity for the CoE deployment. That isn’t actually such a big of a deal, since the CoE Starter Kit data usually doesn’t really take much storage space at all (unless you’ve got a huge enterprise tenant). A nice bonus from this is that you can now deploy CoE in a demo / trial environment with no paid capacity available.

    You still need some actual Power Platform licenses to run CoE, though. Remember: Microsoft 365 does not contain Power Platform licenses – not even at E5 level. From the CoE setup prerequisites, we can find the following statement about Power Automate licenses:

    If you are using the CoE Starter Kit in a Dataverse for Teams environment, a Power Automate per user license will be required for the admin running the sync flows. No additional licenses will be required for users interacting with any of the canvas apps.

    CoE setup prerequisites

    Now, the really big thing is that by using Dataverse for Teams as opposed to the full Microsoft Dataverse, every user with a Microsoft Teams license is allowed to interact with the CoE data and processes. This means that you can actually invite all citizen developers in your organization to participate in the governance practices and automations directly – regardless of whether they already have a premium Power Apps license assigned to them.

    If you only perceive Power Platform governance to be about restrictions and enforcement of policies by IT admins, then the differences between the old & the new model aren’t that big. If, on the other hand, you believe in the power that low-code has to democratize technology and make it accessible to every developer, be it a pro or a citizen one, then this Teams based deployment option is something you’ll definitely want to explore.

    Installation

    Let’s try things out in a new DV4T environment, to see how the deployment process differs from the traditional set up of CoE core components. There’s a different solution package aimed at the Teams deployment option. We’ll need to have an environment provisioned in our chosen team before the installation, so just create one dummy app if you’re using a new team for CoE purposes.

    The import (and export) options within the Power Apps app in Microsoft Teams have only recently been enabled. Importing the managed solution zip file into DV4T gives you a bit different experience than what we’ve been accustomed to in the Dataverse side, by listing all the items that are part of the import:

    Next we need to create a bunch of connections before proceeding further with the installation, to allow CoE to perform the necessary data retrieval through a wealth of APIs. This process will give you ~10 new browser tabs that show the traditional non-Teams version of the Maker Portal. A bit of a click show – but luckily there’s one upside to it.

    While you can’t open the DV4T environment directly in the Power Apps Maker Portal (as of now), you can hack the URL to get access to this full maker UI. So, as you’re adding all the required connections, grab the environment GUID from the address bar in one of the aforementioned tabs. Use that GUID to replace the zeros in the following URL:

    https://make.preview.powerapps.com/environments/00000000-0000-0000-0000-000000000000/home

    Now you have a proper Power Apps browser tab that’s independent from Teams yet lets you browse through the environment’s components. For instance, we can go and check the solution history view, to verify that the Center of Excellence Core Components solution imported successfully in 3 minutes 10 seconds:

    Hmm, but why can’t I see anything yet on the Power Apps Teams UI? Even if I click “See all” then I only see that one dummy app I added earlier, to get the DV4T environment provisioned.

    The secret is in you choice of tabs within the Power Apps app. Specifically, instead of the “built by this team” tab you need to have a look at the “installed apps” tab. Ah! So, it looks like the managed solutions that you import into a DV4T environment are actually treated like Teams apps here – rather than just a list of components like we know them from the XRM era.

    In fact, while we can import solutions into DV4T, the whole concept of a solution package isn’t actually visible when viewing the world from a Microsoft Teams perspective. Also during the import process, we’re importing “a managed application” rather than a managed solution. Make of that what you will.

    By using the full Power Apps Maker portal we have access to not just individual solutions in the DV4T environment but all the components when accessing them via the Default Solution. For example, managing things like Environment Variables can easily be achieved here:

    Let’s get everything configured and move into the CoE core components deployment step that’s common to all environments: sync template flows activation. This will populate the tables in our CoE Dataverse environment with information about environments (how recursive…), apps, flows, makers and so on:

    Once the data is in, we can admire it via the Power Platform Admin View app. Oh, but wasn’t that a Model-driven app? And Dataverse for Teams doesn’t currently have support for those, right?

    Luckily there’s a new Canvas version of the Admin View available instead. Compared to the full Model-driven version, it’s… Well, how should I say this? “You get what you pay for.” Still, it gives a UI for browsing and editing the contents of your CoE environment’s tables. For those admins with little or no exposure to all goodies that the Model-driven apps and Dynamics 365 products offer, this may be perfectly sufficient for basic data management needs.

    How about the Power BI dashboard then? That has always been a nice tool in the CoE Starter Kit to demonstrate the wealth of different elements and data points of the platform. The good news is, the same version that’s used for the full Dataverse based CoE deployments is applicable also to CoE in Dataverse for Teams. The one trick you need to know, though, is how to find the Org URL for DV4T:

    Paste the instance URL without “https://” and trailing “/” into the parameter field when configuring the Power BI dashboard for CoE. Import the .pbix into a new workspace, create a Power BI app from it and publish it to the end users. After pinning it into a Teams channel tab, we now have a lot more visual method for exploring the apps, flows and other elements in our tenant’s Power Platform environments:

    There’s of course plenty of other useful apps in the CoE Starter Kit, both in the Core Components solution and further packages. In fact, when you look at the comparison table of what’s supported in Microsoft Dataverse vs. Dataverse for Teams, the differences boil down to the lack of a Model-driven admin app.

    Conclusions

    Despite of some of the new hoops you need to jump through to work with the simplified maker UI within Teams, the installation process of the Center of Excellence Starter Kit works pretty well in this deployment option, too. I’m actually surprised how well the CoE team has managed to “retrofit” the earlier solutions to work within the limits of DV4T.

    This highlights an important question which I’m sure many people in the Power Platform community have been wondering about: how far will Dataverse for Teams actually go? Sure, if we analyze the detailed feature comparison between Dataverse editions, it’s easy to identify limitations in existing business applications that wouldn’t really fit within the Teams edition. At least yet.

    While I don’t believe we’ll see the full feature set of Microsoft Dataverse unlocked for usage with Teams licenses alone, I also don’t think it’s going to be severely handicapped – intentionally at least. There’s a lot for MS to gain in pursuing the Teams as a platform story when competing against tools like Zoom or platforms like Salesforce + Slack. By attracting as many app makers and users onto the platform and then upselling them on premium Power Apps & Power Automate licenses when things like 3rd party connectivity or enterprise data platform features are needed, the revenue stream can be pretty darn nice still.

    One final thing to keep in mind about CoE is that it’s actually a great showcase in itself of what Microsoft’s low-code tools can do. It’s built with the very same Power Platform tools that it is used for managing. All the APIs, automations, reports and apps use publicly available technology that the customers also could apply for their own scenarios. Put into a different business context, these are the kinds of big systems that could evolve on top of the platform over time, to guide pretty much any digital process.

  • Democratizing code

    Democratizing code

    Throughout my whole professional career, I’ve worked with technology that caters to information workers. Sometimes I’ve been the power user of these tools myself, then a manager responsible for defining the details how these systems should work. For the past decade I’ve been the guy who actually puts the technology pieces together to deliver that system.

    I have never written code in traditional programming languages for a customer project. Sure, I’ve done plenty of work that isn’t accomplished via point & click GUIs, but none of it resembles what the Wikipedia definition of computer programming says. In short: I don’t code.

    Every year it feels like I’m sinking deeper and deeper into the technology domain of Microsoft business applications, and at the same time it’s less & less likely that I’d start writing code for a living. The rise of low-code development platforms (LCDP / LCAP) like the Microsoft Power Platform means that there are more & more people like me out there. Citizen developers are taking over many application development tasks but they don’t do what traditional programmers used to do.

    The impact from this paradigm shift is potentially massive. Computer programming isn’t going away nor decreasing as a professional activity. However, application development as a task is being separated from the domain of programming. The output of what “code” used to create is therefore being democratized:

    Democratization of technology refers to the process by which access to technology rapidly continues to become more accessible to more people.

    Wikipedia: Democratization of technology

    In this article I want to write down a few observations and thoughts on this topic, which I’ll hopefully get to drill deeper into in future writings.

    From code-first to low-code

    Things have moved along surprisingly fast. Just three years ago there was a small debate in the Dynamics 365 community on whether all functional consultants should know how to write code. Neil Benson’s excellent article called “Three forbidden words: I don’t code” popped up in my Timehop stream a while ago to remind me about this. (I must stress that despite of the title, Neil actually argues against the need for every consultant in the project team to write code.)

    https://twitter.com/customery/status/981128432384962561

    Today in 2021, this whole question on whether every IT worker should invest time and effort in learning a “real” programming language felt to me like it must have been from a decade ago. To put things into perspective, we have to keep in mind that this original debate took place in 2018 , at a time when the fusion of Microsoft Dynamics 365 and PowerApps (the “no space” era) had just been announced. MS had only just begun the process of throwing BizApps consultants and citizen developers into the same pool of technology. It was a very different world still.

    Fast forward to 2021. If you look at what the Power Platform community has been debating about recently, I’ve seen a lot of concern from people with software development background & skills. “Isn’t Microsoft valuing coders anymore?” is a question that can rightfully be asked when looking at the common theme of marketing messaging coming from Redmond. It’s a stark difference to just 3 years ago for sure.

    Already earlier, many customers who have previously been burned by problematic CRM implementations full of custom code have begun expressing their preferences in subsequent projects. “Avoid code based extensions and leverage OoB configuration options wherever possible” has not been an uncommon requirement to hear from them.

    Now when Microsoft is advertising how powerful the low-code options can be, it’s going to be even harder to suggest code-first solutions to customers. At least you need a clear justification for why custom code is necessary. This can have unfortunate side effects, too, where the avoidance of coding leads to an even harder to maintain maze of configuration spaghetti. Different cooks, same dish.

    Excel is eating the world

    Power Fx has received a lot of attention based on only the initial announcement of what Microsoft plans to do with this new low-code programming language. I’ve previously analyzed the broader role of Power Fx as well as reflected on how Dynamics 365 professionals might approach it.

    I’m not so sure that it’s wise for MS to go out and shout to the world at this point that “Power Fx is the world’s most used programming language”. Also, I wouldn’t personally say that my Excel skills have gotten me that far in creating formulas for Power Apps Canvas apps. It takes a lot of tutorials and browsing through the formula reference to get into grips with Power Fx.

    Yet there are unquestionable benefits from using the “Think Excel” mantra as the backbone for developing this new programming language for the low-code era. Not just for sharing the same function names, but rather for ensuring the focus of Power Fx remains squarely on the power users that can make Excel sing. Not those wannabe programmers who eventually want to move from the safe sandbox of Power Fx into something without the training wheels. Of course one still might need to have the programmer’s mental model for producing complex apps with Power Fx regardless:

    We need to keep in mind that Power Fx is not aimed at the audience who writes code for a living. Microsoft is not expecting that developers with skills in other programming languages would switch over to Power Fx. Rather the purpose of (eventually) open sourcing the details of the language implementation would appear to be in enabling other parties outside Microsoft to adopt Power Fx for their products.

    Despite the ubiquitous role of Excel in the business world, we should not assume this spreadsheet software to be the only place where future app developer generations will gain their experience from. Gaming platforms like Minecraft or Roblox with their big focus on user generated content could be considered equally important sources from where the inspiration to become a digital maker is first put into the mind of an individual.

    After all, being a guru in Excel formulas isn’t perhaps the strongest indicator of being a potential business app maker. The no-code generation is less likely to dive deep on a single tool, rather they are fearless in combining new services together on the fly to reach the outcome that they need. Separating this ability to grasp new technical tools from the ability to write algorithms in traditional software code is perhaps where the true democratization will take place.

    Professionals vs. Citizens

    The terms we use for grouping people into different teams in the current articles that cover the phenomena of low-code and business applications are somewhat problematic. On one side we have the “classic” developers under the banner that says Professional Developers, while the other crowd represents the “modern” way of creating apps and has been given the Citizen Developers banner.

    “And now, ladies & gentlemen, LET’S GET READY TO RUMBLE!!!!”

    That is exactly how we should NOT depict the situation. There are no winners and losers in this game. We haven’t invented a silver bullet that solves all business problems. There’s no eternal glory to be found from being “all code” or “no code” in everything you build. Yet it’s obvious that we’re not talking about a homogeneous group of developers here. Some of the platforms and tools used may be shared across, but the roles remain distinct.

    The amount of low-code business applications that organizations of all sizes in every industry will soon have in their hands means that we’ll see a growing number of employees working 100% on these. If low-code becomes your full-time job, you’re not just a citizen or a hobbyist. You’re a professional working with advanced technologies and complex processes. The only thing that separates you from the “classic” definition of a Professional Developer is that you don’t write much code (aside from things like Power Fx).

    Microsoft seems to have already reduced their use of the Citizen Developer term. This doesn’t necessarily mean that it would not continue to exist in the discussion, as the idea of anyone being empowered to create apps still is a powerful way to get the message across. It’s more likely that the terms used to describe the different roles within the “fusion teams” that deliver Power Platform based solutions will need to be adjusted.

    When a business professional starts handling more and more technical tasks in the app delivery process, I don’t think this makes him/her a Pro Dev nor a Citizen Dev. It is the area in which I personally operate and yet I can put a label on it. Luckily it doesn’t make my work any less valuable. I’ve always lived as the secret agent between business & IT, so I can easily remain to be that mysterious Agent X. As the army of these agents grows, though, they’ll become a lot less secret with their presence within organizations.

    Are they simply “Makers”? Time will tell.

    Where democratization may lead us

    I think what’s happening today with software resembles something that has previously happened with media. Two decades ago we saw the Web 2.0 phenomenon that moved the online world forward from a static web towards a social web. The elements and the actors aren’t all that different from what the move from code-first to low-code apps is dealing with.

    Content creation exploded when the ordinary people (citizens) were given tools and channels to shift from just being content consumers to the new role of content creators and publishers. That was a huge transfer of power. For me personally, my decision to start this blog back in 2008 and to become an active participant in the Twitter community around Microsoft business solutions have been far more powerful decisions than anything I’ve ever had the chance to make at my actual day job.

    If the traditional media was run by Professional Journalists then what emerged from the social web & social media revolution might as well be called Citizen Journalists. No longer was there any formal training nor editorial processes required for getting your content out there. It had a profound impact on our society as a whole, in both good and bad. The forming of new citizen driven communities around topics like business apps is a very mild example on that scale, but it’s where I’ve been able to observe the phenomenon in the closest possible detail.

    What happened with human communication in the Social Web revolution could very well happen with human-to-computer communication in the next uprising. On a high level, I can’t actually see that many differences between what WordPress did to words and what Power Platform aims to do to apps. Different context yet the same underlying dynamics of how the traditional top-down model is replaced with a bottom-up approach.

    One specific insight that could be drawn from this analogy between the social web and low-code movement is the ratio between different user roles in each. Even if anyone could technically start a blog these days, relatively few people have done it (and even fewer have managed to stick to it over the years). Most are merely content consumers, and some are active in commenting or sharing content.

    It’s very likely that we’ll see a similar distribution when it comes to low-code apps in the business world. Only a small share of those with access to the tools will ever become consistent app makers – and that’s perfectly fine. It’ll still be big enough figures to disrupt the traditional usage of code.

    Opportunities and threats of low-code

    Just like the rise of Facebook or Twitter didn’t solve every problem related to media, we aren’t going to reach the promised land of digital transformation merely through low-code application platforms. Many of the arguments heard from Professional Developers on why the actions of Citizen Developers will create a flood of new problems are in fact well founded concerns.

    Change management and version control don’t suddenly become a non-issue. Application lifecycle management (ALM) isn’t automatically taken care of. Architecture design and documentation can’t be skipped. Just by moving certain parts of the software development lifecycle from code based tools to graphical configuration tools and formulas like Power Fx we’re not magically making all the other parts irrelevant.

    Some of the problems encountered with traditional business application delivery will only be amplified by the low-code model. As the volume of apps grows, as we have more parties involved in their development process, as the backgrounds of these individuals will be more varied – we’ll run into scalability challenges for sure.

    This just highlights the need for new innovation. Reaching into the existing ProDev toolbox isn’t likely to be the answer – just like you couldn’t adopt the practices from a traditional media newsroom and apply those into social media platforms.

    Be it the creation of content or apps, any model of manual governance and control that relies on A) the creators to follow specific rules and policies, and B) human editors/gatekeepers to enforce them, isn’t going to scale very far. Algorithms must be put into use. AI needs to be given the opportunity to help us in everything that goes into developing and maintaining great business apps.

    Can’t put the genie back in the bottle

    It’s time to accept the fact that this thing won’t go away. What low-code represents is not any specific service or tool that today allows you to do A, B and C – but not yet D, let alone E. It’s all about the journey – how to move closer and closer to Z, one step at a time.

    Success is not defined by whether you would ever reach Z without writing a line of code. What low-code platforms aim to do instead is to keep grabbing the low hanging fruits of app development, one by one. Focusing solely on the “what’s missing compared to code-first” aspect is therefore not very beneficial in understanding the actual value that has been derived from different generations of low-code solutions, be it RAD tools or application platforms like XRM.

    Sure, there aren’t many new apps being built on top of MS Access or Lotus Notes anymore (hopefully). Does that prove it was a bad idea to build any of them in the first place? Of course it doesn’t. These tools may have only been good at A or B back in their days, yet there was significant business value to be gained for getting the crude apps out there to the users who needed to manage digital information via them. Besides, even if you built a “proper” app via custom code in the golden era of Access or Notes, you would have likely needed to re-build that solution a few times anyway to stay relevant with modern client technology and new business requirements.

    The evolution of software keeps pushing us towards higher levels of abstraction. It would be strange to think that the direction could ever turn and we’d see a large scale return to artisan software being carefully crafted by coding every line by hand, reducing the use of libraries and APIs that offer shortcuts to those soulless programmers that just want to meet customer requirements quick & easy.

    Early days still

    I’ve had a great opportunity to dive deeper into the concept of low-code during the past year, ever since we founded a company that focuses 100% on Microsoft Power Platform based solutions. One key insights from all my investigation work has been that we’re not yet very close in finding common ground on what low-code actually means. Neither the vendors, tech media, consultants nor customers seem to have a clear understanding on where to position low-code in the greater IT scheme.

    Academic research on topics like end-user development (EUD) / end-user programming (EUP) seems to have mostly stopped almost 10 years ago already – before the invention of the term “low-code”. One study from December 2019 specifically calls out the lack of recent research activity “There are very few publications related to low-code aspects and they are from the last two years, demonstrating its emerging trend.”

    Since it currently appears to be mostly the vendors like Microsoft, OutSystems or Mendix who are pushing forward their agenda, with help from analysts like Forrester in building up the hype, it’s hard to know what percentage of the low-code and citizen developer stories out there are based on facts. Sure, projections like these make it sound like it’s already an amazing success story:

    • Gartner forecasts worldwide low-code development technologies market to grow 23% in 2021.
    • Forrester analysts estimate 75% of all enterprise software will be built with low-code technology this coming year 2021.

    It must be great for anyone investing in low-code to be able to present such growth percentages, to prove they’re betting on a winning horse. Still, I feel like we’re only starting to write the greater story behind all this exciting technology. Democratizing the tools through which our digital world is built one app or one automation at a time – that’s gonna be a bigger deal than just the amount of VC money being pumped into no-code/low-code startups.

    At the end, it’s not even about which tools and platforms will win. Looking at both the investments as well as progress made by Microsoft into/with Power Platform, I have very little doubt that they will be taking low-code into mainstream for real. What’s the truly interesting part is thinking about all the ways in which this may change the business user behaviour, the role of IT departments, the market dynamics for professional services – basically everything around the low-code platforms.

    If that’s something you’re also interested in talking about in more detail, perhaps you’d want to reach out to us at Forward Forever. Or if you feel like there’s something I’m missing in the above thoughts around the democratization of code, I’d sure appreaciate any comments in the box below.

  • How Microsoft Teams can scale up low-code: my 5 min explanation

    How Microsoft Teams can scale up low-code: my 5 min explanation

    At the virtual Microsoft Ignite 2020 event I had chance to join many fellow Finns in our FIgnite session and spend 5 minutes on highlighting a topic that I considered to be important in the MS ecosystem right now. It turned out to be an easy choice to make.

    Project Oakdale (briefly known as Dataflex) is bringing the low-code/no-code functionality from Power Platform into the hands of pretty much all the information workers leveraging Microsoft 365 tools in their day-to-day job. This is not so much about any single technical feature as it is a change in mindset about who the app makers should be. So, I set out to explain this my 5 minute presentation titled How Power Platform Now Empowers All Teams Users.

    https://www.youtube.com/watch?v=Dj_IH4yq1dE

    This is all part of the larger Microsoft Teams as a platform story that I covered in my previous pre-Ignite blog post. It’s no surprise that MS has created much more content around this topic than you could have ever expected to see on Power Apps or Power Automate as independent technologies. It’s a sign of the size of the audience to which this “no cliffs” application platform message is now targeted at.

    Will the inclusion of “CDS Lite” in the Microsoft Teams subscriptions prove to be a gateway drug that makes Common Data Service a household name in Microsoft 365 customer organizations? And if so, what will the actual brand name be for Project Oakdale once wre’re past the preview phase? Time will tell!

  • Microsoft Teams as a platform

    Microsoft Teams as a platform

    2020 became the year of #WFH (work from home) and for many organizations also the turning point when Microsoft Teams became the primary place where being “at work” happens. This is accelerating the evolution of Teams from being merely a communication tool that connects human beings into a foundational service layer for many types of business applications.

    How the concept of Teams as a platform contrasts with Microsoft’s Power Platform suite of technology is something I’ve been thinking about a lot lately. In this post I’ll first reflect on the relatively short history of where Teams came from. I’ll then examine how the recent feature announcements are brining apps front & center in Teams. Finally, a few words on the possible future for Teams as part of Microsoft’s broader strategy.

    The road that lead to Teams

    Looking back ~10 years, the real-time communication & instant messaging tools from MS seemed to be going through an endless renaming cycle: from OCS to Lync to Skype for Business. The core feature set presented to the end user didn’t seem to evolve nearly as much as product branding did. On a broader level, the communication activities of information workers within an organization still typically took place within Outlook’s inbox, and different servers like SharePoint and Dynamics CRM all packed their own features for posting short messages to other users.

    4 years ago, when the first images of what was then called “Skype Teams” started to leak out, we were already waiting for MS to create something a bit more ambitious than just another online meeting tool. Office Groups had began to emerge in various different places inside the MS Cloud, but they were primarily a technical construct with no sensible UX for everyday people to approach them. Even Dynamics CRM had it’s own solution that attempted to bring together the dicussion, calendars, notes, documents and team memberships from under an Office 365 Group associated with a record like account or opportunity:

    I remember having many discussions with our CRM customers where I attempted to steer people away from deploying this Groups solution. Instead I wanted to encourage them to wait for something a bit more polished that I knew had to be on it’s way sooner or later.

    At one point there was a clear & present danger of another “Yammer moment” taking place, as Microsoft was reportedly quite serious about their plans to acquire Slack. In retrospect it was a blessing for both parties that MS decided to keep investing in building their own product, instead of trying to retrofit an established service like Slack into their existing software offering.

    I would argue that this “build over buy” strategy which Microsoft has since then followed across their business software stack has been a key success factor for BizApps in particular. It has enabled MS to move from merely chasing CRM competitors like Salesforce into redefining the business apps playing field with Power Platform. There’s a stark difference between acquiring companies and bundling them as “X Cloud” versus engineering your own software stack to act as a true platform.

    Teams: the collaboration chapter

    Initially the first version of the Microsoft Teams product that became generally available in Spring 2017 was pretty much focused on being three things:

    1. Replacement for Skype for Business
    2. Alternative to Slack
    3. UI layer for Office 365 Groups

    From a business applications perspective there wasn’t all that much you could do to hook Teams up with Dynamics 365, until Fall 2018 when the previews for the first integrated features were launched. In particular the integrated file sharing experience that Teams offered seemed almost like the Holy Grail for many CRM professionals, offering to fix the glaring hole in the SharePoint integration story that lacked any security model synchronization. The roadmap image below presents the plans from 2 years ago on how Teams and Dynamics 365 were going to be integrated:

    The last item on the roadmap has still not been delivered, which is the visibility of Teams conversations inside the Dynamics 365 record form. Why this hasn’t been a higher priority for MS to implement seems to me like a sign of how Microsoft Teams is nowadays positioned as the primary UI for all information work. MS probably would prefer if everything always started from inside Teams. You pin record tabs into channels, you show previews of records inside teams discussions, you interact with records via bot interfaces and so on. As long as Teams is that big umbrella under which all work takes place.

    The lack of a deep 2-way integration does not therefore mean that investments aren’t being made into the products involved. It can simply be a reflection of the new vision that is being built, by aligning many existing services to form a whole that aims to be greater than the sum of its parts.

    As an example, if you look at Microsoft’s task management story, you’ll see that features and data from across various apps like To Do, Planner and Outlook tasks / flagged emails are currently being collapsed into a central location that is the Tasks app for Teams. Tasks as a generic construct don’t necessarily need to be fully controlled by a single database, yet they very much need to be logically represented within “the hub for teamwork” that Teams is positioned as.

    Going forward, when new apps appear into the MS cloud product portfolio and they need to offer task management features to users, the logical integration point to focus on would be Teams. For activity feed type of functionality the choice is even more clear for product development: choose to piggyback on Teams instead of inventing yet another stream of short messages.

    Teams: the platform chapter

    Moving beyond simply integrating Teams with products X, Y and Z, we’re now seeing the rise of a model where apps are built specifically to be used in Teams. This has of course been possible for a long time already, by developing custom web services and using the SDKs. Now there are many features coming up that will amplify the platform story around Teams on the no-code/low-code front specifically.

    lists in teams1.png

    Microsoft Lists app has been the first to reach GA and offers an ultra low barrier for users to process data in a single table through a configurable, readymade UI. When accessed via Teams, the list data gains one more special dimension: discussions to be had regarding a list item. This is pretty much the same as the usage pattern offered for a Dynamics 365 record with the integration mentioned earlier.

    Underneath the new covers of MS Lists is the technology familiar from SharePoint lists. If we were to only examine the UI layer, there is actually a remarkable similarity to a popular no-code service called Airtable. So much that the accusations of MS simply copying the visuals and core features from this competitor don’t seem entirely unjustified.

    Comparing these two offerings gives us some perspective on what exactly is the market position these tools are aiming to conquer. Simple lists themselves are not a particularly unique feature, rather it’s the team collaboration capabilities and ease of data sharing that turns these tables into what you’d call an actual app. Incidentally, just this week Airtable announced they were building a full platform with apps offering JavaScript based extensibility, a marketplace for sharing apps, automations for executing business logic, and finally a sync service to transfer data across environments (“bases”).

    Collaboration scenarios around semi-structured data like lists and Excel style tables can be seen as a gateway drug. They allow turning email or paper based manual processes into a quick first draft of what the digital process could be like. If there are indeed clear business benefits in automating the said process, the requirements for more complex app features will soon begin to emerge from the user base. Hence the collaboration platform should offer an obvious path to grow these pre-built app experiences into more advanced no-code/low-code apps.

    Project Oakdale a.k.a bringing CDS to Teams

    If Microsoft Lists is the equivalent of an Excel table within the Teams context, then Project Oakdale / “CDS Lite” could be though of as bringing SQL Server inside Teams. Now, obviously Microsoft has zero intent on actually replacing Excel nor SQL with features built into Teams. They only need to introduce those parts that make sense from a team collabocation perspective.

    Microsoft Lists is a far cry from what a real Excel workbook can do, yet it can offer much more value in a collaboration scenarios that those lone .xlsx files ever could. Similarly, the version of CDS that will very soon be available for building Power Apps within Teams is nowhere near as powerful as the services powering enterprise CRM systems like Dynamics 365 (or the raw power offered by SQL). Still, the fact that it can be found from within every team and used by a much larger audience than what Power Apps citizen developer tools could hope to capture – those are the factors that can truly make CDS a mainstream service that most information workers in the Microsoft 365 cloud interact it.

    The experience of defining the CDS data model in Project Oakdale will be very different from the path that Power Apps makers have gone through – let alone the XRM veterans. In fact, you could easily mistake the table design and row entry UX to be that of Microsoft Lists rather than CDS. This highlights a key aspect that not all Power Platform experts may yet have grasped: for MS this “CDS Lite” is not so much about deciding what premium features of the full Power Platform to give away for free to Teams subscibers – rather it’s about how to best simplify the enterprise CRM features of CDS into a new product that Teams users could adopt on their own.

    This doesn’t mean that Microsoft Teams should be viewed only as a mechanism for MS to scale Power Platform to the masses, by “dumbing it down”. If the app platform story of Teams plays out like it ought to, there should also be clear benefits from it to enterprise business applications development.

    Capabilities like messaging, notifications, task management, documents or group memberships are not something the Power Platform tools are very good at. For historical reasons there has been the need to build standalone features into XRM for these type of common requirements found in business application scenarios. For the future generations of apps being created, it’s easy to see the benefits of having these non-core capabilities offloaded onto a platform more suitable for managing them – meaning Teams.

    It doesn’t really even matter if the feature set offered by Teams couldn’t cover all the deep business logic integration of native Dynamics 365 functionality. Ultimately it’s not about supporting the system-of-record legacy but rather encouraging the new low-code scenarios that will generate 100x more apps onto the platform.

    Teams is the new Windows?

    The concept of an operating system is something many of us may relate back to the origins of the Personal Computer era, even if OS’s of course have existed far longer than the IBM PC. Windows was the first runaway success in the OS space when it comes to both awareness and commercial results, shaping the fate of Microsoft for roughly three decades. Then along came the era of mobile computing and Android & iOS took over in the number of devices running them. MS could no longer hope to regain that position so they decided to take over a different layer in the computing space: the (business) app cloud.

    Azure has been called “the world’s computer” and this does offer some perspective on how the computing concept has evolved since the PC days. Still, Azure is not something most people will ever interact with directly. To remain relevant in the decades to come, MS needs to have presence in the minds of the end users, too. Now that Windows has become merely an optional part of the modern computing stack, it would be pretty darn critical to gain a strong enough foothold on a level that’s above the traditional OS but still below the individual apps. A platform that spans across all the devices people in the business world are using.

    Teams is now the closest thing that Microsoft has at its disposal to transform into an OS style fabric that connects a significant share of information workers globally. Nothing like the glory days of Windows, of course, but we should expect to see very conscious steps from MS to further the goal of Teams becoming more OS like. The place where the user interacts with a multitude of apps, share their work context with those apps, a “service bus” for the various apps to exchange data with one another, and finally a unified communications channel for notifications and messaging.

    It’s still a long, long way to go for this type of shift to happen where the collaboration tools become the true center of gravity for the multitude of other apps and services that people use today in their #WFH offices. Personally, I can’t live with the limitations on multitasking that the MS Teams content embeds enforce upon the user and much prefer a collection of separate browser tabs to freely switch between. Nevertheless, it’s not an entirely crazy though that the resulting congnitive load for the user isn’t everyone’s ideal way of working. Which means organizations need to be looking for ways to optimize the employee experience via common information work hubs like Teams.

    Dion Hinchcliffe has written an excellent analysis on Microsoft’s platform strategy with Teams, where he talks about seeing Teams as the operating system for work. While it may indeed be difficult to get the current owners of the collaboration tools in customer organizations to accept the business app side of Teams onto their plate (especially now with the #WFH boom and its unexpected requirements), the perspectives may change when the time is right from both the technical capabilities side as well as the organizational targets. In the same way as the MS CRM foundation evolved into a key element of the broader low-code application platform known today as Power Platform, the barriers between collaboration tools and business apps should not be perceived to be carved in stone.

  • 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.