Fluxos órfãos no Power Automate: como assumir antes que parem

Em resumo

• Fluxo órfão é o que perdeu o último proprietário válido: ele continua existindo, mas falha quando as conexões da conta que saiu deixam de funcionar.
• A TI encontra esses fluxos no centro de administração do Power Platform, em Recursos e Fluxos, pela coluna de proprietários vazia, e em volume com um laço em PowerShell que confere cada proprietário no Microsoft Entra ID pelo Microsoft Graph.
• Adicionar um coproprietário devolve o acesso, mas não corrige as conexões: quem assume precisa refazer a autenticação e religar o fluxo, e o coproprietário tem controle total, inclusive para excluir.
• A troca de proprietário só existe para fluxo em solução; fora de solução, o fluxo é exportado e importado pelo novo dono, e o fluxo passa a usar a licença e o limite de requisições dele.
• Três regras impedem a repetição: fluxo de negócio sempre em solução, sempre com mais de um proprietário e, nos críticos, uma conta de serviço ou entidade de serviço como dono.

Como achar e assumir fluxos órfãos no Power Automate antes que parem?

Os fluxos órfãos no Power Automate aparecem na lista de fluxos do ambiente, no centro de administração do Power Platform, com a coluna de proprietários vazia, e a TI assume cada um adicionando um coproprietário ou, quando o fluxo está em solução, trocando o proprietário. Para isso você precisa de papel administrativo no ambiente, do módulo de administração do Power Apps e de um novo dono com a licença certa, e o passo que mais gente esquece é refazer as conexões, que continuam presas à conta de quem saiu.

A própria Microsoft define o fluxo órfão como aquele que não tem mais proprietário válido e avisa que ele pode falhar quando usa conexões ligadas à conta do usuário que saiu. Isso explica por que o problema chega tarde: o fluxo não é removido nem sinaliza nada no dia do desligamento, ele só para quando a conexão deixa de autenticar, o que pode acontecer semanas depois.

O caso típico é o fluxo de aprovação de reajuste de contratos, criado por um analista de compras, que rodou por dois anos sem ninguém olhar. Depois do desligamento dele e do bloqueio da conta, as conexões com o Outlook e com a biblioteca do SharePoint deixaram de funcionar, os pedidos ficaram esperando aprovação, os compradores passaram a confirmar tudo por e-mail e a TI só soube quando a gerência perguntou por que a fila estava parada. O tutorial abaixo cobre o caminho completo: achar, assumir, religar, trocar o dono em solução e fixar a regra que evita a repetição.

O que você precisa ter antes de começar

Tudo o que segue está em disponibilidade geral, sem recurso em preview, então nada do procedimento depende de funcionalidade que possa mudar antes de você aplicá-lo. O que muda de um tenant para outro é quem tem permissão para fazer cada parte, e por isso vale confirmar os itens abaixo antes de abrir o primeiro ambiente, para não descobrir no meio do caminho que falta acesso a quem precisa executar o passo.

• Papel administrativo: Administrador do Power Platform ou Administrador global para enxergar e alterar fluxos de qualquer ambiente, conforme os papéis de administração de serviço descritos no Microsoft Learn. Num ambiente com Dataverse, o papel de administrador do sistema no próprio ambiente também dá acesso às soluções.
• Módulo de administração: Microsoft.PowerApps.Administration.PowerShell, instalado como descreve a página de introdução ao PowerShell do Power Platform, que também informa a versão de PowerShell aceita pelo módulo.
• Consulta ao Entra ID: o SDK do Microsoft Graph PowerShell, com a permissão User.Read.All e, se houver entidade de serviço entre os donos, também Application.Read.All. A Microsoft recomenda o Graph PowerShell no lugar dos módulos AzureAD e MSOnline, que a própria página de origem registra como descontinuados desde 30 de março de 2024, então o script deste post não usa Get-AzureADUser.
• Licença do novo dono: quando o proprietário muda, o fluxo passa a consumir a licença e o limite de requisições dele, de modo que a pessoa ou a conta escolhida precisa cobrir os conectores e o volume do fluxo.
• Identificação do ambiente: o nome (GUID) do ambiente, que o cmdlet Get-AdminPowerAppEnvironment devolve.

Passo a passo para assumir os fluxos sem dono

A sequência abaixo vai do caso isolado ao volume: a tela serve para achar e corrigir poucos fluxos, o PowerShell para o ambiente inteiro e a troca de proprietário para o que está em solução. O centro de administração foi reorganizado mais de uma vez desde a publicação do artigo de origem, então trate os nomes de menu como referência e confirme o caminho na sua tela antes de repassar o procedimento para outra pessoa.

