Questa parte dell’esame non chiede di saper costruire un flow: chiede di scegliere. Lo schema è sempre lo stesso — uno scenario di due righe, quattro opzioni tutte tecnicamente costruibili — e la risposta corretta è quella che regge il requisito con lo strumento più semplice. Il secondo blocco di domande è speculare: qualcosa non funziona, e devi sapere quale strumento di diagnosi ti dice perché.

Prima di automatizzare: il valore va calcolato o scritto?

L’errore più frequente è automatizzare un valore che non andava scritto affatto. «Deve sempre riflettere i valori correnti» è la definizione di un campo calcolato: un flow scrive, e da quell’istante il valore invecchia finché qualcosa non lo riscrive.

Strumento Cosa produce Vincolo strutturale
Formula field Calcolo a runtime sui campi dello stesso record e del record padre via relazione (cross-object formula, es. Account.Industry letto da Case) Sola lettura, non aggrega record figli
Roll-up summary COUNT, SUM, MIN, MAX su record correlati Richiede una master-detail e si definisce sul lato master: con un lookup non esiste
Record-triggered flow Scrive davvero un valore al salvataggio Il valore resta finché un’altra automazione non lo aggiorna
Screen flow Raccoglie input dall’utente, poi legge e scrive record Serve un utente che lo esegua
Approval process Instrada il record fra step e approvatori Ha uno storico di approvazione proprio, che nessun flow replica

Il caso classico: un valore sulla Case che combina due campi della Case con l’Industry dell’account collegato via lookup standard. È una cross-object formula che risale al padre; il roll-up summary va nella direzione opposta e pretende una master-detail che lì non c’è.

Il momento in cui gira conta quanto lo strumento

Su un record-triggered flow, «quando» non è un dettaglio di performance: decide cosa il flow può fare.

Opzione Quando gira A cosa serve
Fast Field Updates Durante l’update che ha scatenato il flow, prima del salvataggio Modificare il record che ha fatto scattare il trigger, o mostrare un errore custom
Actions and Related Records Durante l’update, dopo il salvataggio Creare, aggiornare o eliminare altri record, chiamare subflow, eseguire azioni (email alert, post Chatter)
Run Asynchronously Subito dopo il completamento dell’update Chiamate a sistemi esterni e operazioni lunghe, per non rallentare il salvataggio
Scheduled Paths In futuro, ancorato a un tempo trascorso o a una data sul record Promemoria e solleciti legati a una data del record

Sull’update conviene quasi sempre Only when a record is updated to meet the condition requirements: il flow gira quando la condizione passa da non soddisfatta a soddisfatta, non a ogni modifica successiva.

Riuso: la stessa logica chiamata da tre automazioni

Quando lo stesso calcolo serve a due record-triggered flow su oggetti diversi e a uno screen flow, ed è rivisto qualche volta l’anno, la risposta non è «replicarlo tre volte». Si costruisce una volta come Autolaunched Flow (No Trigger) e lo si richiama con l’elemento Subflow, passando i dati con variabili marcate Available for input e Available for output: quando la regola cambia si modifica un artefatto solo.

Due limiti: Subflow può referenziare soltanto autolaunched flow e screen flow — mai un record-triggered flow — e la chiamata richiede il percorso Actions and Related Records, perché il before-save è volutamente povero di elementi.

Schedulato: due cose diverse con lo stesso aggettivo

  • Scheduled path: vive dentro un record-triggered flow, quindi parte solo se un record fa scattare il trigger, e ritarda l’azione rispetto a quel momento.
  • Schedule-triggered flow: gira a una data e ora stabilite, con frequenza singola, giornaliera o settimanale, a prescindere da qualunque modifica. Con oggetto e condizioni di filtro processa in batch tutti i record che le soddisfano.

Se lo scenario dice «ogni notte, tutti i record che…» e aggiunge che le modifiche diurne di un’integrazione non devono innescare nulla, la scheduled path è esclusa per costruzione.

Non ricostruire l’automazione che esiste già

Un approval process già configurato non si riscrive come flow. Lo si fa partire da un record-triggered flow after-save con l’azione Submit for Approval: il routing resta quello, l’approval history continua a riempirsi e l’utente non preme nulla.

Quando la risposta è «passa a uno sviluppatore»

La guida architetturale sul record-triggered automation ragiona per densità di automazione sull’oggetto:

Densità Indicatori Scelta
Bassa meno di 15 automazioni, logica autoconsistente, 0-1 DML a valle Record-triggered flow
Media 15-30 automazioni, batch standard, 2-4 DML a valle Ibrido: Flow che invoca Apex
Alta oltre 30 automazioni, migliaia di record, 5+ DML a valle Apex trigger

Due criteri qualitativi valgono quanto i numeri: Apex serve quando occorre controllo transazionale (savepoint e rollback espliciti) o messaggistica d’errore condizionale a livello di singolo campo, più ricca dell’elemento Custom Error. E su un oggetto conviene tenere un solo punto d’ingresso all’automazione, senza mescolare Flow e Apex trigger.

Diagnosi: dal sintomo allo strumento

Sintomo Causa tipica Strumento
«Non succede niente» quando alcuni utenti aprono lo screen flow Manca Run Flows su profilo o permission set (o Flow User sul record utente); Manage Flow serve solo per eseguire flow inattivi Permission set dedicato
«Non hai accesso a questo campo» solo per alcuni CRUD/FLS dell’utente: lo screen flow gira di default in user context Permessi sui campi toccati dal flow
Funziona all’admin, fallisce sempre sullo stesso elemento per tre utenti Contesto di esecuzione, non logica Process Automation Settings → Let admins debug flows as other users, poi Debug con Run as another user e Run automation in rollback mode
«An unhandled fault has occurred in this flow» Eccezione non gestita su Get, Create, Update, Delete o Action Fault path con uno screen che mostra $Flow.FaultMessage
Update Records fallisce dopo un Get Records senza risultati Variabile null Decision con operatore Is Null subito dopo il Get, o condizione a monte
Serve una verifica ripetibile prima di attivare una versione corretta Il debug manuale non lascia traccia Flow Test sul record-triggered flow: record iniziale, record aggiornato, assertion salvate e rieseguibili

Record-triggered e schedule-triggered flow girano in system context senza sharing, senza opzione: un «errore di permessi dell’utente» su quei tipi è quasi sempre una pista sbagliata.

Trappole tipiche d’esame

  • «Deve sempre riflettere i valori correnti» esclude ogni automazione che scrive. È un formula field. E il roll-up summary viene proposto come distrattore anche quando la relazione è un lookup: senza master-detail non è nemmeno creabile.
  • Scheduled path e schedule-triggered flow non sono sinonimi. Il primo ha bisogno di un record che faccia scattare il trigger; il secondo gira comunque. Un requisito notturno su tutti i record che soddisfano una condizione è il secondo.
  • Subflow referenzia solo autolaunched flow e screen flow. Le opzioni che richiamano un record-triggered flow, o che duplicano la logica in tre posti, sono sbagliate anche quando «funzionerebbero».
  • Fast Field Updates suona sempre come la risposta efficiente. Ma se lo scenario crea altri record, chiama un’azione o un subflow, serve Actions and Related Records.
  • «Ho provato io e funziona» non è una prova. Il debug va rieseguito impersonando l’utente che fallisce, e con il rollback attivo — altrimenti scrive davvero sui dati.
  • Il fault path non ripara niente: rende leggibile il guasto. Una domanda che chiede un messaggio comprensibile con il dettaglio tecnico sta chiedendo un fault path e $Flow.FaultMessage, non un Custom Error, che è un altro strumento.