Author: Jukka Niiranen

  • Working with solutions in Dataverse for Teams

    Working with solutions in Dataverse for Teams

    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.

  • On being tired

    On being tired

    This post is not about the usual technology topics I cover on my Thinking Forward blog. It’s about the human side for a change.

    The mental battery

    Having spent the last five days in bed, with fever and other symptoms making it impossible to be productive in any of my usual activities, I had time to reflect on a topic that’s inside me: my personal mental battery.

    Physical illness is of course an obvious drain on anyone’s battery, taking away your body’s energy to perform the way you normally could. We can quickly draw the line between the cause and the effect there, hoping that once the illness is cured the energy capacity is also restored.

    Another way the battery can get drained is merely living your everyday life. Just like when you’re using your smartphone during the day for casual activities like browsing social media or more intensive activities like playing games or watching movies, at the end of the day it’s a good idea to plug it into a charger. Let your device battery gain some more juice while you charge your own biological battery via sleeping.

    I’ve found the battery metaphor to be helpful in analyzing my own energy levels. More precisely, the lack of energy and what causes and effects it may have.

    How tired are you?

    It’s natural to feel tired, of course. Who doesn’t feel exhausted and completely drained at times? Things are different if the feeling is all too frequent – or too deep.

    In my self analysis I’ve identified these two distinct types of tiredness:

    • Normal tired: still able to perform things that give back energy. Battery low but stable.
    • Dead tired: unable to participate in activities that would energize me. Battery dead.

    In recent days, due to the illness, I’ve been spending my days in the “dead tired” zone. Once my body overcomes the infection and the CPR levels return to normal, things will surely be different.

    However, the thought that worries me at this point is that I’m probably still going to be tired. Just in my normal way.

    Using the mental battery metaphor, I can identify the following generic energy levels with their fictional battery percentage readings that we would see in our field of vision – if humans had the same kind of battery system as our phones do.

    I’ve drawn two zones into the scale, A and B. These represent the ranges in which the mental battery levels would fluctuate during a typical day of a person. For someone “normal” in zone A, they would operate in the balanced level, occasionally reach a highly energized level, then get normally tired when giving out more mental energy than receiving it. Still, they would always have some reserve energy left in their battery to handle situations that life throws at them.

    Zone B is a different kind of a person. Their mental energy levels can be stretched to seem just as balanced as the former person, when required. However, they don’t have the same reserves and each of these stretches to appear like someone in Zone A takes a toll on the mental battery. They often gravitate towards “tired by default” to spare the energy left in the battery. And the worst part is: when the battery runs out, it’s really at 0%.

    When living in Zone B, there’s a risk that the tiredness becomes you.

    How I became tired

    Obviously I wouldn’t be writing about this topic if it didn’t concern me personally. Yes, I’ve become someone who in the above mental energy model lives in Zone B. To answer the question how it happened, I can’t help but to use one of my favorite quotes: “first gradually, then suddenly”.

    The strange times we’ve been living due to COVID-19 are of course one ingredient. Still, on a practical level it didn’t change my life as much as some bigger personal events, like becoming a father or becoming a company founder. While the world is different now, most of the changes I’ve experienced have been for the better. I should consider myself lucky – and I often do.

    Therein may lie one of the issues that have contributed to my increasing tiredness level – or at least raised the barrier for talking about it. Seeing such big parts of people’s everyday lives get disrupted or even ruined by the global pandemic has made it harder to grant myself the right to complain about my own lil’ challenges. “Things could be worse” mentality can become a blocker for acknowledging your own needs, rather than a tool for identifying reasons to feel grateful.

    I don’t believe there is a root cause to be found for tiredness, to be honest. Life is an infinite puzzle where the pieces are always moving, so trying to get them all perfectly aligned isn’t a relevant goal. We need to gather the energy to keep playing the game, however.

    What’s different now

    I’ve clearly noticed how I tend to be living on the edge almost every day. Meaning the edge where the mental battery can run out of power and make even small challenges feel insurmountable. It is this uncertainty of one’s own energy reserves that in turn will eat up your confidence. Welcome to the vicious circle.

    Another key observation is that this tiredness I’ve been feeling is different from depression. I’ve experienced the latter in the past on a few occasions and while there are similarities in how they impact your life, I’d put them in different buckets. If only for the reason that I haven’t encountered these current experiences before.

    I’ve talked about the mental energy levels but of course this tiredness has a physical dimension. In fact, that is the most interesting part compared to my earlier challenges with mental health. The tiredness keeps manifesting itself in new and surprising physical symptoms.

    During the past year I’ve had quite a number of tests done in healthcare services, in response to sudden pain or other symptoms. All the key components in my body, from heart to brain, have been analyzed in trying to find an explanation. The good news is: everything seems to be in order. Also, none of these specific symptoms have turned into permanent medical conditions that would have affected my everyday life.

    How the body reacts to the “dead tired” level of your mental battery is not always obvious. Yet of course there is a very tangible side to the tiredness. Our brain will try to get the message across in the ways it can.

    So, what’s next?

    Just like there was no clear path into this situation, there isn’t likely going to be a straight route out of tiredness that one could just follow. I’m certain that things will eventually get better and the high energy levels that I’ve been able to achieve with this ol’ mental battery of mine will once again be put into use.

    I wasn’t planning on starting an extensive blog post series on the topic, but I admit there are a couple of other pictures that I drew on PowerPoint while creating the Zone A/B graphics (hey, that’s what consultants do when they see a problem!๐Ÿ˜ ). I may revisit the topic from the perspective on what consumes/gives energy in the context of community work, as an example, since that is a theme I’ve seen many others also raise up in recent times.

    That last part is actually an interesting aspect to point out here in the end: writing this blog post while still on quite a low battery level didn’t reduce the amount mental energy I have available – rather I gained much more from it.

    Update 2022-08-14: For more thoughts on the role that blogging plays in gaining/draining energy, see my new post: Is blogging worth it?

    Update 2022-09-14: I did what I promised, meaning revisiting my pictures about managing your enegy levels. Read the post Your mental battery and the power of living.

  • Modern advanced find test drive

    Modern advanced find test drive

    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.

    The new view hiding feature is something to pay attention to:

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

  • Canvas app source code editing with VS Code in your browser

    Canvas app source code editing with VS Code in your browser

    The experimental feature for connecting Power Apps Canvas apps with Git version control is pretty amazing. You can read this blog post from my FF colleague Timo Pertilรค to see how it looks like for app makers: Power Apps and Git version control.

    What doesn’t feel quite as amazing for a low-code guy like me is the steps needed for configuring the local Visual Studio Code client to connect with a GitHub repo. Timo has also blogged about these steps.

    I’m not sure how many people are yet aware of the really magical feature that GitHub offers: the github.dev web-based editor. In short, what this allows you to do is skip all of the local configuration steps and launch an instance of VS Code directly from a GitHub repo – in your browser. Here it is in action:

    (Grab this MP4 video if the GIF animation doesn’t show up properly.)

    What are the steps needed? First, we completely everything in Timo’s first blog post. Create a GitHub repo, then enable the experimental feature in Canvas app settings. Note: you will now have irreversibly linked your app to GitHub, so don’t do this for any “real” app just yet.

    After linking the repo Power Apps will automatically copy all of the app source code there. Open up GitHub.com and browse to the /Src folder to find YAML source code files for your Canvas app screens.

    Open a YAML file you want to edit. Then, it’s time for MAGIC! Press the period key (.) on your keyboard and watch VS Code load up in the current browser window, with the file you were looking at over on github.com.

    You’ve now got immediate access to the wide variety of editing features of VS Code, to perform updates on any file in that repo you’re in. How does github.dev do this? Here’s the answer:

    The web-based editor runs entirely in your browserโ€™s sandbox. The editor doesnโ€™t clone the repository, but instead uses the GitHub Repositories extension to carry out most of the functionality that you will use. Your work is saved in the browserโ€™s local storage until you commit it. You should commit your changes regularly to ensure that they’re always accessible.

    A simple example of the benefits is that we can visually track all the changes performed on our YAML file. Then, as we’re ready to commit it, just add a commit message and everything will be synced to the repo.

    Whenv we’re back in the Power Apps studio, clicking on the sync button will retrieve the latest updates from GitHub:

    And there we have it! A new value for the “app name” label that we edited in VS Code, with nothing but GitHub.com and a single “.” keypress.

    Could we one day do all of this directly from within the Power Apps Maker portal / studio? Well, as you can see, Microsoft has a lot of the infrastructure already in place to make the online browsing and editing of Canvas app source code technically possible.

  • How to control the lookup view columns for a customer field

    How to control the lookup view columns for a customer field

    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.

  • Year 2021 in Power Platform

    Year 2021 in Power Platform

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

    Power Fx: a programming language for low-code

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

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

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

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

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

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

    Teams as an application platform

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

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

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

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

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

    Pay-as-you-go licensing

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

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

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

    50% price cut for Power Apps

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

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

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

    Hello Azure Synapse, bye Data Export Service

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

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

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

    Fusion Teams story

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

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

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

    Inevitable complexity of low-code

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

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

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

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

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

  • A Power Platform newsletter from our team

    A Power Platform newsletter from our team

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

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

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

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

    To quote our team’s announcement of the newsletter:

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

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

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

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

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

    Subscribe to Forward Forever Monthly

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

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

  • Find contact’s LinkedIn profile with Power Fx & custom command bar button

    Find contact’s LinkedIn profile with Power Fx & custom command bar button

    So far in my experiments with Power Fx and the modern commanding preview in Model-driven Power Apps, I’ve worked with changing record status and cloning a set of existing records. This time I’ll create a custom button for another common CRM scenario: viewing the contact’s LinkedIn profile information.

    In our internal CRM application (Business Forward app) I’ve earlier added a custom field “LinkedIn URL” for contact records, which can be used for storing the reference to the contact’s profile. Not all contacts will of course have this field filled, which is why it’s a common need to go and search for the information on linkedin.com. Could we save a few clicks in this manual process with a simple button? We certainly can!

    This scenario is straightforward enough that you could well use it as your first custom command bar button in your Model-driven Power App or Dynamics 365 CE app.

    Button 1: LinkedIn Search

    Open up your Model-driven app in the preview editor that allows you to access the list of pages in the app. Then for the contact page select the three dots and click “edit command bar (preview)”:

    Select the contact’s main form as the target and the command designer will open. Pick a suitable spot in the existing list of commands and add a new button called “LinkedIn Search”. You can choose the out-of-the-box “LinkedInLogo” icon for it.

    We will want to have a visibility rule that will conditionally show/hide the button, based on whether the contact’s custom text field “LinkedIn URL” contains data or not. The IsBlank function will return a true value when the field is empty, so we can directly input that into the Visible property of our button:

    IsBlank(Self.Selected.Item.'LinkedIn URL')

    Next, let’s go over to LinkedIn website and study how their search actually works. There is of course the global search box in the top navigation bar, but when looking at the search results page we discover additional options for applying specific filters.

    This is the faceted search page, which allows us to specify that we are interested in finding people (1) rather than companies or content. Clicking on “all filters” (2) reveals an even more granular search experience, allowing us to enter keywords (3) for fields like “first name” and “last name”.

    If we were to search for Satya Nadella as an example, the result page URL would turn into this:

    https://www.linkedin.com/search/results/people/?firstName=satya&lastName=nadella

    This is a great scenario for using Power Fx to manipulate a text string for our app’s purposes and inject some dynamic values in there. We can now start designing our OnSelect formula needed for our LinkedIn Search button. It should do these things:

    • Open the LinkedIn search page in a new browser tab
    • Insert the contact’s name information into firstName and lastName query parameters
    • Ensure that any spaces in the name fields don’t mess up our URL validity

    The Launch function will take care of opening the browser tab. For joining the static and dynamic parts of the URL together, we use the string concatenation operator “&”. As for handling any non-URL friendly characters, we can use the EncodeURL function and pass the contact’s first & last name fields to it.

    Let’s save and publish these button configurations, which will generate a component library called “OurAppName_DefaultCommandLibrary” into our solution. Be sure to publish all customizations for your solution and also hit refresh a few times on the Power Apps application screen to make things come alive. (Note: you may also get an error the first time you click a custom command bar button, at least for me that happens every time, but then clears away.)

    Now when we open a contact record that doesn’t have a value in the “LinkedIn URL” field, the new button should be visible. Clicking on it will open up the LinkedIn people search page with results where the first & last name match the contact’s information:

    That was pretty easy!

    Button 2: LinkedIn Profile

    It would be nice if the next user of our CRM system wouldn’t have to browser through the people search results page to repeat the same query. Unfortunately there’s nothing we could grab with Power Fx from the first user’s new browser tab automatically, so we’ll need to ask the user to copy the URL and past it into our contact’s custom field.

    To remind them about the importance of updating CRM contact data, let’s show a notification bar that’s waiting for the user once they return back to the Power Apps tab:

    With this additional step, the OnSave event of our button 1 will therefore have two actions: launch and notify.

    Launch("https://www.linkedin.com/search/results/people/?firstName=" & EncodeUrl(Self.Selected.Item.'First Name') & "&lastName=" & EncodeUrl(Self.Selected.Item.'Last Name'));
    Notify("Found a matching LinkedIn profile for " & Self.Selected.Item.'First Name' & " " & Self.Selected.Item.'Last Name' & "? Please update the LinkedIn URL field for the contact. Thanks!")

    Now we can move on to button number 2. If the contact record already has a LinkedIn URL, we’d of course want to skip the unnecessary search part and open the profile page directly.

    Let’s add another command bar button called “LinkedIn Profile”. The OnSelect property will be very simple this time: we just pass the Launch function a parameter containing the value of the “LinkedIn URL” field.

    This second button should be visible only when the first button is not, to cover the two possible scenarios of the URL field having a value or not. While we could have conditional logic in our Power Fx to handle either scenario with a single formula, we don’t have the possibility to dynamically change the display names (or other properties) of the command bar buttons. So, two buttons with a similar feature is the approach we need to take.

    How do we reverse the visibility rule? For some reason adding a simple exclamation mark before the function doesn’t work as a negation operator in a custom button Power Fx formula like it would in a Canvas app formula, so I wrote the Visible formula of the new button in a less pretty format:

    If(IsBlank(Self.Selected.Item.'LinkedIn URL'), false, true)

    Save, publish, hit F5 a few times & wait. Now let’s open a contact record that already has the URL field filled. We see that instead of “LinkedIn Search” the command bar button now says “LinkedIn Profile”. Clicking on it takes us straight into the correct profile page:

    That’s all there’s to it!

    Closing thoughts

    I would have actually wanted to write a bit more complex formula than this, but there are a number of limitations in the current modern commanding preview feature that have blocked my other scenarios.

    For instance, there doesn’t seem to be any way currently to access the parent account information of a contact. Since under the hood it’s a customer lookup, meaning a polymorphic relationship that can reference either an account or contact record, we’d need to use the AsType function. That doesn’t appear to be supported for command bar buttons, so I couldn’t even grab the name of the company to be injected into the LinkedIn search URL to get better matches. Not a showstopper, but definitely something to add into the button once it becomes supported.

    Due to its preview status, some things in custom commands that used to work earlier aren’t working anymore. The record cloning example I built three weeks ago used the Set function, but today that has been removed from the modern commanding preview supported functions. Now that we can’t use any variables, the resulting Power Fx formulas would have to be constructed via the With function. In the custom button scenarios I had originally planned to build, I can’t easily see how to build them without variables and not causing a headache for myself, so they are currently on hold until the feature matures a bit.

    One question that comes to mind when building this example LinkedIn button is “why do we have to do it ourselves?” After all, Microsoft owns LinkedIn, so it would kinda make sense if there was some built-in integration at least between Dynamics 365 and LinkedIn to cover such simple profile matching scenarios. In fact, back in the April 2019 release wave an out-of-the-box integration for Dynamics 365 contacts was initially promised, but later cancelled:

    Sure, there is the Relationship Sales package available at $162/user/month for those who need a hardcore social selling tool with Dynamics 365 Sales and LinkedIn Sales Navigator. Alternatively, there’s the “$0” feature built into Outlook that will show the matching LinkedIn profile previews for the contacts stored in your address book.

    In between, there’s… nothing. It was interesting to reflect back on this topic by reading my own blog post from 2013 on LinkedIn, Dynamics CRM and Social Selling. The world has of course changed a lot from those days, with data privacy concerns as well as legislation affecting the ways in which this type of contact information can be exposed for commercial purposes. All the old iFrame options and LinkedIn APIs have been shut down, meaning pretty much all you can do without the paid LinkedIn plan is to create a low-code shortcut button like the one I showed in this article.

  • Clone records with Power Fx & custom command bar button

    Clone records with Power Fx & custom command bar button

    In my previous post I built my very first command bar button based on the modern commanding feature currently in preview. This time we’ll continue creating similar generic features often requested yet missing in the standard Model-driven Power Apps or Dynamics 365 Customer Engagement apps.

    Repeated entry of data that already exists in the system should always be a task we aim to minimize in the business applications we build, to increase the likelihood of A) the data being recorded in the first place and B) reducing errors resulting from manual data entry. Sometimes there may be a perfectly valid business need why several nearly identical records should exist in the Dataverse database. In such scenarios, it’s common that users will at some point request a “clone this record” feature to be added into the app when they get tired of typing in the same values over and over again.

    Such functionality has traditionally been implemented via a custom command bar button added with Ribbon Workbench, which then runs JavaScript & possibly a plugin. You could also perform the action with an on-demand XRM workflow. How about the modern command designer, could we do all this in Power Fx? Let’s find out!

    Power Fx for cloning asset records

    In our scenario we are working with a custom IT asset management app that has the following Dataverse tables and relationships:

    Let’s say that we often provide our employees the same phone model and we’d therefore want to make it faster to add these as asset records by being able to clone an existing asset as the starting point.

    First we’ll launch the preview version of the Model-driven app designer and choose to edit the command bar for the asset table. This time we’ll target the main grid:

    In the command designer, let’s add a new command bar button called “Clone” and start thinking about the required configuration for it.

    We’re going to want to do a similar limitation of scope as in the previous article, by supporting only a single record at a time. Multi-record selection is beyond what we can currently process, so a visibility rule is needed for us to ensure that the button is clickable only when a single record from the table main grid has been selected. The way to achieve this is:

    CountRows(Self.Selected.AllItems) = 1

    Then for the button’s action part. The end result of what we need to create looks like this:

    Unlike in the previous article, we are now not updating the currently selected record but rather creating a brand new one. We’re able to use the exact same kind of Patch formula that any Canvas app would leverage when adding Dataverse records and not using the built-in create forms.

    Our assets table has fields than can be directly copied from the earlier asset record. These include text fields like description and lookup fields like vendor and product. The syntax for the formula is very straightforward for all these: just use “Self.Selected.Item.[YourFieldNameHere]” to populate the field on the new record to be patched.

    We can of course manipulate the field values for our cloned record via simple tweaks in the Power Fx formula. Let’s set the asset’s purchased date value to Today() and add a “Copy of” prefix to the asset name field. This ease of modifying the field values based on evolving business requirements is one of the key benefits from having the logic defined with a low-code programming language that a citizen developer can use with confidence.

    After the patch, we can call up the notification bar in the Model-driven app to display a confirmation message from the clone operation. That’s pretty much all there’s to it, so here’s our formula:

    Patch(Assets, Defaults(Assets),{Name: "Copy of " & Self.Selected.Item.Name, Vendor:Self.Selected.Item.Vendor, Product:Self.Selected.Item.Product, 'Purchase Date':Today(), 'Purchased From':Self.Selected.Item.'Purchased From', 'Purchase Cost':Self.Selected.Item.'Purchase Cost', 'Warranty End Date':Self.Selected.Item.'Warranty End Date', Description:Self.Selected.Item.Description});
    Notify("A copy of the selected asset, " & Self.Selected.Item.Name & ", has been created. Please open the record and update the necessary fields.")

    Here’s the resulting end user experience for cloning a record from the main grid:

    Not too bad at all for a relatively simple formula, added as a command bar button via a visual editor available in the platform.

    Limitations of Power Fx commands today

    To be honest, the first cloning scenario that I actually set out to build was targeting the main form. Adding the custom button here is just as simple as the main grid. Actually, since you don’t even have to think about the visibility rules and multiple selection, it would be the logical place for any new Power Fx user to start customizing their Model-driven app command bar. However, I didn’t get exactly the result I hoped for there.

    The general cloning logic works on the form, too, but there is an unfortunate user experience issue. Can you spot it?

    In the above image, we have already clicked on the Clone button. We have a notification bar as a confirmation. However, we are still sitting on the original record form, not the cloned version of it. If a user would for a moment think that “ok here’s the new cloned record, let’s modify a few fields” the business data would be messed up.

    Could we take the user to the form of the newly created record instead? In theory, yes. In practice, nothing I’ve tried works as of today. The Navigate function that should be supported for custom command buttons doesn’t want to co-exist with any other function in the same action of a custom button. It doesn’t want to accept the newly patched record as the target to be navigated to. Even if we’d navigate to the view for all active assets after creating a new record, the UI will still return to the original record after everything in our button’s action formula has been run.

    With this current limitation in mind, I started to explore if we’d have any other method to take the user away from the original record form. Navigating to a dedicated “Cloned Assets” view was out of the question, due to the aforementioned feature/bug. Using the Model-driven app notification bar to display and action button with a link seems to not be an option since the documentation says the Notify function available in the command bar is actually that from the Canvas world. This doesn’t have the same action property as addGlobalNotification on the XRM side that can show a clickable link.

    One thing I really hoped would work is the new in-app notifications for Model-driven apps. This is such an excellent scenario for leveraging Power Fx to construct a rich message aimed at the specific user with targeted actions and helpful information. It could work the way shown below:

    But in the case of the command bar, it doesn’t work today. You see, the above examples of in-app notifications have been triggered from a dummy Canvas app I used for testing the notification feature in general. I took the Power Fx code from the awesome blog post by Diana Birkelbach that describes how to send in-app notifications from Custom Pages.

    The reason why you can’t make this work (at least to my knowledge) inside the command bar is the lack of support for collections. You see, in order to construct the JSON data needed for adding an action button into the notification, you would in practice need to feed a collection into the JSON function in your Power Fx. This will result in a “formula within canvas component manipulates collection” warning inside the command designer and this part of your formula will silently fail upon clicking the button.

    Update 2021-10-10: Scott Durow gave me a great tip over on LinkedIn, reminding that the in-app notification body text actually supports Markdown syntax. This way you could include a dynamic link that points to the newly created record clone, without having to insert the more complex strings needed for displaying proper action buttons in the notification:

    Presumably all of these things will one day work, which will give you plenty of options to design a great user experience for your custom commands. Just be cautious when building on top of the preview feature of modern commanding.

    Cloning parent + child records

    The above example was a very simple case of record cloning, as we only needed to replicate data from one table. In real world scenarios we often run into a requirement where also the child records in related tables would need to be cloned together with the parent record. Can we achieve this with Power Fx?

    Let’s use the same IT asset management data model but move one level higher and build a custom command button to clone a product record and its related asset records. Meaning, both A + B in this picture:

    So, we’d like to first create a new product record, which is the exact same Power Fx formula pattern as before. After that’s done, we’d then need to have one or more record create events, depending on how many assets (if any) there are under the original product.

    Let’s use the ForAll function to do a patch for each of the existing assets. To identify these records, we can reference them from under the current record with the familiar “dot notation” to travel down the Dataverse table relationships: Self.Selected.Item.Assets.

    Then what we need to do is to ensure we link these newly patched assets to the new product record we created in the first step. To achieve this, I’ve added a ClonedProduct variable that is set to the result of the first patch. We can then use this ClonedProduct object when setting values for the N asset records we create inside the ForAll loop.

    Our formula for the “Clone With Assets” button on the product main grid is as follows:

    Set(ClonedProduct, Patch(Products, Defaults(Products),{Name: "Copy of " & Self.Selected.Item.Name, 'Product Category': Self.Selected.Item.'Product Category', Vendor: Self.Selected.Item.Vendor, Description: Self.Selected.Item.Description}));
    ForAll(Self.Selected.Item.Assets, Patch(Assets, Defaults(Assets),{Name: "Copy of " & Name, Vendor:ClonedProduct.Vendor, Product:ClonedProduct, 'Purchase Date':Today(), 'Purchased From':'Purchased From', 'Purchase Cost':'Purchase Cost', 'Warranty End Date':'Warranty End Date', Description:Description}));
    Notify("Product " & Self.Selected.Item.Name & " and its assets have been cloned. Please open the records and update the necessary fields.")

    When selecting a product from the grid and clicking on the button, here’s what the end user will see:

    This is already a much more powerful example of a low-code feature that can save time when users aren’t required to re-create similar sets of records over & over again. You will have the flexibility of easily adjusting the specific fields, field values and defaults used in your record cloning action.

    Sure, you need to understand the concepts used in the Power Fx formula first. I’d still say the barrier for app makers with no software development background is still lower here compared to building the same thing with client-side JavaScript or server-side C# plugins.