O passo 3 é o que mais fica para trás: o coproprietário foi adicionado, mas as conexões continuam na conta de quem saiu.

Passo 1: achar os fluxos sem proprietário no centro de administração

No centro de administração do Power Platform, abra Ambientes, escolha o ambiente, entre na guia Recursos (Resources) e abra Fluxos (Flows). Procure as linhas em que a coluna Proprietários (Owners) está vazia, porque é assim que a tela mostra o fluxo sem nenhum proprietário válido. A lista é paginada, então clique em Carregar mais (Load more) até o botão desaparecer, já que quem para na primeira página audita só uma fração do ambiente. A tela só mostra esses fluxos para quem tem privilégio adequado, o que é mais um motivo para fazer a busca com a conta administrativa e não com a conta de um usuário comum.

Essa tela tem um ponto cego: a conta apenas desativada costuma continuar aparecendo como proprietária, de modo que o fluxo fica com o nome de alguém que não entra mais e não cai na sua busca. É para esse caso que existe o passo 4, que confere no Entra ID se o proprietário existe e está habilitado.

Passo 2: atribuir um coproprietário pela tela do fluxo

Na lista, selecione o fluxo órfão para abrir a página de detalhes, clique em Compartilhar (Share) no topo, digite o nome da nova pessoa, selecione a conta e clique em Salvar. Escolha alguém que vá de fato sustentar o fluxo, porque o coproprietário tem controle total sobre ele, inclusive o de editar a lógica e o de excluir, e não existe papel intermediário nessa tela para quem só deveria acompanhar.

Esse passo devolve o acesso ao fluxo, mas não resolve a parada, porque a permissão mudou e as conexões não, e elas seguem autenticadas na conta de quem saiu, que é justamente o motivo de o fluxo falhar. Por isso o fluxo continua parado depois do compartilhamento, e só deixa de falhar quando alguém refaz cada conexão com uma conta que esteja ativa.

Passo 3: refazer as conexões e religar o fluxo

O novo coproprietário encontra o fluxo no Power Automate, em Meus fluxos, na aba Compartilhados comigo, e abre a edição. Para cada conexão marcada com problema, ele escolhe uma conexão dele ou cria uma nova, autentica, salva e confere se o fluxo está ativo; se o Power Automate o desligou depois das falhas, é preciso ativá-lo manualmente em Ativar (Turn on). Em seguida vale disparar uma execução de teste e olhar o histórico, porque o fluxo passa a agir com a identidade de quem refez a conexão, e uma aprovação criada ou um item gravado no SharePoint vai aparecer com o nome dele.

Essa consequência pesa na escolha do coproprietário, porque a conexão refeita carrega as permissões dele e não as de quem saiu. Se o fluxo grava numa biblioteca com permissão restrita, a nova conexão precisa de acesso a ela, e aí o erro só aparece na primeira execução real, quando o pedido já está esperando.

Passo 4: tratar o ambiente inteiro com PowerShell

Quando a lista tem dezenas de fluxos, o laço abaixo percorre todos os fluxos do ambiente e confere se existe ao menos um proprietário ou coproprietário válido no Entra ID. A diferença em relação ao exemplo da fonte é que ele consulta o Microsoft Graph e exige que a conta esteja habilitada, o que pega o caso do usuário desativado que a tela não mostra. O primeiro bloco faz as conexões, define as variáveis e testa a consulta ao Graph antes do laço.

# Conexão com o Power Platform (módulo de administração) e com o Microsoft Graph
Add-PowerAppsAccount
Connect-MgGraph -Scopes "User.Read.All","Application.Read.All"

# Teste de sanidade: se faltar permissão, o script para aqui e não marca tudo como órfão
Get-MgUser -Top 1 -ErrorAction Stop | Out-Null

$ambiente = "NOME-OU-GUID-DO-AMBIENTE"
$novoDono = (Get-MgUser -UserId "conta.sustentacao@contoso.com.br").Id
$aplicar  = $false   # só troque para $true depois de revisar a lista gerada

O teste de sanidade existe porque a função do bloco seguinte silencia os erros de consulta, e sem ele uma permissão ausente faria o script concluir que todo proprietário é inválido. A função trata o proprietário como válido quando o usuário existe e está habilitado, ou quando o identificador corresponde a uma entidade de serviço.

function Test-PrincipalValido {
    param([string]$Id)
    $usuario = Get-MgUser -UserId $Id -Property Id,AccountEnabled -ErrorAction SilentlyContinue
    if ($usuario) { return [bool]$usuario.AccountEnabled }
    $sp = Get-MgServicePrincipal -ServicePrincipalId $Id -ErrorAction SilentlyContinue
    return [bool]$sp
}

