Caught with my pants down!

I got caught out badly this week because somehow I managed to miss that Microsoft were switching off the SendEmail utility function of the SharePoint REST API as announced here: Retirement of the SharePoint SendEmail API – Microsoft Support. It seems that this was communicated over a year ago but it must have been one of those (semi) silent announcements because I totally missed it ☹.

The article gives no indication as to why this capability has been deprecated, nor does this Dev Blog post: Retirement of the SharePoint SendEmail API – Microsoft 365 Developer Blog, or the M365 Message Center notification: MC921752 – Retirement of the SharePoint SendEmail API | Microsoft 365 Message Center Archive, that I managed to track down after the event. I can only presume that the decision is down to security concerns, which is fair enough I suppose, but it would be nice to be told why services are being deprecated and not simply that they are being shut down.

Anyway, I take it on the chin, and fully accept that the onus is on me to check these things and make sure the solutions I develop, which rely on any such “prone-to-be legacy” API services, are updated in plenty of time. Only I totally missed this one and so was forced to do a hot fix in double quick time when customers started reporting that my apps where no longer sending notification emails – yikes!

I do however find it ironic that one of my (now failing) apps was recently approved for release in the Microsoft Marketplace, just 2 weeks before this service was disabled! It seems that the quality control team might not have known that this was change was going to imminently kick into effect either. Not that I am blaming or criticising them in any way – they simply follow a script of checks and if the app does what it is supposed to, on the day of testing, it gets a green light. Nope, I just need to accept that this one was totally down to me!

The Fix

You might think this is not a big deal. I just need to update my code to send mail using the Graph API instead. And you’d be right, it was easy enough to switch APIs and get things working as before. It only took me half an hour or so to figure that part out.

However, the reason I chose the SendEmail utility in the first place was because it meant that my solution did not require Global Admin approval to send mail using the Graph API. This allowed it to be much more easily downloaded and used by site owners. They could just install the solution in a Site Collection App Catalog as a Site Collection Administrator and everything would be peachy, it would happily send email notifications without the need for Global Admin approval and the potential bureaucracy associated with doing so.

I suspect that this “ease of use” might have been the very reason (or at least contributed to the reasoning) behind why the SendEmail utility was deprecated. Now, if we want our SPFx solutions to send mail, we have few options other than to use the Graph API and that demands that we seek and acquire Global Admin approval. In the screenshot below, you can see my updated solution package now pending this decision.

Although this approval can be granted in just a few seconds, with a couple of clicks, the reality is that for a slow moving organisation this process might take weeks whilst every man (or woman) and their dog pontificates over whether sending out notification emails is a good idea and a safe thing to do!

This is Bonkers!

I’m all for due diligence but sadly (in my experience) too often that diligence falls to those who don’t really understand what they are being asked to preside over and so the default position is simply to say no, because that is the safest thing to do. If you don’t make a decision at all, then you can’t make a bad one!

But here’s the part that I find bonkers. The permission to use the Graph API (any of them) is not tied to my specific app. If another app has already made the request to Send Mail, and it has been approved, my app doesn’t need to cleared separately by a Global Admin. The decision to allow mail to be sent has already been granted, so mine can just piggyback on that!

That’s like my brother passing his driving exam and when I pitch up for my test a couple of weeks later, the examiner just waves me through with an “I passed your brother last week so you must be a safe driver”. In fact it’s worse than that! It’s like my brother passing his test and given a license and being told “well done, this will cover you, the rest of your family and everyone else you know” – or don’t know, come to that!

In summary

I kinda get why Microsoft have deprecated SendEmail but I am very sad to see its demise as it just adds friction (and in this case I would say unnecessary friction) of empowering users to use tools that boost productivity.

If the mechanism in place, is intended to provide appropriate governance, by imposing any approval threshold such that Graph API permissions can only be sanctioned by a Global Admin, then it fails completely if it only works globally at the permission-level itself but fails to provide a way distinguish between specific solutions. Just because my brother has passed his driving test is no guarantee that am not a road menace!

New clothes for the emperor anyone?