Jukka Niiranen

Tag: Microsoft Teams

  • The state of Teams as a platform

    The state of Teams as a platform

    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:

    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:

    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.

    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.

    Header photo by Fallon Michael on Unsplash.

  • Share links with access to records in Model-driven Power Apps

    Share links with access to records in Model-driven Power Apps

    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.

  • Sharing Dataverse for Teams apps outside the team

    Sharing Dataverse for Teams apps outside the team

    When you’re building Power Apps within a Microsoft Teams based Dataverse environment, the most common target group of app users is obviously people who belong to that team. This is very logical when the purpose of the app is to collaborate as a team on something that might have otherwise been an Excel sheet shared with all team members.

    The simplified table security model of Dataverse for Teams with Owner/Member/Guest (“OMG”) levels instead of custom security roles makes things easy to manage when everyone is equal. But what about when you’d need to have more granularity on who gets to do what? What if in addition to the owners (app admins) and members (managers) you also need a level further down this hierarchy: the “normal” users?

    Colleagues with access

    This is where the concept of a “broad distribution app” comes in handy. It allows you to grant access to the app for users who are not part of the team that’s hosting the Dataverse for Teams environment. Here’s how the Docs on Dataverse for Teams table permissions describe this:

    “With Power Apps for Teams, you can share an app with Azure AD security group whose members need not be part of the Teams team where the app was built. This enables you to add users to the application without having to add them to the specific team, and opens up “Broad Distribution” scenarios. For example, you may want to build an app that is enabled for every accountant in the organization, or even every employee in that organization.”

    The ability to share an app with one Azure AD security group makes Dataverse for Teams quite an attractive platform for low-code apps that have a high number of potential users. Not many organizations have yet committed to covering all their employees with a Power Apps Per User license that unlocks premium features like Dataverse. Since every user who’s licensed for Teams via Office 365 / Microsoft 365 is allowed to use apps running on Dataverse for Teams, this option significantly lowers the barrier to start building apps on top of a true relational database designed for business applications – as opposed to running your complex processes on top of several SharePoint / Microsoft Lists.

    Sharing with colleagues in practice

    Let’s say you’ve built an app within a Dataverse for Teams environment and are ready to publish it to the whole organization. In this demo scenario we are using the Bulletins sample app for Teams. We’ve created an Azure AD security group called “Access All Apps”. The first thing we need to do is go an add the necessary access rights to each table used by the app. For example, when it comes to the Bulletin table, users should be able to read all records but not create/modify/delete them, so we grant the “Reference” level to this group:

    You’ll need to do a lot of clicking for an app like Bulletins that has 11 tables, so be sure you’re selecting the “colleagues with access” section before assigning the permission level on each page.

    Next, let’s share the Power Apps canvas app itself with this group. Again, you’ll need to be careful with where to click in the navigation maze that is the Power Apps for Teams app. Go to the Apps list of the Dataverse for Teams environment but don’t select the app. Otherwise you won’t see the “share with colleagues” toolbar button.

    In the modal dialog window, choose which apps from this Dataverse for Teams environment you wish to make accessible with the chosen security group. This is where you’ll notice that while you could have tens of different apps within on environment, there’s no ability to choose which Azure AD security group gets to see which apps – since there can only be one.

    Adding apps to Teams channels

    If we were to now go to our target team and add a new Power Apps tab to the channel, we would not find our Bulletins app there. Nope, not even under that “sample apps” filter, since that actually shows a list of Power Apps sample apps like Asset Checkout that are part of all Power Apps environments. Dataverse for Teams sample apps like Bulletins are a completely separate thing, of course.

    The logic is different when it comes to Power Apps that have been built within Dataverse for Teams. You need to go back to the Power Apps for Teams app, i.e. the Maker experience. Click on the Build tab, choose your environment, find your app, select it for real this time, then choose “Add to Teams”.

    You don’t get to choose a team or a channel, though. That’s because this process actually publishes your app into the Teams app store. It will become available under the “Built with Power Platform” section:

    OK, fair enough. It’s an app built within Teams, so it makes sense to use the same distribution mechanism as apps developed with custom code. The other Power Apps in your tenant are “external content” that you can freely pin to channel tabs. Dataverse for Teams apps are same but different.

    Blocked by Teams permissions

    This is actually the reason why I started writing this blog post in the first place. Ever since the broad distribution apps were announced in January 2021, adding them to a team from the app store worked without any additional hoops to jump through. Recently that has changed in a way that is not yet reflected in any MS documentation.

    In a new tenant with the default settings for Microsoft Teams, you may be blocked from installing the Dataverse for Teams based apps after doing the “Add to Teams” dance. Instead the app store may present you with the following error message:

    Permissions needed. Ask your IT admin to add [app name] to this team/chat/meeting.

    You will get this message even if you are the Global Administrator of the tenant, so it’s not about the user permissions. It is rather the Teams policies that are blocking the deployment of Power Apps created within Teams.

    To solve this issue, you’ll need to contact the Teams administrator of your tenant and ask them to verify that the following setting is turned on:

    Teams apps – Setup policies – Global (Org-wide default) – Upload custom apps – On

    After this change, you’ll be able to open the Bulletins app in the Teams app store, select “add to team” and create a channel tab in any team that you are a member of.

    I can tell for a fact that the requirement for the “upload custom apps” policy didn’t always used to be required (or it was enabled by default). In one of our demo tenants I had previously used the “share with colleagues” feature to add Dataverse for Teams apps outside the hosting team. The existing tabs worked just fine, but adding new apps became blocked until the apps policy in the Microsoft Teams Admin Center was modified.

    It’s a bit unfortunate if this will indeed become a permanent requirement for IT admins to grant the permission for “upload custom apps”, just to share the Dataverse for Teams app into a different team. Compared to normal Power Apps, there are a number of quirks like this that the app makers need to be aware of. Be sure to also check out my earlier blog post where I explore what it’s like to work with solutions in Dataverse for Teams.

    Update 2022-06-17: In case you’re wondering how the general approval process would actually work for Teams store apps where the approval request prompt is shown, check out this great blog post from Tony Redmond: “Users Can Request Access to Teams Store Apps”.

    Update 2022-08-11: there’s a new feature rolling out, called “Microsoft Teams user request configuration to external systems (URL redirect)”, allowing Teams admins to configure a custom URL + message for the app requests in the Teams app store. Read more here.

  • Dataverse meets Teams: my presentation at #TeamsNation 2022

    Dataverse meets Teams: my presentation at #TeamsNation 2022

    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:

    The session recording from Teams Nation 2022 is also now available on YouTube:

    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.

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

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

  • Is Dynamics 365 data now “free” in Microsoft Teams?

    Is Dynamics 365 data now “free” in Microsoft Teams?

    In the opening keynote for Microsoft’s partner conference Inspire 2021, Satya Nadella stated the following:

    Today, I’m excited to share that Microsoft Teams customers will receive access to Dynamics 365 data within Teams at no extra cost.

    Wow! That’s a major licensing related announcement – with not too much details to go with it yet. The feature is also covered in the summary blog post “From collaborative apps in Microsoft Teams to Cloud PC—here’s what’s new in Microsoft 365 at Inspire.”

    Together, Dynamics 365 and Teams offer powerful new ways for everyone across an organization to seamlessly exchange and capture ideas right in the flow of work. Today we announced a new collaborative app that brings together the best of Dynamics 365 and Teams. We’re also eliminating the licensing tax that has historically held organizations back from this kind of integration, making these experiences available within Teams to any user, at no additional cost. No other technology vendor offers this kind of integration and accessibility across the organization without the need to pay for multiple underlying software licenses.

    Clearly this is quite a big factor for Microsoft when competing against the likes of Salesforce. The features are therefore unlikely to be merely on a “check the box” level that the competition could undermine with their counter arguments. Obviously Teams is the platform that Microsoft is betting pretty much everything on, so a deeper integration with Dynamics 365 is hardly a surprise.

    The brand new 2021 Release Wave 2 release plans for Dynamics 365 that came out on the same day have multiple references to new Teams integrated features:

    …And I won’t even go to things like Mixed Reality. You get the idea by now: if a Microsoft product doesn’t have any Teams integration today then it might as well be nearing the end of its natural lifecycle.

    Collaborative apps in practice

    Today we’re limited to the product marketing materials published by MS, but let’s try and make the most of it in our feature analysis and licensing speculation. Starting from the Dynamics 365 + Microsoft Teams landing page, we can watch a promotional video that includes some UI footage of the collaboration scenario. To start off, sharing Dynamics 365 records into a Teams channel is obviously a key to unlocking the collaborative scenarios, so a new experience for attaching records like opportunities or accounts will be provided:

    From the resulting Adaptive Card we see that the user is offered not just an option to “open in Dynamics 365 for Sales” but also to “edit in Teams”:

    We don’t get to go very deep in this video, so let’s switch over to the Inspire session called “The Cloud Built for a New World of Work” where Alysa Taylor introduces the Teams + Dynamics 365 story to the MS partner audience. The story has a similar “attach a Dynamics 365 record to a channel message” scenario. Here the button says “View details” rather than “Edit in Teams” but since these videos probably need to created well in advance, we can assume these two feature to be the same.

    Here we then get to see the actual details/editing experience. An opportunity record opens in a modal dialog within the Teams client’s channel context (no tabs) and presents a simplified form with key fields in the Summary tab. All the fields appear locked here, but the dialog has a Save button, so presumably the security roles from Dynamics 365 will be reflected here on the UI level already.

    Next we see the Activity tab, which is again a simplified version of the full Timeline view found on a Model-driven Power Apps form (meaning Dynamics 365 for Sales et al.).

    The user in question has the ability to add a new note for the record, which will get stored within Dataverse rather than just the Teams thread. Tasks also appear to be an option presented in this modal window.

    What happens next in Alysa’s demo scenario is not entirely clear from a licensing perspective. The marketing executive performing the actions in this demo has also the access to any Dynamics 365 views pinned as Teams tabs. Also the full forms are accessible, including Command Bar buttons allowing record creation and editing.

    Whether these rights have been inherited merely from the Teams collaboration scenario depicted in the demo is not disclosed here. The user might as well be a fully licensed Dynamics 365 user and MS just wants to show off the seamless experience of working with CRM data within the Teams client.

    In addition to the licensing story, there’s also the access management angle that isn’t revealed in detail yet. Obviously not any person within your tenant will just automatically have access to records inside a Dataverse environment. Therefore the process of sharing the record with non-users of Dynamics 365 when attaching a record into a Teams message and mentioning users within a message is likely to have a lot of interesting new functionality for any Dynamics 365 admin or solution architect to consider.

    Contextual presentation of business application data inside Teams is not limited only to channel messages or chat. Meetings can also be associated with Dynamics 365 records in the future, thus opening up further possibilities to make use of this new “free” access to Dynamics data for any Teams user.

    Licensing implications in practice

    Let’s think about the broader context of this licensing announcement. The big picture of what Microsoft wants to draw with their Collaborative Apps story is a stack like this:

    When I’ve drawn a similar diagram for customers I’ve labelled the top layer as “OS” rather than UX. Understandably MS may not want to rock the boat that much yet, keeping in mind that they also have concrete operating system announcements like Windows 365 and Windows 11 to pitch to the partner audience. Still, the logical layering is the same and that’s what matters. Teams is how MS can regain its relevance inside the users’ devices that are today running Android, iOS or even Linux. Therefore making things not just easy to use but “free” to use within Teams makes perfect sense.

    Dataverse for Teams has considerably lowered the barrier for organization wide usage of the low-code apps built on Power Platform tools, with its bundled rights to basic Dataverse features for no additional fee if used within Teams. To me, this Inspire announcement of unlocking access to Dynamics 365 data “without the licensing tax” (Microsoft’s words, not mine) is a logical continuation on this same path. You won’t get full features for free, but the upsell potential with the massive audience of Teams users globally is what makes this bargain lucrative for MS product teams.

    From a Dynamics 365 perspective, there are similarities here to the earlier Team Member licensing model that MS launched back when their CRM+ERP vision of a 365 cloud saw the light of day exactly 5 years ago. It was a $10 license that helped to close deals but ended up being a big headache for MS in practive. The launch of Power Apps as the official platform SKU eventually made the TM license pretty much redundant.

    Whereas Power Apps is the story for custom low-code apps, it isn’t exactly meant to be used for Dynamics 365 scenarios (if you ask MS). Yet the licensing terms currently do make it an interesting option for unlocking light use of Dynamics 365 data. Especially given the coming 50% price drop for Power Apps licenses, the fact that you can use these in a Dynamics 365 environment would certainly make them ever more interesting for customers to evaluate as an option.

    Depending on how far the read rights on Dynamics 365 data for Microsoft Teams users will actually go, this latest change might be able to deflect some of these Power Apps “misuse” threats. It’s a fact that not such a big share of a typical organization’s employees will need to work daily with updating CRM data, yet from a reporting and data referencing perspective it’s pretty darn valuable if you have access to the records within the customer data master system.

    If there’s one thing I hear from pretty much every customer (and many partners), it’s that they think Microsoft Business Applications licensing is complex. I’m hoping that whatever this new Dynamics 365 + Teams licensing announcement turns out to be in practice, it wouldn’t create more seemingly arbitrary lines for what data can be used in which context for what license. I’ll need to revisit this topic once we have the full story on today’s Inspire 2021 announcement, to see which way the licensing model is turning this time.

    Update 2021-07-22

    From the comments section in the original Dynamics 365 product team blog post for this announcement, we can gather the following details around Dynamics 365 privileges that will be embedded within Microsoft Teams:

    • Scope: “We are initially launching Teams experiences for Dynamics 365 Sales and Dynamics 365 Customer Service but working on the possibilities of additional experiences across the Dynamics 365 portfolio.” So, further CE scenarios like Field Service and the ERP side for HR, FinOps, BC will be covered later.
    • Schedule: “These experiences will start to become available as part of our Dynamics 365 Wave 2 release which begins in October.” As expected, 2021 Wave 2 release plan is where you should go and check the current target dates for public preview / early access / general availability dates for these Teams related features.
    • Technical implementation: “We are entitling all paid Microsoft Teams users with ‘Team Members’ level access to Dynamics 365 allowing Teams users to read Dynamics 365 data and action upon designated scenarios. These new connected experiences between Dynamics 365 and Teams will make it easier for Teams users to access Dynamics 365 records but only from within Microsoft Teams.” Quite similar then to the earlier technical enforcement of Team Member licensing on app module level. Except that direct browser access outside of Teams clients will be restricted, so presumably the current Dynamics 365 Team Member license SKU will still remain in place at $8 per user per month.

  • Year 2020 in Microsoft Business Applications

    Year 2020 in Microsoft Business Applications

    Recently I had the privilege to make my sixth appearance in the CRM Rocks podcast run by Markus Erlandsson. Between our first session back in October 2013 and today, the world of CRM has certainly gone through a lot of interesting events. It’s amazing that out of those ~2600 days in between, there are now more days when a product named “Dynamics CRM” has NOT existed than it has.

    CRM of course still is very much a “thing” – it just isn’t the center of the Business Applications universe anymore. In our podcast with Markus we talked about the broader scope of what has happened with both the first-party Dynamics 365 applications as well as the Power Platform in the year 2020. Put on your headphones and listen to the CRM Rocks episode right here.

    The topics in the podcast also tie in nicely with another tradition of mine, which is writing these end of the year retrospectives about the top 3 topics that I’ve found to be most interesting or impactful for our ecosystem. Before we get started with the fourth edition in this series, let’s quickly check back on what themes I picked out last year at the end of 2019. They were: 1) low-code movement, 2) licensing confusion, 3) data story evolved.

    All fairly hot topics still today – which is of course the reason why I emphasized their importance one year ago. Now for 2020, this time I’ll keep you on the edge of your seat by introducing the top 3 in reverse order. Hold on tight, here we go!

    Nr. 3 from 2020: Renaming frenzy

    We all know that Microsoft loves updating not just their software but also the terminology used for referring to these products. CRM is of course a prime example of this. Microsoft’s isn’t always “following the money” by sticking to industry standard names, rather they prefer to reimagine the categories in which their technology can be used for solving new business problems.

    In 2020 we saw the iconic Office 365 brand get removed from the official vocabulary of Microsoft’s list of products available for purchase. Like with CRM, the actual technology and the customer use cases for the products didn’t see any major overhaul overnight. Previously there were SKUs in the price list branded Office 365 and Microsoft 365, which caused confusion for the customers, according to Microsoft’s own branding change announcement. Luckily now everything is crystal clear and no one will be talking about Office 365 in the year 2021 anymore. (Right?)

    While Offi… sorry, I mean Microsoft 365, is a mainstream product used by pretty much all customers in the MS Cloud, its rebranding in Spring 2020 turned out to be just a warm up for the real main event of 2020 that took place in July. I’m of course talking about the rise and fall of Microsoft Dataflex. In may have only lasted for exactly 3 weeks but the Dataflex era will surely be remembered as the crazy days of software branding.

    Luckily the Dataflex saga started in the middle of the year, which means we were able to catch the season finale before 2020 ended. The revised names of “Microsoft Dataverse” and “Microsoft Dataverse for Teams” were revealed in the GA launch of what used to be codename Project Oakdale. These names have persisted for six weeks already without changes, so they seem to be the real deal now.

    Following along the path travelled by CRM and XRM earlier, the three letter acronym of CDS is therefore now officially deprecated. What were perhaps more shocking casualties of the year 2020 were the terms “entity”, “field”, “record”, “option set” and “two options”. (I’m not counting “multi select option sets” in this list since everyone who’s had to deal with them probably hated them already, so good riddance.)

    As for how many adjustments there were to products in the Dynamics 365 family, I honestly can’t even tell. The fact that I needed to do a dedicated “why MS product naming is complex” type of a blog post to analyze the phenomena should be firm enough evidence that the renaming frenzy definitely was one of the top themes of 2020.

    Nr. 2 from 2020: Power Platform licensing complexity growth

    Measured by my own articles and the comments I’ve been hearing, there seems to be no end to how much headache the licensing of different Power Platform components is causing to people. Even though most of the last major changes to the licensing model were actually introduced already in 2019, I think the impact from them has only now started to hit home with a lot of the technical folks when trying to apply the new rules in real life scenarios.

    Earlier in the year there was a lot of fuss around the coming technical enforcement of access rights on the app module level. The immediate attention was of course on the arrival of Dynamics 365 Team Member licensing enforcement and the targeted app modules offered by MS while they would be blocking all other standard and custom apps. This was supposed to take place already on April 1st, but then COVID-19 came around and the deadline was pushed to January 31, 2021.

    We did still see a growing number of technical limitations implemented to keep customers in compliance with the licensing terms while using MS cloud services. The CDS Dataverse storage capacity in particular became a big practical blocker for customers wanting to leverage multiple Power Platform environments to some ALM practices for their low-code apps.

    While storage consumption is already enforced today, the big question on every developer’s mind (well, at least those who follow what the Power Platform community talks about) must be the API call limits. We’ve been getting a few bits & pieces of information here & there from MS about how they actually plan to keep track of the API quota for different operation types, but no definitive guide exists today. The eventual enforcement of these rules could potentially lead into future troubleshooting patterns where we could replace “DNS” with “licensing” in this popular meme:

    In the year 2020 I wrote in total 9 blog posts on the topic of Microsoft Business Applications licensing – including a 4 part series on the various sources of complexity in licensing. As for Microsoft, during the year 2020 they didn’t manage to launch the licensing consumption metrics dashboard that has been promised for Power Platform Admin Center ever since the October 2019 licensing model came into effect (on paper). With all these factors combined, licensing complexity in my eyes earns again a place in the 2020 Top 3 themes, just like it did in 2019. Let’s see if in 2021 things will settle down a bit and we’ll finally gain more confidence in understanding and managing the licensing costs of solutions built on top of Power Platform.

    Nr. 1 from 2020: Microsoft Teams as a platform

    There’s not a single doubt about what the year 2020 will be remembered for on a global scale. The total impact from the COVID-19 pandemic reaches far beyond the mere side effect that it had on us information workers, with everyone being forced to join the #WFH trend and getting used to all of our work being remote work. Still, that is the most immediately and easily observable part of what the virus did to us. As a result, for pretty much anyone working in the MS ecosystem, 2020 became the year of Teams, Teams and a whole lot more Teams.

    Working from home proved to information centric businesses that a surprisingly high percentage of those processes that weren’t fully digital before COVID-19 struck could actually be turned into such when no other option was given. While this will give a major boost to future digital transformation investments for sure, it also demonstrated how little new tech was actually need at the end of the day to make the typical business processes work without any sort of physical encounter. Already with our collaboration tools of 2020 and the low-code application platforms of 2020, many teams have learned to creatively solve their problems and get the job done. No massive multi-year initiatives and agile software development projects with big budgets were needed to reach “good enough for now”.

    In 2019 Microsoft started promoting Power Platform as “the platform for every developer” by addressing the pro developer audience on the benefits they could reap from adopting low-code tools as part of their app development toolkit. In 2020 it was time to address a much wider audience of power users, by promoting Microsoft Teams as a platform for the apps they could be creating for themselves, for their teams, or for their entire organization.

    Power Platform as a whole has managed to reach 1o million monthly users, based on the latest Microsoft FY21 Q1 earnings call. While that’s an impressive figure, it’s nothing compared to the 115 million daily active users that Microsoft Teams has. In my own analysis on this Teams as a Platform motion, I wrote about how Teams is gradually transforming into the next Windows:

    Teams is now the closest thing that Microsoft has at its disposal to transform into an OS style fabric that connects a significant share of information workers globally.

    By bundling the basic Dataverse functionality inside Microsoft Teams both in technical and licensing terms, I’d say we’re seeing the low-code equivalent of what the Internet Explorer + Windows bundle represented back in the early days of the commercial usage of the web. It will be pretty tough for the competing vendors to find their way inside any existing corporate IT infrastructure on the same breadth as what Teams has already achieved.

    Teams of course was delivered there as part of the licensing payload of Office 365, which lead to competing workplace messaging platform Slack to file an antitrust complaint against Microsoft in the EU in July 2020. Later in December when the business app platform vendor Salesforce acquired Slack and announced it plans to use it to “create the operating system for the new way to work”, this kind of validated the strategy that MS had followed with Teams all along.

    The way I see it, Business Applications will increasingly be presented within the context of where the work actually gets done. They will become more targeted for the specific user groups and use cases that may well be unique to every organization. The complex ERP style systems of record will still exist behind the scenes, to orchestrate how work gets assigned, scheduled and invoiced. For the actual end user experience of interacting with these work processes, though, it will likely be closer to just using an app inside Teams than what is required operating the complex UIs of traditional enterprise applications. This is why the biggest theme of 2020 in Microsoft Business Applications has to be the concept of Teams as a key layer in the application platform story.

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

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

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

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

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

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

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

  • Microsoft Teams as a platform

    Microsoft Teams as a platform

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

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

    The road that lead to Teams

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

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

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

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

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

    Teams: the collaboration chapter

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

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

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

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

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

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

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

    Teams: the platform chapter

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

    lists in teams1.png

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

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

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

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

    Project Oakdale a.k.a bringing CDS to Teams

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

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

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

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

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

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

    Teams is the new Windows?

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

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

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

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

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