Flow o Apex? Quando l'automazione Salesforce ha bisogno di codice

La versione breve, prima dei dettagli: scegli Flow quando la regola deve poterla cambiare chi non sviluppa, Apex quando volumi, complessità o gestione degli errori renderebbero fragile un Flow.

Logica scatenata da un record su un singolo oggetto: aggiornare campi, creare record collegati, inviare email e notifiche, pubblicare su Chatter.

Schermate guidate per gli utenti: procedure passo passo, inserimento dati con validazione, richieste di approvazione.

Job schedulati con logica semplice: aggiornamenti notturni, promemoria, cambi di stato.

Orchestrazione di pezzi esistenti: chiamare azioni invocabili, sottoflussi e servizi esterni semplici.

Flow è visibile agli admin, cambia in fretta e non richiede una pipeline di deploy per le piccole modifiche. Quando la logica sta in un canvas leggibile, Flow è la risposta giusta.

Logica complessa: condizioni annidate, cicli dentro cicli, molti oggetti toccati nella stessa transazione. Il canvas diventa illeggibile e non testabile.

Grandi volumi di dati: Flow ha limiti propri ed è più difficile da bulkificare correttamente; l'elaborazione batch di centinaia di migliaia di record appartiene ad Apex.

Ordine di esecuzione: quando più flow e trigger scattano sullo stesso oggetto, il debug diventa un indovinello. Un unico trigger handler con un ordine esplicito è più facile da ragionare.

Gestione errori e retry: i percorsi di errore esistono, ma logiche di ritentativo sofisticate, log e rollback parziali sono molto più puliti nel codice.

Riuso e test: Flow non ha test unitari. Apex sì, e Salesforce impone il 75 per cento di copertura per una ragione.

Logica di business che deve essere affidabile, testata e versionata: motori di prezzo, regole di assegnazione, validazioni complesse tra oggetti.

Integrazioni con sistemi esterni che richiedono autenticazione, retry, paginazione o trasformazione dei payload.

Elaborazioni batch e asincrone ad alto volume.

Interfacce custom con Lightning Web Components che hanno bisogno di logica lato server.

Tutto ciò che un admin non dovrebbe poter cambiare per sbaglio.

Se l'automazione si spiega in una frase e tocca un oggetto, usa Flow. Se serve un diagramma per spiegarla, coinvolge più oggetti o un sistema esterno, o deve essere testata, usa Apex, e lascia a Flow il ruolo di strato sottile che lo richiama. Combinare bene i due è una competenza: tieni i trigger in un unico framework, tieni i flow piccoli e documenta chi governa ogni oggetto.

Descrivi l'automazione che hai in mente e entro un giorno lavorativo sai se è un Flow, un job Apex o un po' di entrambi, con un preventivo a prezzo fisso in ogni caso.