This is a post related to my previous article on Yammer moderation.

This time we will expand the idea I presented previously. In the first article I presented an alternative to moderate posts in Yammer where Power Automate was being used to send Teams approval cards to content administrators and after approval/rejection content was kept or removed depending on the admin desire.

That approach works ok for the vast majority of cases, however there are some situations where the content posted by end users cannot be kept in the Yammer group while we wait the content admin intervention.

The Power Automate flow I’m presenting now solves that issue storing the post content in a SharePoint list and then, when approved, the message is reposted to the Yammer community/group.

There are two versions of the new flow.

The first version uses the Yammer post body to store a tag that indicates the message was approved. Based on that information the flow decides if the message needs to be deleted and stored temporarily in SPO until its approval or if it can just be left on Yammer group.

The second version builds on top of the previous and use a random post passwords to ensure nobody can workaround the control and create the tag manually to pre-approve the post.

In order to use the samples you will need:

  • Admin credentials for your M365 tenant.
  • Access to Power Automate premium connectors as we will use HTTP premium action to delete messages posted on Yammer.
  • The Yammer API authorization token (I’ve shown how to create it on the part 1)

Here are the steps to build the flows and play with the sample:

SharePoint List

Create a SharePoint Online list with the following columns:

  • Message ID (text, single line)
  • Group ID (text, single line)
  • Message (text, multiple lines)
  • Status (choice with ‘New’, ‘Approved’, ‘Rejected values’)

Here is a screenshot of the list I have in my test tenant.

Power Automate Flows

 

First Flow

The first flow has two parts. The first part intercepts the message posted on Yammer, check if the [APPROVED] tag is present and based on that saves the post content on the SPO list, deletes the message from Yammer and sends the approval card for the content administrator.

After the answer to the approval card send using Teams, the flow continues the execution based on the content administrator decision. If the admin approves, we create a new post to Yammer with the [APPROVED] tag and update the status column on SPO with the Approved status. If the admin rejects, we just update the SPO status value.

Second Flow

This flow is a bit more elaborated and use a random generated password as the approved tag. Instead of just tag approved messages with [APPROVED] we are using a password that users cannot guess, thus unable to bypass the approval flow.

This sample is storing the approval password on the body of the message. Best alternative could be store on the Yammer post topic collection. That approach will introduce additional complexity as Yammer deals with topics using collections. To simplify the example I’m using a string stored on the post body.

If the post has the Password: string the body, then we need to check if that value is existent on the SPO list that controls the approval process. If it is approved, then we do nothing and the message is posted to Yammer. If it is an attempt to bypass the system, then we just delete the message from Yammer.

If the message doesn’t have the approval/password tag, then the flow is similar to the previous one, and the message gets stored on SPO, deleted and the approval message is sent to content administrator.

Let me know if you need additional info to build the flows.

Have fun. – Cristiano

Disclaimer – The information contained in this blog post doesn’t represent the official Microsoft guidance or best practices. It is just the view of the author on current alternatives, implementations and workarounds for common issues and/or business needs. Please refer to official Microsoft documentation and evaluate carefully any steps, code or procedures documented herein. The author doesn’t offer any warranty. Use this information at your own risk.