Metà delle domande di Process Automation si vince sapendo cosa può fare ogni strumento dichiarativo; l’altra metà sapendo quando gira rispetto al salvataggio. Lo stesso flow, spostato di un gradino nell’ordine di esecuzione, cambia risposta — e l’esame costruisce gli scenari proprio su quel gradino.
Scegliere lo strumento: cosa può, e soprattutto cosa non può
| Strumento | Fa questo | Il limite che l’esame sfrutta |
|---|---|---|
| Formula field | Calcola su campi dello stesso record | Non aggrega record correlati |
| Roll-up summary | COUNT, SUM, MIN, MAX sui figli |
Richiede il master-detail: su un lookup non esiste |
| Validation rule | Blocca il salvataggio se la formula torna True |
Guarda il record (e il padre in dot notation), non conta i figli |
| Flow prima del salvataggio | Scrive sui campi del record scatenante | Niente schermate, niente azioni, niente record correlati |
| Flow dopo il salvataggio | Crea, aggiorna, elimina altri record; azioni; subflow | Costa una seconda operazione sul database |
| Screen flow | Pone domande all’utente e ne salva le risposte | Non parte da solo a un salvataggio: va distribuito |
| Schedule-triggered flow | Gira a una data, un’ora e una frequenza | Non ha record scatenante: lavora su un insieme |
| Approval process | Instrada il record agli approvatori, blocca e aggiorna | Non è un flow: non ha elementi, ha step |
Due limiti strutturali valgono da soli parecchie domande.
Il roll-up summary vuole il master-detail. Se il figlio può esistere prima di essere attribuito al padre, il padre non è obbligatorio: la relazione resta un lookup, e con un lookup il roll-up summary non è disponibile. Il totale sul padre va allora mantenuto da un record-triggered flow sul figlio.
Un flow record-triggered non mostra schermate. Se il requisito è «chiedi tre cose all’utente e salvale sul record», l’elemento Screen non esiste in un flow scatenato dal salvataggio: serve uno screen flow, distribuito come quick action o incorporato nella pagina. L’automazione del salvataggio prepara i dati, non intervista nessuno.
I quattro momenti di un record-triggered flow
| Opzione | Quando gira | Buona per |
|---|---|---|
| Fast Field Update | Durante l’update che l’ha scatenato, prima che venga salvato | Modificare il record scatenante; mostrare un errore personalizzato |
| Actions and Related Records | Durante l’update che l’ha scatenato, dopo che è stato salvato | Creare/aggiornare/eliminare altri record, subflow, notifiche |
| Run Asynchronously | Subito dopo che l’update è completo | Chiamare sistemi esterni, processi lunghi |
| Scheduled Path | Nel futuro, ancorato a un tempo o a una data sul record | Solleciti e follow-up |
Lo scheduled path è disponibile solo con Actions and Related Records, e non va confuso con lo schedule-triggered flow. Il primo nasce da un record che è cambiato, gira una volta per ogni volta che è scattato ed è ancorato a una data di quel record; il secondo parte a una data e ora con una frequenza (una volta, giornaliera, settimanale) e lavora su tutti i record che soddisfano le condizioni, senza record scatenante.
Sul trigger di update ci sono poi due entry condition: ogni volta che il record viene aggiornato oppure solo quando viene aggiornato in modo da soddisfare le condizioni. La seconda è la difesa dichiarativa contro la ricorsione.
L’ordine di esecuzione, ridotto a ciò che serve
Su ogni salvataggio la piattaforma percorre sempre la stessa sequenza:
- validazioni di sistema (campi obbligatori, formati);
- record-triggered flow configurati per girare prima del salvataggio;
- trigger Apex
before; - validazioni di sistema di nuovo e validation rule personalizzate;
- duplicate rule;
- il record viene scritto ma non committato;
- trigger Apex
after; - assignment rule, auto-response rule;
- workflow rule (e, se aggiornano campi, i trigger
before/aftergirano di nuovo); - escalation rule e record-triggered flow configurati per girare dopo il salvataggio;
- ricalcolo dei roll-up summary sul padre: il padre attraversa a sua volta la propria procedura di salvataggio;
- ricalcolo delle sharing rule basate su criteri;
- commit;
- logica post-commit: invio delle email, Apex asincrono, percorsi asincroni e scheduled path dei flow.
Tre conseguenze pagano quasi sempre all’esame.
Il flow prima del salvataggio è a monte delle validation rule. Se scrive un valore che una validation rule considera illegittimo, l’errore scatta e il salvataggio è impedito: l’utente vede un errore su un campo che non ha toccato lui. Non è un bug del flow, è l’ordine.
È anche a monte delle assignment rule. Consegna quel campo già popolato alle regole di assegnazione, che quindi lo vedono e possono usarlo come criterio. Un flow che gira dopo il salvataggio arriva tardi: l’assegnazione è già avvenuta.
Dopo il commit resta solo ciò che non è più annullabile: le email, l’Apex asincrono, i percorsi asincroni e gli scheduled path. Tutto il resto sta dentro la transazione.
Transazione, limiti e rollback
Una transazione ha un tetto di query, record recuperati, operazioni sul database e tempo di CPU. I numeri pubblicati (100 query SOQL, 50.000 record recuperati, 150 operazioni DML) si sono mossi nel tempo: la lezione è strutturale, non aritmetica. Un Update Records dentro un Loop esegue un’operazione per ogni giro: funziona sui tre record del collaudo e fallisce al primo caricamento massivo. Accumula invece i record modificati in una collection variable dentro il loop e fai un solo Update Records dopo; quando basta, usa Update Related Records.
Il Transform element va preferito al Loop quando è possibile, ma dichiara limiti espliciti: lavora solo su collection, non può contenere altri elementi e non può attraversare gli oggetti dei dati di partenza. Se per ogni elemento devi recuperare un record correlato e decidere in base a esso, serve un Loop con dentro la logica — e le operazioni sul database fuori.
Screen e Wait chiudono la transazione corrente e ne aprono una nuova: per questo un rollback successivo non annulla ciò che è stato scritto prima della schermata. Se un flow fallisce e l’errore non è gestito da un fault path, la piattaforma annulla le modifiche della transazione; se invece imbocca un fault path, la transazione non viene annullata — sta a te chiamare Roll Back Records (negli screen flow) o l’elemento Custom Error, che nei flow record-triggered mostra il messaggio che hai scritto, annulla la transazione e impedisce la modifica del record scatenante. È lo strumento giusto quando la condizione richiede di guardare i figli, cosa che una validation rule non sa fare.
Diagnosi: dove guardare quando non torna
Con più flow sullo stesso oggetto, Flow Trigger Explorer mostra quali girano e in che ordine relativo, e permette di stabilirlo. Contro la ricorsione, confronta nelle entry condition il valore attuale con quello precedente ($Record contro $Record__Prior) ed esegui la logica solo se il campo che ti interessa è davvero cambiato. E tieni un solo punto d’ingresso per oggetto: la guida architetturale chiede di non mescolare Flow e trigger Apex sullo stesso oggetto.
Trappole tipiche d’esame
- Roll-up summary su un lookup: non esiste. Se lo scenario dice che il figlio può vivere senza padre, hai già escluso il master-detail — e con esso il roll-up. Il distrattore sarà «crea un roll-up summary field».
- Validation rule contro Custom Error: la validation rule guarda il record; quando la condizione dipende dai record correlati (un task ancora aperto), la risposta è un flow prima del salvataggio con un elemento Custom Error.
- Prima o dopo il salvataggio: se il requisito è «scrivi sul record scatenante», la risposta è Fast Field Update, non un after-save che riaggiorna lo stesso record. E se lo scenario nomina assignment rule o validation rule, controlla dove cade il flow rispetto a loro.
- Scheduled path contro schedule-triggered flow: «ogni account che soddisfa X, ogni lunedì» è schedule-triggered; «tre giorni dopo la data di rinnovo di questo record» è uno scheduled path, e richiede
Actions and Related Records. - Operazione sul database dentro un loop: la domanda si riconosce dalla frase «funziona in test, fallisce col caricamento massivo». Risposta: collection variable più un unico aggiornamento fuori dal loop.
- «Cosa gira solo dopo il commit»: email e asincrono. Assignment rule, workflow, flow after-save e ricalcolo dei roll-up sono ancora dentro la transazione, e un errore successivo li annulla.