Graph API: Add information about the client that triggered a change notification

Graph API: Add information about the client that triggered a change notification
8

Upvotes

Upvote

 Feb 06 2022
3 Comments (3 New)
New

The change notifications in Microsoft currently looks like this:

 

 

{
  "value": [
    {
      "subscriptionId": "GUID",
      "clientState": "SUB_1",
      "changeType": "updated",
      "resource": "communications/presences('GUID')",
      "subscriptionExpirationDateTime": "2022-02-06T23:37:09.2420488-08:00",
      "resourceData": {
        "@odata.type": "#Microsoft.Graph.presence",
        "@odata.id": "communications/presences('GUID')",
        "id": "GUID",
        "activity": "Available",
        "availability": "Available"
      },
      "tenantId": "GUID"
    }
  ]
}

 

 

The change notification however, does not have the information about which application triggered it. If this data is missing, applications that have a two way integration with Microsoft have a looping problem.

 

For instance, let us say an app sets teams presence using setUserPreferred presence API whenever it's own state changes. When the web-hook from Teams comes in for the changes made, the app again changes it's own presence and sends setPresence to Teams which again triggers web-hook. This is a never ending loop rendering the change notifications unusable.

 

In this case, adding a `triggerredBy` field containing the clientId of the application that triggered it would let my application know if it should reject a web-hook since the web-hook was triggered by it's own action or it should be processed since the presence was changed on Teams application.

Comments
Copper Contributor

This could possibly be done using the open extensions:

https://docs.microsoft.com/en-us/graph/api/opentypeextension-get?view=graph-rest-1.0&tabs=http

By creating and setting the flag as a custom extension.

I agree that it would be easier to use if it had some default field for it since there are some limitations with respect to the extensions (namely, the $expand operation is limited in some use cases).

Copper Contributor

@CharlieDigital thank you very much for this suggestion! But bummer is that open extensions do not work on Presence resource (which is my use case) :sad:. Plus as I understand, these extensions are permanently attached to the resource data irrespective of who triggers a web-hook?

 

Honestly, in my opinion, adding information about the application that triggered a web-hook is a very basic piece of information that any web-hook service should offer. I am surprised how no one has asked for this feature yet.

Copper Contributor

The clientid/sessionid of the one that triggered the presence change would be very helpful!