MS graph webhook subscription for /groups without membership changes included? - microsoft-graph-api

Currently, there is no way to create a subscription for change notifications that track changes to all /groups WITHOUT group membership changes. I know this functionality is available using delta queries with the $select parameter, but that is a pull operation rather than the automatic push notification that is available via webhook notifications/subscriptions. Having this functionality can cut down on the number of notification messages received for groups where membership changes are NOT desired or wish to be tracked by this method - for which in that case, delta notifications could be substituted for that purpose as previously indicated.
Please advise. Thank you!

Currently change notifications for groups do not support $filter or $select odata query parameter to narrow down notifications. The solution in that case would be to use a combination of change notifications and Delta query where the change notification triggers requesting Delta changes which allow you in turn to determine the content of the change and whether it was "interesting" for your application.
If this is not a satisfying solution, you could look at change notifications with resource data (preview), however this is not implemented for groups today so you'd have to request it on uservoice. That or support for odata query parameters.

Related

Overview of how to track mail move change notification ms graph api

Our platform is replicating email functionality, I.e. view all emails folders and contents, reply, create new, draft, move etc for users.
We have successfully subscribed users to all change notifications (create, update, & delete) for the whole mailbox, however, we are not sure how to track folder move operations as I can’t find an example in the documentation and our current implementation is not working reliably.
The issue we have is that after receiving the various change notifications, when we are doing the requests to get the value for the updated/deleted message, sometimes the value returned is the updated value, not the original one, therefore if the folder has changed we do not know which message to delete. This issue is highlighted in the documentation here (half way down): https://learn.microsoft.com/en-us/graph/outlook-change-notifications-overview?tabs=http#example-3-create-a-subscription-to-get-change-notifications-with-resource-data-for-a-message-based-on-a-condition-preview
We tried it using immutable ids, but the final webhook received was sometimes the delete webhook for the message ID. This is supposed to be for the original email that was moved, however because the message ID is the same (and the parent folder ID value is not reliable) we may end up deleting the wrong email.
With immutable turned off, we did not receive any delete notifications (only creates and updates), so we ended up with duplicate emails as the original was never deleted.
Is someone able to advise the correct procedure to track these events?
Thanks
So it turns out the only reliable way to do this is using the delta query - https://learn.microsoft.com/en-us/graph/delta-query-messages - whenever a change notification is received for a folder.
So, when authorisation is provided for access to a users mailbox, you must get subscriptions for each folder and then whenever a change notification is received for that folder/subscription, the delta query is run for that folder.
I believe that MS are in beta testing for providing the change information in the webhook which in my option would be a great improvement in efficiency in terms of implementation and operation.
Hope this helps someone in the future!

How to retrieve all threads which have replies since a given timestamp?

