Content Approval in SharePoint: Governance Without Bureaucracy

Trust in an Intranet erodes quickly when an employee clicks on a “Highlight” news item only to find a 404 error, forgotten “lorem ipsum” text, or, worse, strategic information released prematurely. In a recent Intranet modernization project for a retail multinational, we encountered exactly this scenario: dozens of geographically dispersed editors, lacking any quality filter, were publishing content that contradicted central internal communication guidelines.

The solution isn’t to restrict who can create content—we want to democratize creation—but rather to implement robust and invisible protection mechanisms: approval workflows.

The Technical Context: Content Approval vs. Power Automate

Historically, SharePoint offered native “Content Approval” within list settings. It was functional but rigid and visually outdated. In the modern Microsoft 365 ecosystem, the correct approach combines the EnableModeration property of libraries with the flexibility of Power Automate.

When we enable moderation in the “Site Pages” library:

1. Created pages remain in Draft state - visible only to the author.
2. Upon submission, they move to Pending - visible to the author and approvers.
3. Only after approval do they enter the Approved state and become visible to all readers.

The “secret” lies in not relying on the manual approval interface of classic SharePoint, but rather triggering a flow that takes the approval to where the decision-maker works: Microsoft Teams.

Practical Implementation

Although it is possible to configure the flow manually through the web interface (“Automate” -> “Configure page approval flow”), in an enterprise scenario we need to ensure this configuration is replicable and consistent across all communication sites.

To achieve this, we typically use PnP PowerShell to enable moderation and provision the flow or associate the necessary logic.

1. Enabling Moderation Programmatically

The first step is ensuring the pages library “knows” it needs approval. If we have 50 departmental sites, we won’t do this by hand.

# Connect to target site
$siteUrl = "https://tenant.sharepoint.com/sites/InternalComms"
Connect-PnPOnline -Url $siteUrl -Interactive

# Get Site Pages library
$listName = "Site Pages"
$pagesList = Get-PnPList -Identity $listName

# Check if moderation is already enabled
if (-not $pagesList.EnableModeration) {
    Write-Host "Enabling content moderation on $siteUrl..." -ForegroundColor Cyan
    
    # Enable moderation
    $pagesList.EnableModeration = $true
    
    # Optional: Define if we want versioning (essential for reverting errors)
    $pagesList.EnableVersioning = $true
    $pagesList.MajorVersionLimit = 50
    $pagesList.EnableMinorVersions = $true
    $pagesList.DraftVersionVisibility = 1 # 1 = Author and Approvers, 2 = Author only
    
    $pagesList.Update()
    Invoke-PnPQuery
    
    Write-Host "Moderation enabled successfully." -ForegroundColor Green
}

2. The Approval Flow with Adaptive Cards

Instead of using the standard flow that sends just an email, my recommendation is to create a custom flow that sends an Adaptive Card to a Teams channel or via private chat to the approver. This drastically reduces response time (the famous “Time to Publish”).

Below is an example of the JSON structure we use in Power Automate to create a rich approval card, showing the title, author, and a direct link for preview:

{
    "type": "AdaptiveCard",
    "body": [
        {
            "type": "TextBlock",
            "size": "Medium",
            "weight": "Bolder",
            "text": "New News Pending Approval"
        },
        {
            "type": "FactSet",
            "facts": [
                {
                    "title": "Title:",
                    "value": "@{triggerBody()?['feature']['name']}"
                },
                {
                    "title": "Author:",
                    "value": "@{triggerBody()?['CreatedBy']['Claims']}"
                }
            ]
        },
        {
            "type": "ActionSet",
            "actions": [
                {
                    "type": "Action.OpenUrl",
                    "title": "Review Draft",
                    "url": "@{triggerBody()?['{Link}']}"
                }
            ]
        },
        {
            "type": "TextBlock",
            "text": "Select an action:",
            "wrap": true
        }
    ],
    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
    "version": "1.3"
}

Best Practices and Common Pitfalls

During the implementation of these workflows across various clients, we identified patterns that determine the success or failure of adoption:

1. Avoid Individual Approvers: Never configure the flow to send requests to “john.doe@company.com”. John goes on vacation or changes departments, and the process stalls. Always use M365 Security Groups or shared mailboxes.

2. The “Promote to Major” Issue: If a user edits an approved page, it reverts to a draft state (minor version), but the previous published version remains visible. It is crucial to educate editors that changes are not immediate; all corrections require a new approval cycle.

3. Conditional Logic: Not all news is equal. In a recent project, we implemented logic in Power Automate where news tagged “Institutional” went to the Communications Director, while “Social” news went only to the junior content manager. This avoids unnecessary bottlenecks.

Conclusion

Implementing approval workflows in SharePoint isn’t about bureaucracy; it’s about professionalizing internal communication. With Power Platform tools, we transform a process that used to be “sending an email asking to look” into an automated and auditable pipeline.

For the organization, the result is the assurance that nothing reaches the homepage without the necessary seal of quality. For the consulting team, it’s the delivery of a system that scales with the client’s maturity, ensuring technology serves the process, and not the other way around.