Un approval process risponde a una domanda che nessun’altra automazione della piattaforma sa affrontare da sola: «prima di andare avanti, qualcuno deve dire di sì». Non impedisce un salvataggio come fa una validation rule, non calcola come una formula, non reagisce a un evento come un record-triggered flow. Fa due cose che sono sue e basta: instrada una richiesta a una persona e congela il record finché quella persona non risponde.

La documentazione lo definisce in una riga: un approval process «automates how Salesforce records are approved in your org». In pratica specifica i criteri che un record deve soddisfare per poter essere sottomesso, gli step necessari per approvarlo, chi approva a ogni step, e le azioni da eseguire quando il record viene sottomesso, approvato, rifiutato o richiamato.

Una nota di nomenclatura che vale la pena tenere a mente: in Setup lo strumento vive sotto Approval Processes, ma la documentazione collegata parla ormai di Classic Approval Processes, per distinguerli dalle automazioni di approvazione più recenti costruite su Flow. L’esame usa il termine secco «approval process» e intende questo.

L’anatomia: sei pezzi, sempre gli stessi

Ogni approval process, per quanto complesso, è fatto di questi componenti.

  • Entry criteria — Use this approval process if the following: con criteria are met oppure una formula. Un record che non li soddisfa non entra nel processo: il pulsante di submit produce un errore, non un’approvazione silenziosa.
  • Initial submission actions — scattano una volta sola, all’invio. L’azione di default, e questo è il punto che l’esame ama, blocca il record.
  • Approval steps — «Approval steps assign approval requests to various users and define the chain of approval». Ogni step ha criteri propri (Enter this step if the following: criteria are met): se il record non li soddisfa, lo step viene saltato e il processo prosegue.
  • Final approval actions — «occur only when a record is approved and there are no further approval steps». Tipicamente sbloccano il record e scrivono lo stato.
  • Final rejection actions — chiudono il processo con esito negativo.
  • Recall actions — cosa succede se chi ha sottomesso ritira la richiesta; di default il record viene sbloccato.

Le azioni disponibili in ciascuno di questi blocchi sono le stesse: Field Update, Email Alert, Task, Outbound Message e l’esecuzione di un flow.

Chi riceve la richiesta: le regole di assegnazione

È il cuore della configurazione e la parte che l’esame chiede con più precisione. A ogni step si sceglie come viene determinato il destinatario.

Opzione in Setup Chi decide l’approvatore Uso tipico
Let the submitter choose the approver manually chi sottomette, al momento dell’invio il processo non conosce il destinatario in anticipo
Automatically assign to approver(s) → User l’amministratore, in fase di configurazione ruolo fisso e noto (un travel coordinator, un controller)
Automatically assign to approver(s) → Queue la coda: la richiesta compare a tutti i membri un team, senza un singolo responsabile
Automatically assign to approver(s) → Related User un campo lookup a User presente sul record l’owner, un referente commerciale sul record stesso
Automatically assign using the user field selected earlier il campo gerarchico scelto all’inizio (Manager o un custom hierarchy field) catena gerarchica, il caso più comune

Nel Jump Start Wizard la stessa scelta compare con l’etichetta Automatically assign an approver using a standard or custom hierarchy field, con il campo Manager nel menu a tendina. Sempre nel wizard, la casella Use Approver Field of nome oggetto Owner decide se la gerarchia va risalita partendo dall’owner del record: è il campo che la documentazione chiama Next Automated Approver Determined By.

Quando uno step assegna la richiesta a più approvatori contemporaneamente, si sceglie inoltre se serve l’unanimità o se la prima risposta decide per tutti. Una coda si comporta per definizione nel secondo modo: il primo membro che risponde chiude la richiesta per l’intera coda.

Il record mentre è pending

Testo da tenere a mente quasi alla lettera: «The default initial submission action locks the record. This action ensures that other users (except for approvers and admins) can’t change the record while it’s pending approval».

Da qui discendono tre conseguenze che l’esame trasforma in distrattori:

  1. Il record esiste ed è visibile a chi ha visibilità su di esso. Non sparisce, non diventa una bozza, non viene cancellato.
  2. Il blocco non è assoluto: la proprietà Record Editability Properties sceglie fra Administrators ONLY can edit records during the approval process e Administrators OR the currently assigned approver can edit records during the approval process.
  3. Il blocco è un’azione, non uno stato automatico. Se togli il lock dalle initial submission actions, il record resta modificabile durante l’approvazione.

