Un’integrazione Salesforce non fallisce quasi mai sul protocollo. Autenticarsi è un problema risolto, e scrivere un record pure. Ciò che chiude i progetti è il quota giornaliero di chiamate e la forma del modello dati, scoperti di solito circa tre settimane dopo il go live, quando il job notturno inizia a restituire errori e nessuno sa dire perché in collaudo funzionasse.

Lo schema è abbastanza costante da poter essere previsto. Uno sviluppatore costruisce contro un’org Developer Edition, tutto passa, il cliente approva. Il codice incontra poi un’org di produzione che contiene già un connettore di marketing, un’estrazione verso il data warehouse e un trigger Apex del 2019, e il budget di chiamate che sembrava generoso si rivela un fondo comune che altri stanno già spendendo.

Questo articolo mette avanti le sorprese: quale API dovreste usare, come si calcola il quota, cosa succede quando la vostra scrittura esegue codice che non avete scritto, come è cambiata l’autenticazione e quali decisioni sul modello dati sono costose da annullare.

Cosa decide se un’integrazione Salesforce riesce? Il quota e il modello dati, non il protocollo. Il quota giornaliero di richieste API vale per l’intera org e deriva da edizione e numero di licenze, quindi un’integrazione ben scritta può essere affamata da una scritta male nella stessa org. Progettate il batching dalla prima riga di codice, concordate external ID e upsert prima di scrivere qualsiasi cosa, e date per scontato che ogni record inviato eseguirà l’Apex di qualcun altro.

Cosa deve fare bene un’integrazione Salesforce

Le cose sono quattro e non pesano allo stesso modo.

La prima è il quota. Ogni chiamata sincrona del vostro codice viene prelevata da un unico quota giornaliero valido per l’intera org e condiviso con ogni altro consumatore dell’org.

La seconda è la piattaforma sottostante. Salesforce non è un database con un’interfaccia HTTP. È una piattaforma applicativa, e le vostre scritture eseguono trigger, flow, regole di validazione, regole sui duplicati e riepiloghi configurati da amministratori che non hanno mai sentito parlare del vostro progetto.

La terza è il modello dati. Lead, Contact, Account e Opportunity non sono intercambiabili, la conversione fra loro va in una sola direzione e ha effetti collaterali, e sbagliare la scelta significa una migrazione di dati anziché una modifica di codice.

La quarta è l’identità: come il vostro sistema e Salesforce si accordano su quale record sia quale. Sbagliate e creerete duplicati alla velocità della macchina. Tutto il resto discende da uno di questi quattro punti.

Il panorama delle API, e quale vi serve davvero

Salesforce pubblica una vasta famiglia di API. L’indice delle API Salesforce è l’elenco autorevole, e i nomi qui sotto vengono da lì e non dalla memoria.

REST API e SOAP API

La REST API è la scelta predefinita per tutto ciò che ha forma di record: creare, leggere, aggiornare, eliminare, interrogare, descrivere. È la scelta giusta per un modulo web che scrive un Lead, per un portale che legge i Case aperti di un cliente e per qualsiasi percorso interattivo a basso volume.

La SOAP API fa lo stesso lavoro attraverso un WSDL e sopravvive perché moltissimo middleware aziendale la parla nativamente e perché offre un contratto fortemente tipizzato da cui generare un client. L’errore comune è dare per scontato che SOAP sia legacy e REST moderna. Entrambe sono attuali, e le chiamate SOAP create() e update() accettano fino a 200 record ciascuna, il che conta più del formato di trasporto.

Bulk API 2.0

La Bulk API 2.0 è la via asincrona, basata su job, per il volume. Caricate un CSV, Salesforce lo suddivide e lo elabora in background, e voi interrogate i risultati. I limiti della Bulk API consentono fino a 15.000 batch per ogni 24 ore mobili e fino a 150 milioni di record acquisiti nella stessa finestra, con un tetto di 150 MB per file di job.

L’errore comune è trattare Bulk come una messa a punto per dopo. È un modello di programmazione diverso: i risultati tornano in modo asincrono, record per record, e il vostro codice deve consumarli così fin dall’inizio.

Composite e sObject Collections

Questi due sono la parte più preziosa e meno usata della REST API. Una richiesta composite porta fino a 25 sottorichieste in una sola chiamata, di cui al massimo 5 possono essere query o operazioni sObject Collections, e le sottorichieste successive possono riferirsi agli ID restituiti dalle precedenti. sObject Collections gestisce fino a 200 record dello stesso oggetto in una richiesta. Entrambe contano come una singola chiamata sul quota giornaliero, ed è tutto il punto.

