Hi All, I'm thrilled that Microsoft is adding something to support licensing ISV apps distributed through AppSource. That being said, in its current state it's pretty confusing and the documentation does not provide much clarity on the what or how of this feature.
As an ISV, here's my understanding of this feature in its current form:
We have an existing offer in AppSource. It has a model-driven app and no code components. We have full ALM automation built out in Azure DevOps and everything runs pretty smoothly. We're small so making changes in an unmanaged environment and then committing to repo works for us. All deployments are automated. The only time we mess with Visual Studio is to package for AppSource. We never open command line tools.
Here's a little recap of my experience attempting to implement and evaluate this:
Here's where things slowed down. The first step says "Clone existing solution". In our world, that means go into the unmanaged Power Apps maker environment, select the solution and click "Clone a patch" or "Clone solution". This is not what they mean and it's confusing.
Looking forward to this being more supportable. As of right now, it doesn't seem to be compatible with the ALM tools in Azure DevOps that we rely on.
<?xml version="1.0" encoding="utf-8"?> <serviceplans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <serviceplan name="[SERVICE_PLAN_ID]"> <accessmode>4</accessmode> <iscustomizable>0</iscustomizable> <displayname>[SERVICE_PLAN_NAME]</displayname> <moreinfourl>[YOUR_ISV_PLAN_INFO_LINK]</moreinfourl> </serviceplan> </serviceplans>
<?xml version="1.0" encoding="utf-8"?> <serviceplanappmodulesset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <serviceplanappmodules> <iscustomizable>0</iscustomizable> <appmoduleid> <uniquename>[MODEL_APP_COMPONENT_NAME]</uniquename> </appmoduleid> <serviceplanid> <name>[SERVICE_PLAN_ID]</name> </serviceplanid> </serviceplanappmodules> </serviceplanappmodulesset>
I would like to thank @JeffCarma for the PowerShell snippet, which I implemented in a DevOps build pipeline, and now I do not have to manually add the license metadata to the solution.
If anyone is interested of the steps, I will be happy to explain it.
@kartikka , we would love to see a Microsoft Power Platform Build Tools task in which we can add the license metadata to a managed solution, which will automate the whole process.
Thanks @malkhawaja, I'm glad you found it helpful. In my earlier post, I said I was going to add a double check to ensure the new xml nodes made it. Here is that if you'd like to use it.
I am moving along the experience of the ISV License management, and until now I only added one plan (let's call it TestApp Basic) for one app, and now I will start adding multiple plans, which means according to documentation, I should create multiple apps (one app for each plan), but in my case (which is the case of many others I think) I am adding some extra features (e.g.: extra tables and BPFs) so if I should create an extra app (lets call it TestApp Pro), and supposing I have a customer who wants to go with the "Pro" version, they will end up with 2 model driven apps in their environment (1 basic, and 1 Pro), the basic one will be redundant now, right? what do you think we should do to the redundant app?
The way we're thinking about it is we'd have the basic app and the pro app and map licenses 1:1 to the apps, so a Pro user would have access to the Pro app but not the basic app, and the Basic user would see the basic app but not the pro app. System admins will see both, but users would only see one.
Further down the line, entity-level license permissions will be available, in which case having a single app with multiple levels of license will make more sense.
Learn how to create your own user groups today!
Check out the new Power Platform Community Connections gallery!
Congratulations, the new Super User Season 2 for 2021 has started!
Power Platform release plan for the 2021 release wave 2 describes all new features releasing from October 2021 through March 2022.