Support for Office 365 Connectors Ceasing for Microsoft 365 Groups and SharePoint Online

Message center notification MC798683 (4 June 2024) announces the retirement of Microsoft 365 Groups connectors, a form of what are called Office 365 connectors. The retirement process commences on August 5, 2024, and finishes on September 5, 2024. After that time, connectors will no longer be supported within Outlook (Win32), OWA, and the new Outlook for Windows (aka Monarch).

Connectors take notifications from online data sources and post messages into a target destination. In this case, the target is the Inbox in the mailbox of the Microsoft 365 group configured with the connector. These connectors are used with Outlook groups rather than Teams. You can’t configure a connector for the other folders in a group mailbox, and you can’t configure a connector for any other type of mailbox.

Messages delivered through an Office 365 connector are limited to 28 KB and aren’t intended to be complete articles. Instead, they let users know that something has happened, give them a short snippet about the event, and provide a link to follow for more complete information. Using a connector to post messages from an RSS feed is one of the most common uses, but third-party companies like Asana and Trello have created connectors to bring snippets about information from their services to Outlook and other Microsoft 365 targets.

Microsoft recommends that organizations replace group connectors with the Power Automate app, which has its own set of connectors for different data sources, including the ability to create a cloud flow to post messages to the group mailbox. Some of the Power Automate Connectors (like Salesforce and Jira) require a Power Automate premium license.

Connectors and SharePoint Online

A further blow for Office 365 Connectors comes in message center notification MC793656 (16 May 2024), which announces the retirement of connectors from SharePoint Online webparts. Microsoft says that this is due to “limited usage.” Based on anecdotal evidence and personal experience, I can’t recall ever seeing an Office 365 connector configured with a SharePoint Online webpart.

In any case, from June 15, 2024, site owners are unable to add connectors to SharePoint Online. On August 1, 2024, they’ll be unable to update or manage existing connectors and the connectors will stop receiving inbound notifications.

Teams, Office 365 Connectors, and Workflows

Teams still supports Office 365 connectors, which are configured on a per-channel basis because the target for new notifications are channel conversations. Each notification creates a new conversation.

MC798683 points out that Teams channels also support workflows created using the workflows app (“powered by” Power Automate), and workflows recently turned up in the […] menu for Teams chats (MC683929, last updated 24 May 2024).

I shall have to pay more attention to workflows in the future. I know that the basic stuff works very well (like bringing an RSS feed into a channel). I’m more interested in finding out how to replace the incoming webhook connector, which is used in many ways to bring information from applications into Teams.

So far, my experiments with the Post to a channel when a webhook request is received workflow have not been successful. This seems to work in the same way (publish a URL to post messages to) and it’s easy to find the URL, but more difficult to get the workflow to run. I eventually managed and published my experience about posting an adaptive card to Teams.

Moving to a Single Answer for No-Code Automation

All of this seems to be part of a cunning plan to turn Microsoft 365 users into citizen developers by popularizing the use of Power Automate and the Microsoft Power Platform (Figure 1) for no-code automation wherever possible. According to Microsoft (January 2024), Power Automate has 33 million monthly active users in 350,000 organizations. My assumption is that PowerShell and the Graph are the answer for code-based automation.

It’s hard to argue against rationalization and it does make sense to settle on a single no-code automation platform for Microsoft 365, something that wasn’t viable when Office 365 Connectors appeared around 2016. As always, don’t be surprised when change happens inside Microsoft 365. Just be prepared to cope with the change.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

More Products for End Users to Buy

In November 2019, Microsoft launched an initiative to allow users with an Azure AD account belonging to an Microsoft 365 tenant to self-purchase licenses for a limited set of products. At that time, the range was Power Apps, Power BI Pro, and Power Automate. The uproar from customers was such that Microsoft was forced to backtrack on the plan until they introduced the ability to disable self-service purchases through PowerShell. Sales then began in January 2020.

Roll on to August 2020 and Microsoft augmented the range with Visio and Project Online. Now, MC245825 posted on March 22 tells us that the range increases again to cover Power BI Premium and Power Automate with RPA (Robotic Process Automation) from April 19, 2021.

The Arguments Around Self-Service Purchases

Tenant administrators usually object to self-service license purchases because they want to know what’s happening in the tenant. They point out that it’s difficult enough to exert any control due to the volume of changes introduced by Microsoft. Adding the need to track what spending end users do to buy licenses from Microsoft just complicates matters, especially if cheaper (discounted) licenses can be bought through a software purchase agreement at the organization level.

End users like self-service purchases because they can buy licenses with a credit card through in-app purchases or a Microsoft product website. Access to software they need is immediate without having to involve administrators.

Microsoft loves self-service license purchases because they’re selling to a captive audience. It’s an easy way to sell direct to a targeted audience (anything to drive usage and sell more licenses is grist to Microsoft’s mill; auto-claim policies also fall into this category). Read Microsoft’s FAQ for more details about self-service purchases.

