Entra Lifecycle Workflows: Automatizar Onboarding e Offboarding

O ciclo de vida de uma conta — chega, muda de lugar, sai — é dos processos mais sujeitos a esquecimento em PME: o offboarding que ficou a meio, a licença que ninguém removeu, o guest que entrou em 2023 e nunca saiu. O JML (Joiner-Mover-Leaver) já foi aqui abordado com scripts manuais: os Lifecycle Workflows (LCW) são o produto do Entra ID Governance que automatiza esse ciclo com templates, triggers por atributos e histórico auditável.

O que é

Os LCW correm tarefas automaticamente sobre utilizadores nas três fases do JML:

  • Joiner — quando alguém entra no âmbito de acesso: nova contratação.
  • Mover — quando alguém muda de departamento ou função e o acesso tem de acompanhar.
  • Leaver — quando alguém sai do âmbito: demissão, reforma, fim de contrato.

Cada workflow combina tasks (acções automáticas: gerar TAP, desactivar conta, remover licenças) com execution conditions (quem é afectado e quando dispara — por exemplo, sete dias antes do employeeHireDate). O escopo define-se por atributos de utilizador e a execução pode ser agendada ou on-demand.

⚠️ Atenção: licenciamento. Os Lifecycle Workflows requerem Microsoft Entra ID Governance ou Microsoft Entra Suite. Sem uma destas licenças, a funcionalidade não está disponível.

Os 14 templates embutidos

Tudo o que a Microsoft espera que uma organização precise está em templates que se usam como estão ou se personalizam:

Categoria Template Trigger Tasks por omissão
Joiner Onboard pre-hire employee -7 dias antes de employeeHireDate Generate TAP And Send Email
Joiner Onboard new hire employee No dia de employeeHireDate/createdDateTime Add User To Group, Enable User Account, Send Welcome Email
Joiner Post-Onboarding of an employee Depois do arranque (tarefas de acompanhamento)
Mover Real-time employee change On-demand (sem execution condition) Run a Custom Task Extension + Remove all access package assignments (remoção agendada por omissão a 15 dias)
Leaver Real-time employee termination On-demand (despedimento imediato, sem execution condition) Remove user from all groups, Delete User Account, Remove user from all Teams
Leaver Pre-Offboarding of an employee -7 dias antes de employeeLeaveDateTime Remove user from selected groups/Teams
Leaver Offboard an employee No dia de employeeLeaveDateTime Disable User Account, Remove user from all groups, Remove user from all Teams
Leaver Post-Offboarding of an employee Depois do último dia (limpeza final)
Leaver Pre-Offboard inactive users 90 dias sem sign-in Disable user account, inactivity email
Leaver Offboard inactive users 120 dias após o último sign-in Disable user account + email de inactividade (apaga-se só ao acrescentar a task Delete User Account)
— Employee group membership changes Grupo muda Remove all access package assignments (15 dias) + Remove from Teams + email ao manager
— Employee job profile change Atributo de cargo muda Email ao manager + Remove all access package assignments (15 dias) + Remove from selected groups/Teams + Request access package assignment
— Transition agent sponsorships (2 variantes) Sponsor sai ou muda de função —

O Unsponsored guest cleanup (Preview) soma-se a estes para guests sem sponsor — mais abaixo.

Criar um workflow: offboarding no último dia

O caso de uso mais urgente — a conta que se desactiva no dia da saída — é o template Offboard an employee:

  1. No Microsoft Entra admin center: ID Governance > Lifecycle workflows > Workflows > Create new workflow.
  2. Escolher o template Offboard an employee (categoria Leaver).
  3. Em Basics: nome e descrição do workflow.
  4. Trigger: Time based attribute, employeeLeaveDateTime, Days from event = 0, Event timing = On.
  5. Scope: regra que identifica os utilizadores sujeitos (por departamento, tipo de contrato ou atributo próprio).
  6. Tasks: Disable User Account, Remove user from all groups, Remove user from all teams — a ordem é a sequência de execução.
  7. Revisão e criação. O workflow activa-se e passa a correr em cada utilizador que entra no âmbito.

Para despedimentos imediatos (sem aviso), o Real-time employee termination corre on-demand com Delete User Account incluído — o que apaga a conta na hora, não a desactiva.

Utilizadores inactivos: o trigger Sign-in inactivity