L’errore comune è non sapere che esistono. Creare un Account, poi un Contact, poi un’Opportunity come tre chiamate successive costa tre volte il quota di una richiesta composite, e tre volte la latenza.

Streaming, Change Data Capture e Pub/Sub

La Streaming API è il canale di sottoscrizione basato su CometD per eventi PushTopic, generici, Platform e Change. Change Data Capture pubblica notifiche quasi in tempo reale quando i record vengono creati, aggiornati, eliminati o ripristinati, così un archivio esterno può seguire Salesforce senza polling. I Platform Events sono le vostre definizioni di evento.

La Pub/Sub API è l’interfaccia più recente in gRPC e HTTP/2 che unisce pubblicazione, sottoscrizione, recupero dello schema e scoperta dei topic in una sola API, con payload in Avro anziché JSON. Per una nuova costruzione a eventi, partite da lì.

L’errore comune è trattare gli eventi come un flusso garantito. Non sostituiscono la riconciliazione, per la ragione esposta nella sezione seguente.

I limiti di richieste API sono il vincolo vero

Questa è la sezione che decide la vostra architettura, ed è quella che più spesso si legge a progettazione conclusa.

Come si calcola il quota giornaliero

La documentazione sui limiti di richieste API fissa il quota per edizione e numero di licenze, non per utente né per applicazione. Le edizioni Enterprise e Professional con accesso API ricevono 100.000 chiamate più 1.000 per ogni licenza Salesforce o Salesforce Platform. Le edizioni Unlimited e Performance ricevono 100.000 più 5.000 per licenza. La Developer Edition riceve un forfait di 15.000, e una sandbox Full 5.000.000.

Ne discendono due cose. Un’org Enterprise da sessanta utenti ha circa 160.000 chiamate al giorno, non una scorta illimitata. E poiché il quota deriva dalle licenze, gli unici modi per alzarlo sono più licenze utente o chiamate API aggiuntive, entrambe acquistate tramite l’app Your Account di Salesforce.

Cosa conta, e cosa succede quando finisce

Il quota si misura sull’aggregato di tutte le chiamate ricevute dall’org in un periodo di 24 ore, e comprende insieme REST API, SOAP API, Bulk API, Bulk API 2.0 e la maggior parte delle chiamate Connect REST API. Le chiamate di alcune applicazioni connesse di Salesforce, come l’app mobile, sono escluse.

È questa aggregazione a cogliere impreparati. La vostra integrazione non ha un budget proprio. Lo condivide con il connettore di reporting, la piattaforma di marketing e ogni altra integrazione dell’org, e un solo consumatore scritto male che interroga ogni trenta secondi può svuotarlo e affamare codice che si comporta perfettamente.

Quando l’org supera il quota, le richieste falliscono con un 403 e REQUEST_LIMIT_EXCEEDED. Salesforce concede alle org di produzione a pagamento un margine di sforamento prima di applicare il limite in modo rigido, mentre le org di prova e Developer Edition non hanno alcuna clemenza. Progettate come se non ce ne fosse.

Misurate prima di impegnarvi su un progetto

Chiedete all’amministratore il quota dell’org e il consumo giornaliero attuale prima di scrivere codice; la REST API espone una risorsa con i limiti dell’org proprio per questo. Se i consumatori esistenti ne usano già il 70 per cento, un’integrazione sincrona record per record non è sostenibile, e nessuna messa a punto la renderà tale.

Il batching è una decisione di progetto, non un’ottimizzazione

Una volta accettato che il quota è finito e condiviso, il progetto si deduce da sé.

Non mettete mai in ciclo una chiamata a record singolo. Un job che crea 5.000 Contact uno alla volta spende 5.000 chiamate. Gli stessi 5.000 tramite sObject Collections, a 200 per richiesta, ne spendono 25. Quel fattore 200 è la differenza fra un’integrazione che sta dentro il quota di un’org media e una che non ci sta.

Usate Composite dove il lavoro è un grafo anziché un elenco. Creare un padre e i suoi figli in una richiesta elimina sia i viaggi di andata e ritorno sia lo stato intermedio che il codice dovrebbe altrimenti tenere mentre attende un ID.

Usate la Bulk API 2.0 per tutto ciò che assomiglia a un caricamento o a un’esportazione anziché a una transazione. È sbagliata per i percorsi interattivi, essendo asincrona per progetto e non restituendo alcuna risposta sincrona all’utente.

Mettete in cache i dati di riferimento. Valori di picklist, ID dei record type e risultati di describe cambiano di rado e vengono comunque riletti a ogni esecuzione senza motivo. Quella singola modifica toglie spesso un quarto del volume di chiamate di un’integrazione ingenua.

Governor limit: la vostra scrittura esegue il codice di un altro

Salesforce esegue l’Apex scritto dai clienti dentro tetti rigidi per transazione. I governor limit Apex che contano per un’integrazione sono 100 query SOQL per transazione sincrona, 50.000 record recuperati da SOQL, 150 istruzioni DML, 10.000 record elaborati da DML, 10 secondi di tempo CPU sincrono e 6 MB di heap.

Quell’Apex non lo scrivete voi. Quei limiti li raggiungete lo stesso, perché la vostra scrittura in ingresso apre una transazione che esegue tutti i trigger presenti sull’oggetto.

La bulkification, senza scrivere Apex

L’idea vale la pena di essere capita anche se non aprirete mai un file Apex.

Salesforce consegna al trigger una collezione di record, non uno solo. Un trigger scritto correttamente elabora l’intera collezione con una query e un aggiornamento. Un trigger scritto come se ricevesse sempre un record singolo esegue una query e un aggiornamento per ogni record.

Quel secondo trigger funziona benissimo per anni, perché gli utenti salvano un record alla volta dall’interfaccia. Poi la vostra integrazione invia 200 record in una richiesta, il trigger esegue la sua query 200 volte, sfonda il tetto di 100 query e l’intero batch fallisce.

La Bulk API 2.0 elabora i dati in ingresso a blocchi di 200 record, ciascuno una transazione separata, quindi il caso non è teorico. È la forma consueta di un primo caricamento massivo in un’org con una storia alle spalle.

Cosa fare al riguardo

Verificate trigger e flow su ogni oggetto su cui scriverete, prima di concordare una data di consegna. Se un trigger non è bulkificato, qualcuno deve sistemarlo, e quel qualcuno ha bisogno di competenze Apex e di una finestra di rilascio. Mettetelo a budget come voce a sé.

Dove la correzione è fuori perimetro, riducete la dimensione dei batch. Duecento per richiesta è un massimo, non un obbligo, e scendere a cinquanta a volte compra abbastanza respiro per consegnare mentre il lavoro sul trigger viene pianificato. Costa quota, quindi trattatelo come una misura temporanea.

Un’autenticazione che funzionerà anche l’anno prossimo

Questo ambito è cambiato in modo sostanziale e molte guide pubblicate sono ormai sbagliate.

Il flusso OAuth 2.0 con nome utente e password è quello da evitare. Espone le credenziali direttamente nella richiesta, Salesforce lo blocca per impostazione predefinita nelle org recenti, e il suo ritiro per le connected app è già programmato. Ogni integrazione che lo usa ancora ha bisogno di un piano di migrazione con una data.

Per il lavoro da server a server senza persone nel ciclo, le due risposte attuali sono il flusso JWT bearer, che firma un’asserzione con un certificato, e il flusso client credentials, che scambia consumer key e secret con un token. La guida di Salesforce su come invocare le API REST con l’utente di integrazione e i client credentials dice esplicitamente che questo flusso non emette alcun refresh token, quindi il client richiede un nuovo access token quando il vecchio scade.

Connected app ed external client app

Il contenitore di tutto questo era la connected app. Ora è l’external client app. Salesforce afferma chiaramente che la creazione di connected app è limitata a partire da Spring ‘26 e raccomanda le external client app, descrivendole come la nuova generazione pensata per migliorare la sicurezza e risolvere i problemi di pacchettizzazione.

Se la vostra documentazione di integrazione dice “create una connected app”, descrive un percorso che le org nuove potrebbero non offrire. Verificate cosa vale per l’org di destinazione prima di stimare il lavoro.

Girate con un utente di integrazione dedicato, e pianificate la rotazione

Date all’integrazione un utente proprio, con un profilo a privilegi minimi e limitato alla sola API. Non fatela girare sotto il nome di un dipendente. Quando quel dipendente se ne va e il suo account viene disattivato l’integrazione si ferma, nel momento peggiore possibile e con un errore che non porta da nessuna parte.

I certificati scadono e i segreti vengono ruotati. Entrambi restano silenziosi fino al giorno in cui non lo sono più, ed entrambi mettono un’integrazione completamente fuori linea anziché parzialmente. Mettete le date di scadenza in un calendario di cui una persona è responsabile, conservate le credenziali in un gestore di segreti e provate la rotazione in sandbox prima di averne bisogno sul serio.

Le trappole del modello dati

Sono quelle che costano tre settimane, perché tornare indietro significa spostare dati anziché cambiare codice.

Lead, Contact, Account e Person Account

Un Lead è un potenziale cliente non qualificato, non ancora collegato a un record aziendale. Un Contact è una persona agganciata a un Account. Un Account è un’organizzazione. La conversione trasforma un Lead in un Account e un Contact, facoltativamente con un’Opportunity, e la chiamata SOAP convertLead è esplicita nel dire che vengono sovrascritti solo i campi vuoti della destinazione, quindi i campi del Lead che avete popolato con cura potrebbero non arrivare dove vi aspettate.

I Person Account complicano il quadro. Le org rivolte ai consumatori li abilitano perché una persona fisica sia rappresentata come Account e Contact combinati, e un’integrazione scritta per un modello di Account aziendale non funzionerà senza modifiche contro un’org che li usa. Lo si scopre tardi con deprimente regolarità.

Decidete con il committente, per iscritto, quale oggetto diventa un dato record in ingresso. Non è una decisione tecnica.

External ID e upsert

È l’unico meccanismo di idempotenza sensato che Salesforce vi dà, e non dovrebbe essere negoziabile. Create sull’oggetto un campo personalizzato contrassegnato come External ID e conservateci la chiave primaria del vostro sistema. Potrete allora usare l’operazione upsert, una PATCH su /sobjects/{Object}/{ExternalIdField}/{Value}, che crea il record quando non c’è corrispondenza e lo aggiorna quando ce n’è esattamente una. Zero corrispondenze restituisce 201, una corrispondenza restituisce 200, e più corrispondenze falliscono con un 300 anziché tirare a indovinare.

La conseguenza merita di essere detta chiaramente. Con l’upsert, ritentare una richiesta fallita è sicuro. Senza, ogni ritentativo è un possibile duplicato, e un’interruzione di rete durante un job notturno diventa una bonifica che si misura in giorni.

Le regole che scattano sulle vostre scritture

Le regole sui duplicati possono bloccare o segnalare i record creati dalla vostra integrazione. Le regole di validazione rifiutano i record che non soddisfano condizioni impostate da un amministratore. Campi obbligatori possono essere aggiunti mesi dopo il rilascio, e a quel punto un’integrazione funzionante inizia a fallire su ogni record.

Nessuna di queste cose è un difetto; l’org funziona come è configurata. L’errore è trattare una scrittura respinta come un guasto di trasporto e ritentare all’infinito, quando la risposta corretta è portarla a una persona con la motivazione a livello di campo. La nostra guida ai modi di guasto delle integrazioni con API di terze parti copre la stessa categoria altrove.

Gestione degli errori, idempotenza e riesecuzione

Un’integrazione senza meccanismo di riesecuzione diventa una riparazione manuale dei dati. Non è una previsione, è ciò che accade.

Il successo parziale è il caso normale. sObject Collections imposta allOrNone a false per impostazione predefinita, quindi una richiesta da 200 record può restituire 187 successi e 13 fallimenti con motivazioni singole, e la Bulk API 2.0 restituisce risultati per record allo stesso modo. Un codice che controlla solo lo stato HTTP esterno segnalerà successo mentre perde record in silenzio.

Classificate i fallimenti prima di ritentare. Le condizioni transitorie come blocchi di riga, scadenze e quota esaurito meritano un’attesa esponenziale. I fallimenti deterministici come errori di validazione e campi obbligatori mancanti falliranno sempre allo stesso modo, e ritentarli brucia quota che non potete permettervi.

Ogni record irrecuperabile finisce in un archivio di scarto con il suo payload e il suo errore, perché una persona lo esamini e lo rinvii. Poiché le vostre scritture sono chiavate su un external ID, il rinvio è sicuro. Registrate su entrambi i lati la corrispondenza fra il vostro identificatore e l’ID Salesforce; fra sei mesi quel registro sarà l’unica cosa in grado di spiegare perché il record di un cliente è sbagliato.

E riconciliate. Gli eventi Platform e Change restano 72 ore nel bus degli eventi, e le allocazioni di platform event fissano la consegna giornaliera a 25.000 eventi su Enterprise e 50.000 su Unlimited e Performance. Un confronto pianificato di conteggi record e date di modifica recupera ciò che il flusso ha perso.

Middleware o collegamento diretto