New Products on Sale

The new products eligible for self-service purchases are:

• Power BI Premium per user (code CFQ7TTC0KXG7).
• Power Automate per user plan with attended RPA (code CFQ7TTC0KXG6).

From a technical perspective, RPA is the more interesting. Adding an RPA license to Flows allows the automation of repetitive actions (the robot part of the name). For an insight into what’s possible, you can watch these Microsoft Mechanics videos for an introduction to RPA and how to setup the Power Automate desktop.

Disabling Self-Service Purchases

You can only disable self-service purchases by running cmdlets in the MSCommerce PowerShell module. The current version is 1.6. The commands are simple:

• Import the MSCommerce module.
• Connect to the MSCommerce endpoint with an administrator account.
• Run the Update-MSCommerceProductPolicy cmdlet to disable purchases for each product you want to bar. The product code identifies the target product.
• Check that the current purchase status is as you require by running the Get-MSCommerceProductPolicies cmdlet.

Here’s the code I ran to disable purchases for the two new products:

# Import the MSCommerce module
Import-Module MSCommerce
# Connect to the MSCommerce endpoint
Connect-MSCommerce
# Disable Power BI Premium per user license self-service purchase
Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0KXG7 -Enabled $False

Update policy product success

ProductName                   ProductId    PolicyId                 PolicyValue
-----------                   ---------    --------                 -----------
Power BI Premium (standalone) CFQ7TTC0KXG7 AllowSelfServicePurchase Disabled

# Disable Power Automate with RPA license self-service purchase
Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0KXG6 -Enabled $False

Update policy product success

ProductName        ProductId    PolicyId                 PolicyValue
-----------        ---------    --------                 -----------
Power Automate RPA CFQ7TTC0KXG6 AllowSelfServicePurchase Disabled

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

ProductName                   ProductId    PolicyId                 PolicyValue
-----------                   ---------    --------                 -----------
Power Automate per user       CFQ7TTC0KP0N AllowSelfServicePurchase Disabled
Power Apps per user           CFQ7TTC0KP0P AllowSelfServicePurchase Disabled
Power Automate RPA            CFQ7TTC0KXG6 AllowSelfServicePurchase Disabled
Power BI Premium (standalone) CFQ7TTC0KXG7 AllowSelfServicePurchase Disabled
Visio Plan 2                  CFQ7TTC0KXN8 AllowSelfServicePurchase Disabled
Visio Plan 1                  CFQ7TTC0KXN9 AllowSelfServicePurchase Disabled
Project Plan 3                CFQ7TTC0KXNC AllowSelfServicePurchase Disabled
Project Plan 1                CFQ7TTC0KXND AllowSelfServicePurchase Disabled
Power BI Pro                  CFQ7TTC0L3PB AllowSelfServicePurchase Disabled

After updating the commerce policies, all self-service purchases are blocked in my tenant (all are disabled).

Nothing Against Self-Service Purchases

I don’t really have a problem with the concept of self-service purchases, but I do not like the implementation inside Microsoft 365. If Microsoft wanted to help organizations manage self-service purchases, they could create a customizable app which could be distributed to end users. Microsoft writes applications based on Power Automate to demonstrate concepts (the Milestones and Bulletins apps are examples). Maybe something similar to allow users to request approval for self-service purchases would work?

Keep up to date about developments inside Office 365 by subscribing to the Office 365 for IT Pros eBook. We do the work to research and analyze changes across the ecosystem to make sure that our monthly updates are as valuable as possible to our subscribers.

Email Exfiltration Controls for Office 365 connectors

Updated: 18 June 2021

In May, I wrote two articles about how Office 365 tenants can restrict users autoforwarding email from their Exchange Online mailboxes. The first article covered OWA, the second more general restrictions. In the second article, I pointed out that Power Automate (aka Flow) cheerfully ignores any restrictions imposed by Exchange Online, thus giving those who want to transfer email outside the organization a handy way to accomplish their goal.

That was then and this is now. Microsoft has just introduced some additional capabilities to help tenants control “email exfiltration” through Office 365 connectors. The immediate use case is to stop Power Automate flows sending, forwarding, or replying to email. Exfiltration is an interesting word to choose, and one that will be unfamiliar even to native English speakers. One definition I found that seems to fit is that data exfiltration is any unauthorized movement of data. In this instance, we want to keep email inside Exchange Online so that it’s exposed to compliance and data governance tools, so the unauthorized movement of data is of messages to an external email address.

Exfiltration Headers

There’s nothing complicated in the new controls. Some well-understood and reliable mechanisms are deployed to detect and stop outbound email generated by Power Automate addressed to external recipients. What’s changed recently is that Power Automate now adds an SMTP x-header to messages to identify its traffic. For example, I created a flow to fire when a new item is added to a SharePoint list. The message sent has the following headers:

