Dynamics 365 – The Missing Piece for AppSource

I decided to step away from the third-rail and talk about something else. If you are a Dynamics 365 Partner, you should already know about AppSource. Maybe you have already published an App, or are thinking about it, or maybe you are just thinking about it as a place to add some functionality for your customers. AppSource is great, but it is missing one piece that would make it Awesome.

Why AppSource?

Okay, I am aware that not everybody has the time to explore every single thing that Microsoft shoots our way. To be fair, only a small segment of partners will even be interested in AppSource. App development is not something that most of us have ever done in the channel. Most of us are used to being paid by a customer to build stuff for that customer, not invest our own funds into developing something that no one asked for, in the hopes that we may recoup our investment, plus some, later. However, some partners do build apps, either as their primary business, or on the side. It’s a great way to fill idle capacity.

What does AppSource provide you?

AppSource is really a discovery engine. You can certainly build an App, and you can also choose to create a campaign on your own, to try and get it in front of customers’ faces. In fact, prior to AppSource, that was really your only option. While you may still chose to do that, AppSource should be a part of your plan. AppSource allows you to publish your App to their platform, which then makes it available, many times directly from their first-party solutions, to end customers. For example, from within Dynamics 365 Sales, there is a link called “Dynamics Marketplace”. If you had clicked that link in the past, it would have taken you to a kludgy list of Dynamics only apps, and not very many of them. From there you could choose to download an app (solution) of unknown origin or quality, and manually install it yourself. That old Marketplace was one of many scattered marketplaces across different products. AppSource has now consolidated all of these marketplaces into one. It has also added a layer of “confidence” by having Microsoft test all apps before they are published, basically removing some of the “wild” from what had been a Wild West of Apps.

What is an App?

First of all, the term App seems to intimidate some partners, thinking it is something new. “App” is the new hip name for a bunch of things we already know under other names. For example, that custom solution that you built on a customer’s tenant for say, tracking their customer warranties. If you happened to have created all of your customizations in a “solution”, like you should have been, you could export that solution as a managed solution. Guess what? Your zipped file is what we will now call an “App”. I just revealed the magician’s secret.

How does AppSource work for a Dynamics Partner?

Setting aside what your “App” actually does, and whether anyone would ever want it, what’s next? Let’s say you think there is a market for your Warranty Solution App. You can publish it to AppSource. This “publishing” process has become better over time, and continues to improve, but there are some necessary steps, that you will have to read up on. Creating a “package”, creating your marketing info, etc. Once “Published”, what does AppSource do for you, other than provide visibility? I’m glad you asked. When a customer “Discovers” your App in AppSource, they can tick a box and have it auto-magically installed on their tenant. Pretty cool huh. If you are in the business of building free Apps, you are done, mission accomplished. “Uh, Steve, I had hoped to make a gazillion dollars on my Warranty App…” In that case, you have some more plumbing to do.

Monetization

So, at some point in the future, Appsource may provide a capability to manage the collection of funds for your App. This might take some burden off of you in having to build something just to collect your money, but it is only part of the problem that you need to solve. AppSource is not Dynamics 365 specific, it covers a broad spectrum of Apps. For Dynamics 365, beyond a discovery engine, it’s only role right now is “injecting” your App into a customer’s tenant. It does no more than that. It does not have any mechanism for turning off your app after the required free trail period has expired, or pushing updates, or anything else really. It is exactly the same as if you logged into your customer’s tenant and installed your App from your local drive. So what does this mean to you, if you plan to monetize? Well, first of all you will need to add to your app some mechanism for turning it off after trial, as well as some way to convert it to paid, and monitor that. This is on you. This part, at least for Dynamics 365 partners, will all have to be done on the Dynamics 365 side, AppSource has done it’s job and moved on.

Protection Schemes

Microsoft did not build the XRM platform with Appsource in mind, it actually pre-dates Appsource by many years. So there is nothing in the platform that was specifically created for the protection of your I.P.. You need to create this. Some apps are easier than others, for example our How2 Training Solution. 99% of How2 is outside of Dynamics 365, the only thing that is actually in our App is a button. When a user clicks our button, an external pop-up appears to display our content. We have complete control, on our end, over who gets to see what. Of course we still had to build out a licensing and subscription collection scheme, but we did not have to do anything inside of Dynamics 365 to protect our I.P.. Many Apps, and former managed solutions, from ISVs keep a significant portion of their I.P. outside of Dynamics 365, where they can protect and control it. But what if your App, was really just a unique configuration of out-of-the-box components. Indeed, App Designer exists to let you easily build exactly that, and this is your I.P.. But now, 100% of your “I.P.” resides within Dynamics 365. Locking that up is a real challenge.

The Wild West

The problem is not new. Every ISV has had no choice but to build their own protection schemes, way before AppSource existed, and they still do. Every ISV seems to have approached this protection requirement in a different way. If you installed three different Apps from AppSource, you will have seen three different schemes. Some are better than others. In one case I saw recently, a step being asked of the customer, was to enter their admin credentials into an iframe displayed on the solution configuration page inside of Dynamics 365. What!!! An iframe from where, “Silk Road”!! As a customer, why would I be concerned, after all, it is within the application I already logged into, surely it is safe.

The Missing Piece

I have suggested to the Microsoft teams that they need to build a protection layer of some kind. This will not be on the AppSource side, as I mentioned they just inject and leave, so it will have to come from the Dynamics team. The Dynamics team has a pretty full plate, so I don’t know where this may go. But, imagine that all apps had to utilize a common methodology and components, that were part of the Dynamics 365 core, to protect themselves. Not only would this eliminate the Wild West of security risks, but also our costs of building and maintaining these rodeo rings. Personally, I think it would also provide some much needed grease to the AppSource flywheel, which at the end of the day for us, is our answer to Salesforce’s AppExchange. I’ll keep you posted if this idea gets any traction.

The post Dynamics 365 – The Missing Piece for AppSource first appeared on Steve Mordue MVP.

Original Post https://stevemordue.com/dynamics-365-missing-piece-appsource/?utm_source=rss&utm_medium=rss&utm_campaign=dynamics-365-missing-piece-appsource