Questo testo è stato tradotto utilizzando il sistema di traduzione automatica di Salesforce. Partecipa al nostro sondaggio per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.
Esistono molti modi per accedere, sincronizzare e condividere i dati tra Salesforce e i sistemi esterni. Ma non tutti gli strumenti sono adatti al tuo progetto specifico. Questa guida illustra il panorama degli strumenti di integrazione dei dati disponibili in Salesforce. Offre anche consigli sugli strumenti (o combinazioni di strumenti) più appropriati in un determinato caso d'uso, nonché indicazioni sugli strumenti da evitare per scenari specifici.
Questa guida alle decisioni si concentra sulle integrazioni a livello di dati che coinvolgono Salesforce. In particolare, copre i seguenti casi d'uso di integrazione dei dati:
- Da Salesforce a sistemi esterni
- Sistemi esterni a Salesforce
- Da organizzazione Salesforce a organizzazione Salesforce
Questi sono solo alcuni dei problemi di integrazione che Salesforce Architects deve affrontare, quindi prevediamo di aggiungere altre guide alle decisioni incentrate sull'integrazione basata sugli eventi, sulla creazione di flussi di lavoro efficaci rivolti ai clienti o ai dipendenti utilizzando l'integrazione dei processi e così via. Infine, è importante notare che molti degli strumenti e degli approcci descritti qui possono essere utilizzati per risolvere le sfide di integrazione in tutta l'azienda, ma tali utilizzi esulano dall'ambito di questa guida.
- Evitare repliche inutili dei dati. A meno che i dati non debbano risiedere assolutamente in Salesforce, considerare invece la virtualizzazione dei dati con Salesforce Connect. Un maggior numero di dati nell'organizzazione determina volumi di dati più elevati, che possono influire negativamente sulle prestazioni e aumentare l'indebitamento tecnico. Se i dati si trovano già in Salesforce e sono necessari in un sistema esterno, evitare di copiarli in un sistema esterno a meno che non siano assolutamente necessari. Chiedere invece al sistema esterno di accedere ai dati tramite le API Salesforce.
- Utilizzare MuleSoft o altre soluzioni Enterprise Service Bus (ESB) o Extract-Transform-Load (ETL), se disponibili e parte del panorama esistente. Poiché questi strumenti sono creati per supportare la migrazione e la trasformazione dei dati, spesso dispongono di potenti funzionalità che consentono di riutilizzare le integrazioni in tutta l'azienda, mantenere una governance più forte e centralizzare la gestione delle integrazioni. In questa guida, ovunque MuleSoft Anypoint sia consigliato, valutare se la soluzione ESB/ETL esistente sarà sufficiente.
- Armonizzare i dati provenienti da fonti diverse con Data 360 e Data Cloud One. Tramite il modello di dati Customer 360, la risoluzione dell'identità, la federazione dei dati e altre funzioni, Data 360 consolida i dati di Salesforce e di altri sistemi esterni in una visualizzazione unificata del cliente. Inoltre, con Data Cloud One, gli utenti di altre organizzazioni Salesforce possono accedere in modo sicuro ai dati condivisi virtualmente da Data 360 tramite gli spazi dati.
- Spostare i dati tra le organizzazioni utilizzando azioni e attivazioni Data 360. Dopo che i dati sono stati inseriti da organizzazioni diverse in Data 360, le azioni e attivazioni dei dati possono sincronizzarli con un'altra organizzazione. Questo approccio può essere molto utile per le integrazioni con le organizzazioni Marketing Cloud.
- Estrarre e spostare i dati utilizzando MuleSoft Anypoint. MuleSoft Anypoint può essere utilizzato per estrarre i dati da Data 360 utilizzando l'API Connect e l'API Data Graph e spostarli in un'altra organizzazione Salesforce. Senza Data 360, MuleSoft Anypoint può essere utilizzato anche quando i dati devono essere spostati tra le organizzazioni senza essere replicati in Data 360.
- Prestare attenzione se si sceglie di creare con Messaggistica in uscita. Salesforce continuerà a supportare Messaggistica in uscita entro le attuali capacità funzionali, ma non prevede di effettuare ulteriori investimenti in questa tecnologia.
- La licenza utente integrazione con profilo "Solo API" è sempre consigliata per tutte le integrazioni. Salesforce consiglia inoltre di utilizzare le applicazioni client esterne (a favore delle applicazioni connesse o dell'accesso SOAP) come schemi AuthN e AuthZ correttamente autorizzati per tutte le integrazioni.
Prima di esaminare gli strumenti di integrazione dei dati disponibili, è importante tenere presenti alcune considerazioni comuni quando si sceglie uno strumento. Come è tipico dell'architettura, non esiste una risposta prescrittiva a ogni sfida aziendale. Se hai pronunciato le parole "dipende" quando fai le scelte di integrazione, allora sei nel posto giusto.
| Area da considerare | Domande comuni |
|---|---|
| Strumenti e paesaggio esistenti | Esiste già una soluzione ESB o ETL? I dati interessati hanno requisiti normativi o di conformità? Dove si trovano i sistemi che si sta tentando di integrare (nel cloud o in locale)? |
| Flusso di dati (tempistica, esperienza utente prevista, direzionalità) | I dati devono essere spostati in modo sincrono, asincrono o possono essere raggruppati in batch/pianificati? È necessaria la replica dei dati? Quale sistema dovrebbe essere la fonte della verità? Qual è la fonte di dati? Qual è la destinazione? È necessaria l'interazione dell'utente? L'utente deve visualizzare il risultato dell'integrazione? Quali sono le esigenze relative alla gestione delle eccezioni (riprovare, notificare, non riuscire)? Quanto dovrebbero essere stretti i sistemi? |
| Implementazione | Qual è il livello di impegno per i sistemi non Salesforce? Quali team sono responsabili dell'implementazione delle integrazioni? Quali strumenti preferiscono utilizzare? |
| Gestibilità | Quali team dovranno mantenere l'integrazione? Quali competenze hanno attualmente? Quali competenze avranno bisogno in futuro? Qual è il costo totale di proprietà nel tempo? Quanto è importante la capacità di testare, eseguire il debug, risolvere i problemi con strumenti di codice basso o professionale? |
| Volume di dati | Quanti dati sono coinvolti nell'integrazione? Lavorerai con grandi volumi di dati (LDV)? Con che frequenza avverranno le modifiche in blocco? Che tipo di impatto avranno gli aggiornamenti Singleton? Con che frequenza si verificheranno? |
| Limiti | I dati dovranno subire trasformazioni complesse? È necessario combinare i dati di più sistemi di origine? Con che frequenza avverrà un'integrazione per utente? Quanti utenti totali? Sono stati pianificati in anticipo i caricamenti di dati in blocco (esempio: caricamento dati iniziale per una nuova istanza)? |
Di seguito è riportata una panoramica generale degli strumenti disponibili per l'integrazione dei dati e alcune considerazioni per iniziare a valutare ogni opzione. Le sezioni seguenti includono casi d'uso approfonditi e dettagli sulle funzionalità di questi strumenti.
| Da Salesforce al sistema esterno | Dal sistema esterno a Salesforce | Esecuzione | Licenza aggiuntiva richiesta | |
|---|---|---|---|---|
| Azioni Apex | Disponibile | Disponibile | Lato server | No |
| Modifica acquisizione dati | Disponibile | Non disponibile | Lato server | No* |
| Apex personalizzato (servizi Web REST e SOAP) | Disponibile | Disponibile | Lato server | No |
| Servizi esterni | Disponibile | Non disponibile | Lato server | No |
| Heroku Connect | Disponibile | Disponibile | Lato server | Sì |
| Data 360 | Disponibile | Disponibile | Lato server | Sì |
| MuleSoft Anypoint | Disponibile | Disponibile | Lato server | Sì |
| API native Salesforce | Non disponibile | Disponibile | Lato server | No |
| OmniScript | Disponibile | Disponibile | Lato client*** | Sì |
| Procedura di integrazione OmniStudio | Disponibile | Disponibile | Lato server | Sì |
| Messaggi in uscita | Non ideale | Non disponibile | Lato server | No |
| Eventi piattaforma | Disponibile | Disponibile | Lato server | No** |
| Salesforce Connect/Oggetti esterni | Disponibile | Disponibile | Lato server | Sì |
**Componente aggiuntivo richiesto per i casi d'uso di eventi piattaforma a volume elevato
***Adatto in situazioni in cui è possibile eseguire la logica aziendale all'interno del browser Web.
Legenda colonne:
- Disponibile: funziona bene per la maggior parte dei casi d'uso
- Non ideale: possibile ma considerare uno strumento alternativo
- Non disponibile: nessun piano di assistenza nei prossimi dodici mesi
Esistono altri strumenti che possono supportare alcuni aspetti di un'integrazione a livello di dati, ma non devono essere considerati un mezzo principale per risolvere i problemi di integrazione. Diamo ora un'occhiata a questi strumenti.
I componenti Web Lightning vengono in genere utilizzati per le integrazioni dei processi, ma possono effettuare chiamate utilizzando la funzionalità JavaScript, quindi i dati potrebbero essere coinvolti in queste transazioni.
Il flusso Salesforce può essere utilizzato per orchestrare chiamate esterne con Servizi esterni o Azioni Apex. Flusso Salesforce da solo non è considerato uno strumento di integrazione dei dati indipendente.
Importazione guidata dati e Data Loader possono essere utilizzati per sincronizzare, importare e migrare i dati. Benché i comandi di Data Loader possano anche essere scriptati per automatizzare l'importazione e l'esportazione dei dati, l'interfaccia della riga di comando è solo per Windows e nessuno di questi strumenti è una base consigliata per una strategia di integrazione dei dati. Utilizzarli invece per integrare la strategia di gestione e manutenzione dei dati.
I comandi dati Salesforce CLI possono essere utilizzati per manipolare i record nell'organizzazione. Sono disponibili comandi che consentono di importare ed esportare i dati con l'API in blocco e l'API di salvataggio ad albero SObject ed eseguire semplici operazioni CRUD su singoli record con l'API REST. Salesforce CLI da solo non è considerato uno strumento di integrazione dei dati indipendente.
OmniStudio Data Mapper può essere utilizzato come strumento ETL dichiarativo per spostare i dati tra oggetti Salesforce e strutture di dati JSON. Mentre viene creata automaticamente un'interfaccia REST per ogni interfaccia di Data Mapper, che fornisce un modo dichiarativo per spostare i dati dai sistemi esterni agli oggetti Salesforce, Data Mapper indipendente non è una base consigliata per una strategia di integrazione dei dati. Le azioni di Data Mapper sono disponibili nelle procedure di integrazione OmniStudio.
Dataloader.io è un altro strumento di caricamento dati per Salesforce basato su Anypoint Platform di MuleSoft che consente di importare, esportare ed eliminare in modo rapido e sicuro quantità illimitate di dati per la propria azienda. Dataloader.io non è una base consigliata per una strategia di integrazione dei dati.
Per le integrazioni in uscita da Salesforce, è possibile considerare diversi tipi di strumenti: low-code, pro-code o ibrido. Le sezioni seguenti offrono indicazioni per ciascuno di questi tipi di utensili e soluzioni di esempio.
- Strumenti low-code per le integrazioni in uscita
- Strumenti ibridi per le integrazioni in uscita
- Strumenti pro-codice per le integrazioni in uscita
| Guida | Licenze | Tempistica | Volume e scala | Consegna e manutenzione | Privacy e sicurezza | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Quando utilizzare | Licenza aggiuntiva | Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica) | Supporto multi-oggetto | LDV/Bulk | Test e distribuzione** | Debug | Comportamento di gestione/riprova degli errori incorporato | Può essere utilizzato con dati crittografati a riposo | Protocollo di autenticazione | |
| Modifica acquisizione dati | Quando è necessario pubblicare le modifiche a livello di record apportate in Salesforce in un sistema esterno e non è necessario un payload personalizzato. | Obbligatorio | Asincrono | No | No | Sì | Con strumenti pro-code | Sì | Sì | OAuth |
| Servizi esterni | Quando si orchestra un processo utilizzando Flusso, Apex, Bot Einstein o OmniStudio e le API del sistema esterno sono descritte utilizzando specifiche OpenAPI. | Non richiesto | Sincronizzazione | Sì | No | Sì | Con strumenti pro-code | No | N/D | Credenziali denominate |
| Heroku Connect | Quando si desidera estendere i dati con la sincronizzazione bidirezionale per abilitare le app mobili e di altro tipo in Heroku e si desidera che i dati vengano replicati anche in Salesforce. | Obbligatorio | Asincrono | Sì | Sì | No | Con strumenti pro code | Sì | Sì, tramite Shield Connect | OAuth |
| Procedura di integrazione OmniStudio | Quando è necessario trasformare i dati senza l'interazione dell'utente e migliorare le prestazioni elaborandoli sul server anziché sul browser. | Obbligatorio | Entrambi | Sì | Sì | Sì | Supporto dichiarativo | Sì | Sì | Credenziali denominate |
| Salesforce Connect/Oggetti esterni | Quando si desidera che i dati compaiano nell'interfaccia utente di Salesforce ma si desidera che i dati vengano memorizzati in un sistema esterno. I dati non vengono replicati in Salesforce. | Obbligatorio | Sincronizzazione | No | Sì* | Sì | Con strumenti pro-code e un tracciatore dichiarativo | No | N/D | Credenziali denominate |
| *Gli adattatori OData precedenti alla versione 4.01 sono soggetti a limiti di chiamata. Per ulteriori dettagli, vedere Considerazioni sui limiti di traffico delle chiamate OData. ** Test e distribuzione si riferiscono alla capacità di creare in un ambiente inferiore e distribuire tramite l'API dei metadati pacchetti o serie di modifiche all'ambiente di produzione. | ||||||||||
Quando le opportunità vengono conseguite, è necessario creare un ordine per i prodotti associati nel sistema ERP o nel sistema di gestione ordini della società.
Modifica acquisizione dati Man mano che i record Opportunità vengono aggiornati, Modifica acquisizione dati pubblica gli eventi di modifica che contengono gli aggiornamenti agli oggetti. Gli eventi di modifica vengono consumati sul lato del cliente tramite una connessione CometD (o tramite un connettore MuleSoft) e utilizzati per aggiornare il sistema ERP o di gestione ordini del cliente. Gli eventi di modifica possono essere arricchiti in modo da includere sempre ID record esterni o altri dati dell'oggetto (ad esempio la regione) necessari per l'integrazione. Gli stream degli eventi di modifica per più oggetti possono essere combinati in canali per semplificare l'abbonamento e l'elaborazione degli stream (in modo da potersi abbonare ed elaborare uno stream anziché molti).
Servizi esterni Se si dispone di un servizio Web che supporta la specifica OpenAPI 2.0 o 3.0, è possibile esporre le operazioni e i servizi come servizio esterno in Salesforce. Le operazioni API (ad esempio, l'ordine di creazione) possono essere chiamate come Azione invocabile in un flusso creato con Flow Builder quando la fase dell'opportunità viene modificata in "Conseguita".
Heroku Connect Heroku Connect viene in genere utilizzato per mantenere sincronizzati un database Heroku Postgres e Salesforce. Se il cliente utilizza Heroku Postgres come punto vendita transazionale di origine, è possibile sincronizzare i record e le modifiche da Salesforce a Heroku Postgres utilizzando Heroku Connect. Da qui, è possibile utilizzare i connettori streaming Heroku per pubblicare le modifiche in Apache Kafka e inviarle come eventi alle applicazioni a valle, incluso il sistema ERP o di gestione degli ordini.
Quando viene inviato un ordine, l'OmniScript che orchestra il processo può inviare i dettagli dell'ordine a un connettore ERP o MuleSoft.**** Il post può essere eseguito direttamente dall'OmniScript (lato client) o indirettamente tramite una procedura di integrazione (lato server). Se il sistema ERP genera un errore di convalida, l'interfaccia utente OmniScript deve informare l'utente e, se necessario, tradurre e contestualizzare l'errore per l'utente.
Salesforce Connect/Oggetti esterni È possibile creare un flusso attivato da record in Salesforce che inserisce un record negli oggetti esterni correlati quando la fase dell'opportunità viene modificata in "Conseguita". Poiché si tratta di una transazione mista, per evitare errori aggiungere un elemento di pausa per zero secondi tra l'aggiornamento opportunità e gli inserimenti di oggetti esterni correlati in modo da chiudere un contesto transazione prima di avviarne uno nuovo.
| Guida | Licenze | Tempistica | Volume e scala | Consegna e manutenzione | Privacy e sicurezza | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Quando utilizzare | Licenza aggiuntiva | Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica) | Supporto multi-oggetto | LDV/Bulk | Test e distribuzione** | Debug | Comportamento di gestione/riprova degli errori incorporato | Può essere utilizzato con dati crittografati a riposo | Protocollo di autenticazione | |
| Azioni Apex | Quando si desidera automatizzare le chiamate a un altro sistema tramite Flusso Salesforce. Uno sviluppatore può scrivere una classe Apex che un flusso può invocare oppure scaricare una soluzione predefinita da AppExchange. | Non richiesto | Entrambi | Sì | No | Sì | Con strumenti pro-code | No | Sì | Più |
| Relay evento | Quando è necessario inviare eventi piattaforma ed eventi di acquisizione dati di modifica ad Amazon EventBridge da Salesforce. I relay evento si connettono solo ad AWS Eventbridge | No | Asincrono | Sì | No | Sì | Sì | Sì | Sì | HTTP/1.1 con TLS |
| Messaggi in uscita | Quando è necessario inviare messaggi SOAP su HTTP(S) a un endpoint designato con ricezione garantita quando attivato da una regola di flusso di lavoro. | Non richiesto | Asincrono | No | No | Sì | Supporto dichiarativo | Sì | Sì | TLS bidirezionale |
| Eventi piattaforma | Quando è necessario un payload strutturato e definito su misura per le modifiche quasi in tempo reale in Salesforce o in un sistema esterno. | Non obbligatorio* | Asincrono | Sì | No | Sì | Con strumenti pro-code | Sì | Sì | OAuth |
| Salesforce Connect/Oggetti esterni (con adattatori Apex personalizzati) | Quando si desidera che i dati compaiano nell'interfaccia utente di Salesforce ma si desidera che vengano memorizzati in un sistema esterno che non può utilizzare protocolli standard come OData o GraphQL. | Obbligatorio | Entrambi | Sì | Sì | Sì | Con strumenti pro-code | No | N/D | Più |
| Data 360 | Quando si desidera armonizzare i dati di fonti diverse in un unico archivio dati o replicare i dati in altre organizzazioni Salesforce o in altri sistemi esterni. | Obbligatorio | Entrambi | Sì | Sì | Sì | Sì | Sì | Sì | Più |
*Componente aggiuntivo richiesto per i casi d'uso a volume elevato.
**Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'API dei metadati, pacchetti o serie di modifiche in produzione.
Quando le opportunità vengono conseguite, è necessario creare un ordine per i prodotti associati nel sistema ERP o di gestione degli ordini della società.
Azioni Apex Un flusso attivato da record in base allo stato dell'opportunità può essere attivato automaticamente quando un'opportunità viene conseguita. Il flusso esegue un'azione invocabile che utilizza una chiamata esterna per inviare l'ordine al sistema di gestione ordini o alla soluzione ERP. Gli invii a volume elevato e gli ordini multisito sono gestiti da meccanismi batch e di area di attesa Apex.
Messaggi in uscita Dopo aver impostato la messaggistica, è possibile definire una regola di flusso di lavoro attivata dall'aggiornamento dell'opportunità per inviare un messaggio SOAP su HTTP(S) a un URL endpoint specificato che ospita l'ascoltatore. Il messaggio conterrà i campi specificati al momento della creazione del messaggio in uscita. Se le informazioni nell'oggetto cambiano dopo che la notifica è stata inserita nell'area di attesa, ma prima di essere inviata, verranno consegnate solo le informazioni aggiornate e i messaggi rimarranno nell'area di attesa fino a quando non vengono inviati correttamente o fino a 24 ore prima. Dopo 24 ore, i messaggi vengono eliminati dall'area di attesa. Se il sistema ERP richiede dati aggiuntivi, è possibile passare sessionId nei messaggi in uscita in modo che il sistema esterno possa effettuare una richiesta di richiamata.
Eventi piattaforma È possibile definire un evento piattaforma che include il payload personalizzato con i dati necessari per creare i record nel sistema esterno. Poiché gli eventi piattaforma non vengono pubblicati automaticamente alla modifica del record, è necessario pubblicare l'evento tramite Apex, Flusso Salesforce o Process Builder quando la fase dell'opportunità viene modificata in "Conseguita". Un servizio esterno ascolta il canale degli eventi piattaforma utilizzando CometD (o un connettore MuleSoft) e crea i record appropriati nel sistema esterno.
Salesforce Connect/Oggetti esterni (con adattatori Apex personalizzati) Una soluzione basata su Salesforce Connect/Oggetti esterni non è perfettamente adatta a un caso d'uso che richiede semplicemente la sincronizzazione dei dati. Tuttavia, questa soluzione può essere applicata nei casi in cui gli utenti di Salesforce devono visualizzare e potenzialmente interagire con i dati del sistema esterno e i dati non possono essere replicati in Salesforce. Se il sistema ERP o di gestione degli ordini non supporta i protocolli OData o GraphQL, il team di sviluppo può utilizzare l'Apex Connector Framework per scrivere classi Apex che gestiscono la comunicazione con il sistema esterno tramite un protocollo supportato.
Data 360 Una soluzione basata su Data 360 è perfettamente adatta per i casi d'uso in cui è necessario armonizzare i dati provenienti da fonti diverse in un unico data store. Può essere utilizzato anche quando è necessario replicare i dati da un'organizzazione Salesforce a più organizzazioni Salesforce o ad altri sistemi esterni utilizzando Data 360 come hub di dati. Quando un'opportunità viene conseguita e aggiornata nell'organizzazione di origine, i dati dell'opportunità vengono sincronizzati con Data 360, dove possono essere replicati in altri sistemi, incluse le organizzazioni Salesforce, utilizzando meccanismi diversi come azioni, attivazioni e API. Analogamente, è possibile segnalare un'opportunità senza replicare i dati in altre organizzazioni Salesforce utilizzando Data Cloud One. Tuttavia, Data Cloud One non supporta le piattaforme non Salesforce.
| Guida | Licenze | Tempistica | Volume e scala | Consegna e manutenzione | Privacy e sicurezza | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Quando utilizzare | Licenza aggiuntiva | Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica) | Supporto multi-oggetto | LDV/Bulk | Test e distribuzione** | Debug | Comportamento di gestione/riprova degli errori incorporato | Può essere utilizzato con dati crittografati a riposo | Protocollo di autenticazione | |
| Apex personalizzato | Quando sono necessarie più funzionalità di quelle disponibili negli strumenti low-code. | Non richiesto | Entrambi | Sì | Sì | Sì | Con strumenti pro-code | No | Sì* | Più |
| Servizi esterni | L'integrazione da codice con le API di sistema esterne è descritta utilizzando le specifiche OpenAPI. | Non richiesto | Sincronizzazione | Sì | No | Sì | Con strumenti pro-code | No | N/D | Più |
| MuleSoft Anypoint | Quando è necessaria una singola soluzione unificata di livello aziendale per creare, orchestrare e gestire le integrazioni, quando è necessario sostituire un'architettura point-to-point legacy o quando è necessario il supporto per la gestione API. | Obbligatorio | Entrambi | Sì | Sì | Sì | Con strumenti pro-code | No | Sì* | Più |
*L'abilitazione di Shield Platform Encryption modifica alcuni comportamenti, vedere Considerazioni generali Shield Platform Encryption per ulteriori dettagli.
**Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'API dei metadati, pacchetti o serie di modifiche in produzione.
Quando le opportunità vengono conseguite, è necessario creare un ordine per i prodotti associati nel sistema ERP o di gestione degli ordini della società.
Apex personalizzato È possibile creare un trigger Apex e uno o più handler trigger nell'opportunità che effettua una chiamata al sistema ERP o di gestione degli ordini quando la fase dell'opportunità viene modificata in "Conseguita". Tenere presente che se si effettuano chiamate da un trigger o dopo aver eseguito un'operazione DML, è necessario utilizzare un metodo annotato come future o area di attesa. Una chiamata in un trigger mantiene aperta la connessione al database per l'intera durata della chiamata. Tutto l'Apex Code è vincolato dai limiti Apex Governor e API, che vengono rivisti su base continuativa.
Servizi esterni Se il sistema ERP esterno o il sistema di gestione ordini dell'azienda sono definiti tramite una specifica OpenAPI, le chiamate ai servizi eseguiti nel metodo futuro o nel processo di area di attesa potrebbero essere semplificate. I servizi esterni registrati possono essere chiamati direttamente da Apex senza necessità di scrivere codice boilerplate. Nell'esempio, la chiamata per creare l'ordine può essere gestita dal servizio esterno.
MuleSoft Anypoint MuleSoft Anypoint offre una gestione API di livello aziendale. MuleSoft Anypoint può creare API per abilitare l'accesso in lettura (e/o scrittura) ai dati per Salesforce e molti altri sistemi aziendali. Sono disponibili molti connettori predefiniti per semplificare l'implementazione e le aziende possono anche creare e pubblicare i propri connettori. Queste API possono essere distribuite in Anypoint con policy di sicurezza flessibili, che supportano la gestione e la governance centralizzate. Non esistono restrizioni sul volume delle transazioni, a condizione che l'API sia stata dimensionata correttamente per il picco di utilizzo (misurato in vCores).
Per le integrazioni in entrata in Salesforce, è possibile considerare diversi tipi di strumenti: low-code, pro-code o ibrido. Le sezioni seguenti offrono indicazioni per ciascuno di questi tipi di utensili e soluzioni di esempio.
- Strumenti low-code per le integrazioni in entrata
- Strumenti ibridi per le integrazioni in entrata
- Strumenti pro-codice per le integrazioni in entrata
| Guida | Licenze | Tempistica | Volume e scala | Consegna e manutenzione | Privacy e sicurezza | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Quando utilizzare | Licenza aggiuntiva | Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica) | Supporto multi-oggetto | LDV/Bulk | Test e distribuzione* | Debug | Comportamento di gestione/ritentativo degli errori incorporato | Può essere utilizzato con dati crittografati a riposo | Protocollo di autenticazione | |
| Heroku Connect | Quando si desidera estendere i dati con la sincronizzazione bidirezionale per abilitare le app mobili e di altro tipo in Heroku e si desidera che i dati vengano replicati anche in Salesforce. | Obbligatorio | Asincrono | Sì | Sì | No | Con strumenti pro-code | Sì | Sì, tramite Shield Connect | OAuth |
| Procedura di integrazione OmniStudio | Quando è necessario importare e trasformare dati da fonti di terze parti senza interazione dell'utente. | Obbligatorio | Entrambi | Sì | Sì | Sì | Supporto dichiarativo | No | Sì | Credenziali denominate |
| Salesforce Connect/Oggetti esterni | Quando si desidera che i dati compaiano nell'interfaccia utente di Salesforce ma si desidera che vengano memorizzati in un sistema esterno che può utilizzare protocolli standard come OData o GraphQL. | Obbligatorio | Sincronizzazione | Sì | Sì | Sì | Con strumenti pro-code | No | N/D | Più |
*Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'API dei metadati, pacchetti o serie di modifiche in produzione.
Un referente viene aggiornato nel sistema ERP dell'organizzazione. Queste informazioni di contatto devono essere aggiornate in Salesforce.
Heroku Connect Heroku Connect viene in genere utilizzato per mantenere sincronizzati un database Heroku Postgres e Salesforce. A meno che il sistema ERP non utilizzi Heroku Postgres come punto vendita delle transazioni, questo caso d'uso non è possibile. Se utilizza Heroku Postgres, le modifiche apportate nelle tabelle di Postgres possono essere sincronizzate con gli oggetti in Salesforce utilizzando Heroku Connect.
Procedura di integrazione Dopo che il sistema ERP ha aggiornato il record referente, è possibile chiamare una procedura di integrazione OmniStudio con un'azione di caricamento del data mapper e un'azione di risposta tramite l'API REST generata da Data mapper. Per prima cosa, un'azione Data Mapper Load invia un payload JSON o XML, che viene utilizzato per eseguire l'upset dei record referente in base a un campo ID esterno o tramite una chiave Inserisci con aggiornamento. Se una risposta semplice in JSON è tutto ciò che è previsto, un'azione di risposta può inviare tutte le informazioni pertinenti delle azioni precedenti per indicare l'esito positivo o negativo. Se il sistema ERP prevede una risposta specifica, è possibile utilizzare una trasformazione Data Mapper o un'azione Estrai per generare una risposta JSON o XML con funzioni aggiuntive per includere in modo dichiarativo i dati generati nei trigger dall'aggiornamento del record referente. La sfida principale di questo scenario è la concomitanza: Più chiamate per aggiornare simultaneamente lo stesso record referente causeranno problemi poiché l'API esiste direttamente in Salesforce.
Salesforce Connect / Oggetti esterni Salesforce Connect e gli oggetti esterni non sono consigliati per questo caso d'uso, poiché lo scenario richiede specificamente la replica dei dati in Salesforce. Se si dispone di un'integrazione Salesforce Connect preesistente integrata nell'ERP, è possibile configurare il connettore OData 4.0 per supportare acquisizione dati di modifica esterni se l'ERP può supportare acquisizione dati di modifica. Inoltre, è necessario configurare in Salesforce l'abbonamento allo stream di modifiche dall'ERP, utilizzando l'API Pub/Sub.
| Guida | Licenze | Tempistica | Volume e scala | Consegna e manutenzione | Privacy e sicurezza | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Quando utilizzare | Licenza aggiuntiva | Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica) | Supporto multi-oggetto | LDV/Bulk | Test e distribuzione** | Debug | Comportamento di gestione/ritentativo degli errori incorporato | Può essere utilizzato con dati crittografati a riposo | Protocollo di autenticazione | |
| Eventi piattaforma | Quando è necessario un payload strutturato e definito su misura per le modifiche quasi in tempo reale in Salesforce o in un sistema esterno. | Non obbligatorio* | Asincrono | Sì | No | Sì | Con strumenti pro-code | Sì | Sì | OAuth |
| Salesforce Connect/Oggetti esterni (con adattatori Apex personalizzati) | Quando è necessario che i dati compaiano nell'interfaccia utente di Salesforce ma si desidera archiviarli in un sistema esterno che non può utilizzare i protocolli OData 2.0/4.0. | Obbligatorio | Entrambi | Sì | Sì | Sì | Con strumenti pro-code | No | N/D | Più |
| Data 360 | Quando si desidera armonizzare i dati di fonti diverse in un unico archivio dati o replicare i dati di altre organizzazioni Salesforce o di altri sistemi esterni. Data 360 supporta anche la virtualizzazione per alcune piattaforme. | Obbligatorio | Entrambi | Sì | Sì | Sì | No | Sì | Sì | Più |
*Componente aggiuntivo richiesto per i casi d'uso a volume elevato.
**Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'API dei metadati, pacchetti o serie di modifiche in produzione.
Un referente viene aggiornato nel sistema ERP dell'organizzazione. Queste informazioni di contatto devono essere aggiornate in Salesforce.
Il codice personalizzato in un sistema esterno pubblica un Evento piattaforma quando il record referente viene aggiornato nell'ERP.**** Un trigger, un processo o un flusso in Salesforce può abbonarsi all'evento piattaforma e aggiornare gli oggetti Salesforce corrispondenti quando un evento viene elaborato. L'Evento piattaforma può funzionare semplicemente come segnale che si è verificata una modifica nel sistema ERP del cliente senza contenere alcun dato oppure può contenere i dati effettivi necessari per aggiornare l'oggetto Salesforce.
Salesforce Connect/Oggetti esterni (con adattatori Apex personalizzati) Questa soluzione non è applicabile in un caso d'uso che richiede la replica dei dati. Questa soluzione è applicabile se gli utenti di Salesforce devono visualizzare le informazioni di un sistema esterno che non deve o non può essere replicato in Salesforce e il sistema esterno non può supportare protocolli standard come OData o GraphQL. Vedere Caso d'uso: Integrazione in uscita mediante strumenti ibridi per un caso d'uso di esempio per un adattatore personalizzato Apex.
Data 360 Quando un referente viene aggiornato in sistemi esterni come ERP, gli aggiornamenti del referente possono essere sincronizzati con Data 360 utilizzando connettori pronti all'uso o utilizzando API e strumenti pro-code come MuleSoft. È anche possibile fare riferimento al referente in Data 360 utilizzando il meccanismo copia zero (disponibile con alcune piattaforme). Una volta che i dati sono disponibili in Data 360, è possibile utilizzare diversi meccanismi di integrazione pronti all'uso per sincronizzare i dati con altre organizzazioni Salesforce. È possibile accedere ai dati per riferimento utilizzando Data Cloud One. I dati possono essere replicati anche utilizzando attivazioni e altre API utilizzando connettori pronti all'uso o con l'aiuto di strumenti pro-code come MuleSoft Anypoint Platform.
| Guida | Licenze | Tempistica | Volume e scala | Consegna e manutenzione | Privacy e sicurezza | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Quando utilizzare | Licenza aggiuntiva | Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica) | Supporto multi-oggetto | LDV/Bulk | Test e distribuzione**** | Debug | Comportamento di gestione/ritentativo degli errori incorporato | Può essere utilizzato con dati crittografati a riposo | Protocollo di autenticazione | |
| Servizi Web Apex REST & SOAP personalizzati | Quando sono necessarie più funzionalità di quelle fornite dagli endpoint API nativi, ad esempio l'elaborazione oggetti incrociata o un'altra logica complessa. | Non richiesto | Entrambi | Sì | Sì | Sì | Con strumenti pro-code | No | Sì*** | Più |
| MuleSoft Anypoint | Quando è necessaria una singola soluzione unificata di livello aziendale per creare, orchestrare e gestire le integrazioni, quando è necessario sostituire un'architettura point-to-point legacy o quando è necessario il supporto per la gestione API. | Obbligatorio | Entrambi | Sì | Sì | Sì | Con strumenti pro-code | No | Sì*** | Più |
| API native Salesforce | Quando si necessita di un maggiore controllo o si dispone di competenze professionali per creare integrazioni tramite API REST, API SOAP, API in blocco o API GraphQL o gRPC. | Non obbligatorio* | Entrambi | Sì***** | Sì | Sì | Con strumenti pro-code | Sì** | Sì*** | Più |
*Si applicano i limiti e le allocazioni delle richieste API.
**Le API in blocco hanno aspetti del comportamento di un nuovo tentativo e un certo numero di API offrono protezione dal ritiro tramite l'impostazione allOrNone (ad esempio, vedere parametri allOrNone in richieste composite e raccolte)
***L'abilitazione di Shield Platform Encryption modifica alcuni comportamenti, vedere Considerazioni generali Shield Platform Encryption per ulteriori dettagli.
****Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'API dei metadati, pacchetti o serie di modifiche in produzione.
*****Le API composite hanno il supporto multi-oggetto.
Un referente viene aggiornato nel sistema ERP dell'organizzazione. Queste informazioni di contatto devono essere aggiornate in Salesforce.
Servizi Web Apex e REST personalizzati È possibile creare un servizio Web utilizzando Apex Code che potrebbe eseguire operazioni CRUD (creazione, lettura, aggiornamento, eliminazione) sull'oggetto Referente. Questo servizio verrà richiamato tramite SOAP o REST dal sistema esterno (ERP).
MuleSoft Anypoint L'intento di MuleSoft Anypoint è fornire una gestione API di livello aziendale. MuleSoft Anypoint offre un ampio set di connettori che è possibile utilizzare per l'integrazione con molti sistemi ERP tra cui SAP, Oracle EBS, Oracle ERP e NetSuite. È possibile creare un flusso per ascoltare gli eventi in questi sistemi ERP (in questo caso, quando viene creato un nuovo referente). Quando il flusso viene avviato, utilizza il connettore Salesforce per creare un nuovo record Referente (o aggiornarne uno se il referente esiste già). Inoltre, è possibile integrarsi con altri sistemi, se la transazione di replica prevede la sindacazione del referente in altri sistemi. Se necessario, è possibile utilizzare il linguaggio di mappatura e trasformazione (DataWeave) per eseguire logica e calcoli complessi mentre le informazioni fluiscono in più sistemi diversi. L'autenticazione per questi sistemi può essere eseguita tramite molti meccanismi di autenticazione diversi, ad esempio l'autenticazione di base e OAuth. Non esistono restrizioni sul volume delle transazioni a condizione che il flusso sia stato dimensionato correttamente per il picco di utilizzo (misurato in vCores).
API native Salesforce Al termine (o immediatamente dopo) della transazione di aggiornamento nel sistema ERP, è possibile eseguire un'operazione di inserimento con aggiornamento sull'oggetto Referente tramite l'API SOAP o eseguire una PATCH sull'API REST sObjects Contact nell'organizzazione Salesforce.
Il prodotto Salesforce a Salesforce è giunto al termine del suo ciclo di vita. Salesforce a Salesforce ha semplificato la vendita e l'assistenza ai clienti comuni da parte dei partner che lavorano insieme, ma Salesforce investirà per portare maggiore innovazione ad altri strumenti. In futuro, per la condivisione dei dati tra le organizzazioni Salesforce si consigliano i seguenti approcci.
| Guida | Costo | Tempistica | Volume e scala | Consegna e manutenzione | Privacy e sicurezza | Strumenti da implementare | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Quando utilizzare | Licenza aggiuntiva | Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica) | Supporto multi-oggetto | LDV/Bulk | Test e distribuzione* | Debug | Comportamento di gestione/riprova degli errori incorporato | Può essere utilizzato con dati crittografati a riposo | Protocollo di autenticazione | Codice basso → Pro Code | |
| Heroku Connect | Quando si desidera estendere i dati con la sincronizzazione bidirezionale tra le organizzazioni Salesforce e abilitare l'accesso ai dati anche da dispositivi mobili e altre app in esecuzione su Heroku | Obbligatorio | Asincrono | Sì | Sì | No | Con strumenti pro-code | Sì | Sì, tramite Shield Connect | OAuth | Codice basso |
| MuleSoft Anypoint | Quando si necessita di una singola soluzione unificata di livello aziendale per creare, orchestrare e gestire le integrazioni, quando si deve sostituire un'architettura point-to-point legacy o quando si necessita del supporto per la gestione API | Obbligatorio | Entrambi | Sì | Sì | Sì | Con strumenti pro-code | No | Sì** | Più | Codice professionale |
| API native Salesforce | Quando Salesforce o Heroku Connect non sono un'opzione o è necessaria un'elaborazione più complessa | Non richiesto | Entrambi | No | Sì | Sì | Con strumenti pro-code | No | Sì** | Più | Codice professionale |
| Modifica acquisizione dati | Quando è necessario pubblicare le modifiche a livello di record apportate in Salesforce in un sistema esterno e non è necessario un payload personalizzato. | Obbligatorio | Asincrono | No | No | Sì | Con strumenti pro-code | Sì | Sì | OAuth | |
| Salesforce Connect con adattatore tra organizzazioni | Quando si desidera che gli utenti di un'organizzazione visualizzino o modifichino i record di un'organizzazione diversa senza replica dei dati | Obbligatorio | Asincrono | Sì | Sì | Sì | Con strumenti pro-code | N/D | N/D | Più | Codice basso |
| Data 360 | Quando si desidera che gli utenti di un'organizzazione visualizzino o modifichino i record di un'organizzazione diversa con dati replicati in Data 360. | Obbligatorio | Entrambi | Sì | Sì | Sì | Con strumenti pro-code | Sì | Sì | Più | Ibrido |
*Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'API dei metadati, pacchetti o serie di modifiche all'ambiente di produzione
**L'abilitazione di Shield Platform Encryption modifica alcuni comportamenti, vedere Considerazioni generali Shield Platform Encryption per ulteriori dettagli.
Gli eventi piattaforma non sono ottimali per integrare i dati da un'organizzazione Salesforce a un'altra, poiché non possono "ascoltare" tra le organizzazioni per lo stesso evento. Anche l'Apex personalizzato non è un approccio consigliato per questo tipo di integrazione.
Una grande azienda opera in più unità operative (BU). Ogni unità operativa ha la propria organizzazione Salesforce. Un singolo cliente tratta con più unità operative dell'azienda e dispone quindi dei dati di account e opportunità in più organizzazioni. L'azienda deve accedere a una visualizzazione aggregata di tutti i dati di account e opportunità in tutte le unità operative in un'unica organizzazione.
Nota: Tutte le soluzioni seguenti sono progettate per la minima quantità di replica dei dati, in conformità con Takeaway #1.
I dati di account e opportunità di Data 360 provenienti da organizzazioni Salesforce diverse possono essere inseriti in Data 360 utilizzando connettori Salesforce pronti all'uso. Possono anche essere aggregati e armonizzati (se necessario). Una volta aggregati in Data 360, i dati sono accessibili in altre organizzazioni Salesforce utilizzando Data Cloud One senza replica dei dati.
Heroku Connect Per le singole organizzazioni di ogni unità operativa, è possibile utilizzare Heroku Connect per sincronizzare le modifiche da Salesforce in un unico database Heroku Postgres. In questo scenario, la sincronizzazione bidirezionale non è abilitata, ma solo da Salesforce a Postgres. Quindi, in Heroku Connect, è possibile abilitare il provider OData e selezionare le tabelle da esporre come oggetti esterni nell'organizzazione Salesforce in cui si desidera una visualizzazione aggregata. Dall'interno di Salesforce, si definisce una fonte di dati esterna che punta al provider OData in Heroku.
MuleSoft Anypoint MuleSoft Anypoint offre una gestione API di livello aziendale. Un'API MuleSoft Anypoint può essere configurata in modo che legga le informazioni di più organizzazioni Salesforce correlate utilizzando il connettore Salesforce con più connessioni alle organizzazioni. Il flusso MuleSoft può eseguire query nelle diverse organizzazioni Salesforce e restituire una struttura specifica che viene ottimizzata o arricchita con altre informazioni di terze parti, se necessario. Quando viene richiamata, l'API eseguirà tutte le chiamate appropriate all'organizzazione Salesforce (in questo esempio interrogando le informazioni su account e opportunità) in modo che i dati possano essere elaborati dal consumatore (probabilmente un'interfaccia utente). L'autenticazione per questi sistemi può essere eseguita tramite vari meccanismi di autenticazione, tra cui l'autenticazione di base e OAuth. Non esistono restrizioni sul volume delle transazioni, a condizione che il flusso sia stato dimensionato correttamente per il picco di utilizzo (misurato in vCores o Core).
Le operazioni di query delle API Salesforce native possono essere inviate a ciascuna delle organizzazioni di interesse, in particolare tramite l'API in blocco Salesforce 2.0, che è adatta per estrarre in modo efficiente migliaia di record. È possibile recuperare i risultati delle query da ogni singola organizzazione e aggregarli con un'applicazione personalizzata o un middleware in base alle esigenze del cliente.
Salesforce Connect con adattatore tra organizzazioni L'adattatore tra organizzazioni Salesforce Connect non è adatto a questo scenario, poiché gli account o le opportunità di organizzazioni remote appariranno tutti nell'organizzazione centrale come oggetti diversi. Ad esempio, non è possibile sommare un totale complessivo per gli importi di tutte le opportunità in tutte le organizzazioni.
Scenario tra organizzazioni con aggiornamenti selettivi: Un agente di vendita che utilizza l'organizzazione Salesforce A deve visualizzare e aggiornare i dati del caso dell'organizzazione Salesforce B e aggiungere commenti al caso controllante nell'organizzazione Salesforce B mentre lavora nell'organizzazione A. I dati non devono essere replicati nell'organizzazione A.
Heroku Connect È possibile utilizzare lo stesso approccio descritto nello scenario di aggregazione dati precedente. Tuttavia, è necessario abilitare CRUD sull'oggetto esterno tramite il connettore OData e scrivere nuovamente le modifiche in Heroku Postgres.
MuleSoft Anypoint MuleSoft Anypoint offre una gestione API di livello aziendale. È possibile utilizzare lo stesso approccio descritto nello scenario di aggregazione dati precedente.
Le API Salesforce native utilizzano le credenziali denominate e invocano le API Salesforce native per leggere e aggiornare i dati nell'organizzazione Salesforce correlata. Un componente deve essere progettato per visualizzare i dati.
Salesforce Connect con adattatore tra organizzazioni La possibilità di visualizzare i dati in un oggetto esterno (nonché di modificarli se per l'oggetto esterno è abilitato il CRUD) è supportata tramite l'adattatore tra organizzazioni Salesforce. Le relazioni sono supportate anche tra gli oggetti esterni in modo da potersi collegare al caso controllante nell'oggetto esterno. Tuttavia, la creazione di relazioni è oggi un processo manuale in cui si converte un tipo di dati esistente in un tipo di dati di relazione. Inoltre, le ottimizzazioni apportate in Service Cloud per lavorare con i casi in modo più efficace non vengono trasferite all'organizzazione remota. Salesforce consiglia vivamente di testare l'adattatore tra organizzazioni e di valutare i compromessi nell'utilizzo degli oggetti esterni rispetto agli oggetti standard per il proprio caso d'uso.
Sincronizzazione dei dati tra organizzazioni: Quando un account di un cliente viene aggiornato in una delle unità operative dell'organizzazione Salesforce, è necessario aggiornare gli altri oggetti Account dell'organizzazione Salesforce per mantenere coerenti le informazioni sull'account.
Data 360 Data 360 può essere utilizzato per la replica dei dati da un'organizzazione a un'altra organizzazione Salesforce. I dati degli account di un'organizzazione Salesforce possono essere inseriti in Data 360 utilizzando connettori Salesforce pronti all'uso. È anche possibile utilizzare meccanismi di attivazione dei dati come l'attivazione batch, le azioni dati quasi in tempo reale o le attivazioni basate su API per spostare i dati da Data 360 all'organizzazione Salesforce.
Heroku Connect È possibile utilizzare lo stesso approccio descritto nello scenario di aggregazione dati precedente. Tuttavia, è necessario abilitare la sincronizzazione bidirezionale e non è più necessario abilitare Salesforce Connect poiché la sincronizzazione bidirezionale manterrà aggiornate tutte le organizzazioni quando vengono apportate modifiche alla tabella di Postgres.
MuleSoft Anypoint MuleSoft Anypoint offre una gestione API di livello aziendale. È possibile configurare un'applicazione Mule con Flow Designer in MuleSoft Anypoint per l'ascolto di eventi di oggetti standard e personalizzati per avviare un flusso AutoLaunched in Salesforce. Quando l'applicazione Mule viene attivata, può invocare il connettore Anypoint per Salesforce per comunicare con un numero qualsiasi di organizzazioni Salesforce. In questo caso d'uso, quando un record Account viene aggiornato in un'organizzazione Salesforce, l'app Mule può aggiornare i record Account nelle organizzazioni Salesforce correlate. Ogni organizzazione Salesforce correlata avrebbe una fase di aggiornamento univoca integrata nel flusso di applicazione generale in MuleSoft. L'autenticazione per questi sistemi può essere eseguita tramite vari meccanismi di autenticazione, tra cui l'autenticazione di base e OAuth. Non esistono restrizioni sul volume delle transazioni a condizione che il flusso sia stato dimensionato correttamente per il picco di utilizzo (misurato in vCores o Core).
API native Salesforce L'API replica (operazioni getUpdated, getDeleted) potrebbe essere utilizzata per sincronizzare i dati tra le organizzazioni, ma questo approccio non è consigliabile.
Salesforce Connect con adattatore tra organizzazioni È possibile utilizzare flussi attivati da record e oggetti esterni per mantenere sincronizzati alcuni dati tra le organizzazioni Salesforce. Ad esempio, l'aggiornamento di un record account nell'organizzazione A attiva un flusso che aggiorna il record corrispondente nell'oggetto esterno Account, che scrive tali aggiornamenti nel record account nell'organizzazione B. Ciò richiede l'uso corretto della semantica del flusso per evitare transazioni DML miste. Tenere inoltre presente che le regole di convalida e i flussi nell'organizzazione B verranno attivati allo stesso modo delle modifiche apportate dalle API REST/SOAP.
Tenere presente questa guida e farvi riferimento quando si pianifica una nuova integrazione dei dati con Salesforce. È sempre consigliabile comprendere l'intera gamma di opzioni disponibili e il modo in cui possono adattarsi al proprio caso d'uso specifico.
Aiutaci a pubblicare ciò che è più rilevante per te. Rispondere al sondaggio per fornire un feedback su questo contenuto e dirci cosa si desidera vedere dopo.