Perché servono i Lifecycle Workflows

In ogni organizzazione le identità attraversano tre momenti critici — joiner, mover e leaver (JML). Farli a mano genera ritardi (il neoassunto senza account al primo giorno) e, soprattutto, rischi di sicurezza (l’account di un dimesso che resta attivo per settimane). I Lifecycle Workflows sono la componente di Microsoft Entra ID Governance che automatizza questi task, eseguendo azioni predefinite in risposta a eventi temporali legati agli attributi dell’utente, senza intervento manuale né script custom.

Anatomia di un workflow

Ogni workflow è composto da tre elementi che devi saper distinguere all’esame.

Trigger temporale

Il trigger si basa su un offset in giorni rispetto a un attributo data. I due attributi canonici sono:

  • employeeHireDate → per gli scenari joiner (es. “7 giorni prima dell’assunzione”).
  • employeeLeaveDateTime → per gli scenari leaver (es. “il giorno dell’uscita”).

Questi attributi vanno popolati e sincronizzati in Entra ID (tipicamente da un HR system tramite inbound provisioning da Workday/SuccessFactors, o via Microsoft Entra Connect). Se l’attributo è vuoto, l’utente non rientra mai nella finestra di esecuzione.

Scope (execution conditions)

Definisce quali utenti sono in ambito, tramite una rule query sugli attributi (es. department eq "Sales"). Trigger + scope insieme determinano l’insieme di identità processate a ogni ciclo.

Task

Le azioni vere e proprie, prese da un catalogo di task predefiniti. Per fase tipica:

  • Joiner: Generate Temporary Access Pass (TAP) per il primo accesso passwordless, Enable user account, Add user to groups/Teams, Send welcome email, Send onboarding reminder.
  • Leaver: Disable user account, Remove user from all groups e from all Teams, Remove all license assignments, e soprattutto Revoke all refresh tokens (invalida le sessioni attive), fino a Delete user in un workflow post-offboarding ritardato.

Microsoft fornisce template già pronti (Onboard pre-hire, Real-time employee termination, ecc.) che preconfezionano trigger + task coerenti.

Run scheduled vs on-demand

Distinzione che ritorna spesso nelle domande:

  • Scheduled run: il servizio valuta i workflow a intervalli regolari (di default ogni 3 ore) e processa gli utenti che ricadono nella finestra temporale del trigger. È la modalità di produzione, guidata dalle date.
  • On-demand run: esegui il workflow immediatamente su uno o più utenti selezionati manualmente, ignorando trigger e scope temporale. Serve per gestire eccezioni (un’uscita immediata per licenziamento) o per testare un nuovo workflow prima di affidarlo allo scheduler.

Entrambe le modalità producono run history, user reports e task reports per audit e troubleshooting.

SCIM app provisioning come complemento

I Lifecycle Workflows governano il ciclo di vita dentro Entra ID (account, gruppi, sessioni). Non popolano da soli gli account nelle app SaaS di terze parti. Qui interviene l’app provisioning tramite SCIM: Entra ID crea, aggiorna e deprovisiona automaticamente gli utenti nelle applicazioni collegate (ServiceNow, Salesforce, ecc.) sulla base di assegnazioni o gruppi. In un’architettura JML completa: il workflow gestisce la fase enable/disable e l’appartenenza ai gruppi, e il provisioning SCIM propaga quelle variazioni verso le app downstream. Sono strumenti complementari, non alternativi.

Trappole tipiche d’esame

  • Scenario: “Vogliamo automatizzare la generazione del TAP il giorno dell’assunzione, ma abbiamo solo licenze Entra ID P1.” → I Lifecycle Workflows richiedono Entra ID Governance (add-on che presuppone P2): con solo P1/P2 base la funzione non è disponibile. Risposta giusta: acquistare Entra ID Governance.
  • Scenario: “Un dipendente è licenziato con effetto immediato, fuori dalla data prevista.” → Non modificare l’attributo per forzare lo scheduler: esegui il workflow di terminazione in modalità on-demand sull’utente.
  • Scenario: “Il workflow di onboarding non parte per i nuovi assunti.” → Verifica che employeeHireDate sia popolato e sincronizzato; senza l’attributo data lo scheduler non include mai l’utente.
  • Scenario: “Alla revoca dell’accesso l’utente resta connesso alle app per ore.” → Aggiungi il task Revoke all refresh tokens: disabilitare l’account non termina da solo le sessioni già emesse.
  • Scenario: “Dobbiamo rimuovere l’utente anche da un’app SaaS esterna all’uscita.” → Il Lifecycle Workflow non basta: serve il deprovisioning via app provisioning SCIM verso quell’applicazione.