Allo stesso modo, nessun campo di stato si aggiorna da solo. Se vuoi che il record mostri «In attesa», devi aggiungere una Field Update alle initial submission actions. La related list Approval History mostra invece da sola la richiesta pendente e l’approvatore assegnato.

Approvazioni e rifiuti: dove vanno le azioni

Momento Blocco in cui si configura l’azione Quando scatta
Invio Initial Submission Actions subito, una sola volta; include il lock di default
Approvazione di uno step intermedio Approval Actions dello step solo per quello step
Approvazione conclusiva Final Approval Actions solo se non restano altri step
Rifiuto a uno step Rejection Actions dello step solo per quello step
Rifiuto che chiude il processo Final Rejection Actions quando il rifiuto termina il processo
Ritiro della richiesta Recall Actions unlock di default

C’è un interruttore che collega le ultime due righe alle precedenti: il Reject Behavior dello step. Uno step successivo al primo può eseguire tutte le sue rejection actions e le final rejection actions (rifiuto definitivo), oppure eseguire solo le proprie e rimandare la richiesta all’approvatore precedente. Nel secondo caso le final rejection actions non scattano affatto.

Quindi, se il requisito è «quando l’ultimo approvatore rifiuta, scrivi Not Approved su un campo e manda un’email», la risposta è: una Field Update e un Email Alert messi entrambi nelle Final Rejection Actions, con l’ultimo step configurato come rifiuto definitivo.

Far partire il processo

Il wizard può aggiungere da solo il pulsante Submit for Approval e la related list Approval History ai page layout dell’oggetto. Su una Lightning Record Page che usa le Dynamic Actions, l’azione va aggiunta all’highlights panel. L’invio può anche essere automatizzato: un record-triggered flow con un elemento Action di tipo Submit for Approval sottomette il record senza che l’utente debba ricordarsi di cliccare.

Infine, due impostazioni che vivono altrove: in Process Automation Settings si popola il Default Workflow User e si attiva Enable email approval response, che permette all’approvatore di rispondere via email con «Approve» o «Reject». E il processo, finito di configurare, va attivato: prima di Activate non valuta nulla.

Trappole tipiche d’esame

  • «Bloccato» non vuol dire «sparito» né «read-only per tutti». Con le initial submission actions lasciate al default, il record resta visibile e in Approval History compare la richiesta pendente; a poterlo modificare sono gli amministratori e — se la record editability lo prevede — l’approvatore assegnato. Le opzioni che parlano di cancellazione, di sola lettura per l’admin o di record non più visibile sono sempre sbagliate.
  • Azioni dello step contro azioni finali. Un campo di stato da scrivere «quando il processo finisce male» va nelle Final Rejection Actions, non nelle rejection actions del singolo step. E se l’ultimo step è configurato per rimandare all’approvatore precedente, le final rejection actions non scattano mai: la domanda spesso nasconde qui la risposta.
  • Uno step con criteri non soddisfatti viene saltato, non fallisce. Il processo prosegue allo step successivo; non si ferma e non rifiuta il record.
  • «Lo sceglie chi sottomette» non è una regola di assegnazione del processo. Se la domanda chiede quali opzioni l’approval process stesso offre per determinare il destinatario, guarda alle assegnazioni automatiche: campo gerarchico (Manager o custom), utente specifico, coda, campo Related User. La scelta manuale sposta la decisione fuori dal processo, all’utente.
  • Una coda come approvatore non è «tutti devono approvare». La richiesta arriva a tutti i membri, ma la prima risposta chiude la partita. L’unanimità è un’impostazione a parte, e riguarda gli step con più approvatori nominati.
  • Nessun campo di stato si aggiorna da solo. Se sulla scheda l’utente deve vedere «in attesa di approvazione», qualcuno deve aver messo una Field Update fra le initial submission actions: l’approval process aggiorna solo ciò che gli hai detto di aggiornare.
  • Un record sta in un solo approval process alla volta. Con più processi attivi sullo stesso oggetto, entra nel primo, nell’ordine dei processi, i cui entry criteria sono soddisfatti: l’ordine conta quanto i criteri.