User Community Feedback

Hi Ralf, thanks for responding and for helping me understand your perspective. A few thoughts in response:

• I appreciate the distinction you're drawing between developers and admins and how in that concept they are two different people. I'd suggest that isn't the case in all organizations.

• I agree the back-and-forth process you described for the admin and developer to work together to publish a Service App is painful. I'd suggest alleviating that by adding a granular permission within Control Hub that only permits access to Service Apps and/or other developer-related objects (you could put Bots there as well). You could further add granularity with read-only and modify flavors of that permission. The admin then gives the developer access with only that level of permission, thus allowing them self-service while not exposing too many controls to them. A 3rd-party developer looking to produce a Service App for yet-unspecified organizations can do as you described and push their Service App to AppHub, where it can then be added to Control Hub by an org's administrator.

• I can't speak for the entire community here but I had no idea whatsoever that an Integration, Bot, or Service App could be moved between accounts. I'll freely admit if I'm simply out of the loop on that topic.

• You'd mentioned that should a Service App, Bot, Integration, or something else break because an account was deleted that "thing" can simply be moved to a new account. But that doesn't eliminate the point of failure, that being the reliance on an account; the same thing could happen all over again.

Ultimately my ask is to remove a point of failure by completely de-coupling Service Apps from any association with an individual identity.

There are a couple of things here that need clarification, and then we get into the feature request:

1. When the developer leaves or gets deleted, the service app continues to work. That is what I meant when I wrote it. This is very much in contrast to an integration, which immediately stops even when the developer changes their password ( let alone leaves the company )
2. Even the service app "sits" in a developer account. Any organization admin can freely move the app to other developer accounts, for example, after the developer leaves. We even provide a GUI for it. It's a one click operation to move any app from one owner to another. There is also nothing deleted after the developer left. So this doesn't need to be preplanned.
3. In our app framework, we distinguish between developers and admins. A developer typically does not have admin rights. As such, there are 2 personas involved in a typical Service App lifecycle.


If I follow your suggestion ( and I believe we actually evaluated this when we created the Service App framework ), then I, as a developer who is interested in developing a Service App need to find an admin in my organization, convince them to create a Service App for me give me some details about it. Then I write my code, then ask the admin to hand me over the refresh and access token which I then use in my app to execute its functionality. I don't think this is easier, more secure, or more intuitive. It certainly stifles innovation. It also impedes what we really try to do: get 3rd party developers to push their service apps to AppHub for other organizations to consume.
I do see some merit in some aspects of this proposal, and we have been discussing it for a while. We are thinking of sharing the responsibility of managing the Service App. Like this Service App can be managed ( in a developer function ) by this group.
We likely will implement this, albeit there is no concrete timeframe.