Skip to content

L’offboarding di un utente Tableau senza rompere il lunedì

Una persona se ne va. Il suo nome resta su cartelle di lavoro, pianificazioni e sottoscrizioni, e diverse di queste si guastano senza un rumore. Cosa possiede, cosa si rompe, e l’ordine che mantiene la licenza recuperabile.

Aggiornato · 5 min di lettura

Una persona, molte cose possedute

L’account viene chiuso nell’identity provider. Il ticket viene segnato come fatto. Sul sito Tableau, sei tipi di oggetto portano ancora quella persona come proprietario. Ognuno si comporta in modo diverso una volta che il proprietario smette di essere licenziato.

Cartella di lavoro
Continua a funzionare. Il proprietario se n’è andato e nessuno ne è responsabile. Le credenziali incorporate al suo interno erano le sue.
Origine dati pubblicata
Lo stesso. Tutto ciò che sta a valle eredita il problema, e nessuno l’ha scelto.
Flusso
Smette di girare se si autenticava come l’utente in uscita. Gli output a valle conservano in silenzio il loro ultimo risultato.
Progetto
I permessi si ereditano da dove sta il contenuto. Un progetto senza proprietario attivo lascia il modello dei permessi senza proprietario attivo.
Sottoscrizione
O smette di arrivare, o continua ad arrivare, indirizzata a qualcuno che se n’è andato. Sono sbagliate entrambe, e solo una viene notata.
Attività di aggiornamento
L’estrazione smette di aggiornarsi. La dashboard resta in piedi e diventa obsoleta lì dov’è.

L’ultima è quella costosa. Nulla di essa sembra sbagliato.

I guasti che restano silenziosi

Ordinati per quanto a lungo di solito passano inosservati, i più lunghi per primi.

  1. Un’attività di aggiornamento senza proprietario attivo. La dashboard serve come ha sempre fatto. I dati dietro invecchiano di un giorno ogni giorno.
  2. Una sottoscrizione che continua a inviare. Chiunque la riceva presume che un rapporto che arriva sia un rapporto che qualcuno mantiene.
  3. Credenziali incorporate dalla persona che se n’è andata. La connessione continua a funzionare. Si ferma quando quella credenziale viene ruotata, o quando l’account viene disabilitato.
  4. Un flusso che si è fermato. Le origini dati che alimentava esistono ancora e restituiscono ancora righe. Il guasto sta a un salto di distanza da dove qualcuno guarda.
  5. Contenuti in uno spazio personale. Nessun altro può vederli, quindi nessun altro può ereditarli.

Decidere chi eredita cosa

La riassegnazione sembra tecnica. È una decisione di business. Il software può spostare la proprietà, e solo una persona può dire dove dovrebbe andare.

  • Contenuti con un team evidente: dalli al responsabile attuale di quel team, non a un amministratore.
  • Contenuti che nessuno reclama: dai loro un proprietario provvisorio con un nome, e mettici una data di revisione. Questo rinvia la decisione senza lasciarla cadere.
  • Contenuti il cui unico utente era la persona in uscita: archiviali come prova. Passarli a qualcuno che non li aprirà mai non aiuta nessuno.

A uno schema vale la pena resistere: spostare tutto a chi sta gestendo l’offboarding. È veloce, e sembra reversibile. Un anno dopo sembra uguale a non aver fatto nulla.

Cinque rischi da vedere per primi

Il pianificatore trova questi cinque e li mostra mentre il piano è ancora in sola lettura. Nulla è ancora cambiato.

Credenziali incorporate
L’elemento si autentica come l’utente in uscita. Spostare la proprietà non lo riautentica. Una persona deve fornire una nuova credenziale.
Ruolo non compatibile
Il nuovo proprietario proposto ha un ruolo di sito che non può detenere questo contenuto. L’esecuzione si ferma lì, invece di lasciare uno stato a metà.
Una sottoscrizione senza proprietario attivo
La consegna continua sotto un proprietario che se n’è andato. Oppure si ferma, e i destinatari non sentono nulla.
Un’attività di aggiornamento senza proprietario attivo
La pianificazione sopravvive al suo proprietario e i dati no.
Uno spostamento tra progetti
L’elemento finirebbe in un progetto diverso, e i permessi seguono dove sta il contenuto. Lo spostamento cambia chi può vederlo.

Tutti e cinque compaiono nella fase di piano, che legge e propone e non cambia nulla. Quello è il momento di discuterne.

Una sola regola di ordine

Una sola regola di ordine regge l’intera operazione. L’utente viene impostato su Senza licenza solo dopo che ogni riassegnazione è riuscita.

L’alternativa vale la pena immaginarla. Rilascia prima la licenza, e lascia che una riassegnazione fallisca. Ora dei contenuti stanno sotto un account che non può più possedere nulla. Recuperarli è una conversazione con il supporto invece di un clic.

A volte ogni riassegnazione riesce e fallisce solo il cambio finale di licenza. Quello è il fallimento buono. I contenuti sono al sicuro e la licenza è ancora detenuta. Ciò che resta è una sola azione, da fare con i tuoi tempi.

La sequenza

  1. Scopri tutto ciò che l’utente possiede, in tutti e sei i tipi. Un albero di progetti ne mostra solo una parte.
  2. Leggi il piano, inclusi i rischi, prima di approvarne qualsiasi parte.
  3. Scegli i nuovi proprietari come persone. I valori predefiniti sono il modo in cui i contenuti finiscono da nessuna parte.
  4. Approva, e lascia che la riassegnazione giri fino al completamento.
  5. Solo allora rilascia la licenza.
  6. Conserva il registro: cosa si è spostato, a chi, e chi lo ha approvato.

Tutti nella stanza vogliono indietro la licenza. Resta comunque l’ultima cosa che dovrebbe muoversi. Recuperare una licenza è un clic. Recuperare una dashboard senza proprietario attivo è un pomeriggio e una telefonata a qualcuno in vacanza.

La verifica da eseguire presto

Ogni elemento qui sopra si può trovare mentre la persona è ancora presente. Quello è il momento più economico per sistemarlo. Una revisione trimestrale della proprietà richiede circa un’ora. Toglie la maggior parte delle sorprese da ogni uscita successiva.

  • Contenuti di proprietà di utenti inattivi o non più licenziati.
  • Contenuti di proprietà di un account di servizio senza una persona con un nome dietro.
  • Sottoscrizioni e attività di aggiornamento il cui proprietario ha cambiato ruolo da quando sono state create.

I team di migrazione arrivano alla stessa regola dalla direzione opposta. Sistema prima la proprietà. Altrimenti il problema viaggia intatto nel nuovo ambiente.