Aprovação de Conteúdos no SharePoint: Governação sem Burocracia

A confiança numa Intranet corrói-se rapidamente quando um colaborador clica numa notícia de “Destaque” e encontra um erro 404, um texto “lorem ipsum” esquecido ou, pior, uma informação estratégica divulgada antes do tempo. Num projeto recente de modernização de Intranet para uma multinacional de retalho, deparámo-nos exatamente com este cenário: dezenas de editores dispersos geograficamente, sem qualquer filtro de qualidade, publicavam conteúdos que contradiziam as diretrizes centrais da comunicação interna.

A solução não passa por restringir quem pode criar conteúdo — queremos democratizar a criação — mas sim por implementar mecanismos de proteção robustos e invisíveis: os workflows de aprovação.

O Contexto Técnico: Content Approval vs. Power Automate

Historicamente, o SharePoint oferecia a “Aprovação de Conteúdo” nativa nas definições da lista. Era funcional, mas rígida e visualmente antiquada. No ecossistema moderno do Microsoft 365, a abordagem correta combina a propriedade EnableModeration das bibliotecas com a flexibilidade do Power Automate.

Quando ativamos a moderação na biblioteca “Site Pages”:

1. As páginas criadas ficam no estado Draft (Rascunho) - visível apenas para o autor.
2. Ao submeter, passam a Pending (Pendente) - visível para o autor e aprovadores.
3. Só após aprovação entram no estado Approved e tornam-se visíveis para todos os leitores.

O “segredo” está em não depender da interface manual de aprovação do SharePoint clássico, mas sim gatilhar um fluxo que leve a aprovação até onde o decisor trabalha: o Microsoft Teams.

Implementação Prática

Embora seja possível configurar o fluxo manualmente através da interface web (“Automate” -> “Configure page approval flow”), num cenário empresarial precisamos de garantir que esta configuração é replicável e consistente em todos os sites de comunicação.

Para isso, utilizamos tipicamente o PnP PowerShell para ativar a moderação e provisionar o fluxo ou associar a lógica necessária.

1. Ativar a Moderação Programaticamente

O primeiro passo é garantir que a biblioteca de páginas “sabe” que precisa de aprovação. Se tivermos 50 sites de departamento, não vamos fazer isto à mão.

# Ligar ao site alvo
$siteUrl = "https://tenant.sharepoint.com/sites/ComunicacaoInterna"
Connect-PnPOnline -Url $siteUrl -Interactive

# Obter a biblioteca de Páginas do Site
$listName = "Site Pages"
$pagesList = Get-PnPList -Identity $listName

# Verificar se a moderação já está ativa
if (-not $pagesList.EnableModeration) {
    Write-Host "A ativar moderação de conteúdo em $siteUrl..." -ForegroundColor Cyan
    
    # Ativar moderação
    $pagesList.EnableModeration = $true
    
    # Opcional: Definir se queremos versionamento (essencial para reverter erros)
    $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 "Moderação ativada com sucesso." -ForegroundColor Green
}

2. O Fluxo de Aprovação com Adaptive Cards

Em vez de usar o fluxo padrão que envia apenas um email, a minha recomendação é criar um fluxo personalizado que envie um Adaptive Card para um canal do Teams ou via chat privado para o aprovador. Isto reduz drasticamente o tempo de resposta (o famoso “Time to Publish”).

Abaixo, um exemplo da estrutura JSON que utilizamos no Power Automate para criar um cartão de aprovação rico, mostrando o título, o autor e um link direto para pré-visualização:

{
    "type": "AdaptiveCard",
    "body": [
        {
            "type": "TextBlock",
            "size": "Medium",
            "weight": "Bolder",
            "text": "Nova Notícia Pendente de Aprovação"
        },
        {
            "type": "FactSet",
            "facts": [
                {
                    "title": "Título:",
                    "value": "@{triggerBody()?['feature']['name']}"
                },
                {
                    "title": "Autor:",
                    "value": "@{triggerBody()?['CreatedBy']['Claims']}"
                }
            ]
        },
        {
            "type": "ActionSet",
            "actions": [
                {
                    "type": "Action.OpenUrl",
                    "title": "Rever Rascunho",
                    "url": "@{triggerBody()?['{Link}']}"
                }
            ]
        },
        {
            "type": "TextBlock",
            "text": "Selecione uma ação:",
            "wrap": true
        }
    ],
    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
    "version": "1.3"
}

Boas Práticas e “Armadilhas” Comuns

Durante a implementação destes workflows em diversos clientes, identificámos padrões que determinam o sucesso ou fracasso da adoção:

1. Evitem Aprovadores Individuais: Nunca configurem o fluxo para enviar pedidos para “joao.silva@empresa.com”. O João vai de férias ou muda de departamento e o processo para. Usem sempre Grupos de Segurança do M365 ou caixas de correio partilhadas.

2. O Problema do “Promote to Major”: Se um utilizador editar uma página aprovada, ela volta a estado de rascunho (minor version) mas a versão publicada anterior continua visível. É crucial educar os editores de que as alterações não são imediatas; todas as correções requerem um novo ciclo de aprovação.

3. Lógica Condicional: Nem todas as notícias são iguais. Num projeto recente, implementámos uma lógica no Power Automate onde notícias marcadas com a tag “Institucional” iam para o Diretor de Comunicação, enquanto notícias “Sociais” iam apenas para o gestor de conteúdos júnior. Isto evita gargalos desnecessários.

Conclusão

Implementar fluxos de aprovação no SharePoint não é burocratizar; é profissionalizar a comunicação interna. Com as ferramentas da Power Platform, transformamos um processo que dantes era “enviar um email a pedir para ver” num pipeline automatizado e auditável.

Para a organização, o resultado é a garantia de que nada chega à homepage sem o selo de qualidade necessário. Para a equipa de consultoria, é a entrega de um sistema que escala com a maturidade do cliente, garantindo que a tecnologia serve o processo, e não o contrário.