Jukka Niiranen

Tag: Power Apps

  • A Power Platform newsletter from our team

    A Power Platform newsletter from our team

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

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

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

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

    To quote our team’s announcement of the newsletter:

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

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

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

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

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

    Subscribe to Forward Forever Monthly

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

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

    Power Platform licensing, November 2021 updates

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

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

    PAYG and Azure

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

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

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

    PAYG and apps

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

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

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

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

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

    PAYG and capacity

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

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

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

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

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

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

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

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

    Power Automate licensing updates

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

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

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

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

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

    AI Buider

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

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

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

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

  • Did Power Apps really leak your customer data?

    Did Power Apps really leak your customer data?

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

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

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

    UpGuard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Power Apps pricing drops by 50%

    Power Apps pricing drops by 50%

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

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

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

    More revenue via lower pricing

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

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

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

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

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

    Licensing implementation details

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

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

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

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

    What about Dynamics?

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

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

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

    The price will never be “right”

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

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

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

    Read more about Microsoft Business Applications licensing

    Check out my earlier blog posts in the licensing category.

  • Making Model-driven Power Apps visible (and hidden)

    Making Model-driven Power Apps visible (and hidden)

    I’ve got a confession to make: even though I’ve been building Model-driven apps long before they even were Power Apps (back in the XRM era), I’ve struggled to understand how I can make them visible to the end users in the modern experiences Microsoft offers.

    In this post I’ll address two different challenges. First, how to enable end users to have access to your Model-driven app. Second, how to protect them from seeing irrelevant apps.

    “Why isn’t the app sharing menu working?”

    Once you’ve built your Model-driven app are ready to release it, you need to make it visible not just to the app makers and system admins but also regular users. This involves using the Share menu from the list of apps available in the environment.

    Working in the Power Apps Maker portal, it’s pretty obvious the things we see here have been built with Canvas apps in mind. When it comes to sharing a Canvas app, the steps are fairly logical. You click the 3 dots next to the app, select “Share” and are shown this dialog:

    You add users or groups, set their data permissions via the many available security roles within Dataverse, click Share, after which the users get an (optional) email message. All good!

    Try the same steps with a Model-driven app and your users will see… nothing. It’s not just that there isn’t an email message with the app URL sent to them. They actually don’t have access to the app at all, even if you provide them the URL directly. Why isn’t the share action working from here?

    If you’ve worked with the Dynamics 365 App Modules before, you might remember that you needed to specify which security roles have access to which app. Just like with role-based forms, too. Now, that particular role assignment UI existed in the legacy web client that has been deprecated and there doesn’t seem to be an equivalent in the Maker portal anymore. Does this mean we don’t have to perform this step, rather the sharing of the app to the users takes care of this automatically?

    At some point I assumed so, but this isn’t actually the case. After a long hard look at the documentation, I finally realized that the MS product team had squeezed this functionality into the Canvas sharing dialog in quite an unintuitive way. You see, you’re not only using it to share the app to the users, but also for “sharing” the app to a security role:

    So, rather than sharing the app to the users, stay on the higlighted App section that’s at the top of the list. Pick the correct security role from the list and then click “Share”:

    Now all users with the specified security role will have access to the app when trying the URL shared with them. Yes, you didn’t actually need to explicitly share the app to them via this menu at all! Sure, you can use it for adding the required security roles for these users, if they haven’t already acquired through other means, like group membership. But the whole concept of “app sharing” is still completely irrelevant to Model-driven apps, from what I can see. It’s only this misleading UI that may give you the impression that you can achieve visibility to Model-driven apps via a sharing action when in fact it’s still security role based like it was back in XRM.

    This leads us to the next question around Model-driven app visibility that has been puzzling me:

    “Where can I find the apps I have access to?”

    If the app user is not a maker in the particular environment, they logically won’t have access to the Power Apps Maker portal to view the list of apps in it. So, from where exactly should they be viewing the list of all the apps shared to them?

    If we have past experience from the world of XRM then we’d probably navigate to the Dynamics 365 Home page at home.dynamics.com. This page should be showing all the apps that the user has access to, which it currently does. We can pin our newly shared Model-driven app to the top of the list for easy access:

    Oh, right. “We’re moving to Office” says the banner, since this Dynamics 365 Home page has been deprecated a while ago. In fact, based on the original deprecation message this page should have started to automatically redirect you to office.com/apps already. Today we still have the option to visit the legacy page, but let’s move over to the modern Office experience. We’re greeted with the “launch your business apps” onboarding dialog that points us to the Business Apps tab at the Office 365 home page:

    Looking at the list of apps, though, we probably won’t see our brand new app here right away. There’s a pretty significant delay in the list of business apps getting updated here. Unlike the old Dynamics 365 Home, which suffered from a similar delay, we don’t have a “Sync” button to make this process any quicker.

    While we’re waiting for our new Model-driven app to show up on the Office 365 home page, we may start to wonder what apsp actually are listed here. For instance, why is Solution Health Hub showing up there for a normal user with no admin nor maker roles?

    Perhaps the Model-driven apps visibility isn’t entirely security role based after all. Whatever the reason why these Microsoft built apps like Solution Health Hub or Resource Scheduling from the default environment show up for a non-admin user, it’s not exactly a pleasant user experience. The Office 365 home page doesn’t offer us any pinning or filtering features like the old Dynamics 365 home page did, so there’s not much an end user could do to clean up the mess.

    As a system administrator, though, we actually do have a way to trim the list of apps – even when they are first-party MS apps. Thanks to fellow MVP Alex Shlega, I recently learned that Model-driven apps can now be deactivated and activated. So, let’s go to the Maker portal in the default environment, pick the apps we want to hide from office.com/apps and select “Deactivate”:

    Much better! Not only have the unwanted apps disappeared from the Business Apps list, but also our newly configured Model-driven app has appeared there during our small exercise.

    There still remains one item on that app list that I can’t figure out a way to remove from the user. That “Dynamics 365 – custom” app from the Secret Project 404 environment is actually the result of a Dataverse for Teams environment provisioned by this end user. Now, since we have no way to directly navigate to the full Maker portal of such an environment and they shouldn’t support any Model-driven apps to begin with, these apps are something only MS can clear away in a future update hopefully

    Thankfully there’s another place where the end user has more control over the app list than the Office 365 home page. Whenever you’re using some other Microsoft 365 service and need to open up a Power App, it’s a lot more convenient to use the waffle menu from the top left corner rather than the full home page.

    Thanks to Thomas Sandsør for reminding me about the customizability of this app launcher. This is of course the place where a user should be instructed to pin their new Model-driven app for easy access:

    One final point to make about Model-driven apps visibility is around Microsoft Teams. You should definitely consider pinning the apps into relevant Teams channels as tabs, to maximize the likelihood of the end users remembering to use them. As for a complete list of Power Apps available to the user, currently no such place exists within Teams, so you should pay attention to the Office menus as the portal to display your Power Apps app catalog for desktop users.

    Update 2021-12-07: Office App Launcher new visibility criteria defined

    Microsoft has recently changed the behavior of their app lists, with an update communicated via Microsoft 365 Message center message MC290818. Since many people will not have access to MC content and it will probably disappear at some point, I’ll post the contents here in full:

    To help improve the app exploration and discovery experience for users, beginning mid-November 2021, the Office App Launcher, All Apps (https://office.com/apps), and app search experiences will be updated to only list relevant Dynamics 365 apps, Power Apps apps, and Azure Active Directory integrated apps.

    Following this update, the Office App Launcher, All Apps, and app search experiences will only list Dynamics 365 apps, Power Apps apps, and Azure AD integrated apps that meet one of the following criteria:

    Dynamics 365 apps and Power Apps apps:

    • Apps a user has launched in the last 7 days
    • Apps created by a user
    • Apps an admin has marked as ‘featured’ in the tenant
    • User accessible Microsoft published Dynamics 365 apps

    Dynamics 365 apps or Power Apps apps that meet the above criteria will be shown in the App Launcher, the Business Apps section of the All Apps experience, and in app search results. Note that the time between when an app is shared with a user and when it appears in an Office experience is expected to be 24 hours.

    Azure AD Integrated Apps:

    • Apps an admin or user has added to an Azure AD collection

    Azure AD integrated apps meeting the criteria above will be shown grouped by collection name in the All Apps experiences, as well as individually listed in the App Launcher and in app search results. A link to the My Apps portal where users can create Azure AD collections will be added to the All Apps experiences as part of this update.

    How does this affect me?
    Dynamics 365 apps, Power Apps apps, and Azure AD integrated apps that don’t meet the above criteria will no longer be listed in the Office App Launcher, All Apps, and app search experience. Users can take the following steps to access these apps and have them listed again in their experiences.

    For Dynamics 365 apps and Power Apps apps, if a user cannot find an app they are looking for will need to first launch it in the browser via its Uniform Resource Identifier (URI). Note that admins and makers can get an app’s URI by selecting an app in the Power Platform admin center or via https://make.powerapps.com by selecting details, then selecting web link. Once the app is launched, it will be listed in the Office App Launcher, All Apps, and app search experiences.

    For Azure AD integrated apps, a user can locate the full list in the “Apps” collection of the My Apps portal. Users can create collections for quick access to their favorite or most often used Azure AD integrated apps. Once the Azure AD integrated app is added to a collection, it will be listed in the Office App Launcher, All Apps, and app search experiences.

    What action do I need to take?
    This message is to inform you of an upcoming change, no action is required. However, if you want to guarantee specific Dynamics 365 apps, Power Apps apps, and Azure AD integrated apps are available to users following this update, please perform either of the following:

  • Democratizing code

    Democratizing code

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

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

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

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

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

    Wikipedia: Democratization of technology

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

    From code-first to low-code

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

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

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

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

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

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

    Excel is eating the world

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

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

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

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

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

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

    Professionals vs. Citizens

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

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

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

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

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

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

    Are they simply “Makers”? Time will tell.

    Where democratization may lead us

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

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

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

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

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

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

    Opportunities and threats of low-code

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

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

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

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

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

    Can’t put the genie back in the bottle

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

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

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

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

    Early days still

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

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

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

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

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

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

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

  • Account address capture & mapping with Power Apps

    Account address capture & mapping with Power Apps

    In the Power Apps team blog there was an announcement of the GA availability of Geospatial Features for Canvas apps. In short, we now have a preview of two new controls powered by Azure Maps:

    • Address Input control which suggests the correct address based on partial street names and autocompletes attributes like city, postal code, country, latitude/longitude.
    • Interactive Map control to show one or more records from a dataset as pins or cards on a visual map .

    I decided to do a quick test of how to leverage these new capabilities in a simple scenario where we are managing account address information via a Canvas app running on a phone screen. Here is the end result:

    Simple yet effective! Let’s explore the steps I needed to perform to achieve this functionality.

    Source data

    As a starting point, I’m using a pure Dataverse environment with no Dynamics 365 components. Instead, I’ve installed the free RapidStartCRM solution to give me a simplified CRM data model, plus a fully working Model-driven Power App. I could embed this inside Microsoft Teams and use it via a channel tab, for example:

    In our scenario I want to offer the users a simplified UI to be used on a phone screen, with only a small subset of the full features found in the Model-driven app. I’ll focus just on the account data, which means I can simply start by going to make.powerapps.com and choose to generate the mobile app based on a data source. In this case I’ll select the account table in the Dataverse environment where RapidStartCRM is deployed. This gives me the basic 3-screen UI for browsing, viewing and editing records (yeah, I know, “rows” – but I refuse to adopt this part of the latest MS BizApps naming bingo results just yet).

    I want to create a custom data entry UX for this demo scenario, so I’ve added a “+” button at the bottom of the gallery screen to launch a new screen where I’ll be leveraging the geospatial features.

    Address Input control

    It’s never a fun task to enter the address details when creating new account records, especially when on a mobile device. Instead of asking the user to fill the various fields included in an address, we’ll add the new Address input control from the Input menu onto our “Add new account” screen. From the control’s documentation page we can see there are a number of input properties we could use, but it works quite well just by dropping it as a field onto the form and starting to enter text:

    In my case, I did limit the country set to “FI” to give me just Finnish streets for my demo app. It looks like you need to enter the street name and number before anything is suggested by the Azure Maps API, but you’re allowed to have small typos in the street name, so there’s some fuzzy matching logic applied here.

    The real benefit of the Address input control is in the 19 output properties you get from it. Ultimately I’ll want to use them to A) show the map control based on lat/lon and B) store the data onto the new account record the app will create. But first, it’s nice to see the control’s output on the screen while updating values, so I’ve added a few labels where I display the results from the selected address. To do this, I’ll reference properties like AddressInput1.PostalCode and AddressInput1.Municipality to construct a nice looking string for the text property of the label:

    This exercise will also help me in identifying how I’ll need to concatenate properties like StreetName and StreetNumber to create a valid value for the Dataverse account table’s Street 1 field eventually.

    Map control

    Seeing a map view where the address we’ve inputted is physically located is a big factor in the app’s user experience. We’ll want to give visual confirmation to the user that the address is actually at a location where they expected it to be, plus the ability to zoom in/out on the map to explore the surroundings. So, while in the Power Apps maker studio, let’s click on the Media dropdown and add the Map control onto our screen.

    Hmm, how do we then tell the Map control to zoom in to the address we’ve selected in the Address input control? I had to browse the Interactive map component documentation for quite a while to figure out a way to do this, as it wasn’t entirely obvious how to visualize an individual address rather than a table of records. What I ended up doing was to go into the OnChange property of the Address input control and create a SelectedAddress variable to be set to the chosen address whenever the field’s value changes:

    Set(SelectedAddress, Table({Label:tiAccountName.Text, Longitude:AddressInput1.SelectedLongitude, Latitude:AddressInput1.SelectedLatitude}))

    Note that in my app I’ve got a Text input control tiAccountName into which the user is requested to type in the name of the new account being created, before proceeding to work with the Address input control. I’m picking that name as the label to be shown on the map pin.

    Then in the properties of the Map control I’m setting the values of ItemsLabels, ItemsLatitudes and ItemsLongitudes properties to reference my SelectedAddress variable’s respective properties:

    There’s a variety of other input properties for the Map control, many of which I didn’t yet tweak in my demo app. For example, setting the default location to be that of the current location of the user’s device might be a good idea, but a quick test in the browser didn’t yet tell me how exactly I’d then replace that with my custom location from the variable. I’m sure the will be plenty of ways to optimize these map parameters when connecting them with your app’s business logic and data.

    Saving the account + address

    Finally we need to store the account name and address details onto a new Dataverse record in the account table. As we aren’t working with the form control here, it’s time to use the Patch function. I always need to check the Docs page for the exact syntax, but when working with simple text fields in the target table, the formula isn’t all that complex. On my Save button of the “Add new account” screen I’m running this:

    I’m storing the results of the Patch function also inside a NewAccount variable, so that I could reference the values further in the UI if needed (confirmation dialogs, for example). No error handling or anything else fancy here in the demo app, instead I’m just navigating the user to a “Success!” screen after the record has (hopefully) been saved in Dataverse:

    The “Success!” screen has an invisible timer control set to auto start and a duration of 3000 milliseconds. In the OnTimerEnd I’m doing housekeeping like setting the SelectedAddress variable to Blank(), resetting the Account name text input, then navigating the user onto the account browse screen that will show our newly created account somewhere in the gallery. Another option would of course be to take the user onto the full Edit Screen of the record, to enter further details via the standard form control if needed:

    That’s all there is to it! All in all, my first impression from these new geospatial features is quite a positive one. It’s important to note that since they are using Azure Maps service behind the scenes, these controls have the “premium diamond” next to them in the UI. This means you’ll need to have a premium license like Power Apps Per App or Power Apps Per User for users who are taking advantage of these address mapping features. Also keep in mind that the Power Platform environment where your app lives in must be enabled for geospatial features by the admin.

  • Make your Power Apps search experience more Relevant

    Make your Power Apps search experience more Relevant

    Microsoft recently launched a brand new search experience for Model-driven Power Apps and therefore also first-party Dynamics 365 apps operating on top of CDS. This is a significant step forward in the “non-structured” search capabilities in Power Apps. The structured queries one can construct via Advanced Find were always one of the most powerful features that the XRM platform could offer on top of relational data (and remain one of my most read posts on this blog). Now also the free text based search experience is catching up nicely:

    Being a low-code application platform, there are several configuration options related to how the search features in Power Apps behave. This can also result in people missing out on how they could ensure that the search really works the way that the users would expect. In this blog post I’ll go through some common challenges that the Dynamics 365 professionals may have already learned to overcome but which can be surprising to new Power Apps makers.

    Challenge 1: Relevance Search is not enabled

    If you’re not seeing anything even remotely like the MS blog posts when performing a search in a Model-driven app, then you may well be using the limited Categorized Search instead of the fancier Relevance Search. When attempting to change the search type, you might discover that the dropdown actually doesn’t give you any choices, i.e. it’s a dead end with Categorized Search as the only option:

    Why does this Categorized Search option even exist, and why do we need to specifically enable Relevance Search? It all comes down to the on-premises legacy of the platform, where the single CRM server had to be capable of offering a standalone search option. In the cloud era we can leverage Azure Search as the external search index database to where CDS data is syncrhonized to, thus offering a far richer search experience.

    Now, Azure Search being a separate service and possibly having different types of SLAs and other legal variables than the core Power Apps or Dynamics 365 services follow, it’s not on by default even in the MS cloud. An administrator will need to navigate to the Power Platform Admin Center, choose the environment, then go under Settings / Features / Search to flip on the swith that turns on Relevance Search.

    Once it’s enabled, only then will you see the option to also turn on the new search experience (which probably will become the default option in the future). It won’t show up there immediately, so give it a lil’ time.

    Challenge 2: Relevance Seach doesn’t search my entities

    Cool, we’ve now got the new UI up & running. When we do a search from the new prominent search bar always visible at the top, the results are returned for some of the entites. But why aren’t we getting any hits for Widgets, for example? In this scenario we know there are records in there that contain matches to our search string.

    Even though Azure Search provides a richer search index for your Model-driven Power Apps, it doesn’t directly copy each and every table from CDS into it’s database automatically. When working with a Dynamics 365 environment there are some default entites covered (like accounts, contacts, opportunities). For any custom entities and especially with custom apps, you’re gonna have to explicitly tell which entities should be enabled for Relevance Search.

    To access this configuration option you’ll need to leave behind the modern Power Platform Admin Center and venture into the land of the legacy web client and Dynamics CRM era customization UI. You can either add “/main.aspx?settingsonly=true” to your environment URL or find another path into the land of more advanced options. Once there, find Settings / Customizations / Customize The System and open up the Entities menu in the Default Solution window. Now you’ll see what entities are included in your Relevance Search Index and which are not, i.e. they are in the Available Entities list:

    Select the entities you want, click OK, then Publish All Customizations and now they are enabled for the modern Relevance Search experience.

    Challenge 3: Relevance Search doesn’t search the right fields

    Hmm, why aren’t we still getting the full search results for our Widgets entity, even though we added it into Relevance Search? Well, technically you didn’t add the whole entity into the search index. By default a custom entity seems to pick up only the primary field (usually “name”) into the search scope, but it’s likely that you’ll have plenty of other important field that should also get indexed. The same goes for default entities: only a subset of the standard fields are included, and none of the custom ones are, unless you configure them to be included in Relevance Search.

    If finding the menu from where the entities list for Relevance Search is maintained was a bit tricky, then figuring out the place for specifying the field level search settings ain’t that obvious either. You see, it’s not a property of the field in the entity itself. It’s the inclusion of that field in the entity’s specific view called Quick Find View that determines what gets pushed to Azure Search database and back to Power Apps UI.

    Even though the entity view editor can already be found in the modern Maker Portal for Power Apps, these settings aren’t there yet, so I hope you didn’t close that legacy customization UI just yet!

    From the legacy Solution Explorer, open the Quick Find View for your entity, select Add Find Columns from the right and check the boxes for the fields you consider to be potentially useful for Relevance Search. Save & publish your changes, then verify that the search results match with your expectations.

    Challenge 4: Relevance Search doesn’t cover inactive records

    Sometimes the information you’re looking for isn’t found on records that are actively edited anymore, as you may be digging further into the history of your business data to check up on past transactions. In the typical CRM scenarios where Model-driven apps are leveraged this could mean searching through historical sales opportunities that are either won or lost, to find examples of what offers have been made to which clients on what specific terms.

    With the out-of-the-box configuration of Dynamics 365 or Power Apps, you won’t find them via Relevance Seach. Yes, the vast majority of records that you’re storing in CDS may well be excluded from the search index by default. This is because of the same Quick Find View we visited earlier. Not only does it control the fields being indexed, as well as the column layout of the search results page. It also controls the static filters which are applied to the search results before they are shown.

    Using the OoB opportunity entity as an example, you’ll find a system view called “Quick Find Open Opportunities” under the entity. Click on Edit Filter Criteria to reveal the fact that it indeed does only include open opportunities. While we can’t create additional Quick Find Views for entities, luckily we have the freedom to modify or delete the existing filters. So, just remove that status field filter criteria, save & publish. Now your Relevance Search will also return results from the inactive records for this entity.

    Challenge 5: Relevance Search suggestions aren’t found in the search results page

    The new search experience has a nice UX for suggesting matching records immediately as you type the letters in your the search term. Let’s say that we’re interested in the search term “relevance”. By the time we’ve entered “relev” into the search bar there’s already a number of matches in the suggestions box:

    Looks great, but I think I want to see more details, so I’ll click on “show more results” at the end of the search suggestions. Hey, where did all those matching records go?!?

    Unfortunately this is a challenge where you can’t configure way around it (at least yet). For the time being, this actually is by design. Taken from the documentation, Microsoft lists the suggestion feature separately from the actual search requests:

    Suggestions provide a list of matches to the specified search parameter value, based on an entity record’s primary field. This is different from a regular search request because a suggestion search only searches through an entity record’s primary field, while search requests search through all relevance search-enabled entity fields.

    So, the search box and the search results page follow different logic, which is why it is expected that they will show different matches. This may be seem quite complex to explain to the app end users on a detailed technical level, so it’s better to just instruct them to always apply the wildcard character * at the end of their search term. The results are likely to be closer to what they expected to see:

    Hopefully these 5 tips will help you in setting up the basis for more relevant search results and a better user experience in your Model-driven apps. For more comprehensive guidance, check out these three different levels of documentation that Microsoft provides on the Power Apps seach features: