I’ve got a confession to make: even though I’ve been building Model-driven apps long before they even were Power Apps (back in the XRM era), I’ve struggled to understand how I can make them visible to the end users in the modern experiences Microsoft offers.
In this post I’ll address two different challenges. First, how to enable end users to have access to your Model-driven app. Second, how to protect them from seeing irrelevant apps.
“Why isn’t the app sharing menu working?”
Once you’ve built your Model-driven app are ready to release it, you need to make it visible not just to the app makers and system admins but also regular users. This involves using the Share menu from the list of apps available in the environment.
Working in the Power Apps Maker portal, it’s pretty obvious the things we see here have been built with Canvas apps in mind. When it comes to sharing a Canvas app, the steps are fairly logical. You click the 3 dots next to the app, select “Share” and are shown this dialog:
You add users or groups, set their data permissions via the many available security roles within Dataverse, click Share, after which the users get an (optional) email message. All good!
Try the same steps with a Model-driven app and your users will see… nothing. It’s not just that there isn’t an email message with the app URL sent to them. They actually don’t have access to the app at all, even if you provide them the URL directly. Why isn’t the share action working from here?
If you’ve worked with the Dynamics 365 App Modules before, you might remember that you needed to specify which security roles have access to which app. Just like with role-based forms, too. Now, that particular role assignment UI existed in the legacy web client that has been deprecated and there doesn’t seem to be an equivalent in the Maker portal anymore. Does this mean we don’t have to perform this step, rather the sharing of the app to the users takes care of this automatically?
At some point I assumed so, but this isn’t actually the case. After a long hard look at the documentation, I finally realized that the MS product team had squeezed this functionality into the Canvas sharing dialog in quite an unintuitive way. You see, you’re not only using it to share the app to the users, but also for “sharing” the app to a security role:
So, rather than sharing the app to the users, stay on the higlighted App section that’s at the top of the list. Pick the correct security role from the list and then click “Share”:
Now all users with the specified security role will have access to the app when trying the URL shared with them. Yes, you didn’t actually need to explicitly share the app to them via this menu at all! Sure, you can use it for adding the required security roles for these users, if they haven’t already acquired through other means, like group membership. But the whole concept of “app sharing” is still completely irrelevant to Model-driven apps, from what I can see. It’s only this misleading UI that may give you the impression that you can achieve visibility to Model-driven apps via a sharing action when in fact it’s still security role based like it was back in XRM.
This leads us to the next question around Model-driven app visibility that has been puzzling me:
“Where can I find the apps I have access to?”
If the app user is not a maker in the particular environment, they logically won’t have access to the Power Apps Maker portal to view the list of apps in it. So, from where exactly should they be viewing the list of all the apps shared to them?
If we have past experience from the world of XRM then we’d probably navigate to the Dynamics 365 Home page at home.dynamics.com. This page should be showing all the apps that the user has access to, which it currently does. We can pin our newly shared Model-driven app to the top of the list for easy access:
Oh, right. “We’re moving to Office” says the banner, since this Dynamics 365 Home page has been deprecated a while ago. In fact, based on the original deprecation message this page should have started to automatically redirect you to office.com/apps already. Today we still have the option to visit the legacy page, but let’s move over to the modern Office experience. We’re greeted with the “launch your business apps” onboarding dialog that points us to the Business Apps tab at the Office 365 home page:
Looking at the list of apps, though, we probably won’t see our brand new app here right away. There’s a pretty significant delay in the list of business apps getting updated here. Unlike the old Dynamics 365 Home, which suffered from a similar delay, we don’t have a “Sync” button to make this process any quicker.
While we’re waiting for our new Model-driven app to show up on the Office 365 home page, we may start to wonder what apsp actually are listed here. For instance, why is Solution Health Hub showing up there for a normal user with no admin nor maker roles?
Perhaps the Model-driven apps visibility isn’t entirely security role based after all. Whatever the reason why these Microsoft built apps like Solution Health Hub or Resource Scheduling from the default environment show up for a non-admin user, it’s not exactly a pleasant user experience. The Office 365 home page doesn’t offer us any pinning or filtering features like the old Dynamics 365 home page did, so there’s not much an end user could do to clean up the mess.
As a system administrator, though, we actually do have a way to trim the list of apps – even when they are first-party MS apps. Thanks to fellow MVP Alex Shlega, I recently learned that Model-driven apps can now be deactivated and activated. So, let’s go to the Maker portal in the default environment, pick the apps we want to hide from office.com/apps and select “Deactivate”:
Much better! Not only have the unwanted apps disappeared from the Business Apps list, but also our newly configured Model-driven app has appeared there during our small exercise.
There still remains one item on that app list that I can’t figure out a way to remove from the user. That “Dynamics 365 – custom” app from the Secret Project 404 environment is actually the result of a Dataverse for Teams environment provisioned by this end user. Now, since we have no way to directly navigate to the full Maker portal of such an environment and they shouldn’t support any Model-driven apps to begin with, these apps are something only MS can clear away in a future update hopefully
Thankfully there’s another place where the end user has more control over the app list than the Office 365 home page. Whenever you’re using some other Microsoft 365 service and need to open up a Power App, it’s a lot more convenient to use the waffle menu from the top left corner rather than the full home page.
Thanks to Thomas Sandsør for reminding me about the customizability of this app launcher. This is of course the place where a user should be instructed to pin their new Model-driven app for easy access:
One final point to make about Model-driven apps visibility is around Microsoft Teams. You should definitely consider pinning the apps into relevant Teams channels as tabs, to maximize the likelihood of the end users remembering to use them. As for a complete list of Power Apps available to the user, currently no such place exists within Teams, so you should pay attention to the Office menus as the portal to display your Power Apps app catalog for desktop users.
Update 2021-12-07: Office App Launcher new visibility criteria defined
Microsoft has recently changed the behavior of their app lists, with an update communicated via Microsoft 365 Message center message MC290818. Since many people will not have access to MC content and it will probably disappear at some point, I’ll post the contents here in full:
To help improve the app exploration and discovery experience for users, beginning mid-November 2021, the Office App Launcher, All Apps (https://office.com/apps), and app search experiences will be updated to only list relevant Dynamics 365 apps, Power Apps apps, and Azure Active Directory integrated apps.
Following this update, the Office App Launcher, All Apps, and app search experiences will only list Dynamics 365 apps, Power Apps apps, and Azure AD integrated apps that meet one of the following criteria:
Dynamics 365 apps and Power Apps apps:
- Apps a user has launched in the last 7 days
- Apps created by a user
- Apps an admin has marked as ‘featured’ in the tenant
- User accessible Microsoft published Dynamics 365 apps
Dynamics 365 apps or Power Apps apps that meet the above criteria will be shown in the App Launcher, the Business Apps section of the All Apps experience, and in app search results. Note that the time between when an app is shared with a user and when it appears in an Office experience is expected to be 24 hours.
Azure AD Integrated Apps:
- Apps an admin or user has added to an Azure AD collection
Azure AD integrated apps meeting the criteria above will be shown grouped by collection name in the All Apps experiences, as well as individually listed in the App Launcher and in app search results. A link to the My Apps portal where users can create Azure AD collections will be added to the All Apps experiences as part of this update.
How does this affect me?
Dynamics 365 apps, Power Apps apps, and Azure AD integrated apps that don’t meet the above criteria will no longer be listed in the Office App Launcher, All Apps, and app search experience. Users can take the following steps to access these apps and have them listed again in their experiences.
For Dynamics 365 apps and Power Apps apps, if a user cannot find an app they are looking for will need to first launch it in the browser via its Uniform Resource Identifier (URI). Note that admins and makers can get an app’s URI by selecting an app in the Power Platform admin center or via https://make.powerapps.com by selecting details, then selecting web link. Once the app is launched, it will be listed in the Office App Launcher, All Apps, and app search experiences.
For Azure AD integrated apps, a user can locate the full list in the “Apps” collection of the My Apps portal. Users can create collections for quick access to their favorite or most often used Azure AD integrated apps. Once the Azure AD integrated app is added to a collection, it will be listed in the Office App Launcher, All Apps, and app search experiences.
What action do I need to take?
This message is to inform you of an upcoming change, no action is required. However, if you want to guarantee specific Dynamics 365 apps, Power Apps apps, and Azure AD integrated apps are available to users following this update, please perform either of the following:
- Designate an app as featured using the Power Apps for Admins cmdlet: Set-AdminPowerAppAsFeatured
- Create an admin Azure AD collection
I am missing a model driven app in business app section of office 365 homepage, how can I bring the production model driven app in the business app section of office 365 homepage
How can you include the settings of which Security Roles give access to which app in a Solution?
Bernard, I don’t think this kind of sharing information is solution aware. The steps for granting access to an app in Power Apps canvas apps is always performed as configuration steps in the target environment, so I’m assuming the same limitation applied to model-driven apps. Although unlike with canvas apps and their user security groups, the security roles actually do travel inside a solution. Since Microsoft’s own 1st party apps like Dynamics 365 Sales do implement this via the app specific security roles, the association between roles and apps might exist inside the solution package. It’s a shame we don’t have the managed solution packages from MS to unpack. If anyone else has looked deeper into the solution XML for clues, please do share your findings!
Hi Jukka, thanks for your reply! I have done some further tests and it is weirder than I thought:
* When you create a custom Model-driven App the information about the Security Roles IS included in the solution and the Model-driven App will be linked to those same Security Roles when you import it into another environmen
* Also, when you add the Model-driven App to a Solution Dynamics 365 will suggest to add the Security Roles concerned as related components
* However, if you change the linked Security Roles after the first export this is NOT included in the solution and the linked Security Roles in the destination environment will remain unchanged.
* Also the Security Roles Dynamics 365 is suggesting as related components remain unchanged
Interesting findings! Did you test this with managed or unmanaged solutions?
This was with managed solutions