Agosto tem sido de deep dive no LCW. Além das tarefas built-in, surgiram alguns casos de uso mais customizados que precisam de Custom Task Extension (CTE) chamando um LogicApp. Para que isso ocorra, o LA precisa de algo chamado Azure Active Directory Proof of Possession (AADPOP) e esse é o objetivo do post rapido de hoje, comentar contigo sobre esse processo.

Esse artigo será bem rapido e direto ao ponto, e espero que te ajude a não perder algumas horas durante o setup, como aconteceu comigo.

O que é por que preciso do POP

Como já falamos nesse artigo aqui sobre LCW , quando as tasks built-in não são suficientes, podemos utilizar as CTEs para chamar um LogicApp e executar tarefas que são suportadas por um LogicApp (o que é muita coisa). Pra que esse link ocorra, o LCW precisa ser capaz de iniciar (trigger) o LogicApp e pra isso, uma autorização é necessária, aqui que entra o POP.

Lá no LogicApp, temos um campo “Authorization” e lá você definirá os criterios que uma requisição enviando um POST ao LA deve ter para que ela seja aceita e inicie-o. Como eu prometi que seria um artigo rápido, pedi a meu colega Claudinho que gerasse um fluxo com base na minha explicação e temos o fluxo abaixo.

A configuração

A documentação nos ajuda bastante nesse processo, mas, falha em um detalhe que simplesmente impede que sua CTE funcione. Vamos ao pre-requisitos;

• Teu LA DEVE ser Consumption. É a primeira opção durante o provisionamento do recurso

• Teu LA DEVE TER uma Managed Identity System Assigned. UAMI não funciona, é mandatório ser System Assigned
• A blade de Authorization deve ter o POP configurado

Caso você não tenha esses pontos configurados, teu LA não aparecerá na seleção durante a configuração da CTE.

Lá no LogicApp, o que você precisa fazer é o seguinte:

1. Ative a Managed Identity System Assigned, navegando até Settings > Identity > e virando a chave para “On”
2. No mesmo menu Settings, clique em Authorization, crie uma nova policy e preencha seguindo o modelo abaixo;
   1. Policy Name: AzureADLifecycleWorkflowsAuthPOPAuthPolicy
   2. OAuth Type: Clique e selecione AADPOP
   3. Na sessão de Claims, 2 ja são padrão (Issuer e Audience), para adicionar os demais, clique em “+ Add Custom Claim”

Atenção, para o appid, a documentação entrega um AppID que não funciona. O correto é o que vou deixar na tabela abaixo.

Você também pode conferir essa informação no seu Tenant, buscando por “Lifecycle Workflows” em Enterprise App do seu Entra ID. Copie o Application ID.

Claim	Valor
Issuer	https://sts.windows.net/(Tenant ID)/ Não retire a “/” no final. Copie seu Tenant ID no menu Overview do Entra ID.
Audience	https://management.azure.com
appid	ce79fdc4-cd1d-4ea5-8139-e74d7dbe0bb7 Tudo em minúsculas. Este é o valor correto — não o que está na documentação.
m	POST
u	management.azure.com
p	/subscriptions/(subscriptionId)/resourceGroups/(resourceGroupName)/providers/Microsoft.Logic/workflows/(LogicApp name) Você pega essa linha pronta no seu LogicApp > Settings > Properties, no primeiro campo “Resource ID”.

Salve a policy e, em teoria, seu LA está pronto pra ser linkado a um CTE.

Conclusão

Feito! O proximo passo é criar um Custom Task Extension e linkar seu LogicApp a ela. Veremos isso no proximo artigo!

Espero que tenha te ajudado! Grande Abraço \,,/

O post Lifecycle Workflow – Como configurar seu LogicApp para uma Custom Task Extension apareceu primeiro em Entra ID Brasil.

Faaala pessoal, 100%?

Lifecycle Workflows (ou LCW, pros íntimos), é o nome bonito do recurso que pode te ajudar e MUITO durante processos de onboarding, alteração e offboarding de usuários. Já em GA há algum tempo, entrega templates prontos para uso que o ajudarão a governar e padronizar os fluxos de onboarding, mover e offboarding.

Embora uma baita escolha, a barreira que encontramos para adoção do recurso é, ao menos para ambiente que possuem limitação de orçamento, o Licenciamento: Entra ID Governance ou Entra Suite