Il punto a punto è corretto più spesso di quanto i fornitori di piattaforme ammettano. Una sorgente, una destinazione, una direzione, volume modesto, un contratto stabile: costruite direttamente e risparmiate la licenza.

Il middleware si ripaga quando la topologia smette di essere una linea. Più sistemi che si scambiano dati, trasformazioni che gli utenti di business devono poter cambiare senza un rilascio, orchestrazione fra sistemi che cadono in modo indipendente, un bisogno reale di monitoraggio e ritentativi centralizzati.

La nota onesta è che il middleware sposta il costo anziché rimuoverlo. Continuate a pagare la mappatura, la gestione degli errori e la conoscenza operativa, e aggiungete una licenza, una seconda pipeline e un secondo insieme di competenze da assumere. Il quota API non cambia, perché il middleware chiama le stesse API che avrebbe chiamato il vostro codice.

Sceglietelo perché la vostra topologia lo richiede, non perché sembra ridurre il codice. La nostra guida alla decisione fra costruire e comprare percorre lo stesso compromesso per i sistemi sottostanti, e la guida all’integrazione fra CRM e ERP copre il caso con più sistemi. Se volete che tutto questo venga valutato anziché discusso, è da lì che partono i nostri incarichi di sviluppo software.

Sandbox, rilascio e versioni delle API

Costruite in sandbox. Mai contro la produzione, e mai contro un’org Developer Edition che non condivide la configurazione di produzione, perché è la configurazione a rompervi.

Capite cosa fa un refresh. Sostituisce la sandbox con una copia fresca della produzione, quindi ogni dato di prova che esisteva solo lì sparisce. Ciò che deve sopravvivere a un refresh va scriptato e reso rieseguibile. I team lo imparano perdendo una settimana di dati di prova.

Fissate esplicitamente la versione dell’API in ogni percorso di richiesta e conoscete la politica di ritiro. La politica di fine vita delle API di Salesforce si impegna a supportare ogni versione per almeno tre anni e ad avvisare i clienti almeno un anno prima della fine del supporto. Le versioni dalla 21.0 alla 30.0 sono state ritirate in Summer ‘25, e le richieste verso una versione ritirata restituiscono 410 Gone.

È uno stop netto, non un degrado, ed è per questo che fissare la versione appartiene al piano di manutenzione. La stessa disciplina vale per qualunque API pubblichiate voi, come spiega il nostro articolo sul versionamento delle API.

Protezione dei dati nel Regno Unito e dati CRM

Un CRM è quasi interamente fatto di dati personali: nomi, datori di lavoro, numeri di telefono, indirizzi email, note sulle conversazioni. Spostarli fra sistemi è trattamento ai sensi del UK GDPR.

La prima domanda è chi sia il titolare. Le indicazioni dell’ICO su titolari e responsabili definiscono il titolare come la parte che determina finalità e mezzi del trattamento, e il responsabile come chi tratta per conto del titolare. Quando un’agenzia costruisce e gestisce un’integrazione per voi, di norma quell’agenzia è responsabile del trattamento, e un contratto scritto conforme ai requisiti dell’articolo 28 è obbligatorio e non facoltativo.

La seconda è il trasferimento internazionale. Le org Salesforce e qualsiasi middleware possono trovarsi fuori dal Regno Unito, e le indicazioni dell’ICO sui trasferimenti internazionali espongono i meccanismi disponibili e i casi in cui serve una valutazione del rischio. Stabilite dove atterrano i dati prima di firmare.

Ne discendono tre conseguenze. Non copiate campi che non vi servono, perché la minimizzazione è insieme un obbligo di legge e meno lavoro di mappatura. Non mettete dati personali di produzione in sandbox senza una decisione ponderata. E fate in modo che la cancellazione si propaghi, perché un contatto eliminato in Salesforce e lasciato intatto nel vostro warehouse è un problema di conformità concreto, e lo stesso vale quando gli agenti IA raggiungono quei record.

Quanto costa un’integrazione Salesforce

Salesforce pubblica i prezzi di edizioni e licenze sulle proprie pagine, e qui non ne citiamo alcuna cifra, perché il numero che governa la progettazione dell’integrazione è il quota API che quelle licenze producono, non il prezzo di listino.

Le cifre seguenti sono stime di servizi professionali di Mecanik nel Regno Unito, non prezzi del fornitore, e presuppongono un’org già esistente con un amministratore in grado di rispondere alle domande.

