In the past, I have written a lot of posts on this blog under the Licensing category. Ever since I moved on to writing my weekly newsletter on beehiiv, there’s been a bit of a conflict in my mind about “where should the licensing stuff go?” Because I acknowledge it’s not necessarily something to casually drop into the weekly articles of Perspectives on Power Platform.
What started out as a fun domain I discovered to be free has now turned into a proper website with both persistent pages as well as blog posts on recent events. True to its name, this site does also provide you the quickest possible way to view the latest licensing guides from Microsoft, via the Resources page:
I figured there’s no point in always going via search engines to the latest guide versions. Or to keep some of the commonly referenced MS Learn pages as bookmarks in my own browser only. Better to just put it out there on the internet.
Whenever Microsoft announces something that will shake up their licensing model, like the new per-agent licensing of Agent 365, I will be keeping an eye on the scoops and info leaks as part of this strange hobby that I have. There’s now an obvious place to post these kind of updates, with The Licensing Guide blog section.
The added benefit of collecting your research into one place is that this makes the data easy to chat about with AI tools. That allows turning the complex new concepts buried in MS marketing lingo into illustrations that explain things without the smoke and mirrors. Such as creating mermaid charts from product documentation. Or constructing alternative FAQ pages from product announcement details and docs, like I did with the A365 FAQ page.
As far as topics in the Microsoft ecosystem go, there’s hardly anything less demonstrable than licensing. Yet occasionally I still get the feeling “I’d want to show this in action”, which is when I might record a quick video and put it on YouTube. Like this latest one about the Dataverse Capacity Calculator I built:
Which gets us to another unlikely combination: licensing + vibe coding. Yet that’s exactly what I’ve done with the above-mentioned Dataverse Capacity Calculator. After having a thorough discussion with my AI assistants about the contents of the latest licensing guide PDFs from Microsoft, I instructed them to “go and build me a calculator with these rules”. Now it’s an actual thing that exists on GitHub. Do I fully trust the output? No, whenever problems are found, I’ll just log an issue and assign it to Copilot.
Some might think this isn’t how you should treat serious business topics like software licensing. Yet when I started actively blogging about Dynamics 365 and Power Platform licensing back in 2019, that wasn’t a thing any community member was doing either. These days, you’ll often find licensing-related sessions in community conferences like DynamicsMinds. And even at an upcoming pro-dev conference like Update Days: Power Platform.
I believe the best way to make an impact in this world is to A) find something that people don’t normally do, and then B) just do it. It has been proven to work with citizen development, citizen publishing (i.e. blogging) and all kinds of areas in life.
Remember this, kids: you can be whatever you choose to be. I chose to become the licensing.guide. Because why not? 🦸
When you’re starting to use a brand new computer or phone, usually one of the first things you’re presented with are these questions:
What language do you want me to speak?
Where are you located?
This allows the device to understand not just the preferred UI language and your physical location. It also enables it to make educated guesses on:
Which formats make sense to you for number, date and time fields.
What time zone you are living in.
Now, let’s move from devices to software, namely model-driven Power Apps. Do you recall seeing similar onboarding prompts when starting to use (or build) apps? Nope, Microsoft doesn’t ask such questions.
“I guess they already have that information and are automatically setting things up the way I want them.” Yeah, you might think so. That’s a false assumption, unfortunately. Changing your Microsoft 365 account settings for your tenant isn’t going to get synchronized down to the business applications used in the MS cloud. Meaning, this selector here has no impact on the apps that live in Power Platform environments:
Power Apps canvas apps follow the regional settings from the user’s browser. This can lead to confusion as well, but at least the field formats should be something the users encounter on other websites. In canvas apps there is also the ability for the app maker to force specific locale settings per each control in the app UI. See examples in this article.
Model-driven Power Apps include Dynamics 365 apps from the CRM side. I would guess that for a sizable share of model-driven Power Apps users their settings are likely to be at least partially incorrect. What’s worse is:
Fixing them is quite unintuitive.
Admins can’t do much to help users with this.
In this post I will explain the parts of the Power Platform user settings management story that are broken today. My intention is to spread awareness on issues that many app makers and admins may have ignored, and which their app end users may be suffering from.
In a follow-up post I’ll provide an example of a solution that could make life easier for everyone who uses, deploys or administers Power Apps.
First: blame CRM
There are many great benefits that Power Apps has gained from being merged into another Microsoft platform that first saw the light of day as Dynamics CRM (well, “Microsoft CRM”, to be precise). User settings management is not one of them, unfortunately.
The user settings functionality probably served its purpose back in the on-premises days of CRM servers. Today, this legacy from around two decades ago creates some incomprehensible experiences for an audience many times the size of that which ever interacted with Dynamics CRM.
Power Apps, be it canvas or model-driven apps, live inside Power Platform environments. It is becoming a standard feature that such environments include a Dataverse database. This is essentially what one CRM database was back in the days. Today, larger tenants may easily have hundreds of such database instances.
Dataverse hosts many essential parts of Microsoft’s low-code platform. It provides the solution framework for moving apps and related components across dev-test-prod environments, for example.
There are hundreds of tables (previously “entities”) in the standard schema, with some being meant for storing business data and others for data needed by the system itself. The User Settings table is what the topic of this blog post revolves around.
Each to their own (format)
When your app is connecting to tables in Dataverse and presenting it to the user, the decision of the number, currency, date and time field formats is made on the server side. It defines whether your app UI shows “one million dollars” as:
$1,000,000.00
1 000 000,00 $
$1.000.000,00
Or any other variation. The place and purpose of dots, commas, spaces, currency symbols depends on what the format has been set to on the database side. For each user account.
That’s the important part: it’s not a global setting of the database/environment. Every user may see different things. We are all different as human beings, and it’s a wonderful feature for the system to reflect that as well.
Us humans are also wonderful in our abilities to interpret what the format being used by the system might be. All the three examples above would say “one million dollars” to most people, even if only one format is the official sequence of strings used in whichever region they live in.
With dates, it can be a bigger struggle. Today when writing this blog post, the date is 2/3/2023 – for some part of the world. If you come from the land of Microsoft, it means February 3rd. For basically everyone outside the US, it would mean March 2nd (which is the correct value here). ISO 8601 would be the best format from a logic perspective, yet for some reason 2023-03-02 hasn’t become the norm. Oh well.
We may be able to guess the right date format based on context. Where it gets really dangerous, though, is with time zones. They are invisible to the app user and you’ll have no way to know whether you’re seeing the correct value in any date field of the app.
Why’s that? Because dates in Dataverse are often stored in date and time columns. This means that while the clock on my PC currently says “2023-03-02 21:10”, the user looking at a record in Power Apps may see:
2023-03-02, or
2023-03-03
In Finland it’s March 2nd, but in India it’s already March 3rd. Not only is the value that’s shown to the user determined based on their time zone setting. It also affects the value that is written to the database when the said user enters new/updated data.
There are ways to get around this dilemma, using Date Only or Time-Zone Independent columns in Dataverse. That’s not going to help the app end user, though, since A) the column type it’s not visible to them nor B) configurable for their preferences.
One classic gotcha of the time zone settings is that they affect all user accounts – also calls made via the API instead of the UI. If you’re writing integrations to or code running inside Dataverse, you’ll need to dig a lot deeper into the topic than the shovel that I can give you is good for. Head towards a blog like Scott Durow’s and learn from the master.
Setting the user’s own settings
Now that we’ve established that user settings like time zone and field format are very important things, let’s look at how a user can make sure that they are indeed set correctly.
Say you’re using a Power Apps canvas app and want to check your user settings. Where do you click in the app? That’s the neat part: you don’t. Even if you have the Power Apps navigation bar visible (which might have been hidden intentionally), none of the menu options give you access to the user settings used by the app.
OK, let’s assume that you have been granted maker level access to the environment hosting this app (end users often will not have this option). We go to the Maker portal on make.powerapps.com and click around the similar cogwheels.
From under “Power Apps settings” we get to a promising menu dialog that has a “language and time” tab. Unfortunately, there’s nothing related to time in there. Furthermore, we’re not looking to change our language settings, rather the regional format.
Most people will have already given up at this point. Yet if you’re not afraid to click on obscure menu options, you might find a model-driven app in the same environment. Like the omnipresent Solution Health Hub that Microsoft wants to provision everywhere without asking for permission. This time we’re actually lucky to have it as the only model-driven app in our environment.
Let’s open it up. Don’t worry about that “Active Analysis Jobs” view that opens by default, no one understand what these things are about. What we’re really hunting for is cogwheels and we luckily do discover a new one, in the exact same place as the earlier ones. This opens with a promising menu option: “personalization settings”.
“NOOO!!! MY EYES!!! WHAT IS THIS THING?!?!?” No, don’t panic. You’re in the right place – even though it looks like nothing you’ve encountered in Microsoft 365 apps. What we have here is the classic Dynamics CRM web client UI presented inside a modal dialog window of the Unified Interface. Yes, it reads “Dynamics 365” everywhere but trust me, this is part of Power Apps.
On the General tab you’ll find the Time Zone dropdown menu. If it reads something else than you expected, change the value now. Then hop over to the Formats tab and do the same check/change for the Current Format field.
Click OK. Close the window. Take a deep breath. You made it.
Just don’t forget what exactly you did to get to the user settings screen. Because these settings are environment specific. The next time an internal app is deployed in your organization, it may well be hosted inside a different Power Platform environment. With user settings that are completely independent from the ones you just updated.
“As an administrator, I want to end the pain…”
Given how many potential blockers there are for a Power Apps end user to ever discover nor even be allowed to navigate to the user settings screen, this is something the Power Platform administrators should definitely look into. Is there a way to change the settings on behalf of another user?
Let’s find out. We’ll go to PPAC (Power Platform Admin Center) and navigate to the environment. From the Users list we open up one user account and study the options available.
We see a nice flyout menu that resembles Microsoft 365 admin center experience in many ways. Unfortunately it doesn’t contain anything related to time zone or format settings. Behind the three dots, there’s a “Manage user in Dynamics 365” option. By now we’ve already become aware of how broadly Power Platform relies on things that say “Dynamics” so we know we probably have to click on it.
The initial loading of the page may take a few seconds/minutes/weeks, but once it opens up we see… OH DEAR LORD!!! Not only did we move to Dynamics 365, we actually travelled back in time into CRM 2013 user interface.
We’re presented with notification banners shouting scary things at us. We have a form that contains fields, grids and feeds that seem to be design to just confuse us. We have an endless menu bar with options like “reject email” (wouldn’t we all want to reject it?) and “change position” (would fetal position be a good option right now?).
What we don’t have is access to any of the user settings. This is by design. Sure, no one said it’s a good design, but it is what it is. The answer to our original question is: there is no out-of-the-box option for system administrators to change user level settings on behalf of another user.
It’s design like this that has given inspiration to a countless number of community tools, many of which are available in XrmToolBox. If you need to administer Power Apps that have any dependencies to Dataverse, the first thing on your To Do list should be installing this software on your local PC.
XrmToolBox User Settings Utility is the plugin you’ll want to reach for in the toolbox. Once you establish a connection to a Power Platform environment (always choose the “Microsoft Login Control” option, btw), you can click “load users and settings” to see every user account in the environment. Select one of them to check the current values.
Not only can you modify the settings (time zone, format and many more) for another user. You can also do this in bulk for all selected users. “Woohoo! Now the settings are fixed!”
Until the next user comes along. Or you have a new Power Platform environment that needs equal treatment. Again and again. Being a desktop application, you unfortunately can’t automate the actions that XrmToolBox does. Well, unless you go crazy with Power Automate desktop and build an RPA bot for this…
Is there any better way?
The bright side of having the user settings data stored in a Dataverse table is that we are empowered to use the platform’s tools to build user interfaces and automations for managing it. With low-code.
I have come across a few blog post with examples of how to use Power Automate cloud flows and/or Power Apps canvas apps to update the user settings. For example, my colleague at Forward Forever, MVP Timo Pertilä, recently wrote an article about how to set the number formatting for model-driven Power Apps (auto-translated from Finnish).
As it just so happens, I had also started exploring these possibilities at the exact same time as Timo. My approach is a bit different, since the goal was to resolve the issue not just on a single environment level. So, I’ve created a tool that allows any user to go and update their own settings across multiple environments. Stay tuned for my next blog post where I present the solution.
Last time when the 2022 Release Wave 2 was announced, I wrote about why you should not pay too much attention to these bi-annual release plans. Instead I was encouraging everyone to start using the Release Planner website that listing all the planned and recently launched features as a roadmap site with no artificial boundaries between “waves”.
Now when the 2023 Release Wave 1 materials were launched today, Microsoft defaulted to pointing people to this Release Planner site (here’s the Power Platform 2023 RW1 link). Of course the challenge with that approach is that all the hot new stuff is just behind one small “release wave” filter in the list:
There are still some usability challenges with the Release Planner site that have kept me browsing through the Microsoft Docs Learn when looking for release item information. So, here’s the “switch to classic” bookmark that will take you to the MS Learn edition of the same release wave information: https://learn.microsoft.com/en-us/power-platform/release-plan/2023wave1/
There was now a nice higlights video made on the Power Platform 2023 Release Wave 1 launched on the very same day as the release plans were published. The challenge with this kind of material is that you can’t really show realistic demos about features that might be launched half a year from now, so keep that in mind when watching the video.
As always, there’s a lot to digest in the plan and you might therefore be interested in reading the hand picked top items by some trusted folks in the Power Platform community. As a purely subjective opinion, here are the top 5 items in 2023 RW1 that I was initially most excited about when reading through the plan.
Fluent UI everywhere
We’ve seen the concepts and components from Microsoft’s Fluent Design System introduced here and there when it comes to Power Apps and Dynamics 365 app UIs. The Power Platform Creator Kit has brought Fluent UI controls available to canvas apps built by advanced makers. Demos of the future model-driven app UI have included features like dark mode that are familiar from the more modern product UIs on the Microsoft 365 side. Now with 2023 RW1 there should finally be a wider roll-out of these modern controls for the MS low-code application platform, too.
You may remember that small tweaks to the model-driven UI have been taking place in pretty much every release wave. This update should be a lot more impactful than the previous ones – which is why it will be rolled out behind an opt-in switch initially. You can expect some things to break in the process, so it may take a while before MS will dare to push it out to all users by default.
Canvas apps, on the other hand, have been living in a split reality for a long time already. Dataverse for Teams based Power Apps have used the Fluent UI controls since forever, causing friction for app development across Teams vs. full Power Platform environments. Hopefully this coming update will now bridge the gap and get us closer to the dream of “Run One UI”.
Responsive canvas pages design experience
The one place where model-driven apps have felt clearly superior to canvas apps in their UI capabilities has been the responsiveness of the screen layout. Their many constraints on adjusting how the menus and forms can (or rather can’t) be configured have in turn made it amazingly simple to adjust to different screen sizes. The platform handles it out of the box, the maker doesn’t have to worry about it much at all.
Building responsive canvas apps has been technically possible, yet something that feels quite tedious. I’ve mostly had to deal with responsiveness in apps built in Dataverse for Teams, where worrying about which fields, columns and buttons fit onto the screen when surrounded by the Teams UI chrome has been one of the unavoidable everyday frustrations.
2023 RW1 release plan gives us a glimmer of hope by showing a screenshot of the coming responsive layouts and spacer tools in the canvas studio. The ability to resize controls and spacing directly in the authoring canvas could greatly reduce the effort needed in achieving sufficient levels of app UI responsiveness. Not on the same level as model-driven for sure, yet it could offer a decent compromise between precise control positioning and responsive reflow of controls on the page.
Control system administrator role assignment
No matter how granular the security model in Dataverse is, this granularity has vanished when you go up to the admin roles. Every Global Admin or Power Platform Admin will automatically be granted the sysadmin role for every Power Platform environment in the tenant. While it makes sense that people with powerful roles get wide access, it is often not desirable that such user accounts would by default see all data, be it via UI or API. After all, usually the admin roles need the power to change settings and work on the metadata – not the actual business data managed in Dataverse.
Now MS is promising that customers will be able to manually assign the System Administrator role to appropriate users in the environment. This is a very welcome feature to have control over the auto assignment, even though we don’t yet know now exactly what process will be built around this. Also keep in mind that certain governance features like this might get bundled into the Managed Environments capability, which would limit its available to premium licensed users only. Let’s see how it goes.
Personal environments with Dataverse
It has already been possible for users to sign up for the Power Apps developer plan – as long as they are aware such a thing exists and find the right path to acquire it. Now MS is going to promote these type of environments to Power Platform makers much more prominently within the product. They will be called “personal environments” and the idea is to lower the barrier for all makers to experience premium capabilities like Dataverse.
Unlike trials, personal environments won’t expire. Unlike sandboxes, the makers won’t need help from the Power Platform admins of the tenant to get a personal environment provisioned. There will be new governance capabilities introduced that give admins the possibility to disable this feature if required, yet hopefully most organizations wouldn’t need to introduce such a limit. Personal environments don’t consume tenant level capacity, so as long as there’s a solid governance plan in place to apply DLP policies, the risks should be fairly low with these personal environments.
Check out this Power CAT Live video for more details about the developer plan and its enhancements (YouTube embedding disabled by Microsoft): https://youtu.be/yXRSnN2AWTs
Paginated reports editing on the web
Back in 2006 when I got introduced to the technology that later became Power Platform, the one area that struck to me as incredibly difficult was report creation. SQL Server Reporting Services had just replaced Crystal Reports with a native Microsoft technology in the stack. While there was plenty of advanced features available for summarizing data, the number of hoops you had to jump through to get any of the business data from the relational database onto a PDF output made sure that only the bare minimum number of reports were ever created.
The age of Power BI unlocked this precious data from the enterprise reporting tools and allowed basically anyone to slice & dice it to their heart’s content. Yet the paginated report design tools didn’t seem to evolve quite as rapidly. Neither was there much (well, any) progress made on the Word mail merge side for making it easier to produce documents with dynamic data. Recently many Makers have gone ahead with Power Automate and used HTML as the intermediate format on the road toa PDF output. None of these methods have really been very citizen friendly.
Is this about to change now? In 2023 RW 1 Microsoft is going to allow you to create and share paginated reports on the web, through a WYSIWYG design experience. “Create invoices, financial statements, and other operational reports with low code, drag-and-drop experiences on the web. You can share these in a variety of formats or just print them out!” That sure sounds like something most customers would prefer over the existing options for using dynamic data in documents. Let’s see how far this first iteration of the new editor in Power BI will get us once it arrives in the summer.
What’s missing from the plan?
To better understand the direction of Microsoft products, you should not just get excited about the features MS actively advertises. You should also search for things that are not mentioned. This will help in seeing behind the product marketing hype and making smarter decisions on your own investments of time and other resources.
Microsoft Teams doesn’t get much love in the Power Platform release plan. On the Power BI side there is the new teams meetings integration and enhancements to multi-tasking in the Power BI app for Teams. Power Automate touches on Teams in the sequential approvals feature. And that’s pretty much it. No word whatsoever on whether MS plans to keep investing in Dataverse for Teams, for example, which seems to have been largely abandoned after the initial launch 2 years ago.
If we ignore AI Builder, there aren’t too many mentions of products delivering shiny new features with the help of AI. Given how much talk there has been about Microsoft investing billions of dollars more into OpenAI and bringing ChatGPT features into their existing products, this could surprise the reader. Now, it’s important to understand that these release plans for the release waves are hardly ever the place where big splashy announcements like that are made. They are more about the incremental improvement of existing products.
Remember: new things will appear into the release wave between now and September 2023 (end of the wave). Similarly, we can expect a certain percentage of items in the release plan get delayed, postponed to a future release wave or cancelled entirely. Remember to keep an eye on those changes on a regular basis, instead of just studying the Power Platform roadmap twice a year.
Of the things that were added to the plan during the 2022 release wave 2, Cards for Power Apps does not exist at all in the new release plan. Does that mean it’s “done and ready”? No, it’s just sitting in the release plan from the previous round with no GA date and still a lot of things to be improved before being ready for real life use.
Looking at much higher profile initiatives on the same area, Microsoft Loop still doesn’t seem to be a thing either. ContextIQ is mentioned on the Dynamics 365 Business Central release plan, though. It’s kinda amazing that BC will now be the first Dynamics 365 product to actually deliver on the “no additional license required when working in Teams”promise from 1.5 years ago.
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.
Microsoft has been working towards a unified sharing experience across their cloud products. The dialogs that many are using today in Microsoft 365 services like SharePoint and OneDrive for sharing access to files is also finding its way to Power Platform.
The visible UI in a sharing dialog is only one part of the experience. Knowing what the traditional sharing experience for Dataverse records has been in Dynamics 365 and what the underlying security model consists of, the new direction can present a few surprises for app makers and admins.
For example: did you know that a user without any visible security role may be able to read the data of certain Dataverse records? Wow! That goes against everything we’ve learned about security modelling in the good ol’ XRM era. Sounds like something worth investigating a bit deeper then.
Enabling the sharing links
Since the new sharing functionality can have a big impact on the security model of your business apps, this capability needs to be consciously enabled by the administrator. I haven’t yet come across the official Docs materials for the feature. Presumably this page is where the details will eventually be published. For now, this blog post is based on my experiments of what you need to have in place (by minimum).
First, you need to enable the collaboration feature in the environment settings via Power Platform Admin Center (PPAC):
Next, you should go to the Privacy + Security page of the same environment and switch “enable sharing” to on:
As the message says, this should “allow users to share read-only links to records with other users from this environment.” I managed to get this working in a couple of different environments in our tenants, yet another demo tenant in the same European geo refused to co-operate. So, don’t be surprised if you see different results in your environments at this point.
The link sharing experience
Now that the features are turned on via PPAC, you should be able to go to a record like an account in a model-driven Power App and discover the new sharing menu in the top right corner of the form. Selecting “copy link” will give you a standard link that is the exact same URL as you’d get from the browser’s address bar. That’s because it’s meant for “people with existing access”.
Once you click on the chevron and explore the link settings, there should be more options available (assuming the environment settings applied earlier have taken effect). Let’s select the “people in your organization with the link” option this time:
Now we get a URL that is appended with parameters “shareLink” and “sig”. These are the magic keys to authorize someone who does NOT have existing access to the record in Dataverse.
To validate how the feature actually works, I used our sandbox tenant’s user account FF App User as the guinea pig. First, as an administrator I went and removed any existing security roles for this user from the environment. Then I ran the diagnostics test from the user list in PPAC. A warning was displayed, saying “this user doesn’t have any security roles assigned directly to them”. Looks perfect for our testing purposes.
(I actually also removed the license, yet that didn’t get flagged in the diagnostics test. Oh well, we all know how mysterious the license assignment and validation in Power Platform can be, so let’s ignore it this time.)
Opening the naked URL of the Power Platform environment with this user account resulted in a screen saying “we can’t find any apps for your role”. Under normal circumstances, this would be the end of the road for a user.
This user has a special trick up his sleeve, though: the sharing link with the secret access code parameters. Using it allows us to open the account form outside any Model-driven app module. Yes, it’s read-only as the feature’s description text suggested, but from a viewing perspective this record form seems fully functional.
How far do the sharing rights go?
If we’d go back to our admin user’s profile and re-run the user diagnostics in PPAC, we’d see that there still aren’t any security roles assigned for the FF App User. Let’s visit the sharing dialog of the single record instead and go to “manage access”.
This screen shows us that we have one sharing link generated for the account in question, with read permissions. Also, since FF App User has accessed the record via the link, the user account is listed under “shared with”.
Time to go deeper still, so let’s open XrmToolBox. Using the Access Checker plugin, we can run a test for the specific account record and the specific user account. We do indeed see that when called via the API, the user has both read and share privileges for this record:
Could we find out even more about how the privileges are applied? Sure! Another plugin in XrmToolBox, “Your User Security – Magnified”, gives us a very interesting output for the FF App User account:
As many of you know, there are plenty of system metadata tables (entities) that the user must be able to read for the application to function properly. Things like “attribute” or “user” are therefore understandably opened up for the FF App User account upon sharing the record.
There are plenty of real business tables listed in that output, too. Contact and activity, for example. While the privileges are granted only in the user’s scope (meaning only records that the user is an owner of), this made me go back and think: what else did we see on the account form when we opened that one record?
Activities related to the account show up on the timeline. In addition, we’re able to navigate to their forms. We do also see the primary field values of anything that’s in a lookup, such as the regarding opportunity name.
Clicking on lookups, such as the contacts that are activity parties, will show an error message on missing read access rights. So, the security model is still enforced as expected, meaning we couldn’t just navigate via links to other records. It’s not just the lack of a surrounding app and its navigation that is missing from this user, there’s access checks also on the server side of course.
It’s good to keep in mind that the modern collaboration features are currently enabled only for certain tables: account, contact, opportunity, case. There may be more configuration options ahead for how the sharing links work once the feature reaches general availability.
Sharing within Microsoft Teams
The primary scenario that these internal sharing links have surely been designed for is collaboration within Teams. Already back in July 2021 it was announced by Satya Nadella that “Teams customers will receive access to Dynamics 365 data within Teams at no extra cost.” We’ve been waiting for that possibility to arrive ever since.
Given how the concept of sharing access to data has been radically different between a document world like SharePoint and a business record world like Dynamics 365, there has understandably been a lot of work needed to be done on the platform side. Now that the share links infrastructure appears to be in place, are we ready for the collaborative apps story to come to life?
Although the sharing capabilities are a Power Apps feature, there doesn’t yet appear to be the needed pieces in place on the Teams side for any low-code apps to take advantage of record sharing. However, if we test the sharing links in a Dynamics 365 enabled environment and with the Dynamics 365 Teams app deployed for the user, things start to light up:
Pasting the link into a Teams chat will now unfurl the contents and show an information card preview of the record. We also get the option to view the full record in the context of Teams, via the “view details” button. These are small yet important steps in allowing people to get work done within the platform that is Microsoft Teams, without needing to look for the details in another browser window.
We’re still missing some of the elements showed by Microsoft as part of their collaborative apps story, like Context IQ for at-mentioning a Dataverse record or Loop components to embed live data into messages in Teams or Outlook. While we wait for a delivery timeline on those elements, at least this easy record sharing feature in Power Apps model-driven apps has a target GA date for September 2022.
In November we had a situation where our production environment had records unintentionally deleted. This required us to restore a backup copy of production into a new environment and retrieve the missing records from it.
Why didn’t we restore the environment backup directly over the production environment? There are many reasons which I’ve documented in the Forward Forever team blog. In short, if you’ve got any Power Apps canvas apps or Power Automate cloud flows in your environment, things can get seriously messed up if you restore the backup into the same environment. My recommendation is to avoid doing this in production if you have any workarounds at your disposal.
After we had manually copied & imported the data back, we left that restore environment in place for a while. In this case, “a while” actually meant 6 months. We were in no rush to free up the capacity, so I decided to wait and see if there were any further lessons to be learned from this incident.
What happens to the storage space of a restored environment that no one is using? You might expect it to remain roughly in the same size as the original backup. In our case, the restore environment grew to be over 2x the size of the original environment. Below is an illustration of the restore vs. production environment storage usage from Power Platform Admin Center reports:
Our production today is at around 7 GB total Dataverse storage consumed, whereas the production restore environment had ballooned to 17 GB. What was consuming all that space? The AsyncOperation table:
This is where all the Dataverse system jobs are stored. These jobs will keep running, even if no live users (nor outside integrations) touch the environment.
Looking at the number of rows in that table (via XrmToolBox plugin Fast Record Counter), I saw that while our production environment had 8.4k rows, the restore environment had 51k rows in that table.
Why are there more jobs in the dormant environment? This is because normally the completed system jobs are deleted by another scheduled job, known as bulk delete jobs. Only in this restore environment the jobs just kept piling up. I checked that the bulk delete jobs weren’t reporting any errors. However, the actual system jobs offered the explanation to the storage space growth:
Switching to the suspended system jobs view revealed that there were 3.5k system events stuck. New batches seemed to be generated on a daily basis. With titles like “Microsoft.Dynamics.CDD.AuthorizationCorePlugins.RoleAutoExpanderPlugin”, it wasn’t immediately obvious what these jobs were related with.
Upon inspecting the system jobs records, the column “message name” revealed that these are related to solution imports and updates. Yes, just because you stop using a Dataverse environment, that doesn’t mean Microsoft would stop from servicing it with the latest solution versions and new features.
Why did the jobs get suspended then? The answer is in what happens after restoring tje environment from a backup. It gets put into administration mode by default. The intention here is quite sensible, since you wouldn’t want any integrations from the newly restored environment to be talking with the outside world. This could cause issues when you’d have multiple Dataverse environments connecting to the same target systems, potentially causing duplicate data and messages to be created.
The challenge here is that in today’s Dataverse / Dynamics 365 environments there are first-party integrations that also rely on features that the admin mode by default disables. These will keep running as system jobs inside the environment, yet they can’t complete their tasks and are therefore put in the queue as suspended jobs.
In a small CRM style environment like we have, this caused 10 GB worth of additional data to get accumulated into the Dataverse tables within 6 months. While system jobs are now stored in the cheaper file capacity rather than the expensive database capacity, it’s still quite a lot of unwanted storage consumption from built-in features.
Obviously the administration mode is not designed to be a permanent state for any Power Apps or Dynamics 365 solution’s hosting environment. This does highlight the fact that it’s not possible to simply “freeze” a Dataverse environment and keep a snapshot of your data and configuration for a longer duration in the MS cloud. All live environments will get updates to system solutions sooner rather than later, thus altering the state of the database. While the business data in the Dataverse tables will be preserved as-is, the metadata and its surrounding maintenance processes will keep on living their lives.
I had the pleasure of attending the Teams Nation conference on March 23rd, alongside more than 4000 Microsoft Teams community members. Not only that, they also allowed a former XRM geek like me to do a presentation on the Power Platform track. So I did.😄
Since I’ve recenly been working a lot with Dataverse for Teams, that was a natural topic to cover in a Teams related event. My session was titled “Dataverse meets Teams: low-code app opportunities for everyone”.
I first explained the big picture of what Dataverse means, the demonstrated three different apps our team has built on top of DV4T. Finally, a few words on the known limitations of the Teams based Dataverse environments and how you need to take them into consideration in your solution architecture design.
The slides are available for download on SlideShare, or you can browse through them in the embedded version below:
If you’re planning to build apps into a Dataverse for Teams environment, then be sure to also check out my earlier blog post on the solution management experience in DV4T.
For over a year now, we’ve been living in a world where Microsoft has two separate offerings of Dataverse. When it comes to the tools especially around solution management, there are certain differences app makers should be aware of.
In this article I’ll go through the peculiarities I’ve ran into when building solutions in Dataverse for Teams (DV4T). But first, a few words on why you should care about the Teams based environments when building Power Apps.
Positioning of Dataverse for Teams
Understandably, not everyone is a fan of the Teams version of Dataverse. After all, it’s a cut-down version of the full Microsoft Dataverse that many have been using for Dynamics 365 and XRM scenarios for ages. However, there’s that one unbeatable feature in Dataverse for Teams that’s hard to ignore: it’s FREE!!! (*With capacity limits, though.)
If you are building a complex business application for a specific audience, it’s almost always sensible to pay a little more and get the Power Apps Per App or Per User license to unlock the full Dataverses platform capabilities. But when you need an app with a casual usage pattern that applies to a huge number of individual users, sometimes it just ain’t feasible to go premium all at once. So, to avoid falling back to SharePoint lists, Dataverse for Teams a.k.a. DV4T can be a well justified choice from an architecture perspective.
Just because you’re using Teams as a platform for your low-code apps doesn’t mean you don’t need to plan for ALM (application lifecycle management). A single production environment ain’t going to be sustainable in the long run for the more important business processes. There are good news and bad news when it comes to Dataverse for Teams in this regard.
Let’s get this one bad news out of the way first: all of the APIs to programmatically interact with Dataverse are not available when working in a Teams environment. So, any pro-dev ALM processes that involves automation via DevOps pipelines and such is out of the question.
That leaves us manual ALM, meaning export and import of solutions by a human being. Nothing wrong with that, since surely the vast majority of business apps running on the platform globally are developed and maintained this way. After all, there really isn’t a low-code specific ALM process available in Microsoft’s world today that wouldn’t require at least some pro-code developer skills in the delivery team.
The secret life of solutions in DV4T
When you build apps from within the Teams UI, you will never encounter the word “solution” in the app maker experience. The Power Apps app inside Microsoft Teams will instead show you tabs called “built by this team” and “installed apps”:
How does one create new apps here alongside the already installed ones? By importing managed solutions into the DV4T environment. Of the three apps in the above example, IT Self-service has been imported as a managed solution package from another environment. Milestones is a sample app from MS with its own proprietary install experience, whereas Flow Approvals is just the raw infrastructure bits that get auto-provisioned when you create your first approval request in an environment.
All the unmanaged components in this environment will be found under the “built by this team” tab. Looking at the source DV4T environment from where the above IT Self-service app has been exported from, here’s how its bits and pieces show up in that environment:
When you click “see all” you’re taken to what looks a bit like the modern solution explorer in Dataverse, except it’s missing most of the features you’d expect to find there. When you consider for a moment that this experience is aimed at new citizen developers who aren’t really even aware of what “Dataverse” means, it does make a lot of sense.
We’re not like them, though. We are advanced low-code app makers who know what we want to achieve with these tools. Our escape hatch from this simplified world is the “Open in Power Apps” button that can be found when selecting “Apps” from the tree view.
We’re then taken into a special version of the Power Apps Maker portal that cannot be accessed directly from make.powerapps.com. This is because the DV4T environments do not show up in the environment picker of the usual Maker portal (they do on the Power Automate side, though). Time to add a browser bookmark for this URL, to keep you from having to always remember the curious navigation acrobatics required to land here.
Anyway, at least we’re now in a place where the good ol’ solutions can be created:
You’ll quickly notice that only a subset of the full solution explorer features are available here. I’ll next demonstrate how this can lead to some challenges in your app development tasks.
Choices in a DV4T world with less… choices
The IT Self-service app that was mentioned above is a fairly straightforward app with a few tables, a canvas app and a cloud flow. After getting the initial version ready in the development environment and preparing to configure it for another Dataverse for Teams environment, I ran into an interesting issue. This example reflects some of the “gotchas” you should be aware of when working without access to the full Dataverse tools.
We can import solution files from the Power Apps experience within Microsoft Teams, too – even if the word “solution” is avoided. When importing my test app from here I encountered the error “import failed due to missing dependencies”. Clicking on the “show dependencies” button didn’t do anything at all.
Switching over to the Maker portal UI for this DV4T environment, then initiating the traditional solution import process, I was able to see the that my solution package was apparently missing a Choice:
Ah, the awkward naming choices that Microsoft has recently made with our beloved platform… Ok, I’m now switching back to the old terminology that makes more sense.
So: I had added an option set field for my entity. However, it was a global option set, and now the solution package was missing the actual list of values that are stored within this separate solution component.
How did I end up in this situation? I’m not actually sure. I did a test with a different app, to see whether it makes any difference if I create the table columns from the Teams experience (which is very citizen friendly in its Microsoft Lists type UI) or the Maker portal. It is different in the sense that Teams creates a local choice vs. the global choice that the Maker portal defaults to (as recommended by Microsoft’s own Docs). Still, the solution export/import worked without any dependency errors on both versions.
No big deal, I’ll just add the missing component into the solution… Not so fast, Mr. Advanced Maker! Just because you’re working in a UI that resembles the full Dataverse solution explorer, doesn’t mean you have the same features at your disposal. Although Choices is one of the nodes that does show up in the tree view, you can’t actually find it in the “Add existing” menu:
Those of you who work with full Dataverse know that the “Add existing” menu contains well over a hundred items. The official Docs on solution component types only list 90 values at the time of writing but MS is adding internal components there all the time. We sure don’t need most of them in DV4T, but this omission sounds a bit unfortunate.
I had already done all sorts of debugging and hacking to find a way around this annoying limitation until I discovered a UI based way out. I saw that the existing Choices in the solution had the “Add required components” option behind the three dots. Unfortunately the Tables view didn’t include the same option. In the full Dataverse solution explorer we’ve got it in the main toolbar, but DV4T is different in this regard, too.
Finally I found the place where the option does apply to tables, too: the all objects view. Success!
It took a few hours for an experienced low-code developer to discover how to do what he wants to do in this simplified environment. It was still faster than replacing everything with a new column at this point, though. I had almost accepted the fact that I had simply clicked on the wrong navigation path somewhere in building the app and managed to break the boundaries of the DV4T sandbox. Luckily that wasn’t the case today.
Solution publishers
When you start adding items into a Dataverse for Teams environment via the Teams UI, they will get created under the CDS Default Publisher. The prefix for new solution components will be something like “crdc2”, meaning a random value that’s different in each environment. At least it isn’t the dreaded “new_” prefix…
You can create a your own custom publisher when creating a new solution via the DV4T edition of the Maker portal, similar to how the full solution explorer works. As long as you create the items from under this solution in the Maker UI rather than the Teams UI, the correct prefixes get assigned to them. However, since you cannot create a new canvas app (or chatbot) via the Maker UI, this means your app schema names will always get the CDS Default Publisher prefixes.
There are nice new features like the table editor in the Teams UI, which you might be tempted to use for quick editing of demo data while building your app. If you’ve created your tables from the Maker portal side, though, you won’t find them in the Teams UI:
The reason for this is that the Power Apps app inside Teams will only display the unmanaged solution components for the environment’s default publisher. So, if you tried to follow solution management best practices and created your own solution publisher, the doors will be closed over on the DV4T native app building experience.
Unmanaged, invisible solutions
This leads us to another gotcha on how DV4T treats solutions that come from outside the current environment. We already saw the differences in how the managed solutions imported into the environment are listed under “installed apps” and unmanaged stuff is under “built by this team”. That’s how the Teams experience shows things, and as we’ve come to now understand, it isn’t always sufficient for advanced makers.
When we do the equivalent of “switch to classic” in the Teams world and hop over to the Maker portal view of the environment, are things in their right places again? Well, not if you imported an unmanaged solution into the environment. Here, try and find the unmanaged IT Self-service solution from this list below:
No matter how many times you hit refresh on that page, your imported solution won’t show up. All the imported components do exist in the environment, though. You can access them via the Common Data Services Default Solution:
Why isn’t the solution visible then? Because Microsoft decided that you don’t need to see it, apparently. Deep down in the database all the solution metadata is stored. You can tell this from the fact that if you try to re-import the same solution, you’ll see a message “this version of the solution package is already installed”.
The limitation isn’t technical then, just a UI level filter. Yet from a practical point of view it is very real in a DV4T environment. This is because all the standard Dataverse APIs are blocked, so using tools like XrmToolBox to work around UI limitations and improve app maker/developer productivity are out of the question.
Closing thoughts
Dataverse for Teams has capabilities for running quite extensive business applications (just look at the CoE Starter Kit for reference). Many internal low-code apps could benefit from having a proper relational database behind them, yet they may not be feasible to be implemented with features requiring Power Apps premium licenses due to their usage patterns. The current app packaging story of DV4T raises some concerns on how solid this foundation will be for applications that will need ongoing maintenance and development.
Ultimately it would be best if we had a clear path for using the full Dataverse as our development environment, then publish the final app into DV4T for testing and production. As it stands today, the Canvas app editor experiences between the two environments are technically different. Also, it can be all too easy to “infect” your solution with some dependencies to features of full Dataverse that are going to block importing it into a DV4T environment, based on my experiences.
Update 2022-10-20: Today I learned about one more gotcha with Dataverse for Teams that involves Power BI reporting. If you build your tables from within the Teams Power Apps UI, you won’t see a “publish all customizations” button. However, unless you publish your customizations, the TDS endpoint won’t pick up the choice column labels. You’ll only have the ID values but the “name” fields will be blank. So, as a best practice, always keep the full Power Apps Maker portal open while building Teams apps/tables and remember to publish your customizations from there – just like you always have in the XRM days.
The single most powerful end user feature of Dynamics CRM, XRM, CDS and Dataverse was always Advanced Find. Period.
There, now that we’ve settled that argument, it’s time to move forward and see what life is going to look like when Dataverse no longer includes Advanced Find. Yes, there will still be the broad capabilities of advanced find, but I will refer to it without capitalization. This is in line with the fresh new documentation on a very important feature that aims to take the place of Advanced Find: modern advanced find.
So modern you can barely see it
Advanced Find was always its own UI in a separate popup window. This was perfectly in line with the Dynamics CRM 2011 UI – which was the last time there were any material changes to the visible features. Let’s have one last look at Advanced Find’s glorious Ribbon icon before we move on:
OK, so this wasn’t actually the last time Microsoft touched the user experience for this feature. The CRM 2013 release did a complete overhaul of the application UI (I’d say a more visible change than Unified Interface even), which lead to the Advanced Find buttons getting either hidden or missing from parts of the app navigation. I had to write a blog post called “Finding Advanced Find in CRM 2013” to help out users who were worried that the feature had been removed from the product entirely.
The modern advanced find that has been introduced as a preview feature in February 2022 takes the hiding game to a whole new level. You see, the entry point to modern advanced find is hidden within the global search bar. You have to 1) click the bar and then 2) click“search for rows in a table using advanced filters”.
Be sure to not enter any search text into the bar, because that will hide this new option. Also, whatever you do, do not press enter after this text – otherwise you’ll be taken to the global search results page. There’s no way to “go advanced” from here, it’s a completely different search experience.
Search “any” table
A big new feature in the modern advanced find is what happens after you click on the new button within the search bar. (I already forgot the name of that button since it wasn’t anything as nearly catchy as “advanced find”, so I’ll refrain from scrolling up this post to see what it was and just move on instead.)
You will see a sidebar saying “select a table to search”. Cool, just like in good ol’ Advanced Find! The difference you need to understand, though, is that it’s not a list of all the tables in the environment. Yes, it will likely be a longer list that what your Model-driven app’s sitemap navigation contains. This is because modern advanced find covers all the table’s that your app’s maker has chosen to include in the app module when working with the Model-driven app designer.
There are pros and cons to this approach. The obvious upside is the ease of use for the casual data finder. He/she doesn’t need to confront the ever growing list of both standard and custom tables in a Dataverse environment (especially those with many Dynamics 365 apps installed in them). Things are quite different now compared to back when Advanced Find was originally designed for a simple CRM systems. Showing hundreds of cryptic tables isn’t a great UX to most users, so cutting down the noise of the underlying data model is understandable.
How about those users who DO understand the data model, or even work in configuring and extending it? The advanced app makers, consultants and developers will most likely be frustrated by this limitation whenever they need to examine the detailed contents of an environment. Quite often I myself need to build new views and filters just to understand what data has been entered into the system (that has been designed by someone else).
Sounds to me like there will be a growing demand for a “Super Advanced Find” type of a tool to be introduced in XrmToolBox. If you’ve already got a favorite tool for ad-hoc data exploration needs, be sure to leave a comment below.
Query criteria remains the key criteria
The one area where an advanced search feature in Dataverse simply has to perform well is the creation of complex query criteria across the relational data model of the environment. One of the most read articles on my blog has been Advanced Queries with Advanced Find, which illustrates both the possibilities of the tool as well as the demand for such advanced query criteria in real-life business scenarios.
Luckily this is already included in the non-preview feature set of Model-driven Power Apps. The filter editor that you can find in any table view today is a very worthy replacement for what Advanced Find used to offer. Although I haven’t done a detailed comparison, I couldn’t easily spot any missing capability from the tools available for defining the view filters in modern advanced find vs. the classic pop-up query editor for Advanced Find.
Just imagine if it was this easy to define the filter criteria for Dataverse tables on the modern automation side, too – not just views? Perhaps one day something similar will be made available for Power Automate cloud flows, based on what is being planned for SharePoint data sources in 2022 wave 1 (because priorities). Until then, luckily we have great articles and reference guides created by the community to copy-paste our “flow code” from while we wait for a GUI to arrive.
Actually viewing the data
Far too often I’ve seen people put all their effort in defining the correct query criteria and then being lazy when it comes to actually showing the results of that query. You could say I wrote the book on the importance of Dynamics CRM view design back in the 2013 era, so you can image how such user experience oversights have irritated me over the years.
Smart choice of view columns and sort order are what defines the user experience outcome. Query filters are merely table stakes.
Jukka Niiranen, in this blog post right here.
As a data exploration tool, Advanced Find wasn’t always perfect, but us consultants learned to make the most of it. When needing to dig up data from columns that weren’t readily available in the system views, it was easy to just go and add all columns into an exploration view. Whereas when building more targeted we had two useful features in the “add columns” screen of Advanced Find: sort by name, sort by data type.
Unfortunately this is where the modern advanced find is a little behind on the classic Advanced Find. Let’s look at what the column editor experience is like.
First of all, the editor includes the very same modern stumbling block that you might have noticed when working in the Power Apps Maker portal and searching for table columns. When you open the “add columns” side pane, the list of available columns doesn’t cover everything that the table contains. Instead you are defaulted to a “Default” filter that’s easy to miss. Switch to “All” and you’ll finally see that field you wanted to include in your view.
What exactly does “Default” mean in this context and how is it defined? No one can tell, not even Microsoft. It appears to be one of those good intentions in tidying up the menus of what should be a citizen developer friendly platform yet also serves huge enterprise CRM systems. A tough balance to get right, that’s for sure.
One very nice improvement in the modern advanced find (as well as the Maker portal) is the ability to search for things while you are configuring those very things. Narrowing down the long list of available columns with a free text search term could be especially handy when you’re looking for information stored on a related parental ent… table.
What could make such a feature even better? I’ve got one idea: extend the search index to include also the schema names. Believe it or not, the display names of f… columns can become quite misleading when you eventually need to adjust them for the places in the app UI where they can’t be customized (which just happens to mainly be: VIEWS!).
Anyway, often the schema name may have a pattern that makes it easier to logically group columns, which in turn makes the app maker more productive as he/she finds them more easily when defining the views. Right now that’s something the modern advanced find doesn’t yet support. If you think it should, then go and vote for it.
So, you’ve created a hundred and one views…
If there was something that the classic Advanced Find feature really didn’t handle well at all, it was the process of managing the views created with it. The way how the Ribbon UI managed to both hide the feature and yet make it highly misleading at the same time was something… special.
Compared to what we used to have in Advanced Find, the enanced personal view management now launched in preview is a thing of beauty. Changing the sort order and hiding unnecessary views are very welcome additions to how the power users will be able to take control of their business app UI details.
“Hiding a view is a way to personalize the view list and reduce clutter by making views not be visible in the view selector. A view may be needed for a specific purpose periodically or a view could be shared with you that you may not need it anymore. In such instances, hiding enables you to manage your view list by seeing only the views that are most important for you.”
This probably won’t solve all the pain associated with view management as their number grows in “busy” tables used for different kinds of analysis, both via system and personal views. Yet it’s a simple, user-driven concept to offer personalization within Model-driven apps.
Closing the Advanced Find popup
We’ve known for quite some time that eventually the legacy web client popup with Advanced Find will not be supported anymore. This modern advanced find feature in 2022 release wave 1 aims to include the necessary features to allow deprecating a very central part of the product. It does a pretty good job and the general principles in modern advanced find are quite justified.
Will I miss the good ol’ Advanced Find once the new feature is enabled and the icon to the classic experience is gone? Of course I will. Like with many of the modernization efforts around Power Apps as a business app platform, the new experiences always take away something that used to allow XRM veterans like myself to be productive. Often we get less information density in the screens, blocking the use of multiple tabs, slower loading times due to new API dependencies, more options hidden/missing due to simplification efforts…
Enough with the complaining already! Things weren’t better before, they were just different. What used to be a single app in a single service is now a cloud where traditional boundaries are vanishing at an astonishing rate. Now everyone really can make apps, and there can be a thousand “XRMs” in an organization. Both the audience and the purpose of these tools is forever evolving – and so must their features.
Update 2022-06-08: Microsoft has started to roll out an enhancement to the view filter editing screen. There will be a button to download the FetchXML definition of the view filters. Also, export to Excel will now honor the filter modifications done, without requiring the view to be saved. Just like in the good ol’ Advanced Find days then.😊
Update 2022-08-02: As we get closer to 2022 Release Wave 2 when the classic Advanced Find button will be hidden from the UI for everyone (see Modern advanced find turned on by default), you should keep in mind that there is still a way to open the Advance Find page with the direct URL. You can (and should) install the LevelUp extension for Chrome/Edge/Firefox to have access to this dynamic URL. This will hopefully work for as long as Microsoft keeps the legacy web client page infrastructure alive.
It’s the little things in a user interface that can drive me nuts – at least when I keep running into them repeatedly.
One such detail in Dynamics 365 CE apps / Model-driven Power Apps is the scenario where you’re creating a new contact record and linking it to a parent account. Filling in the lookup field gives a nice little preview of the matching records. Like this:
Now, look at the first two results: aren’t they actually saying the same thing, but in different order?
At least I have a hard time distinquishing which record I should pick when I want to link this new contact under the account Forward Forever Oy. So, why is row nr. 1 the right answer and row nr. 2 the absolutely wrong choice to pick here?
The underlying dilemma is that this lookup field is a customer field (column). It can reference either an account or a contact record (row). It’s one of those non-simple types of lookups that Dataverse has contained since forever, thanks to it being originally designed for the purpose of being a CRM database.
Now, in a B2B CRM scenario you would almost never want anyone to link child contacts under other contacts. Unfortunately, even after 2 decades of shipping a mighty fine CRM product, Microsoft still hasn’t considered it worthwhile to offer customer organizations a configuration option to force contacts to be linked only to parent accounts.
Being an extensible enterprise business application platform, you can of course get a developer to write some JavaScript to change the default behaviour of the lookups that bother you. As for me personally, I always like to explore if there are no-code ways that would allow me to achieve a similar result without adding even a few lines of script into the environment for the future me / someone else to manage.
In this case what I want to do is this: don’t show the Primary Contact field in the lookup view of an account. As we’ve seen, it can be highly confusing, since this very same contact itself can also show up in the list of results. For a contact, it’s very logical that the parent account should be shown in the lookup preview results. (and used as a search field). For accounts, the Primary Contact value would likely be irrelevant in 99% cases when looking up records.
To give Microsoft some credit on the UX front, they have invested in developing a new Advanced Lookup feature that gives the end-users more filtering options to find the right record to link to. Opening up this modal dialog also gives us a way to examine why the previews behave the way they do.
Initially this lead me to scratch my bald head even more. Based on what the documentation says about lookup field behavior, I shouldn’t see the Primary Contact field value in the dropdown preview of the lookup, as there are columns like Account Number before it in the view.
“For system lookups that allow for multiple table types, the first two columns of the table lookup view are shown.”
It turns out this is not true anymore. To demonsrate the real behavior, l added an Account Number “111” for Forward Forever Oy account record. This is what happens with the lookup preview:
Ah. The current lookup in the modern Unified Interface is so darn clever that it shows the first non-empty column from the lookup view.
The solution is simple then. You can just add columns at the beginning of the table’s lookup view that are always going to have data. These will then push further left the lookup fields that aren’t relevant in the dropdown preview. This means you can still keep the other fields visible by default when opening the Advanced Lookup dialog. Even that confusing Primary Contact field can be left there, just in case we need it.