I am ideally looking for an API that returns all the messages posted(including replies) since a given timestamp.
conversations.history is supposed to be the one I should be using, but it does not return replies, it only returns parent message (only if the timestamp of the parent message satisfies the "oldest" param I supply - i.e. if the oldest supplied in the query is later than parent's ts but earlier than replies, neither parent nor replies will be returned).
Hence, I am trying to find if there is any other API that returns the threads based on "oldest" timestamp. i.e. all the threads which have replies since a given timestamp.
Note: I looked at conversations.replies, it is only useful if you know which thread's replies you are fetching.
Currently there is no API to do what you aspire to do.
The best work around is manually fetching all threads data in-memory and then applying filter.
Did you find an alternative solution to this question? I have the same use case and when contacting Slack support I received the same response that we need to use the combination of conversations.history & conversations.replies. This will be quite an intensive and continuously growing number of calls if we need to call conversations.replies for all threaded messages just to filter out the timestamps that fit the date range. This would be catastrophic in the long run.
Ideally slack need to update conversations.replies API to support getting all replies between oldest & latest parameter just like in history.
Another alternative I am considering is to change the implementation and use the Events API instead of the Web Client API and use queueing to store all incoming messages then this will make sure that all messages are captured and stored then apply the required filters.

How to get a list of active PSTN calls in Teams using the Microsoft Graph API

We're looking for a way to get a list of all currently active PSTN calls being made into MS Teams. We've tried this:
https://learn.microsoft.com/en-us/graph/api/callrecords-callrecord-getpstncalls?view=graph-rest-beta
That's almost exactly what we need except records do not seem to appear here until the call has ended. What we need for the app we're trying to build is live call records.
We've also tried it by creating subscriptions and getting the ID of specific calls then looking up call records, but this data also appears to be delayed.
Is there a method we're missing here, or equally, is this something that may be added to the API some point soon?
Currently there is no graph API to get a list of active PSTN calls in Teams.
Microsoft will always focus on customer’s feedback and experience, some new features would be added to the services based on customers' feedback in the future, we also recommend you give your new idea in Teams UserVoice here.
They clearly mentioned in the document, we can not fetch the details directly. But you can fetch the records from your application. Using app side bearer token.

Get Change type in delta Events in Microsoft Graph Api

I am migrating from EWS to Microsoft graph and having problem in replacing flow "ExchangeService.syncFolderItems".
ChangeCollection<ItemChange> changedItems = exchangeService.syncFolderItems(calendarFolder.getId(),
FirstClassProperties, null, 512, NormalItems, syncState);
This gives me all the changes since last sync state with change type.
Now I need to replace this with Microsoft graph.
I saw Get delta api in Microsoft graph and also how to call it recursively using stale token. My query is, Get delta api is not returning the change Item type. Could someone suggest me the best way to implement this in Microsoft graph? Maybe the Apis that I need to use for this?
Note:This flow will be called by my service to get changes after fixed interval of time. Also I saw subscriptions ( https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0 )but not sure that could be used in my case as my service will be making a call to get changes for a meeting room after a fixed scheduled interval of time.
I am stuck here. Please help. Thanks in advance.
Deleted events will have a #removed property and only provide the id of the object as denoted here https://learn.microsoft.com/en-us/graph/delta-query-overview#resource-representation-in-the-delta-query-response
Updated objects will only include the updated properties and added objects should include all the data available. It's up to the 3rd party application (your app) to maintain a state on it's side to be able to differentiate between updated and created objects when using Delta queries.
Combining webhooks with Delta to trigger the sync instead of relying on a timer is a good approach to provide an end user experience that feels more real time

Microsoft Graph Webhooks subscription on /users - not usable in current format

So having been to Ignite in 2017 I was really excited with the new possibilites the Webhooks in Microsoft Graph and binding to Azure functions.
Recently I got the chance to really explore this for myself.
I am looking at this from the perspective of Identity Management - I really want to see what kind of user onboarding/change management we can react to and process with Graph Webhooks and Azure functions. So I started looking at the beta endpoint and the Webhooks available for "/users"
The first thing that struck me was that in the beta only "updated" or "deleted" is a valid changetype. I really would like "created" - since that is when the most work would get done on a user (for example generating some unique attribute values)
Ok I thought and just tried looking at "/users" and only changetype="updated". I created a subscription and an basic Azure function to handle the requests. Updated a user in Azure AD (just changed "Last name" attribute) and sure enough a trigger was sent to my Azure function
Now comes my biggest problems - this is really unusable in its current form.
his seems to react to the all changes /users and i guess the trigger response could contain several users.
It really would be preferable to get individual triggers for each object changed in /users even though they were changed at the same time
Looking at the actual information sent here lies the BIG problem.
I get the id of the user changed (good, but also expected)
I get the organizationId (ok..)
I get the eventTime (good)
I get a sequenceNumber (unsure what this is?)
I get subscriptionExpirationDateTime (ok fine good to have)
I get subscriptionId for the webhook (ok fine good to have)
... but WHERE is information about what data was changed??? Nowhere to be found is what attributes of the user were changed (i my case "Last name"). This makes the triggers totally unusable for "/users" and I cant really think of anyone who could use this function as is?
Sure I know the object was changed but I have no idea WHAT happened and if the change was relevant to my function
Please tell me there are plans to include the actual changes in the trigger response?
EDIT: ok right, yeah this is more a feature request from the actual developers of ms graph - will look for a better place to get this answered
Please provide feature requests here (ex: richer data in notifications, "created" change type) : https://officespdev.uservoice.com/forums/224641-feature-requests-and-feedback?category_id=101632
Here are answers to other questions.
Microsoft graph doesn't guarantee ordering of events when sending notifications (ex: your webhook endpoint could be down and we will retry events delayed by up to 4 hours or drop if the outage is longer than 4 hours). Hence "SequenceNumber" can be used to track if an event is in order and hence used as is or if it is out of order and needs a query to Graph to get current state.
Currently, we provide Ids of objects and associations (member, manager) that have changed, whether the object/associations is deleted or updated but not details of other properties that were changed. In its current form, webhook is best used with delta query. Instead of polling delta query every X minutes and in most cases receiving zero changes, developers can create a subscription and perform delta query only when a notification is received. This would help scale in case there are many tenants that needs to be polled.
Delta Query: https://developer.microsoft.com/en-us/graph/docs/concepts/delta_query_overview
Also FYI, webhook notifications for user/group is now also available in V1.0

Resources