We have a service application that generates and sends email within an organization on behalf of users.

It has Mail.Send. It does NOT have Mail.ReadWrite on purpose. This allows us to send email and save a copy into their sent folder, but does not allow us to arbitrarily read the user's email (and other potentially problematic/dangerous access). This is inline with the principle of least privilege.

We want to give the users the option of reviewing the generated email from within Outlook and sending it only after review. Outlook already supports this via Drafts.

Unfortunately you only have two permission levels: Mail.Send (inc. save to Sent) or Mail.ReadWrite (inc. save to Drafts).

Mail.ReadWrite is substantially too powerful for simply blindly saving an email to the Drafts folder, and I don't understand how it is substantially different from saving to their Sent Folder vis-a-vis Mail.Send.

I'm asking for no additional functionality at all. I'm asking for you to consider the concept of "Send as Draft" (i.e. save a draft but DON'T send) as being part of the Mail.Send permission. It still should have no ability to read or alter the Draft/Draft folder (i.e. blindly write, just like save to Sent today).

Allow administrators to filter which fields can be returned per endpoint. Our end client is concerned that even though we are filtering the results on our side we still have access to Calendars.Read and technically have access to read meeting subjects, etc. Is there any way in Office365 or the Graph API that our end client can apply more granular permissions to filter which fields we have access to?

My particular example is using the CalendarView endpoint to retrieve a users appointments for a specific time period. While calling the endpoint we are passing $select=start,end,showAs. Our end client does not want us to have access to meeting subjects, attendees, etc.

MS Teams configuration is currently split between two powershell modules: the Skype for Business Online PS Module and the Teams PS module.

We're using these to provision MS Teams, but it is cumbersome to do remote PS, the SfBO Module has stringent limits like number of sessions, throttling and speed overall (takes a long time to even get a session).

My suggestion is to move everything to MS graph.. and for end users, extend the MS Teams PS module using these newly established graph API functionality and offer them to developers as well. We'd be a lot more effective being able to do everything in MS graph. We can assign licenses, but configuring users (Set-CsUser, Set-CsXXPolicy) should be possible as well.

Currently, when working wth automatic replies, Graph requires read/write permissions on "mailboxSettings".

I would like to pose that while automatic replies make sense to logically group with outlook settings given where they are in the Outlook UI, from an API and permissions standpoint, this is a bit overkill. Now, any app I build that works with automatic replies needs to have an administrator's approval to be installed because of the high level of permissions it requires.

I suggest moving or creating an endpoint for automatic replies that is not tied to mailboxSettings, so that apps making use of it can ask for an appropriate level of isolated permissions.

Thank you for considering!

I would like to be able to call the Excel REST API using app only permissions.

My use case is to have excel workbooks with models that have complex calculations. I could then use then call the Excel REST API from say an Azure Function using a Managed Identity that first populates some cells (that are parameters so to speak) and then calculates the workbook and gets the result from another cell, so basically I can delegate the "programming" of the complex model to a finance user who knows how to build complex models in excel.

I would effectively be using the Excel workbook as my custom calculation engine, allowing me to build some non-trivial code as a (straight-forward to any finance expert) model, and I can simply use the Excel REST API to "return" the result of the calculation.

As a developer, I'd like to use the Microsoft Graph API to access data on Microsoft Sharepoint Sites. At first glance, I would enable the permissions at the Application Level and access the Sharepoint Site data, however, when an administrator grants access they are granting access to ALL sharepoint sites - therefore in a large enterprise organization, this is viewed as a security risk and is usually disabled (as it should be). Recently, Exchange services enabled scoped permissions so that only specific mailboxes can be accessed at the application level. It would be great if we could apply a similar solution to the Sharepoint API so that large organizations could enable this feature.