A curva técnica para implantação não é muito grande, mas precisa se atentar a quais atributos o recurso olha para iniciar uma ação. Exploraremos mais a seguir.

Neste artigo eu quero mostrar por que vale a pena, o que os templates entregam de graça, e o que da pra expandir além do built-in.

Por que eu devo utilizar

Imagine o cenário em uma empresa com mais de mil funcionários (não é raro), RH abre um ticket pro TI avisando que o Fulano sai dia 15. O analista abre o chamado, aguarda a data definida e inicia o processo padrão: Desabilita a conta, remove a licença e uma nova demanda mais urgente chega. O processo de offboarding, muitas vezes, para por aí.

Ninguém revoga os refresh tokens, então a sessão do Teams no celular pessoal dele continua válida por horas. Ninguém tira ele dos 14 grupos de segurança. Ninguém cancela os Access Packages pendentes.

O Lifecycle Workflows entra para apoiar nesses processos. A Microsoft pegou o modelo Joiner-Mover-Leaver (JML) e “transformou” em objeto de configuração dentro do próprio Entra. Você define três coisas:

• Escopo (quem): uma regra de filtro tipo (department eq 'Vendas'), ou uma associação de grupo
• Gatilho (quando): baseado em atributo de tempo (employeeHireDate, employeeLeaveDateTime), mudança de atributo, mudança de grupo, inatividade de sign-in, ou sob demanda.
• Tarefas (o quê): A lista ordenada de tasks

Depois disso, o LCW toca o workflow sozinho, conforme os gatilhos e tarefas que você definiu.

Por que não um Logic App ou Automation

Eu diria que as palavras aqui são duas: Governança e Auditoria. É bem verdade que seja possível alcançar objetivos similares com recursos existentes no Azure, como Automation Account ou o proprio Logic Apps. O que muda de fato são alguns pontos que, para ambientes mais regulados com compliance forte, fazem diferença.

• Versionamento por padrão: Um workflow é versionado. Você altera uma tarefa, o Entra cria uma nova versão, e as execuções antigas continuam referenciando a versão que rodou naquele momento. Todas as alterações auditáveis e imutáveis.
• Escopo declarativo: A regra de filtro fica diretamente na definição do workflow, não em uma condição de determinado step dentro de um Logic App, por exemplo.
• Execução sob demanda com o mesmo código: Os templates de Real-time employee change e Real-time employee termination permite que o próprio HR possa iniciar o fluxo que rodará da mesma forma que um iniciado por triggers pré-definidas. Nesse fluxo podemos considerar tanto tarefas built-in quanto Custom Extensions.

Os que temos built-in

A Microsoft entrega os templates organizados por categoria JML, e hoje temos mais de 10 opções disponíveis. E não, você não precisa utilizar os templates para toda e qualquer fluxo. A Minha sugestão é utilizar-los como uma base apenas, você tem liberdade de alterar as tarefas como preferir, inclusive adicionando Custom Extension com link a um LogicApp (falaremos mais sobre logo menos).

Joiner (chegada):

• Onboard pre-hire employee — Roda em T-7 ( 7 dias antes da data de admissão) por padrão. Aqui temos uma tarefa que é a geração de TAP enviada por e-mail ao gestor. Pra quem tá indo pra passwordless, isso resolve o problema do “como o user faz o primeiro login sem senha”.
• Onboard new hire employee — Roda em T Zero: Habilita a conta, joga nos grupos, manda o e-mail de boas-vindas.
• Post-Onboarding of an employee — Roda em T+7 dias : Adiciona em Grupos e Teams Secundários.

Mover (movimentação):

• Real-time employee change — Sob demanda. Você pode entregar uma permissão users do RH para executar quando precisar
• Employee group membership changes – Como o nome sugere, executa uma alteração de grupo
• Employee job profile change — Dispara em mudança de jobTitle, notifica o gestor, e remove os access packages antigos com remoção agendada de 15 dias por padrão.

Leaver (saída):

• Pre-Offboarding of an employee — T-7 dias antes do último dia.
• Offboard an employee — No dia: desabilita, remove de todos os grupos e Teams.
• Post-Offboarding of an employee — Depois: Remove todas as licenças, remove dos Teams, deleta a conta.
• Real-time employee termination — sob demanda.

