Replacing the Incoming Webhook Connector with the Teams Post to Channel Workflow

Last week, I discussed the looming end in sight for Office 365 connectors following their retirement from SharePoint Online and Microsoft 365 Groups. Connectors are still supported to bring information into Teams channels and the incoming webhook connector is a popular choice to create posts in channels from different network sources. For instance, this article describes how to post a notification about a report about expiring Microsoft 365 groups while this article discusses how to post information about service degradation for Office 365 workloads.

Both articles show how to use PowerShell to format the information sent for posting to a channel through the incoming webhook connector. I wanted to do the same thing with Power Automate workflows, specifically with the workflow called Post to a channel when a webhook request is received, which seems very close in concept to the incoming webhook connector: both publish a public URL for information to be sent to, and both demand that the information is formatted in a certain way.

The problem I ran into is a dearth of knowledge about how to construct the request body with PowerShell to send to the workflow. I knew that an adaptive card is used, but the example in Microsoft’s documentation wasn’t a great starting point. But persistence pays and the examples of formatting cards for Teams are better, and the adaptive card designer helped to debug various elements. In the end, I had a solution, and here’s how it works.

Create the Workflow

Channels have a workflows option in their overflow […] menu. Go to the channel you want to use as the target for the notifications and select Workflows (Figure 1).

Select Post to a channel when a webhook request is received from the screen listing available workflow templates (Figure 2).

The workflow needs an account to authenticate connections and post to the channel (this is different to the incoming webhook connector, which doesn’t need to authenticate using an account). The account must be a member of the host team. If, like me, the organization uses a utility account for this kind of operation, you’ll need to add the account to the team or select one of the existing team members. Figure 3 shows that the utility account is selected and validated (green tick). If you want to use a different account, click the […] menu and choose another account to connect.

After collecting all the necessary information, the dialog displays the name of the target team and channel. You can choose a different team or channel at this point. Once the correct target is chosen, click Add workflow. Power Automate proceeds to create the workflow and responds with the workflow URI (Figure 4).

Copy the URL and keep it safe because it is needed to tell Power Automate where to post payloads. When a payload arrives, Power Automate parses its content and if it’s OK, posts the content to the target channel.

If you forget to copy the URI, you can find it by opening the Workflows app, selecting the workflow, and copying it from the When a Teams webhook request is received step (Figure 5). To avoid potential confusion if multiple workflows of the same type are in use, I suggest that you take the opportunity to rename the workflow to make its purpose obvious.

Posting Requests to the Workflow

It’s at this point that we do some PowerShell magic to create the request sent to the workflow URI. To create a realistic example, I decided to use the Get Service Health Graph API to retrieve the current health status for critical services running in the tenant, like Exchange Online, SharePoint Online, Teams, and so on.

The request is an adaptive card, which is composed of elements like text blocks, images, and fact set. I settled on a simple design composed of an image, a heading (text block), and a fact set. A fact has a name and a value. In this case, the name is a service (like “OneDrive for Business”) and the value is the current service health status (like “service degraded”).

I created a prototype adaptive card with indicators where to add the header and facts. Creating the facts is a matter of retrieving the service health status, filtering the data to extract the status for critical services, adding a graphic indicator for each depending on the health status. After generating the data, it was then a matter of formatting it in JSON to meet the requirements of the adaptive card schema and inserting the facts and header into the right places in the prototype adaptive card. The final step is to submit the request using the Invoke-MgGraphRequest cmdlet. Figure 6 shows the result.

You can download the script from GitHub.

Normal Migration Woes

I am no Power Automate expert and profess no insight into how Power Automate works behind the scenes. I approached this exercise from the perspective of a tenant administrator who needs to replace the incoming webhook connector with a workflow. Persistence, some experience with PowerShell, knowledge of how to navigate Microsoft documentation, and trial and error got me a result in a few hours.

Overall, the transition was harder than I expected, but that might be due to lack of knowledge. It’s always difficult to do things when you suffer from that problem. I’ll chalk the experience down to normal migration woes.

Learn about using Teams, Power Automate, and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

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.

Unexplained and Unannounced Change Affects Tenant Processing

The ability to send email to a Teams channel has existed since the earliest days of the product. If Email integration is turned on (the default) for Teams (in the Teams settings section under Org-wide settings in the Teams admin center), team members can retrieve an email address for a channel using the Get email address option (Figure 1). If the address doesn’t already exist, Teams creates one in the form Channel display name <identifier.domain@region.teams.ms>. The identifier is a unique 8-character value and the region is the datacenter region the tenant belongs to.

The email address is a tad strange, you can’t change it, and any team member (except guests) can remove and replace the address, but the mechanism works to get email into Teams. Any message sent to the address is picked up by a connector and posted as a new conversation in the target channel. Team members can then reply to the conversation as they wish (replies do not go back to the original sender).

All in all, sending email to a channel is a simple and effective way of taking messages which arrive at any mailbox and share information with Teams. Outlook’s Share to Teams option is a more elegant option if you have a supported client, but it doesn’t offer the flexibility of an email address.

Guest Account for a Teams Channel

I often create a guest account or mail contact using the email address for a Teams channel. This technique allows me to include the channel as a member of Microsoft 365 groups (guest account) or distribution lists (mail contact), and be visible in the GAL. Once available in the GAL (Figure 2), anyone in the tenant can send or forward messages to the channel as easily as addressing any other recipient. This is an example of the flexibility of the channel email address.

Teams Channel Email and SharePoint Online

When email arrives for a channel, Teams captures a copy in the SharePoint team site belonging to the team. Each channel has its own folder, and if messages arrive in the channel, they go into the Email Messages folder under the channel folder.

That is, until February 5 when Microsoft changed how delivery works. Instead of creating copies in the Email Messages folder, a new folder called EmailMessages_2_2021 appeared in the channel folder (Figure 3). New messages received since are in separate folders created for each month.

Breaking Flows

On the surface, there’s nothing bad here. Microsoft had some reason to change how SharePoint stores email delivered to Teams. It seems like a sensible idea to use separate month-based folders instead of stuffing everything into one big folder. There doesn’t seem to be a technical reason for the change as the documentation for SharePoint Online limits doesn’t mention anything that seems to be related, with the only mention that when a folder contains more than 100,000 items, you can’t break permissions inheritance.

But making an unannounced change without warning can have unexpected consequences for service users. In this case, users noted that Power Automate flows failed because messages went to the new folder instead of the expected folder. The workaround is to create yet another flow to trigger when .eml (message) files appear in the document library and create a copy where the original flow expects it to be. Although this works, it is clunky and shouldn’t be necessary. And what about the people who don’t realize yet that a change has happened?

Microsoft knows about the problem. However, there’s no word yet how they plan to address the issue. When we know, we’ll publish an update here.

Changes like this are the bread and butter of the Office 365 for IT Pros writing team. We see similar updates come along every month and process them as updates to book chapters. Once we get to the bottom of this development, we’ll update Chapter 12. Stay updated by subscribing to Office 365 for IT Pros – the only book about Office 365 tenant management republished monthly.

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.