Nel corso degli anni, progettando integrazioni per merchant su Adobe Commerce, la coppia che mi capita di dover far parlare più spesso è proprio questa: la piattaforma di commerce da un lato, Salesforce dall’altro. Sono due mondi che si guardano da vicino ma non sono nati per stare insieme. Adobe Commerce nasce come motore transazionale (catalogo, checkout, ordini); Salesforce nasce come CRM, cioè come luogo dove vive la relazione con il cliente. Farli dialogare bene è un problema di architettura, non di plugin — e la differenza tra un progetto che regge e uno che si trascina bug per due anni sta quasi tutta nelle scelte fatte all’inizio.
Provo a mettere in fila come si integra davvero Adobe Commerce con Salesforce, quali pattern esistono, cosa si sincronizza, e — soprattutto — quando ne vale la pena e quando è sovradimensionato.
Cosa vuol dire “Salesforce” quando parliamo di integrazione
Prima cosa da chiarire, perché genera più confusione di quanto si creda: Salesforce non è una cosa sola. Nei progetti che vedo entrano in gioco soprattutto tre prodotti, ognuno con esigenze di dato diverse.
- Sales Cloud — il CRM commerciale vero e proprio. Qui i sales vogliono vedere lo storico ordini, i quote, i carrelli abbandonati per fare outreach mirato.
- Service Cloud — il customer care. Gli agenti hanno bisogno di ordini, stato spedizioni, resi e rimborsi direttamente nella schermata del ticket, senza saltare tra sistemi.
- Marketing Cloud — automation ed email. Qui serve segmentare i clienti per comportamento d’acquisto e alimentare campagne e flussi.
Ognuno di questi tira dati diversi da Adobe Commerce. È un errore classico partire con “integriamo Salesforce” senza aver deciso quale Cloud, con quali oggetti e in quale direzione — perché il costo e la complessità cambiano radicalmente.
I pattern di integrazione (in ordine di robustezza)
1. Connettori marketplace pronti
Sul Commerce Marketplace e sull’AppExchange esistono connettori pre-costruiti Adobe Commerce–Salesforce (TechNWeb, NetApp/Netable e altri). Fanno il mapping degli oggetti standard — customer, order, product — spesso con sync bidirezionale, gestione dei duplicati, supporto multi-website e multi-currency, e sync dei carrelli abbandonati nelle versioni a pagamento. Molti promettono go-live “in un giorno”.
La mia posizione onesta: per uno scenario B2C standard, con oggetti standard e senza troppe personalizzazioni, un connettore è la scelta giusta nel 70% dei casi. Costa poco, si installa in fretta, ed evita di scrivere codice di integrazione che poi qualcuno dovrà manutenere. Il rischio arriva quando il tuo modello dati diverge da quello standard: custom attribute sul cliente, logiche di prezzo B2B, listini per account. Lì il connettore inizia a fare i capricci e ti ritrovi a piegarlo con override che vanificano il vantaggio del “pronto all’uso”.
2. Middleware / iPaaS
Quando i sistemi in gioco sono più di due (tipicamente Adobe Commerce + ERP + Salesforce + PIM), il pattern serio è un iPaaS in mezzo: Boomi, MuleSoft, Celigo, e simili. Il middleware fa da hub: trasforma i dati, li instrada, gestisce le code di errore e ti dà un cruscotto di monitoring. Adobe Commerce espone le sue API REST e GraphQL, Salesforce le sue, e l’iPaaS orchestra.
Il pro è la resilienza e la governance: se Salesforce è giù, i messaggi si accodano e si recuperano quando torna su. Il contro è il prezzo — le piattaforme iPaaS enterprise partono facilmente da cifre a sei zeri l’anno di sola licenza, prima di aver scritto una riga di mapping. Per un merchant mid-market è spesso il punto in cui l’integrazione diventa il progetto più costoso dell’anno. Va scelto con gli occhi aperti, non perché “fa figo avere il middleware”.
3. Integrazione custom event-driven (API + code + eventing)
Il pattern che preferisco quando serve controllo pieno: integrazione diretta guidata dagli eventi. Invece del batch sync ogni 30 minuti, Adobe Commerce pubblica gli eventi rilevanti (order placed, customer created, inventory updated) e un consumer li processa in near-real-time. Sotto, Adobe Commerce usa RabbitMQ come message broker per disaccoppiare produttore e consumatore: se il sistema a valle è temporaneamente indisponibile, i messaggi restano in coda e si recuperano — cosa che nel B2B, dove un’ora di fermo può valere decine di migliaia di euro di ordini in ritardo, non è un dettaglio.
Nel 2024 questo pattern ha un abilitatore in più: Adobe App Builder e l’out-of-process extensibility. L’idea è tenere il codice di integrazione fuori dal core di Adobe Commerce, su un runtime serverless Adobe I/O, agganciato agli eventi transazionali della piattaforma. Il vantaggio è enorme per il TCO: non tocchi il monolite, non complichi gli upgrade, e la logica verso Salesforce vive in un componente aggiornabile a parte. È la direzione in cui Adobe sta spingendo l’intera piattaforma verso il composable, e per le integrazioni è la strada che consiglio di valutare per prima nei progetti nuovi.
Cosa si sincronizza, e in che direzione
Il cuore di ogni progetto è decidere l’anagrafica delle entità e la direzione del flusso. In pratica:
- Clienti — di solito bidirezionale: il cliente creato in Commerce nasce come Contact/Account in Salesforce, ma anche i dati arricchiti nel CRM tornano indietro.
- Ordini — quasi sempre da Commerce verso Salesforce, in tempo reale: testata, righe, indirizzi di fatturazione e spedizione, spese, tasse. È il flusso che dà valore ai sales e al service.
- Prodotti e prezzi — dipende. Nel B2B con listini per account, spesso è Salesforce (o l’ERP dietro) la fonte di verità dei prezzi, e Commerce li consuma.
- Stock — se c’è un ERP, la fonte è l’ERP, non Salesforce; attenzione a non creare due sorgenti di verità.
La regola che ripeto a ogni kickoff: una sola fonte di verità per ogni dato. La maggior parte dei disastri di integrazione che ho visto nasce da due sistemi che si credono entrambi padroni dello stesso campo e si sovrascrivono a vicenda.
Quando conviene, e quando è overkill
Prendo posizione, perché è il senso di questo blog.
Conviene quando hai una forza vendita o un customer care strutturati che lavorano dentro Salesforce tutto il giorno e oggi non hanno visibilità sull’e-commerce. In un caso B2B seguito qualche tempo fa — distribuzione, sales agent sul territorio — dare agli agenti lo storico ordini e i carrelli aperti direttamente in Sales Cloud ha cambiato concretamente il modo di lavorare. Lì l’integrazione si ripaga.
È overkill quando il merchant compra Salesforce “perché ce l’hanno tutti”, non ha team che lo vive, e lo userebbe di fatto come database di clienti. In quel caso stai spendendo per un’infrastruttura che nessuno guarda: molto meglio partire da Marketing Cloud (o da uno strumento più leggero) per il solo bisogno reale — di solito l’email marketing — e rimandare il resto. Ho visto merchant mid-market bruciare budget di integrazione a sei zeri per popolare un CRM che poi nessuno apriva.
FAQ
Serve un middleware per integrare Adobe Commerce e Salesforce?
No, non sempre. Se in gioco ci sono solo Adobe Commerce e Salesforce con oggetti standard, un connettore marketplace o un’integrazione custom event-driven bastano. Il middleware/iPaaS ha senso quando i sistemi da orchestrare sono tre o più (tipicamente si aggiunge un ERP) e serve governance e monitoring centralizzati.
La sincronizzazione può essere in tempo reale?
Sì. Adobe Commerce usa RabbitMQ e un modello a eventi che permette di propagare ordini e clienti verso Salesforce in near-real-time, invece del batch periodico. Con Adobe App Builder la logica di integrazione può girare fuori dal core, agganciata agli eventi transazionali.
Meglio Sales, Service o Marketing Cloud per partire?
Dipende dal bisogno reale, non dal prodotto. Per email e segmentazione si parte da Marketing Cloud; per la forza vendita da Sales Cloud; per il customer care da Service Cloud. Integrare “tutto Salesforce” senza un team che lo usa è lo spreco più comune che vedo.
Fabio Canovi è consulente Adobe presso il gruppo Lutech. È stato tra i primi in Italia a certificarsi su Adobe Commerce ed è certificato anche su Adobe Experience Manager, Adobe Analytics e Adobe Target (Master – Target Architect). Ha oltre 10 anni di esperienza su Magento e Adobe Commerce, dalla progettazione all’integrazione con i sistemi aziendali.