x-ms-mail-application: to identify that the message comes from Power Automate. For example, my flow generated the following header. The underlined identifier is important because it can be used to allow or block messages from specific flows.

Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow d356b212a66640dab94fd13546ca88d8; version 08586039113867675952) microsoft-flow/1.0

x-ms-mail-operation-type: to identify whether the message is a send, forward, or reply. In this instance, SharePoint Online creates a new message, so the action noted is Send. The value can also be Forward. Either will work.

To find this information, I sent the message to an Outlook.com address and examined it with the Message Header Analyzer after it was delivered (Figure 1).

Implementing an Email Exfiltration Block in a Transport Rule

Anyone who has ever created an Exchange transport (mail flow) rule knows that all outbound mail passes through the transport service, which examines and applies the conditions set in rules. In this instance, the rule is very simple. Figure 2 shows all that’s needed for a complete block of all email sent to external recipients via Power Automate flows.

The rule is: If the recipient is external, check if the x-ms-mail-application header is present and contains the words “Power Automate.” If it does, block the message and send the user a reject notification.

The rule conditions and action are: If the recipient is external, check if the x-ms-mail-application header is present and contains the words “Power Automate.” If it does, block the message and send the user a reject notification.

You can compose some nice text to explain the problem to the user which Exchange Online will insert into the reject message (Figure 3).

Microsoft’s article explains how to add conditional processing and exceptions. You might want to allow some flows to run because they are needed to send email to invoke an external process, or you might want to allow flows from specific senders or addressed to specific recipient addresses because you’re happy that the email is necessary and doesn’t compromise the organization’s data governance policy.

Good Flow Controls

The email exfiltration control is simple and effective. It’s just strange that it’s taken Microsoft four years since the introduction of Flow in April 2016 to figure out that controls are needed over email generated by Power Automate. In their defense, the data governance landscape was very different in April 2016 and Office 365 did not have the same kind of compliance feature set that’s available now.

And Now for the Twitter Connector for Groups

This article originally covered the retirement of the Twitter connector for Teams. On March 23, 2020, Microsoft announced (MC207399) that they are also retiring the Twitter connector for Office 365 Groups (referred to in the notification as the Twitter Connector feature from Outlook, Yammer and Skype Consumer). Microsoft says they will begin retiring the connector on March 24 and complete the process by March 31. It remains a mystery as to why Microsoft wishes to retire a component that functions perfectly well and works better than its suggested replacement.

Tweets Keep on Flowing Into Teams

The decision to retire the Teams Twitter connector announced in Office 365 notification MC204830 on February 26 seems odd. It’s also a retrograde step.

Apparently, Microsoft retired the connector on February 21 without telling anyone (but they do apologize for the inconvenience). As I write this note on March 8, the connector is still working in the channels where it’s configured in my tenant (Figure 1) and tweets continue to flow in as normal. It must take as long to retire features in Office 365 as it does to deploy them. Or I’m just lucky…

Go to Power Automate to Flow Tweets into Teams

The announcement blithely says: “If your organization enjoyed using the Twitter connector, we recommend using Microsoft Power Automate to integrate Twitter with Microsoft Teams.” I’m not sure that the folks who wrote that text understand the difference between injecting tweets into Teams through the connector and using Power Automate (what used to be known as Flow) for the task.

Like other connectors, the Twitter connector injects content from a network data source into a channel to inform users and potentially spark conversations in the channel (Figure 2). Each tweet is captured as a conversation and comes complete with a set of actionable buttons to like or retweet the tweet without leaving Teams or going to Twitter to view the conversation there.

Power Automating Twitter

Following Microsoft’s advice, I went to Power Automate and attempted to create the functionality available through the Twitter connector. The “Post on Microsoft Teams when a new tweet matches the specified hashtag” template seemed like a good place to start, and I duly configured it to read from Twitter using my account and post to a target channel in Teams ((Figure 3).

Alas, the results weren’t as good as those products by the Twitter connector (Figure 4). Everything is posted as me rather than the eponymous Twitter connector. The actionable buttons have disappeared and the user photos for those who post tweets are not captured. All in all, it’s a poorer experience.

Odd Decision, Poor Results

I don’t know why Microsoft decided to retire the Twitter connector for Teams. The connector is also used in Office 365 Groups and there’s no mention of its retirement there. The connector is useful, does what you expect, has added functionality over time, and the items created in channels look good.

The decision is even harder to understand when viewed in the light of a lesser replacement, but that might also be because the Power Automate template that I selected wasn’t the best for the job. Perhaps the problem is the way that the connector fetches information. Like most social media companies, Twitter is tightening up its regulations about how processes access data, and it could be that Twitter doesn’t like this connector. If so, that’s a pity.

In my copious spare time, I need to do more research to see if I can discover how to make Power Automate be nicer to Teams. Or maybe one of the Power Automate gurus will come up with a nicer solution.