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
I'll be totally cynical and assert that MS is blocking app read-access because they don't want anything competing with MSTeams - deliberately driving people that their app is the only choice for such data.
I believe they are blocking the 'status message' for the same reason
They are such obvious use-cases it much be deliberate
We route calls based on presence status, for our customers. Polling MS Graph API for Teams presence status with tens of thousands of users in multiple AD's, is not a feasible solution and according to the documentation: it's a bannable offence.
It would be great to have the ability to use the subscription API with the client credentials grant. Would be a considerable boost for us developers and our customers, to not have a complex authentication process.
@jh7459I doubt that is the case, there are plenty of businesses who do not want to migrate from Skype to Teams, just because of lack of functionality or API support. This is mostly due to limited resources (time, personnel) and design choices.
@Jeger "and according to the documentation: it's a bannable offence" - Where did you find this?
Polling is doing a GET operation on a resource over and over again to see if that resource has changed. You're allowed to GET the same resource multiple times a day, as long as it's not polling. For example, it is okay to GET /me/joinedTeams every time the user visits/refreshes your web page, but it is not okay to GET /me/joinedTeams in a loop every 30 seconds to refresh that web page.
Thanks @Jeger . However, that remark is under the 'Teamwork'-node. This discussion is about presence information, which is retrieved using the APIs mentioned under the 'cloudcommunications'-node in the documentation. There is no such remark there:
@robert_anywhere thanks for the info, that must be the case. I probably had that info from before the presence API, due to it being linked in the teams service limits, in the throttling guidance: https://docs.microsoft.com/en-us/graph/throttling#microsoft-teams-service-limits
It appears that there is now an Application level presence permission, Presence.ReadWrite.All.
Unfortunately, it can't be used to actually read presence, only write presence status...
Ideally, one would use the change notification webhook model (https://docs.microsoft.com/en-us/graph/webhooks#firewall-configuration) to subscribe to presence changes, but that's really not workable when Delegated permissions are the only option for getting presence information.
Because if an Application could read such status, you could standup your own teams-type GUIs. I believe their business model is to remove all such API to drive people into their app. Once a monopoly always a monopoly.
Another app-only use case: I have a simple daemon app to check the welfare of home office workers (during the Covd pandemic). The app uses last network login times and posts a daily message on Teams to team leaders about any user who hasn't logged in today, so they can be checked up on. However, users may still be logged in from a previous day, so this generates many false alarms. It would be much more convenient if the app could use the Graph Presence API to check before reporting someone missing. It should not require a specific user to perform this check, because (a) the app serves multiple team leaders, and (b) that just wastes time.
Hence I'm up-voting this topic.
@jh7459 I'm not sure why you have asserted that Microsoft don't want people accessing Teams data through APIs for fear of people using this capability to build a competitor product... Surely if we're relying on the APIs, Microsoft would still benefit from people having to pay to access the service in the first place to be able to set presence data or whatever else people want to do with the API. It's not like using the API can circumvent license fees...
I think a less cynical thought process might be that Microsoft are more than happy for us to access data (otherwise they wouldn't have created the Microsoft Graph), and they're more than happy for us to access presence data (otherwise they wouldn't have created the ability to do so with delegate permissions), they just have some kind of technical impediment that means it's hard to do with application permissions and they don't want to spend the time fixing technical debt unless enough people get behind the request.
I don't know how repeatedly suggesting the same "Microsoft don't want you to have access to the data", "Once a monopoly, always a monopoly" etc... contributes anything useful to this thread. Other contributors are trying to suggest ways in which application permissions to read/write Teams presence data would be useful to them. One has also suggested that a new API permission has appeared but doesn't work as they might have expected. In my mind this shows either an uncanny coincidence, or perhaps that Microsoft are actually working on implementing what the community very clearly want to see.
As a final thought on the matter, have you heard of Azure Communication Services, a service offering by Microsoft that exposes the same platform used by Teams to allow the development of applications that use voice calling, video calling SMS, and other such communication experiences? If ever there was an indication that Microsoft are opening up, rather than closing us out, this would have to be it.
I hope that eventually the app permissions for presence will be introduced and help reassure you that Microsoft have changed - they're not now the business that they once were. There's much more work on standards, open APIs, collaboration with the open source community, focus on cross-platform - in my opinion, they're more open than they've ever been.
They could clarify that themselves by simply responding to this thread.
Upvoting. Our app is a case management tool, allowing emails to be sent to and from cases being managed. We’d like the app to be able to check the presence status of a user that a case is assigned to so that it can generate an out of office message if someone emails a case when the owner is away. We can’t find a way of doing this with delegated permissions.
Upvoting. We are working on MS Teams integration tool and we would love to have this feature implemented.
Upvoting as well. We have two main use-cases; a helpdesk-only app that integrates into a number of different platforms, and an internal directory where viewing of Lync / SfB presence information has been integrated for at least the last 8 years.
It's things like this that give our teams deployment a bad rep with internal users; a reduction in feature-set and capability.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.