To make automated tests of MS Teams, you need to use the designated list of Graph API requests.
But the Graph API requests all require the access type “Group.ReadWrite.All” using admin consent, which is not useful for our customers.
The proposal would be to add one more access type, for example with the name “Group.ReadWrite”, which will allow the creation of a team, creation of a channel in the team, sending a message to the channel and replying to that message.
The same user needs to be able to delete the channel and the team previously created.
This is be permitted without admin consent in the MS Teams user interface, either from a Web Browser or from the MS Teams application, in comparison to Graph API, where the admin consent is required.
In this way, a Graph API application will have possibility to work with its own teams and channels, without access to extraneous teams and channels and without creating refresh and access tokens with admin consent.

If you have a tenant with a lot of users or a SaaS platform that works with millions of users accounts in Microsoft, it is extremely painful and time consuming to pull/sync profile images from Microsoft Graph. Doing live queries against Graph for photos are also causing additional strain on the Graph infrastructure and end users suffer the performance penalty of a service having to query another service first. So it is ideal to sync images in some cases to local systems for performance gains.

Based on testing that I did I calculated that fetching photos on 300'000 users can take up to 4 hours. Reason for this is because you first have to fetch all the members and then fire a separate query per user to https://graph.microsoft.com/v1.0/users/{userid}/photo/$value to fetch the photos, while staying within the throttling limits of Graph.
The other problem is also that the query to fetch the photo is blind as it may not return a photo as the user does not have a photo. But since I do not know if the user actually has a photo, I am forced to fire them blindly and then based on the response I will know if the user has a photo or not.

So, to resolve this two things would be required:
a) The user object needs a photo property populated with a last-updated date or etag.
This will tell me firstly, the user actually has a photo, stopping the need for a blind query against $value, and then secondly, is the photo the same as the previous time queried based on the photo property value.

b) Delta queries and subscriptions need to adhere to the photo property change of the user.
This will allow me to setup a web hook or timer job that will only query and work with user records that actually got changed, reducing the need for me to pull all user accounts from graph and then in turn reduce the amount of calls required.

The collection size of a request to /users cannot be feasibly limited.

Our active directory has tens of thousands of entries. The API only enables retrieving 100 entries per request. Getting ALL the entries takes a long time and I don't need them ALL. Unfortunately, the options for filtering the request are quite chintzy.

I can use the eq (equal) filter, which would be fine if looking for a single user, but I'm trying to limit the resulting collection to a group of users (e.g. to users who's displayName contains a substring, or where surname is not null). I cannot even use the not equal filter. I receive the following reply:

"Unsupported property filter clause operator 'NotEqualsMatch'."

endswith is not supported. regular expressions are not supported. search.in is not supported.

Not to mention, the user object only has a few useful properties.

Currently the documentation says (as of 20th of April) that MS Graph query parameters are compatible with OData v4 queries.
https://developer.microsoft.com/en-us/graph/docs/overview/query_parameters

This is not completely orthogonal as there are cases where some operations work and other cases where they don't.
I've used the Graph Explorer to find out what works and what doesn't so far, but it isn't the ideal way.

Filter operations Contains/Concat/Trim/ToUpper/ToLower are not supported in /v1.0/users but some are supported in /v1.0/me/events.
Furthermore it seems string comparisons are case insensitive, rendering ToUpper and ToLower meaningless. Using case sensitivity and allowing the use of ToUpper/ToLower would allow the users to decide if they want to use case sensitive queries.

Thanks.