$orfaos = foreach ($fluxo in Get-AdminFlow -EnvironmentName $ambiente) {
    $temDonoValido = $false
    $papeis = Get-AdminFlowOwnerRole -EnvironmentName $ambiente -FlowName $fluxo.FlowName
    foreach ($papel in $papeis) {
        $tipo = $papel.RoleType.ToString()
        if ($tipo -in @("Owner","CanEdit") -and (Test-PrincipalValido $papel.PrincipalObjectId)) {
            $temDonoValido = $true
            break
        }
    }
    if (-not $temDonoValido) { $fluxo }
}

$orfaos | Select-Object DisplayName, FlowName, Enabled, CreatedTime | Format-Table -AutoSize
$orfaos | Select-Object DisplayName, FlowName, Enabled, CreatedTime |
    Export-Csv -Path ".\fluxos-orfaos.csv" -NoTypeInformation -Encoding UTF8

Com a lista na mão, o bloco final aplica o Set-AdminFlowOwnerRole em cada fluxo sem dono válido, com o papel CanEdit, que é o de coproprietário. Deixe a variável $aplicar em $false na primeira rodada, revise o CSV e só então rode com $true, porque o laço conta como inválido também o grupo que esteja como coproprietário, e você não quer descobrir isso depois de alterar duzentos fluxos.

