Currently only delegated user permissions are supported, and this is very sub-optimal for bots and service applications that need to monitor Teams presence of users.
Agreed. Also needs the ability to set presence.
Set presence is being worked on for app-only scenarios.
@Darrel Miller does your comment imply that only set presence will be available with app permissions or will get be available too?
@DanielArkley The former. Please tell us the scenarios that app-only get would enable so that I can share with the team that owns this API.
@Darrel Miller there are so many uses for app-only presence retrieval!
Fundamentally, all the same reasons that make it useful for application permissions to be able to access the Microsoft Graph apply to Teams presence too. We have specific use cases where we’d like to show Teams presence in our employee directory, and we want to replicate Teams presence into our on-premise PBX.
@DanielArkley Is there a reason why the first two cannot be done with delegated access and Presence.Read.All? Those scenarios indicate that some user is being shown the presence and therefore once they have signed in, delegated access should be sufficient.
The third scenario is a an edge case. I can see how app-only might be useful for that, but delegated access should be possible.
The last scenario is definitely more like the canonical app-only scenario. Thank you for that call out.
@Darrel Miller Certainly most of these things can be achieved with delegate permissions but that doesn’t mean they should.
For example, in the UC use case we operate a UC platform that provides open APIs for any application with permissions to be able to get or set the presence of a user. I could fairly easily write a service that consumes presence from the Microsoft Graph and publishes this into our other UC platform. At the moment, as delegate permissions are the only option I have to write an additional application that runs somewhere, in the context of someone, to collect this information using delegate permissions. I’d probably end up just creating a user account for a service to run as, and then having to authenticate that service account periodically to get a token to use with Graph. Writing a service with application permissions is more robust, more scalable, and doesn’t rely on a temporary authorisation.
I think the most important takeaway here from my perspective is that we don’t always have the option to just build in support for delegate permissions — I’m sure mine isn’t the only business working with legacy applications that provide integration APIs, but which don’t allow us to just bolt on the necessary UI and boilerplate code to use delegate permissions. With application permissions I can write headless services that perform the integration work through APIs with no dependencies on users. Without application permissions my applications have to take a UI dependency on Graph which just isn’t feasible in many older applications or deployments.
I’m happy to elaborate further on any of these points.
@Darrel Miller I posted this in the first place because I had become frustrated with the insane hoops that I have had to jump through to abuse the delegated permissions over the past year.
My application is a call-center type application that distributes incoming chats to a pool of agents based upon their availability in Teams. Originally, this was built around the OCS/Lync/Skype for Business UCMA TrustedApplication platform, and it was simple to subscribe to presence changes for the users in the call queues. When we rewrote the application for Teams, initially there was no presence API at all, then the beta presence polling API was added, and finally there's now the production presence API, such as it is. The delegated presence permission doesn't fit well here for a server application watching the presence state of a pool of users, but we have abused the API such as it exists by requiring that one of the admin users of the application sign in to the web interface, so that we can log them in through Azure AD and obtain their access token, that we maintain and then use for the application to poll presence with. I feel dirty just explaining the process...
I don't see a strong reason why querying for presence information should be handled much differently, permissions-wise, from the way that Graph API handles classic profile or LDAP directory type information.
@ericrrichards @Darrel Miller @DanielArkley
My scenario is pretty much similar to Erics', also delegating incoming calls to available agents based on their Teams presence. We now use a dedicated user account (aka the 'old' serviceaccount, exactly what app registrations thankfully replaced) to poll for presence.
Besides the polling api, I would also like application support for subscriptions to presence (as described here). That way my own application can subscribe to presence changes, so we don't need to query the graph api all the time when we need presence information in our application. This also prevents errors because of throttling, since query-load is now on our own app, instead of the Graph API.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.