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.
We have a chat app where we want to display our internal employees Team status to our customers. This would let the customer know if the employee is available to chat. Currently, we have our employees manually set a status which gets displayed in the chat app. We also have a Teams bot setup that sends a Teams message to the employee when the customer wants to chat.
The application permission for get presence would allow us to use their Teams status in our custom chat app which would greatly simplify things.
We have a employee status app for Slack that lists all employees and their current status on a web page using the Slack presence API.
We are moving to Teams since we are already an O365 E5 subscriber.
Management rely heavily on employees using the custom status feature of Slack and would like to see that in Teams. This feature enables employees to give a more detailed status than the canned available, busy, out of office etc,
Also, the ability for one or more designated senior staff to be able set someone's status in their absence would be good. We frequently have employees go on PTO and forget to set their status appropriately. Would be handy for the CFO to be able to override to accurately reflect where someone is or is not
Another upvote, application needs the ability to GET user presence.
Looks like the /beta Graph API now supports Clearing and Setting a users presence but still no support for Getting the users presence for Applications. Only delegated is supported but this is not viable for enterprise applications.
Can you provide a link to any documentation on this? Not seeing anything in Graph Explorer so far. Will keep looking
OK found some docs:
Docs mention in a callout flagged as important:
Provide the ID of the application as sessionId in the request.
Is it asking for the Teams App ID? Clicking around in the Azure portal, it seems to be 1fec8e78-bce4-4aaf-ab1b-5451cc387264.
My goal is this. I have written an app that retrieves the presence for all users in a specified AD group and displays them in a list on a tab within Teams. Management want the ability to set the presence of a specific user when they go on vacation for example and forget to set their presence accordingly. Specific people would be provided the ability to essentially override the displayed presence.
The C# example has a hard coded session ID. Obviously I need to replace that value, but with what?
Any help always appreciated
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.