if ($aplicar) {
    foreach ($fluxo in $orfaos) {
        Set-AdminFlowOwnerRole -EnvironmentName $ambiente -FlowName $fluxo.FlowName `
            -PrincipalType User -RoleName CanEdit -PrincipalObjectId $novoDono
    }
}

Para um fluxo isolado, o par Get-AdminFlowOwnerRole e Set-AdminFlowOwnerRole com o nome do ambiente e o GUID do fluxo faz o mesmo sem o laço. Antes de desligar alguém, o caminho inverso é listar o que a pessoa criou com Get-AdminFlow -EnvironmentName $ambiente -CreatedBy ID-DO-USUARIO, o que transforma o desligamento em uma checagem e não em uma descoberta. Se a conta já foi excluída e o Get-MgUser não a encontra, o identificador pode ser lido na lista de papéis do próprio fluxo.

Passo 5: trocar o proprietário dos fluxos que estão em solução

A troca de proprietário só existe para fluxo em solução, conforme a página da Microsoft sobre como alterar o proprietário de um fluxo de nuvem. No Power Automate, abra Soluções, entre na solução que contém o fluxo, abra os detalhes do fluxo e edite o campo de proprietário, escolhendo a nova conta. Se a licença da conta escolhida não atender o fluxo, quem faz a troca recebe um aviso na hora, e vale tratá-lo como bloqueio, já que o fluxo passa a usar a licença e o limite de requisições do novo dono e um dono sem licença adequada só transfere a parada de lugar. Depois da troca, as conexões e referências de conexão precisam ser conferidas como no passo 3.

A troca de proprietário só existe para fluxo em solução; fora dela, o novo dono importa o pacote e a criação como novo gera outro identificador e outra URL de gatilho.

Fora de solução não há troca: o fluxo precisa ser exportado pelo dono atual, ou por um administrador, como pacote e importado pelo novo dono, que passa a ser o proprietário. Na importação o assistente pergunta se o fluxo deve atualizar o existente ou ser criado como novo, e criar como novo gera outro fluxo, com outro identificador, histórico de execuções zerado e outra URL de gatilho, o que quebra qualquer sistema que chame o fluxo por HTTP. Aproveite para adicionar o fluxo importado a uma solução, o que o deixa pronto para a regra da próxima seção.

Como impedir que o fluxo volte a ficar sem dono

Corrigir fluxo órfão é trabalho repetível, mas o custo real está no tempo entre a saída da pessoa e o dia em que alguém percebe, e é esse intervalo que a prevenção precisa encurtar. Ela se resume a três regras de propriedade, e cada uma fecha uma das falhas que os passos anteriores acabaram de consertar, de modo que o mesmo problema não volte na próxima saída.

Regra 1: fluxo de negócio sempre dentro de solução

Um fluxo em solução pode ter o proprietário trocado em segundos, sem exportar nem importar, e isso muda o custo da saída de alguém de um projeto para uma tarefa. As soluções também dão o caminho de promoção entre desenvolvimento, homologação e produção, que é o que a sustentação precisa de qualquer maneira. Defina como critério de entrada em produção que nenhum fluxo de aprovação, de documento ou de integração fica fora de solução.

Regra 2: sempre mais de um proprietário

Um fluxo com dois proprietários habilitados sobrevive à saída de um deles sem parar, porque a conexão que importa continua de pé e a TI ganha tempo para trocar a outra. Como o coproprietário tem controle total, escolha pessoas que respondem pelo processo e evite adicionar meia equipe por conveniência, já que cada nome a mais é alguém que pode editar a lógica ou excluir o fluxo. Rode o script do passo 4 em rotina mensal, com $aplicar em $false, e trate a lista como pendência de sustentação.

Regra 3: nos fluxos críticos, conta de serviço ou entidade de serviço como dono

O fluxo que sustenta um processo de que a empresa não abre mão não deve depender de uma pessoa, e a conta de serviço ou a entidade de serviço como proprietária resolve isso, desde que você aceite os custos. A conta de serviço precisa de licença própria, passa por política de senha, MFA e Acesso Condicional que podem quebrar a conexão se forem mal configurados, e precisa ela mesma de um responsável nomeado, para que o órfão não suba um nível. A entidade de serviço evita a senha, mas nem todo conector aceita esse tipo de autenticação, então teste o conector do fluxo antes de padronizar.

Quando não aplicar

Não use essa estrutura em fluxo de produtividade pessoal de um usuário só, como o que salva anexos do próprio e-mail numa pasta do OneDrive, porque para esse caso um coproprietário basta. Levar solução, conta de serviço e rotina de auditoria para ele cria mais trabalho de sustentação do que o risco justifica, e a TI acaba mantendo uma estrutura que ninguém pediu.

Como validar que deu certo

• O Get-AdminFlowOwnerRole do fluxo lista o novo coproprietário com o papel CanEdit ou, em solução, o novo proprietário.
• No centro de administração, em Recursos e Fluxos, a coluna Proprietários do fluxo deixa de estar vazia, depois de carregar a lista inteira.
• O fluxo aparece como ativo e o histórico de execuções mostra uma execução recente concluída com sucesso, sem conexão marcada com erro.
• Uma nova rodada do script do passo 4 devolve lista vazia. Antes de confiar nela, confirme que um fluxo em solução que você sabe que existe aparece na contagem do ambiente, comparando com o que a tela mostra.

Erros comuns e o que causa cada um

• "The term 'Get-AzureADUser' is not recognized as the name of a cmdlet": o script do artigo original foi copiado sem adaptação, e o módulo AzureAD já não é o caminho recomendado. Use o Get-MgUser do Microsoft Graph PowerShell, como no passo 4.
• "Insufficient privileges to complete the operation": a sessão do Connect-MgGraph não recebeu o consentimento para User.Read.All, ou o consentimento exige um administrador. Reconecte com os escopos do passo 4.
• "Resource ... does not exist or one of its queried reference-property objects are not present": é a resposta do Graph quando o identificador não corresponde a um usuário, e é exatamente o sinal de proprietário excluído. O script silencia essa mensagem de propósito, mas você a vê se consultar o identificador à mão.
• Todos os fluxos aparecem como órfãos: a conexão ao Graph aponta para outro tenant ou falta permissão, e a função silenciou os erros. O teste de sanidade com Get-MgUser -Top 1 evita isso.
• Coproprietário adicionado e o fluxo continua falhando: as conexões seguem na conta de quem saiu, e o fluxo pode estar desligado. Volte ao passo 3.
• Aviso de licença ao trocar o proprietário: a conta escolhida não cobre o fluxo. Escolha outra, ou licencie a conta antes de repetir a troca.
• Opção de trocar o proprietário ausente: o fluxo está fora de solução, e nesse caso o caminho é exportar e importar.

O que levar para quem aprova

Depois de pronto, todo fluxo de negócio do ambiente fica dentro de solução, com mais de um proprietário habilitado e, nos críticos, com conta de serviço ou entidade de serviço como dono, de modo que a saída de uma pessoa deixa de parar processo e passa a ser uma tarefa de rotina da sustentação. O procedimento em si não exige licença nova, pois usa o papel administrativo e os módulos gratuitos que já existem, e os custos reais são a licença da conta que passa a ser dona do fluxo, o consumo do limite de requisições dela e a rotina mensal de revisão. O risco fica sob controle da TI porque a lista de fluxos sem dono válido é gerada por script em qualquer momento, a troca de proprietário em solução é rápida e reversível e a regra de propriedade vira critério de entrada em produção, sem depender da memória de quem criou o fluxo.

Se quiser levar isso à aprovação, a Trinapse pode compartilhar o roteiro de revisão de fluxos por ambiente e o texto da regra de propriedade em formato de política curta, a partir do que já aplicamos em outros ambientes, o que poupa o trabalho de montar o material do zero.