Un’integrazione semplice a senso unico, un modulo web che crea un Lead con external ID e una gestione degli errori sensata, costa tipicamente da GBP 3.000 a GBP 7.000. Una sincronizzazione bidirezionale di uno o due oggetti con risoluzione dei conflitti e un job di riconciliazione sta di solito fra GBP 15.000 e GBP 40.000. Un’integrazione a eventi su Pub/Sub con riesecuzione, gestione degli scarti e monitoraggio si colloca in genere fra GBP 30.000 e GBP 80.000.

Cosa dovrebbe contenere la consegna

Un documento di mappatura a livello di campo concordato con il committente anziché dedotto. Un external ID su ogni oggetto sincronizzato. Una gestione degli errori con archivio di scarto e processo di rinvio documentato. Un job di riconciliazione. Il monitoraggio del consumo API rispetto al quota dell’org, con avvisi ben al di sotto del tetto. Procedure operative per la rotazione dei token, la scadenza dei certificati e la riesecuzione. Una configurazione di sandbox scriptata perché sopravviva a un refresh. Un’integrazione senza tutto questo è un prototipo, qualunque cosa dica la fattura.

Costo ricorrente

Mettete a budget da GBP 400 a GBP 1.500 al mese per il monitoraggio, le tre release Salesforce annuali, la rotazione delle credenziali e le modifiche ai campi che un amministratore farà senza dirvelo. Le org che finanziano questa voce sono le org in cui le integrazioni continuano a funzionare.

Come si arriva alla realizzazione

I modi di guasto qui sono di una costanza noiosa: quota scoperto tardi, un trigger che nessuno ha verificato, un Lead che avrebbe dovuto essere un Contact, nessun modo di rieseguire un batch fallito. Tutti e quattro costano poco da prevenire in fase di progetto e molto da correggere quando esistono record reali.

Mecanik costruisce e mantiene integrazioni Salesforce come parte del proprio lavoro di sviluppo software, partendo da una verifica di quota, trigger e modello dati dell’org prima che venga scritta una riga di codice. Per un pezzo di lavoro di integrazione ben definito anziché un incarico completo, potete assumere uno sviluppatore web direttamente.

Domande frequenti

Quante chiamate API riceve al giorno un’integrazione Salesforce? Dipende dall’edizione e dal numero di licenze, e il quota vale per l’intera org anziché per singola integrazione. Le edizioni Enterprise e Professional con accesso API ricevono 100.000 chiamate più 1.000 per ogni licenza Salesforce o Salesforce Platform, Unlimited e Performance ricevono 100.000 più 5.000 per licenza, e la Developer Edition riceve un forfait di 15.000 in un periodo mobile di 24 ore.

Per Salesforce conviene la REST API o la Bulk API? Usate la REST API per il lavoro interattivo, a basso volume e in forma di record, e la Bulk API 2.0 per caricamenti ed esportazioni dove il volume è alto e una risposta asincrona è accettabile. Per tutto ciò che sta in mezzo, sObject Collections a 200 record per richiesta e Composite a 25 sottorichieste per richiesta contano ciascuna come una singola chiamata sul quota e tolgono gran parte della pressione.

Quale flusso OAuth deve usare un’integrazione Salesforce da server a server? Il flusso JWT bearer o il flusso client credentials, eseguito come utente di integrazione dedicato limitato alla sola API. Il flusso con nome utente e password è bloccato per impostazione predefinita nelle org recenti ed è destinato al ritiro, quindi non va usato per lavori nuovi. Notate inoltre che la creazione di connected app è limitata a partire da Spring ‘26 e Salesforce ora raccomanda le external client app.

Perché la mia integrazione Salesforce fallisce solo sui batch grandi? Quasi sempre per un trigger Apex non bulkificato. Salesforce consegna ai trigger una collezione di record, e un trigger scritto come se ne ricevesse uno alla volta esegue le sue query una volta per record, superando il limite di 100 query SOQL quando arriva il vostro batch. Con gli utenti dell’interfaccia che salvano un record alla volta funziona benissimo, ed è per questo che è sopravvissuto senza farsi notare.

Serve un middleware per integrarsi con Salesforce? Non per un’integrazione con una sorgente, una destinazione e una direzione a volume modesto, dove costruire direttamente è più economico e più semplice. Il middleware si ripaga quando più sistemi si scambiano dati, quando gli utenti di business devono cambiare le mappature senza un rilascio, o quando servono orchestrazione e ritentativi centralizzati. Sposta il costo anziché rimuoverlo, e non aumenta il vostro quota API.