Higiene de contas inativas:

• Pre-Offboard inactive users — 90 dias sem sign-in por padrão, usando lastSuccessfulSignInDateTime.
• Offboard inactive users — 120 dias.

Esses dois de inatividade são, pra mim, a entrada mais fácil no LCW. Não dependem de integração com RH, não dependem de employeeLeaveDateTime, e ajudam diretamente a TI garantindo que contas inativas serão tratadas, seja por delação ou disable.

Agent Identities (preview):

• Transition agent sponsorships when a sponsor leaves
• Transition agent sponsorships when a sponsor changes roles

Esses dois exigem licença Microsoft Agent 365 e tratam de um problema que dois anos atrás não existia: identidades de agente de IA têm sponsor humano, e quando esse humano sai da empresa, o agente fica órfão. A Microsoft já colocou isso no modelo JML. Algo me diz que a gente vai falar muito mais disso em 2027.

Dica: Comece pelos templates de inatividade em modo de notificação (tarefas de send email) e sem nenhuma ação destrutiva. Roda por 30 dias, você vê quem ia ser pego, e ganha confiança antes de deixar o workflow rodar de verdade.

Custom Task Extensions

A lista de tarefas built-in é boa, mas não cobre processos mais complexos e customizados. Cada empresa pode ter peculiaridas que as tarefas built-in não cobriram. Por exemplo: Verificar se um usuário possui um dispositivo Windows com enrollement no Intune, e se sim, enviar um Autopilot Reset para o dispositivo.

Outras atividades que geralmente são bem comuns:

• Converter a caixa do usuário em shared mailbox e delegar ao gestor
• Configurar um auto-reply avisando que a pessoa saiu
• Abrir um ticket no service desk pra devolução do notebook

Pra cobrir esse casos de uso existe a tarefa Run a Custom Task Extension (CTE), que faz o workflow chamar um Azure Logic App (Consumption mode apenas, Std não é suportado) no meio da execução. Esse LogicApp entrega possibilidade infinitas ja que suporte ações com chamadas ou chamando um Automation Account que roda PowerShell, Python e outros. O Céu é o limite aqui.

Algo que é interessante de comentar é que o LCW não te obriga a resolver tudo dentro do Logic App, você consegue mesclar ações Built-In com a execuçao de um CTE. Temos dois modos de execução:

• Launch and continue — Dispara o Logic App e segue em frente rodando as tasks que fazem parte do workflow. Se o disparo deu certo, a tarefa é considerada sucesso. Se tua ação não depende de um retorno com sucess ou falha para seguir, essa é uma ótima opção.
• Launch and wait — Dispara e espera a resposta, com timeout configurável. Se ninguém responde dentro da janela, a tarefa falha. Pensa no seguinte fluxo: você pode ter um workflow leaver que, na tarefa 4, dispara um Logic App que abre um ticket no seu ITSM pra aprovação do gestor sobre o destino dos dados do usuário. O workflow fica parado ali. Quando o gestor aprova no ITSM, o ITSM responde ao Entra, e as tarefas 5, 6 e 7 (remover licença, deletar conta) continuam. Isso é um gate de aprovação humano dentro de um processo automatizado de identidade, com trilha de auditoria dos dois lados (compliance, auditing, compliance de novo).

Conclusão

O Lifecycle Workflows está em GA a certo tempo e ja amadureceu bastante. Os templates built-in cobrem o “feijão com arroz” do JML e os de inatividade dão um cheiro da capacidade da ferramenta. Acoplando CTEs, você consegue expandir muito seu uso e cobrir casos aqueles processos e casos de uso exóticos que eu sei que geral tem.

Ao que tudo indica, a Microsoft pretende transformar o LCW no orquestrador do ciclo de vida de qualquer identidade do Tenant. Como já vemos Agent Identities entrando nessa história, fica difícil não imaginar o LCW saindo do JML tradicional e começando a cuidar de outros tipos de identidade também.

Embora o licenciamento ainda possa ser um fator complexo na defesa da solução, os benefícios em padronização e governança pesam pro lado do “Por que Investir”.

Espero que tenha te ajudado! Grande abraço \,,/

O post Entra ID Lifecycle Workflows — Automatizando o Ciclo de Vida de Identidade apareceu primeiro em Entra ID Brasil.