LLMs are getting pretty slick at generating working code for your apps. Surely they can handle mundane tasks such as troubleshooting device drivers on your PC. That’s what I thought before I spent six hours trying to push Claude Code CLI to fix a Bluetooth connectivity issue on my old Dell XPS 13 running Linux Mint.
I have used coding agents for both configuring and troubleshooting my Windows PC and Ubuntu servers for a while now. Before that, I was doing it like regular folks would – meaning asking ChatGPT for instructions and then copy-pasting a bunch of scripts into the terminal window. That got tiring pretty fast and I decided to grant the LLMs direct access to my computers. “This is fine.🐶🔥”
Since language models like Claude Opus 4.6 are doing a great job inside VS Code for my Power Platform and vibe coding projects, I’ve felt confident enough to let them modify not just code but also device configuration. Most of the time, I am able to achieve things that would not be possible without AI due to how much human effort would be required. Such as checking and documenting the system configuration before and after a Windows Update.
When Microsoft decided not to provide an official Windows 11 update for my Dell XPS 13 from 2015 anymore, I decided to erase Windows from that device and deploy Linux Mint instead. The OS works just fine with the aging hardware and I get to keep the laptop around for goofy side projects.
Some things in the hardware land do show their age, though. The keyboard is really “sticky” and the once great trackpad is hit or miss. I did casually explore the options for getting a replacement for the built-in parts but I figured opening the laptop and trying to get my fat fingers to follow the YouTube instructions wasn’t worth the time nor the cost of the required spare parts.
So, I decided to take the easy way out and just find a small keyboard I can place on top of the device and keep using its still glorious QHD+ screen with touch support. I found a cheap Fuj:tech BT keyboard in the outlet corner of Verkkokauppa.com for €12 (45% off!) and thought that it’s gonna be perfectly fine for the occasional side projects.
No Linux support mentioned on the box, but hey: “No worries! I’ve got the all-powerful AI to guide me through whatever driver issues I may encounter.” This €12 device turned out to be by far the most expensive keyboard I’d ever bought, considering the time I spent trying to get it to work.
The issue wasn’t that Linux Mint plus the XPS 13 wouldn’t have supported Bluetooth input devices. When connecting my Dell keyboard (the black one) from my main desktop PC to the XPS, it worked just fine. As for the €12 Fuj:tech keyboard, it connected – for one second. And then it disconnected. Again & again.
It was just the kind of thing that I believed Claude Code CLI could figure out on its own. Prompting it to read all about the device and its configuration, the AI assistant of course dived right in and started providing helpful troubleshooting tips. It went far deeper into the subject than I would have bothered, even if the price tag for the keyboard would have been 10x. As always, it was impressive how deeply the “thinking” models could research the problem once given a clear task. Far beyond human endurance.
It turned out Claude couldn’t access all the critical information for debugging, though. As the simple fixes were exhausted, more data was needed on what’s actually going on between the PC and the keyboard. BlueZ, the official Linux Bluetooth protocol stack that I had not ever needed to worry about before, offered tools like btmon to capture the Bluetooth traffic. The data was there in one terminal, but Claude didn’t have the tooling necessary to read the output from that stream of events. The human operator had to do that part.
Now I had turned into the assistant for the AI. “Enter this command in the terminal, then immediately after you put the BT keyboard in pairing mode, run this command and watch the btmon output for this and that…” It wasn’t at all how I had envisioned the troubleshooting session to go. Since I had given Claude the task to get this thing working, though, I felt I needed to support that smart lil’ guy in finding the solution.
When I got tired of this and told Claude I can’t do the thing anymore, it came up with plan B. Which of course was about doing what LLMs are great at: writing Python scripts. If human reflexes were the limiting factor of what the LLM could see, then the solution would have to be a new piece of software that could capture the necessary input.
Working around the limitations of a cheap BT keyboard with just one device slot also meant a human was needed to perform the actions on the other devices. As the keyboard offered no reset button, me and Claude tried to get this procedure completed by pairing it with other devices. Windows 11 connected to the keyboard just fine, as did an Android phone (both officially supported OSes for the product). Could this solve the problem of a stale key in the Fuj:tech’s memory?
Of course it didn’t. Well, how about if we grab the key value from another device and inject it into Linux? Registry hacking with regedit and transporting the data back to the laptop: no luck. Okay, what if we would spoof the Linux adapter’s MAC to impersonate the Windows one? Nope, the Broadcom adapter on the Dell doesn’t support it.
And it went on and on. Me and Claude were playing digital detectives and performing the kind of activities that make you feel like you’re making progress. And in practice, we had just discovered twenty ways that didn’t work.
Have you ever experienced this with AI? Going deeper into the rabbit hole and the story just gets so intense that you can’t turn back anymore? Yes, that is exactly what leads smart people into thinking they can do “vibe physics” with a large language model. Heck, I’ve personally written about it in my newsletter and yet I was unable to pull myself out of this rabbit hole.
I was not trying to make new scientific discoveries with AI here. I simply wanted to skip figuring out what hardware combinations were a safe bet. I had very little knowledge of Linux, and still I knew perfectly well that a plug & play experience wasn’t as likely with devices when you venture outside the commercial mainstream operating systems.
But I trusted the convincing AI assitant. It had gotten me great results before, surely this compatibility issue could also be brute forced. Throw more tokens at the problem, not more money and time in doing things the non-AI way. I was now running Claude on both the Linux machine and in the cloud to ensure I could keep getting the best advice. Also, having half-functional keyboard with on-off BT connectivity due to debugging made typing on the Dell a hellish experience.
At some point, I of course realized that the ROI on this adventure is going to be negative regardless of the outcome. Claude isn’t dumb either. Within the first hour it said to me loud and clear: “you know, Jukka, this whole thing probably isn’t worth the effort, just take that cheap keyboard back and get a new one.” Did I listen? No, I was determined to see this thing through.
In the end, the problem did get solved. What was the magic piece of Python script that made this happen? There was none. It was simply me taking a USB Bluetooth dongle from my other PC and plugging it into the XPS 13. And just like that, the BT connectivity became stable. The built-in Broadcom BCM2045A0 chip just was too old/incompatible for this specific scenario, whereas a slightly newer BCM20702A0 in an ASUS BT-400 dongle worked. No AI magic required.
If it weren’t for the ubiquitous artificial intelligence now surrounding us in all the apps and devices we use, I probably would have figured out to test the USB dongle around five hours sooner. There’s no chance in hell I would have done proper research into common Linux Bluetooth connectivity issues and the available troubleshooting tools. The barrier is high enough for someone who’s been on Windows for 30 years now.
In my day job as someone who works with Microsoft Power Platform tools and solutions, I am one of the most vocal AI skeptics in this ecosystem. Especially with any built-in Copilot features. In my weekly newsletter I mock the state of AI features mercilessly and try to demonstrate how most of the value in this technology still comes from the core platform features and the expert knowledge on this niche. I see the gaps between marketing and reality so clearly because I truly am pretty damn good in the specific domain of MS business apps.
When I step outside this bubble, I lack that protective expertise. I am aware of the rabbit hole effect that LLMs as the greatest bullshit machines ever built are likely to trigger in the user. At the same time, I must acknowledge I can now go much further and faster with these tools when encountering problems and tasks that are outside my comfort zone. I’d hate to work without this capability.
What I try to always do, though, is to pay attention to failure and talk about it. The online world is full of excitement around whatever vibe-coded tools someone was able to create by one-shotting the latest AI models. The Claude Code moment of 2025 is only now spreading into the wider information worker population and we’ll see even more incredible stories about where an LLM succeeded. We should celebrate both success and failure, just like all the startup gospel and innovation coaching tells us. If AI is now a normal part of business, the same rules must apply to how we treat it.
I tend to ask my AI assistants to write postmortems when we come across a failure worth remembering. In this case, the analysis centered around the issue of observation bandwidth. What seemed like a fitting use case for LLMs (search details about the complicated but finite Bluetooth spec) turned into a wild debugging goose chase because the results could not be validated. Hardware debugging is very different from software development in terms of how AI can close the loop via testing the code.
In Claude’s own generated words, here’s what was “genuinely hard” for it:
The feedback loop is the fundamental constraint. Every hypothesis required: copy a command, paste it into a terminal, run it, read the output, type or paste it back. That round-trip introduced real friction — commands broke across lines, shell escaping failed, btmon output got truncated. Debugging through a keyhole. A human expert sitting at the machine would have caught the btmgmt -i flag anomaly in ten seconds by just running btmgmt info twice. It took multiple frustrating iterations.
Related: no ability to observe state changes. When the keyboard was in its connect/disconnect loop, what was needed was to watch btmon live, see the exact frame sequence, and react. Instead: filtered snapshots. The capture script helped, but it’s a workaround for a fundamental limitation.
The multi-session memory loss also cost real time. The MITM/Numeric Comparison theory that dominated the early sessions was wrong — the errors were from a stale LTK — but it took a full re-diagnosis in a later session to establish that, partly because the reasoning that led to the wrong theory had been summarised away.
Fair points, my AI buddy. Some of these limitations may well get solved in future tools, just like the arrival of CLI-based AI tools clearly pushed the boundaries much further. In the end, this is a domain where it should be far easier to close the loop with technology than in most of the scenarios advertised for autonomous AI agents in the messy world outside the computer.
Claude and I fail together, and we succeed together. As of today, only one of us can learn from this and adjust our actions accordingly.
This text was written by a human being, not AI – even if some of the images are AI generated.
Adding such a disclaimer would have sounded ridiculous only a few months ago. Today, many of us are starting to be rightfully sceptical towards online content we come across that touches upon any current hot topic. Is it organic or at least partially machine produced?
LLMs, large language models, struck earth like a meteorite in the end of 2022 and made some of us question what we really understand about the current capabilities of computers. If you’ve logged in to ChatGPT or signed up for the New Bing version now running on top of OpenAI’s GPT-4 model, you will have certainly experienced a “WTF?!?” moment or a few when seeing the kind of answers they can come up with.
In this blog post I’ll reflect on the experiences I’ve had with this latest wave of AI capabilities and how I think they potentially will change the business I operate in. Meaning low-code application platforms (LCAP) and in my case the Microsoft stack of tools.
Why didn’t we see this coming?
When discussing the AI phenomenon over a pint of craft beer with a colleague of mine a couple of weeks ago, he asked a great question: “why didn’t anyone see this recent AI wave coming?” Indeed, how can people in the tech industry be so surprised about what took place in 2022 on the AI front? Where’s the catch? Is this real or just momentarily hype that will fade away once the next hot topic comes along and takes over our LinkedIn feeds – in the same vein as web3, crypto, metaverse etc.?
One of my all time favorite phrases is “first gradually, then suddenly”. It applies to pretty much any disruptive change that the world of technology and business encounters. Things like AI don’t just emerge one day and immediately start wrecking havoc. Instead they remain in the “bubbling under” stage for quite some time, then they suddenly erupt.
ChatGPT has been called the iPhone moment of AI. If we think about the technology that Apple put together to create the original iPhone as a product, key elements like touch screens or downloadable apps were all introduced many years before by the biggest player in the phone business (Nokia). It was not the existence of these technical capabilities that created the perfect storm. It was the way in which they were delivered to the market as a product that made people think: “wow!”
Creating a web service like chat.openai.com and just casually making it available to the whole world on one day was completely different from having the GPT family of LLM published via the traditional APIs and researcher/developer focused forums. Unlike the iPhone as a physical product, no one needed to purchase anything or make a switch/commitment to experience the potential of generative AI. That’s how you grab the attention of the world in these always-on always-connected days.
Even alpha geeks like Bill Gates didn’t believe it was going to happen this fast. Tech giants like Google had been sitting on much of the technology needed for building what became ChatGPT, yet they lacked the financial incentive to proceed with it. As a result, in 2023 I’m now using “just Bing it” in a non-ironic way. One year ago I would have given a below 0.1% chance for this being the year of Bing – and today it already clearly is such. Google has access to all the necessary tech to grab the lead, yet the dynamics of their business model (targeting search based ads) is a force very similar to that which took Nokia under once phones became computers. Google, like probably also Nokia, became a victim of their delusions of excellence.
So, about the original question. No one saw this coming because that’s how disruption always happens. Which leads us to the next topic:
OMG, they’re coming after us now!
In the IT consulting business we’re accustomed to the endless talk about change. Everyone wants to change the way how people use technology, and many are surely fantasizing about being able to disrupt existing business models. Very rarely, if ever, do us tech people see ourselves as the target of such disruption. Until now, that is.
What the recently discovered capabilities of LLM based AI systems have shown already is that a very, very significant share of what us knowledge workers spend our days doing while at work can be handled by computers. It should be a wake-up call to all of us: we have been wasting our wetware brain cycles for reading and writing things that generative AI should be processing instead.
Shouldn’t we be happy about AI coming and promising to handle the mundane parts of the consulting business that we didn’t really enjoy all that much anyway? While everyone sort of cheers for the virtual assistant that can process our emails, summarize data, generate reports, (very shortly) do basic interactions with CRUD based systems – some might notice that this also sounds like an existential threat. Even Bing knows it:
Ah. AI skills and bioweapons nicely coexisting in one answer from a service that used to be just a dumb internet search engine a few months ago. Nothing to see here, folks! Move along!
When I first started to explore this recent leap in AI’s capabilities, I was introduced to Moravec’s paradox. It states that high-level reasoning requires very little computation, while low-level sensorimotor skills require enormous computational resources. In short what this means is: replacing the driver in a car will require a huge amount of computing resources, whereas replacing the office worker sitting next to a computer all day is almost trivial in comparison.
This is not what most of us have been taught about how technical advancements replace human workers with digital tools. Yet it makes perfect sense when you think about it. The natural selection of evolution has had billions of years to develop the skills we use for observing and operating inside a physical space. Email has existed for only 54 years. We are all really just helpless babies when it comes to processing data, yet we are quite advanced in our abilities needed when diving through the busy streets of a city full of physical objects / actors.
The arrival of year 2022 level AI skills in the form of LLM was the first time many of us ever needed to take a look in the mirror and say:
We used to be the ones disrupting the working life of others. Now we are gradually joining the ranks of disruptees. No, I still don’t regret one bit that I chose to pursue a career in the cross section of business and IT. This is a much better position to be in when thinking about what lies ahead and who’s got the possibilities of participating in building something new and exciting.
Things have always evolved and we’ve seen technological leaps before. I just can’t help thinking that the world in which I grew up to understand what IT is about will now seem incomprehensible to the new generations who’ve yet to discover it.
Backward never
As a child, the first time I got the chance to physically interact with a computer was the ABC 80 that my dad bought. Serious computers seemed very complex to use, yet at that time I was young enough to entertain myself simply by typing on the keyboard and pretending to use the computer. Fake it till you make it, right?
Photo by Frédéric BISSON: Pacman on Atari 800XL at RetroGaming Days IV
When I got my first personal computer for myself, the Atari 800XL, it supported loading games from a cartridge that you just plugged in. That was the “instant gratification path” of using a computer. I did also start reading the magazines of the time and even typed in a few of the Basic games, transforming the code that was printed on the paper into bits that I typed in via the keyboard. It was interesting, yet it always felt too hard to achieve some tangible results. Code didn’t provide me a way to express myself. It wasn’t until I started creating music on the early PC tracker software that I saw computers as a tool for creativity.
My kid is now 3 years old. As he’s getting exposed to how technology is used in our daily lives, I’m pretty sure he’ll never see computers as “hard to use”. Now as the natural language interaction pattern will presumably quickly take over most casual usage of smart devices, the concepts of programming or code may remain very distant to him. He’s already happily giving Google Assistant voice commands via a smart speaker in our living room. Why wouldn’t it work for everything by the time he’s old enough to start creating things with computers on his own?
It goes far beyond the difference between punching keys vs. shouting commands. As of today, Google Assistant is a complete moron compared to ChatGPT. It won’t be that way for long, though. The idea of a computer that understands what you want to achieve without it having been programmed to fulfill that specific request is a shift so profound that such AI capabilities will be infused in every possible smart device. Because otherwise calling them “smart” with the 2021 level of skills would just get the vendors laughed out of our homes and businesses.
Soon, no one will be given the opportunity to claim that they don’t know how to use computers. There may not be a single visible computer around, but everything around you will be processing data and adjusting itself to the sensors inputs. That’s likely the world in which our children will grow up in, regardless of what we as parents would do. Life without ubiquitous AI may soon be like trying to live without electricity.
And now to Power Platform.
Everyone as a developer
The idea of how the low-code Power tools could eventually democratize the creation of applications is something very close to my heart. The products were introduced roughly a decade ago now. At around 2018 I started talking about the crazy idea of how in the future creating apps would be as commonplace as creating documents already was. I used it as a way to get my point across when talking with colleagues, claiming “every PowerPoint should really be a PowerApp”. I wanted to challenge their traditional idea about apps being something big and expensive created by professionals, insisting that they could also be small, disposable things created by anyone with a computer.
MS has of course been talking about infusing AI into their product portfolio for a long time already. We’ve seen some neat little demos and product features introduced with what NLP (natural language processing) has been able to do, but in reality it hasn’t had almost any impact on the everyday life of the app/flow/report makers. Sure, AI Builder as a citizen friendly entry point into the world of Azure Cognitive Services has seen some real-life usage, yet it has hardly been a mainstream tool for citizen developers.
The more powerful next generation AI features have first landed on the pro-code side, under the GitHub Copilot product. These stats from the announcement of the latest GPT-4 based Copilot X version give some indication about the adoption rate. It doesn’t sound like just a marketing gimmick anymore. A fair share of developers out there are probably at least considering taking it into everyday use for the process through which they produce their work output.
Those of us who come from outside the world of programming and spend our days working with something other than raw programming code could soon be facing the same question: should I let AI do a part of the work for me? As anyone with more extensive experience on Power Platform probably agrees, low-code does not mean low complexity. Working with data, business logic and UI can present quite a cognitive load, even if you are “just point’n’clicking” or writing Power Fx formulas instead of JavaScript or C#.
If anything, no-code/low-code should become the area in which safe usage of AI generated components would go mainstream a lot faster than in code generated without any productized guardrails around it. In the end it’s still all made of code and it all runs in the Microsoft cloud already (in the case of Power Platform). Training dedicated AI models to serve this well defined playground should be a very doable task for the platform provider. Of course the UX of how app makers interact with the generated results needs to be thought out, as direct manipulation of the generated code wouldn’t be quite ideal.
If business users will learn to leverage Microsoft 365 Copilot to generate documents for them, how far can we be from the stage where they are also comfortable generating apps and automations in the same way? I believe were are definitely moving into the direction where questioning the abilities of non-programmers to design and develop their own tools isn’t a valid generalization to make anymore. I honestly did not believe we’d get so close to the state of “hey Copilot, turn this PowerPoint into an interactive Power App” being a possible reality this soon.
This, in turn, will lead us to the question to think about: is this what the world really needs?
The NoApps future
In the end, people don’t need apps. In the same way as the record industry was formed around the concept of producing, promoting and selling physical items containing a representation of music created by the artists, our current business applications consulting industry is also focusing on the intermediate output. The actual value delivery is something we must never lose sight of. Else you may find yourself selling plastic discs when the world has decided to jump into streaming audio instead.
Quicker creation of apps will initially have plenty of demand I’m sure. Besides, it really is a cool demo that you could draw a form design with pen & paper and then have AI generate a digital app’lified version of it (both Microsoft and OpenAI have used this scenario). Yet it’s still just a static data capture form. How many forms can employees or consumers navigate through during their days before getting exhausted with the “there’s an app for everything” experience?
These UIs for standardized data capture and processing have been needed because our technology couldn’t previously work with anything more fuzzy. Well, we’ve now seen through ChatGPT that it most certainly could. Not only can the AI figure out what us humans mean, regardless of what language we type our text in. It can also figure things out from what anyone else out there in the world has written.
There’s an interesting demo / research preview of “just some guy” applying GPT-4 to instruct the web browser on what to do. Not just writing out the instructions but actually performing the steps. In the example provided in this TaxyAI project, while on the GitHub website, giving a prompt “protect the main branch” will trigger the AI to do research on what that means, where it should be clicking, and then completing the steps as an RPA style bot:
I’m not saying this is a tool that would go mainstream. Rather it serves in giving ideas on what the tech giants out there will be creating with their 1000x budgets. The Copilots of tomorrow will not just return a box filled with text that they generated. They’ll probably do the actual work for you, rather than just providing instructions.
Think about all the process documentation and ad-hoc instructions that has been created inside a medium size enterprise. It will never be realistic to turn each of them into dedicated apps and automations. Yet if we get an AI service that can read these instructions created in human language, turn that into actions for the computer, and then complete the chain of activities to move from the original process input to the final process output – that would be something.
The concept of “working out loud” by proactively sharing our observations of the world and our accumulated knowledge with the community of colleagues meeting on a digital platform has been a great productivity booster and a source of professional & personal growth for me. Today with ChatGPT or Bing we can gain further benefits by “thinking out loud” with the machine, providing it a sequence of dialogue like prompts. The natural evolution from this could lead towards a world that actually supports “working by thinking”:
“Hey Copilot, I spent €50 on a cab ride.”
“I can see that you’re in a city where you had previously agreed to visit for a customer project. I’ve grabbed the Uber receipt from your email, filled all the details into our corporate systems and the reimbursement has been deposited back to your bank account.”
Instead of this sounding like a scene from some flashy “World of Tomorrow” video created by IT companies to sell us boring & expensive tech of today by using a fictious scenario from the year 2060 or something – it doesn’t sound too far off anymore. An AI assistant that understands what we say we want & what others say we should do in order to get it is in theory here today already, in the form of LLM based chatbots.
We just need to plug it in.
Endless problems
Cue the soundtrack from The Terminator. This is exactly how you create Skynet, isn’t it?
“Defence network computers. New… powerful… hooked into everything, trusted to run it all. They say it got smart, a new order of intelligence”. “Skynet saw all humans as a threat; not just the ones on the other side” and “decided our fate in a microsecond: extermination”.
Michael Biehn as Kyle Reese in The Terminator (1984)
AI will introduce brand new problems for humanity. Some will be existential (“is there a place for us in the world after AGI arrives?”), others much more mundane. What I’m somewhat worried about is that we’ll be faced with them pretty much all at once in the greater scheme of things. Without the ability to identify what is a serious issue for the whole world, what is merely a speedbump on the road to innovation and business productivity, we’ll be mighty confused.
The number of things we could be worrying about when it comes to AI is overwhelming already today. Use this list as an example and pick one item if your bag of worries is looking empty:
Copyright issues of imitating/borrowing content from original makers without permission.
Tech monopolies growing even bigger and stronger than they are today.
LLM hallucinations making it impossible for us to know what’s right & wrong.
The internet & every media getting flooded with machine generated content.
Biased data in the training sets inflicting harm on how minorities get treated.
Next generation surveillance society á la Minority Report.
The challenge I see ahead is that AI may be unlike anything we have ever encountered before. Sci-fi literature and movies have attempted to provide at least some context to the phenomenon, enabling us regular human beings to talk about what’s happening around us by using references from popular culture. Yet where are the AI consultants that will help organizations of all shapes and sizes make sense of this? (I know: just open LinkedIn and everyone is an AI expert there these days. But anyway.)
The range of reactions to AI that we can expect to encounter when starting to talk about it as just regular technology consultants is probably going to be all over the place. Many organizations will have legitimate legal and compliance concerns that will cause them to choose the “better safe than sorry” approach and put things on hold. Elsewhere, the gains from initial experiments with LLM powered information systems may turn out to be so compelling that AI becomes the next Digital Transformation that must be sprinkled on top of everything the company does.
I suspect the divide between individuals will be even greater. Just like the low-code tools have enabled the new breed of app makers to stand out from the ranks of ordinary business people and create something few of their colleagues could have ever imagines, the same thing can happen with adoption of AI tools. One’s formal education nor professional background may not be the best criteria to identify those who’ll be able to apply this new technology into solving real life problems.
If anything, I suspect it will be even more likely that the domain experts, the citizens, will be able to set aside all those “this AI generated code is garbage compared to what a true professional developer could write” complaints and just focus on the end results from using that code instead.
Good enough is close enough
We’ve been taught to believe that the world of computing is very binary by nature: it’s either 0 or 1. Computers either behave in a logical, repeatable manner and deliver the exact result they have been instructed to – or they deliver nothing but an error. People trust the computer to be right just as long as someone programmed it the right way.
LLM’s have flipped these roles around. Now the computer is the creative one, generating an endless list of ideas and content variations, based on the simple prompts given to it by humans. Not instructions like code, as there’s no way to guarantee that the neural network would produce the same output the next time you provide the exact same input. This new generative AI is whimsy and unpredictable, which makes it so much closer to behaving like us humans do.
If you work in a profession where any part of your output can be presented as text, there’s a high probability you’ve given ChatGPT a go and tested how it performs in producing similar outputs. It’s equally likely that you’ve seen the answers given by the machine to contain plenty of factual errors. “Hah! Nice try, AI, but no matter how much data they feed you, you’re still just a stochastic parrot“.
We should of course take pride in our craft. Many of us work in an environment where the professionals who can provide the most detailed answers to questions presented to them get the highest amount of respect. We gain trust from others, we build up our own confidence, we “level up” by being knowledgeable in our field and delivering high quality work outputs.
Are you always right, though? Of course not, we’re all only human.
Can you apply your expertise to any areas of business? Heck no, the deeper we go on topic Z the less time we have for studying topics A…Y.
Can you work 24/7/365? Not possible, you know that.
Communicate in any language? Why are you even asking these th…
WILL YOU WORK FOR FREE?!?!? Okay, I prefer not to continue this discussion anymore.
AI doesn’t have to be perfectly accurate to be of extremely high business value to companies. It only needs to be close enough, so that the superpowers it does possess over us living and breathing human beings can be put into use. Yes, it will very often need supervision and intervention from humans at some stage of the process. Yet the biggest financial gains will be achieved wherever the share of human work can be brought down to a minimum. Which means people will be very creative in finding ways to harness the creativity of AI in novel ways.
AI can always be there for you when needed, whereas a human professional cannot. In my line of business, today the customers are googling for answers and following videos & blog posts to manually repeat the steps on a computer to get their job done. When it gets too tricky or they don’t even know what to search for, Power Platform Advisors can step in and ensure the desired results are achieved. Customers can rely on us, but they need to sacrifice both their time (adjusting to whenever we are available) and money (sorry, we also have to make a living).
If you can take away all these nasty human constraints, AI will be a sweet enough deal to consider as an option for pretty much anything. People will try it because the barrier is almost non-existent. The tools for creating business solutions will have the Copilot capabilities baked into them, thus promoting them as the first resort. You’d be crazy not to use them.
What about the possible damages, though? Let’s say that generative AI is right 90% of the time and a human professional gets to 99% accuracy. When your AI built business solution causes big problems for the first time, won’t everyone go back to the good ol’ professionals?
There will undoubtedly be business models emerging that work a bit like insurance does. Since we can’t be sure that LLM based answers are correct, and we also can’t sue the AI for providing us wrong advise, someone needs to step in and become that middleman. Yes, accidents will happen and someone needs to cover the damages. Now, if your AI based service costs €20/month instead of €200/h and you’ve got a policy that promises to fix whatever issues were caused by unsupervised AI-driven decisions – it can be quite a lucrative model for both parties.
Bicycle evolved
Steve Jobs called the computer “a bicycle for the mind.” It is a beautiful, powerful metaphor. In the early 80s, the democratization of computing through the rise of a personal computer that was available for work and personal tasks was presented as a huge leap in the capabilities of an individual. Just like hopping on a bicycle improves man’s efficiency on energy use per kilometer travelled beyond that of any animal in the world, our possibilities for cognitive work rose onto a new level as computers became an everyday tool within our reach.
AI could lead to something of similar magnitude eventually. Is it just a faster bicycle, though? Did our computers become more powerful or did the tools change in a way that requires a new metaphor? When talking about LLM based tools like ChatGPT specifically, I quite like the analogy of “calculator for words”. It underlines the way in which these new tools of 2023 need to be approached as not the all knowing sources of truth but rather the wizards of words. They are extremely powerful in delivering combinations of words to represent most things us humans use text for (be it communication or code). However, assuming that they understand the world in the way that humans do is a mistake to be avoided when making use of their wizard skills.
If the electronic calculator was brought into an office where everyone had previously been crunching the numbers with only pen and paper, what would be its impact? A thought exercise like this might help us in understanding why there will be both enthusiasm and scepticism expected as AI capabilities begin to appear in the applications and platforms used in organizations today. And just like what happened to the physical calculator devices, eventually we’ll get a next generation of machines where the ability to perform calculations is just one app among many.
Two years ago I wrote one blog post that became fairly popular – possibly because the idea explored in it was still a bit like science fiction. At that time we were only 6 months into COVID pandemic and most people were still scrambling to adjust to their new working lives, now spent largely inside digital tools like Microsoft Teams rather than physical workplaces.
Microsoft Teams as a platform was not the first thing that organizations were looking for back then. Yet the huge spike in Teams usage and similarly in the amount of money Microsoft started allocating to the product made it seem like a logical future state. In my blog post I even predicted that Teams could become the next Windows – an OS level fabric that brings Microsoft back into the game now dominated by Android and iOS.
Has science fiction turned into reality since then? Are we now living in the future with cars driving themselves and apps running inside of Teams? Not just yet. Although I bet we’re closer to the latter vision becoming mainstream than the former one. In this post I’ll round up some of Microsoft’s announcements from the past few months and combine them with my personal observations on where we are today in regards to the Teams as a platform vision.
Innovation delayed
My general thoughts on the direction where things are headed with Teams haven’t changed. Yet it has become obvious that the pace of change will not be as dramatic as the sudden shift to remote work might have lead us to believe. This isn’t necessarily a bad thing for any of the parties involved.
Not only are the software end users often overwhelmed with how product features change and how capabilities tend to shift from one tool to another. The simple question of “where do I go to find this information” has an incredible number of possible answers in the Microsoft cloud. Yesterday your file was in Windows Explorer, today it is in SharePoint, tomorrow you’ll use it via Teams, and the day after your file will be gone and transformed into a Loop. Oh, and that Office thing doesn’t exist anymore, it’s now Microsoft 365.
Umm, what?😦 Imagine taking a longer break, such as parental leave, then returning back to work to discover all the core tools and vocabulary of the information processing tools have changed.
Then there is the product development side. Microsoft isn’t just building a single mega product called Teams, rather they are assembling several existing capabilities to serve as the foundation for modern work. These will usually take a few years. Just like Power Apps wasn’t born to work together with Dataverse (the 2015-2018 era), Teams wasn’t designed to host all your Power Platform apps initially.
It has easily taken 3-4 years from the announcement of Power Platform for the technology to actually start working like a unified platform from app development perspective (and you still run into 10+ years old legacy Dynamics CRM areas inside it on a daily basis). Trying to squeeze all of it to work within the frame given by Teams while this unification is going on… – well, the metaphor of replacing parts of an airplane mid-air comes to mind.
Dataverse for Teams
The idea of allowing Microsoft Teams users to independently provision Dataverse environments within the teams they manage was radical 2 years ago – and it still is. Today in every organization to where I’ve deployed the CoE Starter Kit to start analyzing the platform usage, the number of Teams based environments created has been high.
Whether the citizen developers have actually done more than install the sample apps or do quick tests with Power Apps – that’s a different question. What I do know is that at our company (Forward Forever) we’ve built several apps on Dataverse for Teams for our customers when a broad use / light touch scenario hasn’t warranted a premium license for all uses. I’ve been preaching the Dataverse for Teams gospel in many occasions (like Teams Nation 2022), to help raise awareness for all the cool things you can do with just a Teams license.
I gotta admit: it hasn’t been easy. The tools available for solution management in Dataverse for Teams are quite frankly unfit for purpose. What we have available today are more like a combination of temporary workarounds. It’s now 2 years since Dataverse for Teams GA launch and we don’t really have any formal ALM story around how to manage apps and environments on this platform. Which leads me to believe the investments nor ownership for Dataverse fo Teams at MS simply aren’t there today. Not at the level compared to 2 years ago, at least.
The co-existence of full Dataverse and the lite version in Dataverse for Teams has been a struggle also for the Power CAT team at Microsoft who develop and maintain the Power Platform CoE Starter Kit. A Dataverse for Teams edition was launched in April 2021, containing most of the features from the full Kit. This was to date the best demonstration of how complex solutions you could technically run inside Teams, while making them accessible to anyone with just a Teams license. In September 2022 it was announced that the team could no longer justify making the required investments in maintaining the Dataverse for Teams version:
A sad day for Dataverse for Teams platform story: #CoEStarterKit in DV4T is "deprecated".🪦 From now on, there's a premium price tag for any Maker that should view or update compliance data for their #PowerPlatform solutions. PAYG needs to be evaluated as an alternative. pic.twitter.com/Rs0xbbIPzK
In addition to the data platform side, there are plenty of quirks in the Power Apps studio experience, too. The product team has been aiming to unify the Maker experiences of these different studios for quite some time already. I get the feeling that there’s just so much unification efforts going around, ranging from things like Fluent UI support to the general “Run One UI” initiative (from 3 years ago already). It’s turning into one of those “in the fullness of time” episodes where we need to draw our own conclusions on what are the reasonable choices to make in the present moment.
Still, there is certain beauty to how Dataverse for Teams has been constructed from only the modern elements of the stack. Leaving away all those old layers that depend on the legacy web client infrastructure and who knows what ancient XRM bits the full Dataverse environments contain – that’s a brave goal to pursue. Shutting off direct access to the Dataverse APIs (used in every XrmToolBox plugin, for example) is surely necessary if the feature set of a “free” Dataverse for Teams edition needs to be restricted to differentiate it from the premium edition.
In theory these design choices make sense, yet what we see as the practical outcome from them as the “Power Apps in Teams” product today is… incomplete, for the lack of a better word.
Your business data accessible via Teams
Let’s move on from the app maker scenario in Teams and explore how existing business applications from Microsoft align with Teams today. In Summer 2021 there was a big statement made by Satya Nadella himself that Teams customers would receive access to Dynamics 365 data at no extra cost. I blogged quite extensively about the possible means through which such a capability might be implemented in practice.
So far, it all remains speculation only. It’s been over a year now and these capabilities have not materialized as product features that would support the licensing or security model required to make things real. Microsoft has been actively promoting the collaborative apps theme, though, and we’ve seen some demos of how Teams could better expose business data within the context of conversations.
After you see the high level product vision in a demo video, it’s always a good idea to search for the product release plans for any matching items to answer what exactly might be arriving into which product and when. Recently I noticed that in the latest release plans for Dynamics 365 pretty much all the Teams and Outlook related new features under Sales had been removed from the plan. It was later clarified by a MS employee that these were in fact moving under the Microsoft Viva Sales app:
These features will ship within the context of Viva Sales, and we're actively working on them. 👍That said, I agree this was a confusing message… apologies. @jukkan would love to find some time to sync and get your feedback on Viva Sales (I'm leading the PM team).
Microsoft Viva of course is a huge topic of its own. In a way, it is all about bringing apps within the context of Teams. Yet all those Viva apps will be built by Microsoft. It is therefore not a similar platform story nor an opportunity as what Power Platform represents to customers or partners.
There’s a lot of resemblance between the Dynamics 365 and Viva brands, in the sense that they are 1st party apps designed in Redmond. A few years ago we saw the Dynamics 365 product family rapidly grow with new apps being announced every few months (remember all those “AI for X” products?). A lot of them seemed quite experimental in nature. I suspect we’re about to see the same phenomenon within Microsoft Teams as new Viva apps will be arriving for various business processes. These will demonstrate how MS themselves are using Teams as the platform for their products.
Viva Sales
The first Viva product with a business application focus to reach GA status is Viva Sales. It is marketed as “the app that removes the burden from your sales people to work with your big, clunky CRM system directly”. The notion here is that CRM tends to evolve into a tool for sales management and customer master data integration across other big systems, which can be at odds with what the persons doing the real interaction with customers would need to get their jobs done.
The three main areas where the Viva Sales app manifests itself are 1) Outlook side pane for emails, 2) Teams chat/channel messages and 3) Teams meetings. The app itself doesn’t store customer data, rather it connects with either Salesforce or Dynamics 365 to pull this information.
If you’re a Salesforce customer, than the purpose of Viva Sales today is pretty clear: helping your sales people to use CRM data across Microsoft’s Teams and Outlook apps. If you’re using Dynamics products, then this will sound pretty familiar and obvious to you. You might be wondering: “isn’t that something we can already do today?” To a large extent, yes. Much of what Viva Sales represents to existing MS customers is the promise of a better tomorrow with future integrations and experiences that may deliver new value.
This leads us to the commercial positioning question. Salesforce customers will need to pay $40/user/month to access Viva Sales features. Dynamics 365 Sales Enterprise or Premium users will get it bundled into their existing subscription. For everyone else, Viva Sales is not relevant / available today. Maybe in the future we’ll see more CRM systems supported, who knows. I think it will depend a lot on whether the Salesforce audience buys into this or not.
So, how would Dynamics 365 Sales professionals users get access to Viva Sales? By upgrading from their $65 subscription to the $95 Enterprise version. What about users of other Dynamics 365 CE apps like Customer Service Enterprise? By paying $20 more to add Sales Enterprise into their plan. OK, then what if you’ve built a custom business app on top of Dataverse? It’s not supported today by Viva Sales, although Charles Lamanna suggested it was in the works. We’ll see.
For everyone working with business data in Dataverse, the existing Dynamics 365 App for Outlook remains an option. It’s one of those “hidden gems” of Power Apps that MS avoids bringing up too much, yet the Outlook integration is fully supported and working with a Power Apps license. As for the Teams integration part, we have the Dynamics 365 app that hasn’t seen much love recently but also hasn’t yet been announced as deprecated.
Microsoft has said they are working on bringing more Viva apps to support customers’ business processes. It’s likely that we’ll see a customer service focused app at least. While these targeted experiences sound sensible from a single user persona perspective, it’s unclear to me what the targeted state for collaboration scenarios across departments should look like. Will a sales rep share an account in a Teams channel via the Viva Sales app and then for the customer service rep this somehow switches to be the “Viva Service” app data instead? Multiply this with all the other departments plus custom business apps on top of Power Platform and we’re going to need bigger navigation bars to accommodate all the different app icons…
The Viva Sales price point of $40 is something I personally see as a tough sale. For perspective, back when Dynamics CRM Online was launched globally, the whole CRM cloud suite covering sales, service and marketing cost less than that. It also included the XRM platform, which has since then been split into a dedicated SKU called Power Apps Per User – at $20. Comparison of empty platforms vs. readymade apps isn’t that fruitful, though. Perhaps the sticker price is set intentionally the way it is, to then allow MS account managers to negotiate sweet deals with customers running Salesforce today and get them more deeply hooked into the Teams platform story, instead of Slack.
Teams infrastructure for applications
The more people do their work inside Teams, the more demands there are for it to work like an operating system rather than just a meeting app. The current framework we have in Teams right now, based on Electron, is a known resource hog and a performance bottleneck that doesn’t scale into the future vision of the Teams platform. There is also great challenges in enabling cross-organization collaboration today, given how painful the tenant switching process is for accessing resources as a guest user in a team.
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) October 10, 2022
We’ve heard Microsoft say that Teams 2.0 will eventually arrive, built on Edge WebView2, yet the timeline remains unknown. The next Teams version might be tightly integrated with Windows 11. At least the Teams Linux client was recently retired and users are instructed to move to the Progressive Web App (PWA) version once available. This all points to MS being quite serious about turning Teams into something that isn’t merely a Zoom alternative for meetings but more like an extension of the OS. If that means the best experience is available only via modern Windows devices, maybe it’s not such a bad trade-off with the current market share of Teams.
Performance isn’t the only infrastructure issue that may stand in the way of Teams becoming more of a platform. If a growing number of applications and services are consumed via Teams rather than via a native app or the browser, this inevitably turns the eyes of IT professionals into the security implications of such a shift. A recent study has revealed that the app model used by Slack and Teams is potentially “six years behind that of iOS and Android”. Once organizations wake up to the possibilities of how individual Teams users can authorize third party apps to run code from external servers and potentially impersonate them for phishing purposes, for example, Microsoft will be forced to spend a lot more energy on platform security topics.
One might think that while allowing 3rd party applications with custom code running in external services could be problematic, allowing the low-code apps built on Microsoft’s own services inside Teams would be an easy choice to make. Yet it’s in fact the opposite. External apps from third parties have been in the app store for many years now, while the publishing of Power Apps into Teams store has been explicitly forbidden. Distributing low-code collaborative apps across organizations has therefore been a bit of a dead end. Presumably the Power Apps based solutions wouldn’t have met the Microsoft Teams store validation guidelines.
A few months ago the wording in the documentation was changed and now it says: “If you’re interested in publishing your power apps in the Teams store for users across all organizations, please fill out this form.” It seems the product team is now gathering data on which scenarios to prioritize for the app store publishing route. Getting the road open for partners to distribute Power Platform solutions via the Teams apps store may still take some time.
The final topic which I want to touch upon before closing this “state of the Teams platform” analysis is technically not about Teams, yet in practice I think it’s very much intertwined with it. I’m talking about Loop components.
It’s a bit over a year now since Microsoft announced Loop at Ignite 2021. One year later, at Ignite 2022, the Microsoft Loop app was again announced – as private preview. I bet not many people outside the MS geeks ecosystem have interacted with a Loop component (at least intentionally). While the product documentation tries really hard to get you excited, claiming“the possibilities for collaboration are endless”, in fact you reach the end of possibilities with Loops today quite quickly. You might create a quick list in a Teams chat, then that component gets pushed into history as new stuff arrives – and you never see it again.
I think this has not been the optimal way to build up authentic excitement towards the technology. What MS could have been putting more emphasis on is showing how data can be pulled from an existing source, like CRM or other systems of record, and then shared as dynamic cards in the context of a discussion. These scenarios have of course also been included in Microsoft’s product vision videos for a long time already, with Context IQ linking you to any business record via a simple at-mention. Yet the problem is: it’s been a while and all we still can do with Loop is type text into lists and tables.
Coming from the low-code side, I was pretty excited the first time I saw the feature that has now been given the name Cards for Power Apps. Technically it isn’t anything revolutionary, rather it is a citizen developer friendly way to utilize the concept more familiar to pro-devs: Adaptive Cards. It’s not a flashy real-time co-editing experience of data like Loop aims to be, yet it is something that’s much easier to find real business use cases for. Interactive notifications that allow you to complete a quick data entry task without opening any other apps – the world is full of scenarios where these could replace the daunting of system generated emails.
The idea of sharing a live Loop instead of a link to a document or an app in the cloud is something most information workers probably wouldn’t explore on their own. It will take many consecutive and consistent nudges from MS to get people to change their ways – which is why Teams probably plays a more important role in this shift than the dedicated Microsoft Loop app itself.
Cards for Power Apps today are a very rough preview still, yet I think these might be the middle ground that can actually push the idea of Teams as an application platform forward. We’ve seen Microsoft promote the concept of Adaptive Card-based Loop components for partners like SAP, Zoho, Smartsheets to bring their business data inside the context of a Teams chat. No, it’s not built on the futuristic co-authoring experience of Microsoft’s Fluid Framework – and that’s just fine.
For that future to eventually arrive, I believe we should first get a working intermediate version of the technology out there into the hands of the Makers. I really hope Microsoft could find a way to promote the makers of Power Apps to become “first-class citizens” inside the Teams world. Unlike the commercial ISV solutions from keynote demos that merely integrate with Teams, the citizen developer solutions could be born inside it – if only it didn’t require extra effort and compromises like it does today.
If I had to choose only one blog I could follow in the Microsoft Business Applications ecosystem, it would be Steve Mordue’s blog.
Why this blog? Because you’ll learn more about the true business of BizApps in Steve’s blog than you would from reading all the partner channel materials MS puts out there.
It’s not just the unfiltered opinions and provocative comments from Steve that make the content unique. He manages to get Microsoft leaders like Charles Lamanna or Ryan Cunnigham speak openly about product roadmap and business strategy whenever he has a chat with them. It’s the kind of material you couldn’t hear from anywhere else – at least not without an NDA.
When MVPs used to get together
One unfortunate impact that COVID has had on the Microsoft MVP program is that our annual MVP Summit events have gone virtual. Even though the world is slowly opening up to physical events again, at the same time the world economy is sinking. This has pushed even the biggest tech corporations like Microsoft to announce cuts on their internal travel, training and event budgets. This means the next Summit, which will be my 10th, is probably done over Teams again.
It’s better than nothing, of course. The Microsoft product team members do put in effort to share their plans with the MVPs and are open to receiving feedback from us, since the protective shield of the NDA agreement covers both digital and physical worlds. Making things digital can also help scale the amount of tech content that can be made available as well as the means through which to consume it.
What the virtual events cannot in any meaningful way compensate for is the lack of informal interactions between MVPs. When you can’t go grab a drink with the smartest people in the business together at JOEY Bellevue, a large part of the Summit is wiped away. Sure, the product group interactions are valuable, but the MVP-to-MVP interactions are priceless.
No, you can’t replicate this in the virtual Summits. When you’re first sitting 6-8 hours alone in front of your computer, from 6pm onwards after your normal working day, staring at the Teams screen – trust me, you’re in no mood for “virtual drinks” after that.
Events quickly turn into non-events due to the lack of any changes in the physical surroundings. No travel costs, no jetlag, only a little loss of billable work during the week – it’s all very productive, to the point where you start asking yourself: why did I ever consider this “fun”? It sure helps to contribute to the feeling of being constantly tired.
Time to move forward again
You shouldn’t become too bitter about things not being what they used to be. The older you get, the more stuff like this is going to come at you every single day. You don’t have to like it, and you certainly are entitled to feel what you feel about it. That’s where our entitlements pretty much end, though.
Choosing how we react to change is pretty much the essence of life – and business as well. This is an area where both me and Steve seem to have similar ideology that drives our behavior. If you know the only certain thing in life (and business) is constant change, it’s better to be someone who’s pushing that change to happen instead of becoming the object that must endure the change pushed upon it.
So that’s one thing we share in addition to our hairstyle. With nothing more as a prepared agenda, we opened up Teams and stated recording a session on Steve has a chat with Jukka. It’s as close to an MVP-to-MVP informal interaction you can get to without flying to Redmond.
You can listen to the audio track on Steve’s website or on Spotify / Apple Podcasts. Alternatively, you can watch two BizApps MVP baldies on your screen for one hour via the embedded Vimeo clip below:
https://vimeo.com/742784310/7101b864c1
Some of the topics we discuss with Steve include:
How different the world looks like when you choose to go all-in on Power Platform instead of being a Business Applications generalist
The struggle of convincing customers that a $5 app can actually give them more value than a $95 app
How to get the IT on board with the citizen developer movement and turn governance into an enabler instead of a blocker
What would be the ideal support model for a platform-first business that would reduce the customer/vendor tension and get everyone on the same side
Why Dynamics 365 partners have very little financial incentives to move their capacity into true low-code business
The difficulties in making the Fusion Team story sound attractive enough for pro-devs to find their place in the low-code world
Why Teams is the most important platform Microsoft has and why it isn’t yet quite the right platform for wide scale business applications usage
That’s just a few things I remember off the top of my head, after our awesome chat session. So, if you’re interested in hearing what us two loudmouths think the future of Microsoft Power Platform is – you know what to do.
There’s no sponsors in any of these chats nor either one of our blogs, so I’ll just leave you with two commercial call-to-actions:
Check out RapidStart CRM to experience what you can do with just a $5 Power Apps Per App license (the CRM part comes free, courtesy of Steve).
To keep up with what our 100% Power Platform focused team of pretty amazing experts is doing, subscribe to the Forward Forever Monthly newsletter.
It’s that time of the year again when Microsoft have published their plans for the upcoming 2022 Release Wave 2 for Power Platform and Dynamics 365. “How exciting! New PDF documents with hundreds of pages to read!”
I’m sure many of you have learned to skip the static PDF files by now and instead add bookmarks to quickly get to the online version of these plans. Like these:
That’s much better, but it isn’t really optimal either. I don’t know about you, but personally I’ve had a hard time getting very excited about the new Release Plan drops for a couple of years now. There’s just something not quite right with this “wave” model.
Everything changes, always
Don’t get me wrong. It’s great that the Power Platform community members are curating their own top lists from these Release Plans twice a year. There’s plenty of value in seeing what items people are actually excited about, not just reading MS corporate style “excitement” on everything included in the Plan.
Yet the reality is this: the contents of these Releases Plans is likely to reflect less than 50% of what will actually be delivered into the products over the course of the wave. If you need proof, then check out the most important page of the online Release Plans: change history.
At any given time, Microsoft product teams are working on several new features and enhancements that they are not yet ready to disclose. They’ll get added to release plan later (or sometimes launched without it). As a very recent example, Managed Environments was announced as a preview feature on the same day as the 2022 wave 2 plans came out. The feature is not yet in either wave 1 or wave 2 documentation. It’s very natural that the product marketing’s need for making feature specific big announcements is a higher priority. After all, diligently maintaining the long list of similar release items won’t bring that much attention to any single feature.
Then there’s the inevitable reality of planning / estimating in software development. Things can get delayed due to too optimistic estimates, dependencies to other items/products, changes in MS product strategy, acquisitions, and so on. Ultimately the Release Plans are just a publicly visible backlog of what the team is working to deliver. It’s better not to get too excited about any specific feature on the list – often those will be the ones that get eventually postponed / removed…
While it’s kinda nice that we have a steady rhythm of 2 release waves per year that can be easily communicated to customers, the reality is more messy. These waves are forcing an artificial structure onto the ongoing product development work. Remember: the “wave” is not any actual release in itself. October 2022 will deliver a tiny fraction of the items listed in the 2022 wave 2 plan, as the wave lasts for 6 months.
While the waves themselves are sequential, Microsoft’s communication model has overlap for the waves. The fact that the wave 2 plans are first announced when there’s still 3 months worth of wave 1 to go (until end of September) can make it complex to keep track of items. You can’t tell whether a feature is in the product roadmap just by looking at the latest plan since it might be in the previous pipeline still. Here’s one example:
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) July 13, 2022
If only we had a more dynamic view into the Power Platform and Dynamics 365 product backlog, without these artificial “waves” to confuse us…
Say hello to the Release Planner website!
Although it’s still a preview in itself, the Dynamics 365 and Microsoft Power Platform release planner is already a very worthy rival to the familiar Release Plans. If you’re familiar with the Microsoft 365 roadmap, then this a similar website that provides the current state of what features are being planned, rolling out or recently delivered.
The data on release items is largely identical to what the official release plans already offer. However, it’s not wrapped within the wave concept, meaning everything can be found under a single site.
There have been recent enhancements made to the Release Planner (listed here). Searching the release plan items with keywords is now possible. There’s a change history to reflect updates made to delivery milestones (i.e. delays in early access / preview / GA dates). Finally, filters and sorting options have been introduced, so you can view only the latest additions (7/30 days) or updated items across Dynamics 365 and Power Platform.
Since the Release Planner is a Power Apps Portal Power Pages website instead of a Microsoft Docs site, it is much easier to implement such features that are intended for working with a list of records. Docs is great for documentation of course, as well as version control through its GitHub back end.
One really neat feature in Release Planner is the personalization option. When I log into the site, I have the ability to pick items into “my release plan”. Essentially its a way to create a list of favorite items to follow. Because let’s face it: we all focus on some corner of Power Platform or Dynamics 365, not the entire MS BizApps cloud. Creating a personal release plan also provides an option to copy a public share link for it:
Using a short URL service, I can now create an easy to remember link that will always take me to the list of Power Platform release plan items I’ve flagged for myself to follow. You can of course have a look at it, too:
With this link, I can now spend less energy on A) remembering if an item has been in wave 1 or 2, and B) stop hunting through the change history page for status updates. Oh, and it also works fairly well on a mobile device, whereas trying to navigate the legacy release plans on MS Docs seems to be impossible (at the moment at least, on Android/Chrome).
Of course any dynamic website is only as good as the underlying data that is used for rendering it. At the time of viewing, there seem to be tens of release plan items from 2022 wave 1 that have not yet been updated to reflect the current status. The Release Planner site says they should be available/GA when in reality they’ve been delayed, postponed or even cancelled. This is something that technology in itself won’t fix. I hope as Microsoft’s release planning process matures beyond thinking about “waves” we’ll see more up to date information in the Release Planner site, too.
Did you know?
This Release Planner isn’t the first step for Microsoft to use the Power Platform to manage the product development of the very same platform. Already back in 2019 the process and tools used by the BizApps team for release planning was published in a blog post. There’s a sample app on GitHub that contains a solution with the tables, forms, plugins, PCF controls, cloud flows etc. for deploying your own copy of the release management tools.
This process was designed to dynamically produce outputs from the release items data managed in Dataverse. Both the release plan document as a Word output as well as the Docs pages as markdown files on GitHub were generated with Power Automate cloud flows:
Since the solution was built on top of a solid platform designed for managing business process data, there were of course other opportunities to leverage it. As was pointed out in the comments section of the 2019 blog post, by a certain ex-MVP (now at MSFT) with a long history on Portals in the form of Adxstudio:
Which brings me back to an even more ancient blog post of mine, from 2015, called XRM Strikes Back. Inspired by Microsoft’s acquisition of Adxstudio, I argued why in the long term it would be a more successful strategy for MS to bet on the platform, rather than trying to integrate SaaS products from outside the ecosystem into the Business Applications portfolio.
Success doesn’t happen overnight either way. Looking at the XRM based acquisitions, Adxstudio is now the 5th product in the Power Platform family, with the new name Power Pages. FieldOne Sky turned into Dynamics 365 Field Service that has quite a solid position in the market (from what I know). Mojo Surveys evolved into Dynamics 365 Customer Voice, which may not have an extensive roadmap right now, yet it’s still widely used by the customers we are working with at least.
Back in 2011 when Dynamics CRM Online itself was used for managing the Dynamics CRM Online launch website, backed by (Windows) Azure, so might have considered that a crazy thing to do with a business application platform like XRM. Well, who’s laughing now?!?😁
Did you know that #MSDYNCRM website content @ http://crm.dynamics.com is managed with #MSDYNCRM itself? http://bit.ly/ehOP7p @Adxstudio#XRM
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) March 14, 2011
The journey up to this point has been long, but that’s exactly what such low-code application platform journeys are for customers, too. Microsoft is now in the process of also migrating their third party Ideas sites for product feedback into the Dynamics 365 Customer Service Community portal template (meaning Power Pages). The Power Automate Ideas site is moving there next week. Dynamics 365 Ideas already lives on this platform, so I’d imagine other products will soon follow. Another piece of the digital feedback loop coming together, through the power of the platform.
Recently I was invited to the Demystifying Enterprise Innovation podcast run by AgilePoint. The podcast host Sharjeel Sohaib is interviewing experts from the field of digital process automation technologies and low-code platforms.
Our topics covered not only the Microsoft specific technology in Power Platform but also the broader market around low-code/no-code platforms. How are they impacting the lives of citizen developers? What should organizations do to drive the low-code tools adoption? Where is the technology underneath these platforms heading towards?
This turned out to be quite a comprehensive “state of Power Platform in 2022” type of a discussion. I guess that’s just what tends to happen when someone asks me a question about it. Below is the mind map of what I planned to cover in the podcast episode (click for a bigger image):
You can listen to the end result on your favorite podcast service – assuming it is either Spotify or Apple. The detailed show notes with a few quotes from me are available on the Transistor.fm page for the Demystifying Enterprise Innovation podcast.
Notes and thoughts
In the podcast episode we start by discussing my own journey as a citizen developer from 20 years ago, learning about CRM / marketing automation processes at a large B2C company (Nokia). This path then lead me to different Dynamics CRM consulting roles, and most recently going all-in with Power Platform in 2020.
Being on the citizen side from day one instead of starting my career in formal IT projects has been undoubtedly one of the key reasons why I’ve found the low-code movement to be so close to heart. To me, the ability to democratize code is a much more worthy goal than just trying to get sales people to enter more information into the CRM database.
Sure, such business apps may be the “what” but citizen development is the “why”. The way Microsoft has managed to infiltrate the existing toolkits of these citizens by bundling Power Apps and Power Automate into Office 365 is the prime reason why things have moved along so fast in this space. Merging PowerApps with XRM 4 years ago is what allows them to still keep moving fast today, even as more complex enterprise IT requirements now need to be met when the apps originally built by citizen devs are becoming more & more business critical.
Despite of this move towards enterprise processes, bottom-up innovation is still what excites me the most. Grandiose digital transformation programs with their top-down agendas may have the big funding behind them, yet I believe the net impact from small apps built by citizens motivated to fix practical issues in their daily working lives is going to be greater in total. Teams as a platform is a story that may cause problems for us more experienced MS BizApps practitioners, and still this kind of simplification is definitely needed when you really want to scale low-code in practice.
Power Platform governance topics are where I spend the majority of my working days on right now. When delivering our Power Platform governance advisory services, I’ve seen how difficult it can be for the IT organization to get a handle on citizen driven apps and automations – at least if no one was there to educate them on how Power Apps & Power Automate administration works in practice.
This is not so much a challenge of the technology not being available. Rather it is the new roles and alignment of IT alongside the citizen developers that poses the biggest barrier for companies to feel safe enough to fully embrace what this corner of the MS cloud can offer them. The same gradual increase in maturity that has happened with Office 365, Azure, and also Power BI from the “power family” – all of it seems inevitable for Microsoft’s low-code products, too.
This is why we’re now seeing less new maker focused features right now and a bigger push for admin & governance capabilities in Power Platform. The next big target for MS is in formalizing the fusion development story for low-code, to get the professional developers on board this new way how customer organizations address the growing demand for digital solutions that can’t all be met with custom code alone.
The ISV opportunity in Power Platform has not yet been a true focus area for Microsoft. Their emphasis has been on the internal transformation of organizations via citizen developer solutions. Yet many MS partners are naturally interested in the huge opportunity of the low-code movement. They’d love to become a part of this new ecosystem where the number of low-code developers is growing by 40% every year. However, there’s a lot of work ahead before the mainstream wave of ISVs could be onboarded to Power Platform, both from commercial and technical perspective.
We can’t just take the good ol’ Dynamics business model and apply it to Power Apps since the platform is designed to empower bottom-up innovation distributed all across the organization (who’s gonna do the top-down purchase decision on your project?). Neither can we make the Office style assumption that all these tools would be common to all information workers (justifying the premium licenses requires stepping outside the generic productivity story and quantifying the value from business specific processes). Experience from the other MS clouds is definitely a major advantage from an ecosystem insights perspective. At the same time, if you just sprinkle a bit of Power Platform technologies on top of your existing business model and projects, you can’t expect to see any radical growth or shift in how your customers are engaging with you.
At Forward Forever we’ve been lucky to get the chance to educate several MS partner companies on the practicalities of developing apps for Power Platform in 1:1 coaching sessions over the past two years. It has affirmed our belief that this low-code movement is an infinite game where we aren’t competing against other players. There’s no sense in trying to be the winners once the final whistle blows. Rather we should do our best to keep the game going, helping the whole league around us to grow and build an audience (even a fan base) who wants to see us succeed.
There are no winners or losers in an infinite game; there is only ahead and behind.
Simon Sinek
In addition to advising customers and partners on how to succeed with Power Platform, we’ve also invested resources into building products on top of it. Our offering in this field has recently reached a point where our Sustainability Action Pack is now listed on Microsoft AppSource for everyone to see. It’s a solution template that provides tools to drive environmental actions, make progress transparent and help organizations reach their social, environmental and climate targets (see SECAP).
Power Pages, Power Apps, Power Automate, Power BI – the whole MS low-code stack is being used when we’ve delivered the solution to municipalities in Finland. The big difference compared to Azure based applications, for example, is that the end product truly runs on the customer’s platform. Modifying and extending our Sustainability Action Pack functionality can be done by business users – as long as they’ve got the willingness to learn how Power Platform works.
This might have been just marketing talk a decade ago. Today the reality is that the persons who are willing and able to use these low-code tools to shape your business applications are likely to be among your most valuable employees. They probably haven’t been hired for this exact role, yet the organization should acknowledge the positive impact that they’re able to achieve by adopting Power Platform tools and thus adapting your tools to deliver better business outcomes. Otherwise they may quickly find a new place to work where such evangelism is appreciated.
From the outside, as a consultant/advisor, we can only show you the direction to take. The real adoption journey for low-code relies on empowering internal personnel to build new things that create business value. Ownership of your own tools is the biggest difference in mindset when it comes to the traditional Dynamics business applications versus the new breed of Power Platform solutions. This is the revolution in low-code – the technology part is just evolution.
For more of my thoughts on Microsoft Power Platform evolution / low-code revolution, go and check out the podcast episode:
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.
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) March 3, 2021
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.
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) April 13, 2021
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 governancepressure 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.
Channel tabs are a great way to bury Power Apps inside Teams, never to be found. How about if we'd push them right into the app launcher instead? https://t.co/hOtEm4fhyx#PowerApps#MicrosoftTeams
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) December 2, 2021
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.
As for Power Apps competitors in the #lowcode space: every one of the 5 Leaders in Gartner MQ has pricing/licensing listed as a key caution. Microsoft isn't most likely wasn't too expensive in this arena to begin with. https://t.co/mES4Re4Cwapic.twitter.com/VRQXAQ0tjH
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) October 1, 2021
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:
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) April 27, 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.
"Easy but not necessarily simple" is pretty much the definition of all things #lowcode. We just gain easier tools to create ever more complex solutions. https://t.co/EoE65wE9kO
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) May 6, 2021
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.
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:
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).
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.
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.
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.)
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.
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:
The biggest problem with Excel is that it presents itself as a programmer’s tool, with a programmer’s value system. Programmers can make Excel sing, while normal humans can just muddle through. The solution does not lie in programmer mental models. 24
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.
By now many of you will have read about the announcement Microsoft made at Ignite 2021 on their “low-code programming language for everyone”. I’ve written about the wider role of Power Fx in the high level Power Platform story in the Forward Forever team blog, which will give you all the basic information on what/why/how/when:
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) March 3, 2021
Recently I also recorded a quick 10 minute video discussion I had with Julie Yack from 365.training where I had a chance to verbally express some of my thoughts on Power Fx:
I’ve personally started my low-code journey with Microsoft Business Applications back when the concept of XRM was first promoted, which is why most of my hands-on experience with Power Apps lies firmly on the Model-driven side. Power Fx as a formula language originates from a time when the two app types (Canvas & Model-driven) were still completely separate product offerings. If you’ve always built Canvas apps, there’s essentially nothing new for you in Power Fx. If you’ve only worked with the Model-driven business apps (Dynamics 365), there will be plenty of changes ahead.
In this blog post I’ll share some initial thoughts on how I see the arrival of Power Fx potentially affecting the way Model-driven Power Apps are built.
Why Model-driven needs Power Fx
There has traditionally been a clear divide between no-code and pro-code tasks when building apps the XRM way – meaning customizing and extending Dynamics 365 Customer Engagement apps in most cases. You’ve had a GUI for clicking your way through a variety of configuration options the application platform offers, to perform tasks like:
Define entities, fields and relationships
Determine the layouts of your forms, sitemaps and views
Design business logic via workflows, business rules, BPF
Our reliance on the almighty mouse pointer as the sword with which we fight our way through a battle field full of fierce business problems might be considered a weakness. Sure, we’ve often managed to emerge as the no-code hero who’s been able to tackle a business requirement most bystanders would have expected to require custom code. Yet there’s frequent frustration to be experienced when the particular configuration option we would have needed was not present in the graphical user interface (GUI).
Such problems don’t need to be very complex to become unsolvable. All it takes is for the specific function to have fallen outside of the scope of features that the Microsoft product team has managed to squeeze into the platform’s built-in toolkit. Sometimes you might find a community tool that generates the required JavaScript for you, or a custom workflow activity comes and extends the built-in actions to let you implement that specific calculation your customer needs.
Yet it remains mostly a black box for the non-pro developers: the next time you run into a similar limitation, you’re likely to again need help from the pro-devs to move forward. Venturing beyond the GUI tends to always push us into uncharted territory.
What the announcement of Power Fx promises is far more empowering. “Formula based Power Apps Model-driven customizations” sounds like you could actually get a peek of the underlying logic layer in text format rather than a finite list of picklist options to choose from. At the same time you probably would not need to assume responsibility of any software code implementation details. The lower level of how the conditions defined by your formula are actually met by the big computer running in the cloud would not be your concern.
The maker describes what they want their logic to do, not exactly how or when to do it. This allows the compiler to optimize by performing operations in parallel, deferring work until needed, and pre-fetching and reusing cached data.
Power Fx documentation on the language’s design principles
For me, the big reason to steer clear from copy-pasting JavaScript snippets from websites and tweaking them to be used in business applications built for customers is that I’m all too aware of what I don’t know. While I can often read what the specific scripts are doing, I don’t fully understand why they work vs. why they would not work under different circumstances. It would be far too easy for me to accidentally create something that breaks in the near future – not because of a bug in Microsoft’s code but a bug in my code.
Formulas that are written in Power Fx (today only in Canvas apps) are very different. Sure, they can be very complex as well, but there’s no knowledge required from outside the domain of Power Apps. If I pick a tutorial video from Shane Young’s YouTube catalog that explains the usage of a particular function in Canvas apps, most of the time I get it. I can immediately adapt it for my own scenarios, and get helpful Intellisense error messages from Power Apps Maker Studio when there’s something missing from my function (well, not always helpful messages, but at least an indicator of “keep trying”).
Taking the step to writing your Power Fx formulas instead of just clicking around the GUI helps in unleashing your creativity in app design and significantly expanding the realm of what’s possible. There’s also big potential in improving the efficiency of the app building process when you can copy-paste text based formuals instead of having to repeat a series of clicks in the MS admin portals that seem to only get slower and slower as years go by…
Why Power Fx may be scary for Model-driven app makers
Canvas apps have been promoted as the way to create “pixel perfect experiences” tailored to the end users’ specific requirements and needs. This is a completely different starting point for low-code app creation than the traditional business apps in CRM style projects where you are mostly customizing an existing application. On a high level, everything will look & behave pretty much the same way every time.
I’d argue that many of the limitations in Model-driven apps are in reality a safety net for the no-code app makers. Back in 2019 I did a presentation on the topic “Canvas apps for the Model-driven mind”, which describes the kind of leap that is needed both on mental and practical level for an XRM pro to turn into a modern Power Apps app maker. Power Fx will now play a big role in this transformation.
The relational Dataverse data model that sits behind every Model-driven Power App largely dictates how the app UI will function. As a result, there’s not too much creativity required nor allowed in creating the visual side of your business application. Navigation and Command Bar buttons will be generated for you, and you can rely on them being constantly presented to the user. Everything’s responsive out of the box, too.
The other side of Power Apps that’s not built on relational data structures and predefined UI grids is the world where everything runs on Power Fx. In Canvas apps the buttons don’t exist until you drop them on the screens and they do absolutely nothing until you add a piece of Power Fx text into the OnSelect property. Any dynamic behavior that’s desired for the app’s controls (visibility, size) must be expressed in Power Fx for their respective properties.
Building Canvas apps doesn’t require you to have programming skills, but it does quickly push you much closer to the experience of custom app development. You’re no longer merely a system customizer like in Dynamics 365 scenarios, now you’re an app maker. The whole purpose of the low-code tooling is that it blurs the lines between traditional developer roles, thus powering the new “fusion teams” that may share many of their tools – and now also the programming language.
As a result, it becomes less obvious what you can & can’t do without custom code extensions when building Power Apps. Configuration expressed as text based formulas can be vastly more powerful than GUI based options, allowing the most creative makers to achieve functionality that others might assume to be impossible with the available tools.
Journey towards “just Power Apps”
Back in Summer 2019 Microsoft revealed their long term roadmap on how the two types of Power Apps would eventually converge into one. We haven’t yet seen much concrete changes on how Model-driven and Canvas could coexist within a single app, apart from the embedding feature. The original plans for launching custom pages as a “canvas” within Model-driven apps were removed from 2o20 release wave 2 and no new target dates have been announced for it.
There is likely a wealth of moving parts in this puzzle that have dependencies between each other, so it’s no wonder this merging of Model and Canvas apps is taking time. Power Fx is a clear step towards making the new app building story consistent. Plenty of new functionality is likely to be needed, though, as you’re not simply replacing one programming language with another. Rather it’s the case of expanding bespoke GUI tools with a low-code programming language that can also be used to express the same logic.
Exactly what the new Power Fx based “form and commanding customization in Power Apps” promised at Ignite will consist of remains to be seen. Calculated columns defined with Power Fx are much easier to grasp. The same goes for the conversion of Business Rules into Power Fx formulas, since already today the Text View in the editor looks a bit like these.
Making that If-Then-Else box editable would be a simple step. However, turning the actions in Business Rules into something that you could define with Power Fx and apply on a Model-driven form will surely require some more platform unification work. Show/hide fields, set required, prompt for errors… They all sound straightforward from a logic perspective, but how will such concepts be extended to cover not just Canvas sceen controls but Model form controls is going to be interesting to watch.
This is probably why Business Rules are in the same “future roadmap” bucket as the Power Automate flows for receiving Power Fx coverage. It’s not yet easy to envision how the declarative logic of Excel that Power Fx tries to follow wherever possible is going to be applicable to these more imperative scenarios. What would a flow written in Power Fx look like and is it really going to be easier for app makers to grasp than the current GUI?