O trigger de inactividade usa o atributo lastSuccessfulSignInDateTime: define-se Days of inactivity (o template traz 90) e o workflow dispara sobre quem passou desse limite. Os templates Pre-Offboard (desactiva e avisa) e Offboard inactive users (elimina) formam um par que evita contas-zombie — a clássica conta de ex-colaborador que ninguém desactivou e alguém autentica dois anos depois.

⚠️ Atenção: desactivar contas por inactividade exige uma política de comunicação prévia — um utilizador de licença longa sem sign-in não é necessariamente um leaver. O template Pre-Offboard envia email antes do corte por uma razão.

Limpeza de guests sem sponsor

O template Unsponsored guest cleanup (Preview) ataca outro esquecimento clássico: guests convidados por colaboradores que já saíram. O trigger Guest sponsor status fica fixo em Number of sponsors = 0 (não configurável neste preview) e a task por omissão é Delete User Account — opcionalmente com um email de notificação a destinatários definidos.

Ler bem o trigger antes de activar: o filtro é número de sponsors igual a zero, por isso todo o guest sem sponsor atribuído apanha o filtro — e a task por omissão apaga a conta. Um tenant em que ninguém preencheu sponsors é exactamente o caso em que o workflow apaga tudo quanto apanha. Antes de activar: validar quantos guests estão sem sponsor e atribuí-los, começar com o email de notificação em vez da task de apagar, e testar com scope restrito (a Microsoft descreve estes guests sem sponsor como risco de segurança e compliance).

Nota de custos: a Microsoft indica que a funcionalidade está sujeita ao modelo de facturação de guests — mais um motivo para o scope ser intencional.

Limites e administração

  • 100 workflows por tenant e 100 custom task extensions — as extensões ligam logic apps para cenários que os tasks embutidos não cobrem.
  • Para criar e gerir workflows é preciso (no mínimo) o papel Lifecycle Workflows Administrator — o histórico e a audit de cada execução ficam no próprio workflow.
  • Os tasks Disable/Delete user account não correm para utilizadores com papéis do Entra atribuídos nem membros/owners de grupos role-assignable — contas de administradores precisam de tratamento manual.
  • Remove user from all groups só remove de Microsoft 365 e security groups cloud: mail-enabled, distribution, dinâmicos e role-assignable ficam — é a causa do clássico “apaguei o utilizador e os grupos ficaram sujos”.
  • O email de inactividade e o TAP de onboarding vão ao manager (requer manager e mail do manager preenchidos) — não ao utilizador.
  • Os templates Transition agent sponsorships exigem licença Microsoft Agent 365.
  • Os tasks Disable/Delete dos templates por omissão não apagam nada: Offboard inactive users = Disable user account + email de inactividade, e só ao acrescentar a task Delete User Account o offboard elimina contas.
  • Os e-mails dos tasks customizam-se (subject, corpo, idioma, traduções) e levam atributos dinâmicos — {{user.displayName}}, {{user.employeeHireDate}}, {{temporaryAccessPass}} — o email vai ao manager do novo colaborador (é o task “…send via email to user’s manager”), para escrever “Olá Marina, o teu acesso temporário é…” sem script.
  • Microsoft Security Copilot cria e gere workflows por linguagem natural — para quem prefere texto a cliques é o caminho mais curto de “quero desactivar quem não entra há 90 dias” para um workflow pronto a executar.
  • Tudo isto tem caminho programático — o endpoint /identityGovernance/lifecycleWorkflows do Graph cria workflows e tasks, corre execuções on-demand e devolve o histórico de cada run.

Erros comuns:

  • O workflow não dispara — o scope ou o trigger não cobre o utilizador: confirmar o atributo (employeeHireDate preenchido pelo RH-driven provisioning, employeeLeaveDateTime definido antes do último dia).
  • A conta é desactivada mas os grupos ficam — a tarefa “Remove user from all groups” é outro task — ver a lista de tasks do workflow e não confiar na desactivação só.
  • Delete User Account num template offboarding — apaga mesmo a conta: em sync híbrido o apagamento no cloud pode ser recriado pelo Entra Connect sync. Os tasks Disable/Delete têm suporte documentado para contas sincronizadas: os argumentos disableOnPremisesAccount / deleteOnPremisesAccount (ou o checkbox do task no portal) actua na conta on-premises — exigem o Entra provisioning agent (≥1.1.1586.0) e, para o delete, o Active Directory recycle bin activado.

Artigos Relacionados

Fontes oficiais