# architect Guide alle decisioni (decision-guides) - Full Documentation

<!-- document id=ddadd71836b922a67d0479f07d4c3a5f3693fc3a774d86e380b82cdbcfcec3c1 url=/architect/current/it-it/decision-guides/guides/event-driven.md -->

# Utilizzo degli strumenti e degli schemi giusti per le architetture basate sugli eventi

Le architetture basate sugli eventi supportano la produzione e il consumo efficienti degli eventi, che comunicano le modifiche dello stato del sistema o dell'applicazione. Queste architetture consentono connessioni flessibili tra i sistemi e supportano processi e aggiornamenti quasi in tempo reale che funzionano tra i sistemi. Benché i vantaggi delle architetture basate sugli eventi siano facili da vedere, i dettagli dell'implementazione non sono sempre altrettanto chiari. Quali funzionalità è necessario considerare negli schemi architettonici basati sugli eventi? Quali problemi specifici risolvono questi schemi? Quali considerazioni speciali valgono per le soluzioni e quali sono gli schemi ottimali per affrontarle?

## Panoramica della guida

Questa guida presenta gli schemi utilizzati per creare architetture basate sugli eventi ottimali quando si utilizzano le tecnologie Salesforce. Vengono inoltre discussi gli strumenti per gli eventi disponibili in Salesforce e vengono forniti consigli sugli strumenti per una selezione di casi d'uso. Per informazioni sulle integrazioni a livello di dati che coinvolgono Salesforce, vedere la nostra [Guida alle decisioni](/docs/architect/it-it/decision-guides/guide/data-integration).

## Takeaway

- **Utilizzare architetture basate sugli eventi per i processi che non richiedono risposte sincrone alle richieste.** Gli schemi descritti in questa guida sono progettati per la coerenza, la scalabilità e il riutilizzo dei dati, che consentono di ridurre al minimo l'indebitamento tecnico man mano che il panorama applicativo dell'organizzazione si evolve. (Per ulteriori informazioni, vedere [Ben progettato - Affidabilità](/docs/architect/it-it/well-architected/guide/reliability.html)).

- **Se MuleSoft o un'altra soluzione Enterprise Service Bus (ESB) fa parte del panorama esistente, utilizzarla dove possibile.** Queste soluzioni sono progettate appositamente per supportare schemi di architettura basati sugli eventi e dispongono di potenti funzionalità che consentono di riutilizzare le integrazioni in tutta l'azienda.

- **Utilizzare l'API Pub/Sub per qualsiasi schema di pubblicazione/abbonamento futuro anziché creare i propri handler eventi utilizzando altre API, inclusa Streaming API.** Ora che l'API Pub/Sub è disponibile in generale, utilizzarla per eventuali nuovi schemi di pubblicazione/abbonamento. Pianificare la migrazione delle comunicazioni degli eventi esistenti utilizzando altre API piattaforma, ad esempio Streaming API o servizi Apex personalizzati, all'API Pub/Sub quando possibile.

- **Eventi piattaforma e Acquisizione dati di modifica (CDC) sono i meccanismi preferiti per pubblicare le modifiche di record e campi che devono essere consumate da altri sistemi.** Non è consigliabile utilizzare PushTopic ed eventi generici per le nuove implementazioni. Salesforce continuerà a supportare PushTopic ed eventi generici nell'ambito delle funzionalità correnti, ma non prevede di effettuare ulteriori investimenti in questa tecnologia.

## Prodotti nell'ambito

<table style="border:none;width:100%">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Platform</a> è una piattaforma completa basata sull'intelligenza artificiale che unifica dipendenti, agenti autonomi dell'intelligenza artificiale, dati aziendali e applicazioni in un unico sistema affidabile per migliorare la produttività e l'esperienza dei clienti. Consente la creazione di un'"azienda autentica" collegando le app Customer 360, Data Cloud e Slack per l'automazione end-to-end.</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: MuleSoft logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/mulesoft-new.png" alt="MuleSoft"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/mulesoft/">MuleSoft</a> è la piattaforma di integrazione leader di Salesforce che consente alle organizzazioni di connettere applicazioni, dati e dispositivi in ambienti locali e cloud. MuleSoft è una piattaforma che offre all'IT le piattaforme per sbloccare i dati tra i sistemi, sviluppare framework di integrazione e automazione scalabili e creare esperienze connesse e differenziate in modo rapido.</td>
    </tr>
  </tbody>
</table>

## Punti decisione

Le architetture basate sugli eventi (EDA) sono consigliate per gli scenari che richiedono notifiche quasi in tempo reale, la distribuzione del carico di elaborazione per messaggi a volume elevato o complessi e l'integrazione di sistemi come IoT e dispositivi mobili che richiedono la resilienza della connettività tramite l'area di attesa. Tuttavia, le AED non dovrebbero essere implementate per i processi che richiedono risposte umane immediate e sincrone, poiché sono progettate per l'esecuzione asincrona. Né sono adatti se i dati di origine cambiano così raramente che uno schema più semplice come l'elaborazione batch sarebbe sufficiente.

### Quando utilizzare un'architettura basata sugli eventi

Di seguito sono riportati alcuni scenari comuni che spesso sono adatti a un'architettura basata sugli eventi:

<table style="width:100%">
<thead>
<tr><th scope="col">Punto Decisione</th><th scope="col">Guida</th></tr>
</thead>
<tbody>
<tr><td><strong>Notifiche quasi in tempo reale</strong></td><td>Gli schemi di architettura basati sugli eventi come pubblicazione/abbonamento, fanout e streaming tendono a funzionare bene negli scenari in cui più applicazioni devono essere informate delle modifiche dello stato o degli aggiornamenti dei record quasi in tempo reale.</td></tr>
<tr><td><strong>Elaborazione parallela</strong></td><td>Schemi come pubblicazione/abbonamento tendono a funzionare bene negli scenari in cui volumi elevati di dati o messaggi molto complessi richiedono la distribuzione del carico di elaborazione tra più sistemi.</td></tr>
<tr><td><strong>Letture a volume elevato</strong></td><td>Gli schemi Messaggi passati e Area di attesa sono comunemente utilizzati negli scenari in cui le organizzazioni subiscono picchi e il volume dei messaggi prodotti può superare la capacità degli abbonati di elaborarli immediatamente.</td></tr>
<tr><td><strong>Scritture a volume elevato</strong></td><td>Gli schemi Streaming e Area di attesa funzionano bene in molti scenari in cui le organizzazioni sperimentano un aumento del numero di messaggi prodotti.</td></tr>
<tr><td><strong>Invio degli stessi dati a sistemi diversi</strong></td><td>Benché la pubblicazione/abbonamento sia una soluzione piuttosto comune per le organizzazioni che necessitano di inviare gli stessi dati a più sistemi, può essere affrontata dalla maggior parte degli schemi descritti qui. Assicurarsi di esaminarli in dettaglio per trovare la misura migliore.</td></tr>
<tr><td><strong>Introduzione frequente di nuovi sistemi o dispositivi</strong></td><td>Gli schemi di pubblicazione/abbonamento, streaming e inserimento in area di attesa tendono a funzionare bene per gli scenari in cui il panorama generale tende a essere in movimento, con nuovi sistemi e dispositivi aggiunti regolarmente. In questo scenario, un nuovo sistema o dispositivo deve semplicemente diventare abbonato al bus degli eventi o associato a un'area di attesa per iniziare a ricevere messaggi anziché richiedere un'integrazione point-to-point personalizzata.</td></tr>
<tr><td><strong>Dispositivi IoT</strong></td><td>Poiché i dispositivi IoT in genere forniscono aggiornamenti frequenti e possono anche generare un'impennata di messaggi in alcuni scenari, gli schemi Streaming e Area di attesa tendono a funzionare bene quando li integrano in un panorama IT.</td></tr>
<tr><td><strong>Dispositivi e sistemi mobili offline</strong></td><td>I dispositivi mobili che devono lavorare in aree con accesso a Internet di bassa qualità o inesistente o sistemi che potrebbero essere offline al momento della consegna dei messaggi beneficeranno dello schema di inserimento in area di attesa, che consente loro di connettersi alle aree di attesa e recuperare tutti i messaggi pertinenti una volta che sono di nuovo online.</td></tr>
</tbody>
</table>

La maggior parte delle organizzazioni di grandi dimensioni dispone di ambienti IT complessi con una combinazione di sistemi con funzionalità diverse. È possibile, o forse probabile, che l'organizzazione disponga di sistemi legacy che non supportano le integrazioni basate sugli eventi. Si potrebbero anche avere casi d'uso in cui le integrazioni basate sugli eventi non hanno senso, anche se i sistemi le supporteranno (ad esempio, i trasferimenti di file SFTP da terze parti). Se si fa un passo indietro e si esamina il panorama IT dell'organizzazione nel suo complesso, è probabile che, proprio come con altre soluzioni architettoniche, si utilizzi una combinazione di schemi per supportare scenari diversi. Quando si decide di utilizzare l'approccio alle integrazioni basato sugli eventi come approccio preferito, considerarlo come un altro strumento nella propria casella degli strumenti. Può e deve essere utilizzato negli scenari giusti, ma non è un approccio da imporre a tutti i sistemi. Sviluppare una strategia di integrazione completa aiuterà a determinare quando gli schemi descritti in questa guida possono essere appropriati o meno.

### Quando non utilizzare un'architettura basata sugli eventi

Molti scenari richiedono architetture basate sugli eventi e, in alcuni scenari, le architetture basate sugli eventi funzionano anche se non sono particolarmente adatte. Tuttavia, in alcuni scenari, le architetture basate sugli eventi semplicemente non dovrebbero essere utilizzate. Di seguito sono riportate alcune domande sui punti decisionali che consentono di identificare questi scenari:

<table style="width:100%">
<thead>
<tr><th scope="col">Punto Decisione</th><th scope="col">Guida/Domande da porre</th></tr>
</thead>
<tbody>
<tr><td><strong>Requisiti aziendali</strong></td><td>Esiste una reale esigenza aziendale per una delle funzionalità descritte nella sezione [Quando utilizzare un'architettura basata sugli eventi] (#when-to-use-an-event-driven-architecture)?</td></tr>
<tr><td><strong>Requisiti tecnici</strong></td><td>L'integrazione che si sta progettando è adatta a uno schema diverso, ad esempio virtualizzazione dei dati, batch o richiesta/risposta? In altre parole, stai cercando di inserire un piolo quadrato in un foro rotondo?</td></tr>
<tr><td><strong>Processi che richiedono agli esseri umani di attendere le risposte</strong></td><td>Qualsiasi integrazione che prevede un essere umano in attesa di una risposta dal sistema di destinazione non è adatta alle architetture basate sugli eventi, poiché sono progettate per l'esecuzione asincrona e non possono garantire un tempo di risposta. Prima di implementare le soluzioni tecniche, valutare se processi di questo tipo sono ottimali per la propria organizzazione. Vedere [Well-Architected - Operational Excellence](/docs/architect/it-it/well-architected/guide/operational-excellence.html) per ulteriori informazioni.</td></tr>
<tr><td><strong>Modificare raramente i dati di origine</strong></td><td>Se i dati nel sistema di origine cambiano così di rado che gli aggiornamenti periodici sono sufficienti, è probabile semplificare l'architettura utilizzando [batch pattern] (https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) anziché schemi basati sugli eventi.</td></tr>
<tr><td><strong>Requisiti di implementazione</strong></td><td>La maggior parte dei sistemi coinvolti nella soluzione supporta architetture basate sugli eventi? Che cosa sarebbe necessario per utilizzare architetture basate sugli eventi con i sistemi che non le supportano (ad esempio, aggiornamenti, personalizzazioni o middleware)? Quale livello di impegno sarebbe necessario per soddisfare tali requisiti?</td></tr>
<tr><td><strong>Stabilità della struttura del messaggio</strong></td><td>Con che frequenza sarà necessario modificare le strutture dei messaggi? Quali sistemi saranno interessati da tale modifica e quale sarà il processo di risanamento?</td></tr>
<tr><td><strong>Governance organizzativa</strong></td><td>Esiste una struttura di governance per garantire che tutti gli stakeholder siano informati e in grado di intervenire sulle modifiche alle strutture dei messaggi, ai trigger e ad altre decisioni relative all'architettura e ai processi?</td></tr>
<tr><td><strong>Insiemi di competenze richiesti</strong></td><td>Il personale ha esperienza con le architetture basate sugli eventi e sa come supportarle?</td></tr>
</tbody>
</table>

## Casi d'uso

Esistono diversi schemi di architettura basati sugli eventi. Alcuni sono schemi di uso generale che possono essere applicati in casi d'uso che non hanno requisiti speciali oltre a essere basati sugli eventi; ad esempio, vedere [Ben progettato - Affidabilità](/docs/architect/it-it/well-architected/guide/reliability.html). Altri schemi sono applicabili ai casi d'uso specifici descritti qui, ad esempio integrazioni che comportano volumi elevati di dati o scenari che richiedono una conservazione dei messaggi più lunga.

### Schemi a colpo d'occhio

La tabella seguente confronta gli attributi degli schemi descritti in questo documento. Utilizzarlo come riferimento rapido quando è necessario identificare potenziali schemi per un determinato caso d'uso.

<table style="width:100%">
<thead>
<tr><th scope="col">Schema</th><th scope="col">Quasi in tempo reale</th><th scope="col">Copia messaggio univoco</th><th scope="col">Consegna garantita</th><th scope="col">Ridurre le dimensioni dei messaggi</th><th scope="col">Trasforma dati</th></tr>
</thead>
<tbody>
<tr><td>Pubblica / Abbonati</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Fanout</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Messaggi passati</td><td>✓</td><td></td><td>✓</td><td>✓</td><td>✓</td></tr>
<tr><td>Streaming</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Area di attesa</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
</tbody>
</table>

### Strumenti per l'architettura basata sugli eventi

Salesforce offre diversi strumenti per gestire i casi d'uso basati sugli eventi. Questa tabella contiene una panoramica generale degli strumenti disponibili.

<table style="width:100%">
<thead>
<tr><th scope="col"></th><th scope="col">Strumento</th><th scope="col">Descrizione</th><th scope="col">Competenze richieste</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>Piattaforma che consente l'integrazione dei dati utilizzando livelli di API.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connettore Salesforce Pub/Sub</a></td><td>Connettore per l'API Pub/Sub, che offre un'unica interfaccia per la pubblicazione e l'abbonamento a eventi piattaforma, eventi di monitoraggio evento in tempo reale ed eventi di acquisizione dati di modifica.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">Connettore JMS MuleSoft Anypoint</a></td><td>Connettore che consente di inviare e ricevere messaggi ad aree di attesa e argomenti per qualsiasi servizio di messaggistica che implementa la specifica JMS (Java Message Service).</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Connettore per spostare i dati tra Apache Kafka e applicazioni e servizi aziendali.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Connettore MuleSoft Anypoint Solace</a></td><td>Un connettore per i broker di eventi Solace PubSub+ con integrazione API nativa utilizzando JCSMP Java SDK</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">Connettore MuleSoft Anypoint MQ</a></td><td>Un servizio di messaggistica cloud multi-tenant che consente ai clienti di eseguire messaggi asincroni avanzati tra le loro applicazioni.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Connettore MuleSoft Anypoint MQTT</a></td><td>Un'estensione MuleSoft compatibile con il protocollo MQTT (Message Queuing Telemetry Transport) v3.x.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Connettore MuleSoft Anypoint AMQP</a></td><td>Un connettore che consente all'applicazione di pubblicare e utilizzare messaggi utilizzando un broker compatibile con AMQP 0.9.1.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">API MuleSoft Anypoint basata sugli eventi (sincronizzazione)</a></td><td>Linguaggio indipendente dal settore che supporta la pubblicazione di API basate sugli eventi separandole in livelli evento, canale e trasporto.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Servizio di messaggistica cloud multitenant che consente ai clienti di eseguire messaggi asincroni avanzati tra le loro applicazioni.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">Stream di dati MuleSoft Anypoint</a></td><td>Framework disponibile in MuleSoft Anypoint per la pubblicazione e l'abbonamento ai dati in streaming.</td><td>Pro-code</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka su Heroku</a></td><td>Componente aggiuntivo Heroku che fornisce Apache Kafka come servizio con integrazione completa della piattaforma nella piattaforma Heroku.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Modifica acquisizione dati</a></td><td>Registro eventi di modifica, che pubblica le modifiche ai record Salesforce. Le modifiche includono la creazione di un nuovo record, gli aggiornamenti di un record esistente, l'eliminazione di un record e l'annullamento dell'eliminazione di un record.</td><td>Da codice basso a codice pro</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Messaggi in uscita</a></td><td>Azioni che inviano messaggi XML a endpoint esterni quando i valori dei campi vengono aggiornati in Salesforce.</td><td>Basso codice</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventi piattaforma</a></td><td>Messaggi sicuri e scalabili contenenti dati di eventi personalizzati.</td><td>Da codice basso a codice pro</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>API che abilita abbonamenti a eventi piattaforma, eventi di acquisizione dati di modifica e/o eventi di Monitoraggio evento in tempo reale.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relay evento</a></td><td>Abilita l'invio di eventi piattaforma ed eventi acquisizione dati di modifica da Salesforce ad Amazon EventBridge. Tenere presente che i relay evento si connettono solo ad AWS Eventbridge.</td><td>Basso codice</td></tr>
<tr><th scope="row"></th><td></td><td></td><td></td></tr>
</tbody>
</table>

### Pubblica/Abbonati

Quando un record critico cambia stato all'interno di un'applicazione centrale, ad esempio lo stato di un ordine passa da "Elaborazione" a "Spedito", è probabile che più altri sistemi richiedano una notifica quasi in tempo reale per eseguire le rispettive operazioni. Quando il volume di questi cambiamenti è elevato e i messaggi sono complessi, si pone una specifica esigenza aziendale, rendendo le integrazioni tradizionali da punto a punto onerose e difficili da gestire. La creazione di connessioni fragili e personalizzate per ogni singola applicazione dipendente comporta un indebitamento tecnico e impedisce all'organizzazione di scalare rapidamente. È necessario un approccio di integrazione efficace per gestire queste frequenti sincronizzazioni dei dati senza associare il sistema di origine direttamente a ogni sistema che utilizza.

#### Schema di pubblicazione/abbonamento

Lo schema riportato sotto rappresenta un tipico schema di pubblicazione/abbonamento in cui più publisher e abbonati condividono i dati tramite un bus degli eventi. Questo schema di base costituisce la base per gli schemi più specifici che si possono trovare nel resto di questa guida. Alcune caratteristiche chiave di questo schema sono:

- Non esiste una connessione diretta tra publisher e abbonati. I publisher inviano semplicemente messaggi a un bus degli eventi, che li trasmette a qualsiasi altro sistema che desideri ascoltarli.

- Lo stesso sistema può essere sia un publisher che un abbonato.

- I sistemi possono pubblicare o abbonarsi a più tipi di eventi.

- Come per tutti gli schemi di questa guida, lo schema di pubblicazione/abbonamento rientra in una categoria di schema di integrazione generale nota come invocazione di procedure remote (RPI) o semplicemente ["fire and forget".](/docs/architect/it-it/fundamentals/guide/integration-patterns#invocazione-di-processi-remoti--fire-and-forget)

<!-- Image: Publish/subscribe pattern diagram (Level 2) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Publish - Subscribe L2.png" alt="Questo diagramma di livello 2 mostra un esempio di schema di pubblicazione/abbonamento che include più publisher, più abbonati e più eventi distribuiti attraverso i canali in un bus degli eventi. In questo schema, lo stesso sistema può essere sia un publisher che un abbonato e un sistema può abbonarsi a più eventi.">

#### Strumenti pertinenti allo schema di pubblicazione/iscrizione

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flusso e comportamento dell'evento</th><th colspan="2" scope="colgroup">Considerazioni sul payload</th></tr>
<tr><th scope="col">Strumenti disponibili</th><th scope="col"></th><th scope="col">Competenze richieste</th><th scope="col">Pubblica tramite</th><th scope="col">Abbonamento tramite</th><th scope="col">Periodo di riproduzione</th><th scope="col">Struttura payload</th><th scope="col">Limiti del payload</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connettore Salesforce Pub/Sub</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">Connettore JMS MuleSoft Anypoint</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Connettore MuleSoft Anypoint Solace</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">Connettore MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Connettore MuleSoft Anypoint MQTT</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Connettore MuleSoft Anypoint AMQP</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">API MuleSoft Anypoint basata sugli eventi (sincronizzazione)</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka su Heroku</a></td><td>Pro-code</td><td>API, modifiche dei record in Heroku Postgres</td><td>N/D</td><td>1-6 settimane</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Modifica acquisizione dati</a></td><td>Da codice basso a codice pro</td><td>Modifiche record</td><td>Apex, API, componenti Web Lightning (LWC)</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinito</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Messaggi in uscita*</a></td><td>Basso codice</td><td>Regole di flusso e di flusso di lavoro</td><td>N/D</td><td>24 ore</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_wsdl.htm">Definito dall'utente</a></td><td>100 notifiche per messaggio</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventi piattaforma</a></td><td>Da codice basso a codice pro</td><td>API, Apex, Flusso</td><td>Apex, API, Flusso, LWC</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>API o API Pub/Sub, Apex, Flusso</td><td>API Pub/Sub</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relay evento**</a></td><td>Basso codice</td><td>Eventi piattaforma, Acquisizione dati modifica</td><td>API</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Salesforce continuerà a supportare i messaggi in uscita nell'ambito delle attuali funzionalità, ma non prevede di effettuare ulteriori investimenti in questa tecnologia. **I relay evento si connettono solo ad AWS Eventbridge</td></tr>
</tbody>
</table>

### Fanout

Quando un'organizzazione deve inviare aggiornamenti istantanei a un numero elevato di applicazioni client, ad esempio notifiche push o messaggi SMS ai dispositivi mobili, il processo tradizionale di creazione di trasmissioni univoche per ogni singolo destinatario diventa rapidamente un collo di bottiglia nella scalabilità. In questo caso, l'esigenza principale del business è la distribuzione rapida e ad alte prestazioni di una singola informazione, ad esempio un avviso account o un avviso di modifica critica del servizio, a numerose applicazioni endpoint contemporaneamente. Un approccio semplificato per soddisfare questo requisito prevede l'instradamento di tutti i messaggi attraverso un'unica area di attesa, che funge da punto centrale delle informazioni sull'evento per tutti i sistemi che consumano. Questo approccio migliora le prestazioni eliminando la necessità di gestire molte copie separate dei messaggi.

#### Lo schema Fanout

Con lo schema di fanout, i messaggi vengono consegnati a una o più destinazioni (ovvero client o abbonati in ascolto) tramite un'unica area di attesa messaggi. Gli abbonati recuperano lo stesso messaggio dall'area di attesa anziché la propria copia univoca. Tenere presente che, sebbene ciò migliori le prestazioni, può anche rendere più difficile verificare se un determinato abbonato ha ricevuto o meno il messaggio.

<!-- Image: Fanout pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Fanout L3.png" alt="Questo diagramma di documentazione e implementazione di livello 3 mostra un esempio di schema di fanout. Rappresenta un evento che viene pubblicato e scritto in una singola area di attesa quando un record viene modificato tramite un&apos;interazione utente, un flusso o un processo batch. Il sistema abbonato dispone di più servizi che ricevono lo stesso evento dall&apos;area di attesa dei messaggi.">

#### Strumenti pertinenti allo schema Fanout

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flusso e comportamento dell'evento</th><th colspan="2" scope="colgroup">Considerazioni sul payload</th></tr>
<tr><th scope="col">Strumenti disponibili</th><th scope="col"></th><th scope="col">Competenze richieste</th><th scope="col">Pubblica tramite</th><th scope="col">Abbonamento tramite</th><th scope="col">Periodo di riproduzione</th><th scope="col">Struttura payload</th><th scope="col">Limiti del payload</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">Connettore JMS MuleSoft Anypoint</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connettore Salesforce Pub/Sub</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Connettore MuleSoft Anypoint Solace</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">Connettore MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Connettore MuleSoft Anypoint MQTT</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Connettore MuleSoft Anypoint AMQP</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka su Heroku</a></td><td>Pro-code</td><td>API, modifiche dei record in Heroku Postgres</td><td>N/D</td><td>1-6 settimane</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Modifica acquisizione dati</a></td><td>Da codice basso a codice pro</td><td>Modifiche record</td><td>Apex, API, componenti Web Lightning (LWC)</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinito</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventi piattaforma</a></td><td>Da codice basso a codice pro</td><td>API, Apex, Flusso</td><td>Apex, API, Flusso, LWC</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>API Pub/Sub o Apex, API, Flusso</td><td>API Pub/Sub</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relay evento*</a></td><td>Basso codice</td><td>Eventi piattaforma, Acquisizione dati modifica</td><td>API</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*I relay evento inviano i dati solo ad AWS Eventbridge</td></tr>
</tbody>
</table>

### Messaggi passati

Alcuni scenari di eventi sono caratterizzati da un notevole afflusso di volume di messaggi che minaccia di sovraccaricare la capacità dei processi di sincronizzazione e trasformazione o da una logica complessa a più fasi necessaria per elaborare e trasformare i dati degli eventi.

Alcuni esempi sono:

- **Picchi di volume stagionali:** Ci possono essere picchi di volume che i rivenditori online sperimentano quando una selezione dei loro prodotti è "di stagione". Quando un numero elevato di clienti effettua acquisti contemporaneamente, il numero di eventi generati può superare temporaneamente la capacità dei processi di sincronizzazione e trasformazione. Per ulteriori informazioni, vedere [Ben progettato - Affidabilità](/docs/architect/it-it/well-architected/guide/reliability.html#scalability-and-capacity-planning).

- **Gestione di casi o richieste:** Le aziende di servizi possono riscontrare un aumento del numero di casi o richieste durante le interruzioni.

- **Trasformazioni dati complesse:** Le organizzazioni che richiedono una logica complessa per trasformare i messaggi spesso temono che gli eventi vengano generati più velocemente di quanto possano essere trasformati.

#### Schema dei messaggi passati

Questo schema affronta la sfida di generare i messaggi più velocemente di quanto possano essere trasformati. Garantisce che volumi elevati di messaggi e manipolazioni dei dati richieste possano essere gestiti in modo affidabile, incorporando una piattaforma di messaggi in streaming e segmentando la logica di gestione dei messaggi in componenti dedicati.

Lo schema Messaggi passati funziona segmentando la logica di gestione dei messaggi in più componenti:

- Un componente gestisce l'instradamento dei messaggi, determinando le trasformazioni richieste e la destinazione finale.

- Un insieme separato di componenti gestisce diversi livelli di trasformazione dei messaggi (ad esempio, mappature di campi, relazioni tra oggetti e così via).

- L'ultimo componente scrive il messaggio finale modificato.

<!-- Image: Passed messages pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Passed Messages L3.png" alt="Questo diagramma di documentazione e implementazione di livello 3 mostra un esempio di flusso di processo per lo schema dei messaggi passati che include un publisher, un abbonato e un messaggio. Il messaggio viene suddiviso in più parti, che vengono trasformate singolarmente e quindi riassemblate prima di essere inviate all&apos;abbonato.">

#### Strumenti pertinenti allo schema dei messaggi passati

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flusso e comportamento dell'evento</th><th colspan="2" scope="colgroup">Considerazioni sul payload</th></tr>
<tr><th scope="col">Strumenti disponibili</th><th scope="col"></th><th scope="col">Competenze richieste</th><th scope="col">Pubblica tramite</th><th scope="col">Abbonamento tramite</th><th scope="col">Periodo di riproduzione</th><th scope="col">Struttura payload</th><th scope="col">Limiti del payload</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connettore Salesforce Pub/Sub</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka su Heroku</a></td><td>Pro-code</td><td>API, modifiche dei record in Heroku Postgres</td><td>N/D</td><td>1-6 settimane</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Modifica acquisizione dati</a></td><td>Da codice basso a codice pro</td><td>Modifiche record</td><td>Apex, API, componenti Web Lightning (LWC)</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinito</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventi piattaforma</a></td><td>Da codice basso a codice pro</td><td>API, Apex, Flusso</td><td>Apex, API, Flusso, LWC</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>API Pub/Sub o API, flusso Apex</td><td>API Pub/Sub</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relay evento*</a></td><td>Basso codice</td><td>Eventi piattaforma, Acquisizione dati modifica</td><td>API</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*I relay evento inviano i dati solo ad AWS Eventbridge</td></tr>
</tbody>
</table>

### Streaming

Alcuni produttori generano uno stream continuo di eventi. Un esempio comune è lo streaming multimediale, che prevede interazioni utente che si verificano naturalmente come eventi discreti. Più sistemi devono reagire contemporaneamente allo stesso comportamento dell'utente senza bloccare l'esperienza di streaming core.

Considerare gli eventi per una piattaforma di streaming musicale. Questi possono includere:

- Monitoraggio degli eventi avviati/messi in pausa/saltati

- Eventi della sessione di ascolto con indicazioni orarie

- Eventi di creazione/modifica della playlist

- Eventi di condivisione sociale

- Download per l'ascolto offline

#### Schema di streaming

Nello schema Streaming, gli abbonati accedono a ogni stream di eventi ed elaborano gli eventi nell'ordine esatto in cui vengono ricevuti. Copie univoche di ogni stream di messaggi vengono inviate a ogni abbonato, consentendo di fornire contenuti specifici dell'abbonato e di identificare gli abbonati che ricevono quali stream.

<!-- Image: Streaming pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Streaming - L3.png" alt="Questo diagramma di documentazione e implementazione di livello 3 mostra un esempio di schema di streaming che rappresenta uno stream di eventi in corso di pubblicazione. Gli abbonati che sono in ascolto degli stream li ricevono ed elaborano di conseguenza.">

#### Strumenti pertinenti allo schema di streaming

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flusso e comportamento dell'evento</th><th colspan="2" scope="colgroup">Considerazioni sul payload</th></tr>
<tr><th scope="col">Strumenti disponibili</th><th scope="col"></th><th scope="col">Competenze richieste</th><th scope="col">Pubblica tramite</th><th scope="col">Abbonamento tramite</th><th scope="col">Periodo di riproduzione</th><th scope="col">Struttura payload</th><th scope="col">Limiti del payload</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">Stream di dati MuleSoft Anypoint</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connettore Salesforce Pub/Sub</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka su Heroku</a></td><td>Pro-code</td><td>API, modifiche dei record in Heroku Postgres</td><td>N/D</td><td>1-6 settimane</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>API Pub/Sub o API, flusso Apex</td><td>API Pub/Sub</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Definito dall'utente</a></td><td>1 MB</td></tr>
</tbody>
</table>

#### Gestione ordini di eventi in streaming

Perché uno stream abbia senso, tutti gli eventi e i messaggi associati devono essere nell'ordine corretto. Se i dati provengono da stream di sistemi diversi, sarà necessario incorporare ulteriore logica di ordinamento come parte del processo di progettazione.

### Messa in attesa

I casi d'uso di aree di attesa sono onnipresenti. Gli esempi includono:

- **Connessioni Internet di bassa qualità:** Le organizzazioni di Field Service o altre organizzazioni in cui i team con dispositivi mobili devono lavorare in aree con accesso a Internet di bassa qualità o intermittente traggono vantaggio dall'inserimento in area di attesa poiché le applicazioni su questi dispositivi possono connettersi alle aree di attesa e recuperare tutti i messaggi pertinenti quando viene ripristinata la connettività.

- **Buffering dei messaggi:** Quando il volume dei messaggi occasionalmente supera la capacità di elaborazione di un abbonato e la latenza aumentata non crea ulteriori problemi, le aree di attesa possono fungere da buffer per memorizzare i messaggi in eccesso e impedire la perdita di dati.

- **Gestione dei trasporti:** Le organizzazioni logistiche che devono monitorare i propri parchi veicoli possono utilizzare questo schema per visualizzare i percorsi che ogni veicolo sta seguendo quasi in tempo reale e assicurarsi che i conducenti siano il più efficienti possibile.

- **Dispositivi IoT:** I produttori utilizzano spesso sistemi che generano flussi rapidi di dati e questi flussi possono avere effetti a valle su sistemi aggiuntivi. Questo schema può essere utilizzato per identificare sequenze di eventi che richiedono l'intervento umano prima che si verifichino guasti catastrofici che interessano più sistemi.

#### Schema dell'area di attesa

Nello schema Area di attesa, i produttori inviano messaggi alle aree di attesa, che li conservano fino a quando gli abbonati non li recuperano. La maggior parte delle aree di attesa dei messaggi segue l'ordine first-in, first-out (FIFO) ed elimina ogni messaggio dopo che è stato recuperato. Ogni abbonato ha un'area di attesa univoca, che richiede ulteriori fasi di impostazione ma consente di garantire la consegna e identificare gli abbonati che hanno ricevuto quali messaggi.

<!-- Image: Queuing pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Queuing L3.png" alt="Questo diagramma di documentazione e implementazione di livello 3 mostra un esempio di schema di area di attesa che rappresenta un evento pubblicato e scritto in un&apos;area di attesa quando un record viene modificato. Gli abbonati ricevono copie dell&apos;evento dalle aree di attesa associate ed eseguono gli aggiornamenti appropriati ai propri record.">

#### Strumenti pertinenti allo schema di area di attesa

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flusso e comportamento dell'evento</th><th colspan="2" scope="colgroup">Considerazioni sul payload</th></tr>
<tr><th scope="col">Strumenti disponibili</th><th scope="col"></th><th scope="col">Competenze richieste</th><th scope="col">Pubblica tramite</th><th scope="col">Abbonamento tramite</th><th scope="col">Periodo di riproduzione</th><th scope="col">Struttura payload</th><th scope="col">Limiti del payload</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/4.3/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connettore Salesforce Pub/Sub</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">Connettore MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Connettore MuleSoft Anypoint MQTT</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Connettore MuleSoft Anypoint AMQP</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Come configurato</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Definito dall'utente</a></td><td>Nessuno</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka su Heroku</a></td><td>Pro-code</td><td>API, modifiche dei record in Heroku Postgres</td><td>N/D</td><td>1-6 settimane</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Definito dall'utente</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Modifica acquisizione dati</a></td><td>Da codice basso a codice pro</td><td>Modifiche record</td><td>Apex, API, componenti Web Lightning (LWC)</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinito</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventi piattaforma</a></td><td>Da codice basso a codice pro</td><td>API, Apex, Flusso</td><td>Apex, API, Flusso, LWC</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>API o API Pub/Sub, Apex, Flusso</td><td>API Pub/Sub</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relay evento*</a></td><td>Basso codice</td><td>Eventi piattaforma, Acquisizione dati modifica</td><td>API</td><td>3 giorni</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Definito dall'utente</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*I relay evento inviano i dati solo ad AWS Eventbridge</td></tr>
</tbody>
</table>

#### Gestione della memoria e dell'archiviazione

A causa della natura asincrona dello schema di inserimento in area di attesa, può verificarsi un lungo ritardo tra l'aggiunta di un messaggio a un'area di attesa e il recupero del messaggio. Le aree di attesa richiedono memoria o spazio di memoria per contenere i messaggi, quindi non possono crescere all'infinito, il che significa che un abbonato offline a tempo indeterminato può causare un errore se nell'area di attesa si accumula un numero sufficiente di messaggi. Il buffering dei messaggi può avere lo stesso effetto se i tempi di elaborazione dell'abbonato diventano troppo lunghi, causando volumi elevati di messaggi nelle aree di attesa. Per ridurre questi rischi, eseguire un'analisi approfondita dei requisiti di memoria per tutte le aree di attesa dei messaggi e, se necessario, progettare processi che eliminino e disabilitino le aree di attesa se i messaggi non vengono recuperati entro un determinato periodo di tempo o raggiungono un volume predeterminato.

## Considerazioni non funzionali

Oltre alle considerazioni funzionali elencate nelle sezioni precedenti, è necessario tenere presenti anche considerazioni non funzionali.

### Migrazione da integrazioni da punto a punto

Anche se si è pienamente convinti che un'architettura basata sugli eventi sia adatta alla propria organizzazione, è possibile iniziare con un panorama che include già un gran numero di integrazioni da punto a punto. Ottenere finanziamenti per un progetto che sostituisca tutte le integrazioni contemporaneamente può essere difficile e potrebbe anche non essere possibile utilizzare un'architettura basata sugli eventi direttamente con alcuni sistemi legacy. In questi scenari, è possibile adottare un approccio incrementale alla migrazione a un'architettura più vagamente accoppiata convertendo prima le applicazioni più critiche per l'azienda, quindi convertendo altri sistemi man mano che vengono aggiornati o sostituiti nei progetti futuri. Questo approccio semplifica l'aggiunta di nuove applicazioni al bus degli eventi e consente al panorama IT complessivo di rimanere scalabile e resiliente man mano che i sistemi continuano ad essere aggiunti nel tempo.

### Scambi all'interno di sistemi accoppiati liberamente

Come architetti, sappiamo che ogni architettura ha dei compromessi. Un'architettura basata sugli eventi non fa eccezione. Mentre un panorama pieno di sistemi vagamente accoppiati è altamente scalabile e resistente, ci sono anche alcuni compromessi da considerare:

- **Strategia di integrazione generale:** Indipendentemente dagli strumenti e dagli schemi che si decide di utilizzare, è importante iniziare creando una strategia per la condivisione dei dati tra i vari sistemi nel panorama dell'organizzazione. Questa strategia deve includere gli obiettivi dell'organizzazione per i propri dati, il modo in cui i dati possono essere condivisi e gli schemi utilizzati, nonché le fonti di dati, i target, le strutture e i requisiti di proprietà e accesso.

- **Supporto per i sistemi legacy:** L'organizzazione potrebbe avere sistemi legacy che semplicemente non supportano schemi di architettura basati sugli eventi. Benché sia possibile creare soluzioni alternative (ad esempio, con un processo che funge da pass-through abbonandosi agli eventi e quindi inviando l'output al sistema di destinazione tramite un mezzo diverso di trasferimento dei dati), è possibile considerare altri metodi di integrazione in questo caso.

- **Modifiche strutturali ai messaggi:** Una volta definita e concordata la struttura iniziale dei messaggi tra publisher e abbonati, può essere difficile modificarla, soprattutto se gli abbonati sono esterni. Esistono diversi modi per risolvere questo problema. È possibile utilizzare gli endpoint con versione, ma assicurarsi di definire e comunicare un ciclo di vita chiaro per ogni versione in modo che gli sviluppatori non debbano gestire troppe versioni contemporaneamente. Se Apache Kafka su Heroku fa parte del paesaggio, è anche possibile considerare un registro di schema o uno strumento simile, ma assicurarsi che anche gli altri sistemi nel paesaggio supportino (e utilizzino).

- **Mancanza di visibilità tra publisher e abbonati:** Nella maggior parte degli schemi di architettura basati sugli eventi, i publisher non sono consapevoli dello stato dei propri abbonati. Pertanto, se un publisher invia un messaggio critico mentre tutti gli abbonati sono offline, il messaggio potrebbe non essere mai consegnato. È possibile risolvere questo problema utilizzando la funzionalità replay o aggiungendo abbonati ridondanti eseguiti su server separati per tutti i messaggi critici.

- **Colli di bottiglia delle prestazioni:** Man mano che un'architettura basata sugli eventi aumenta, il bus degli eventi può diventare un collo di bottiglia per la consegna dei messaggi se viene sovraccaricato da troppi publisher che tentano di inviare messaggi a troppi abbonati contemporaneamente. È possibile risolvere questo problema aumentando la memoria e le risorse di elaborazione allocate al bus degli eventi o utilizzando più bus degli eventi per elaborare diversi tipi di messaggi in parallelo.

## Procedure consigliate correlate

Oltre alle indicazioni già fornite, considerare anche le seguenti procedure consigliate.

### Implementazione di architetture basate sugli eventi

Prima di implementare un'architettura basata sugli eventi, valutare se è davvero necessario utilizzarne una. La sezione precedente descrive scenari aziendali comuni adatti a ogni schema di architettura basato sugli eventi. Ulteriori informazioni sono disponibili in [Ben progettato - Affidabilità](/docs/architect/it-it/well-architected/guide/reliability.html). Esaminare le sfide da considerare durante l'implementazione delle architetture basate sugli eventi per determinare se gli schemi previsti sono più adatti ai propri casi d'uso specifici.

Tenere presente che, sebbene la maggior parte degli scenari descritti in questa guida preveda integrazioni, le architetture basate sugli eventi possono essere utilizzate anche per inviare messaggi all'interno di una singola organizzazione Salesforce, ad esempio tramite l'uso di eventi piattaforma. Assicurarsi di tenere presenti gli eventuali [limiti di allocazione](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) applicabili quando si progettano processi che utilizzano gli eventi piattaforma come sistema di messaggistica interno.

### Evitare gli anti-schemi

Spesso, gli schemi anti-pattern relativi alle architetture basate sugli eventi derivano dall'utilizzo degli eventi come soluzione per le comunicazioni interne all'interno di un'organizzazione Salesforce. Gli anti-schemi comuni includono:

- **Pubblicazione di eventi da trigger Apex associati allo stesso oggetto evento:** Questo risulterà in un loop trigger infinito.

- **La pubblicazione di eventi da Apex prima che una transazione DML completi:** Se una transazione non riesce e viene ritirata, tutti gli eventi pubblicati con il comportamento di pubblicazione Pubblica immediatamente non verranno inclusi nel comportamento di ritiro.

- **Pubblicazione di eventi in Flusso per orchestrare l'automazione successiva:** Il modo migliore per coordinare la logica in più automazioni è utilizzare i [sottoflussi](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm) o [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm).

- **Creazione di dipendenze di runtime:** Non pubblicare eventi per facilitare la comunicazione tra i pacchetti senza eseguire i [passaggi](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8) appropriati per eliminare le dipendenze in fase di esecuzione.

- **Carichi utili non necessari:** Quando si effettuano richieste, è consigliabile inviare e ricevere la minor quantità di dati possibile nel payload. Ogni azione di un utente potrebbe generare più richieste ed è importante che vengano elaborate in modo efficiente. L'invio di più dati del necessario può contribuire a rallentare il trasporto e ad aumentare il tempo di elaborazione.

- **Gestione non selettiva degli eventi applicazione:** Quando sono presenti più componenti in ascolto per un evento applicazione, gli sviluppatori devono assicurarsi che l'handler evento venga eseguito solo quando è effettivamente desiderato e utile. Ad esempio, in Lightning Console, i componenti contenuti nelle schede che non sono attivati possono essere ancora in ascolto anche se non sono visibili. Uno sviluppatore può utilizzare varie tecniche, ad esempio utilizzare un elemento utilità in background come unico ascoltatore o chiamare getEnclosingTabId() per determinare se questa istanza del componente è racchiusa nella scheda attivata per garantire che ogni evento venga gestito solo quando previsto.

- **Il comportamento di pubblicazione degli eventi piattaforma non è corretto:** Gli eventi piattaforma hanno due comportamenti di pubblicazione: Pubblica immediatamente e Pubblica dopo l'impegno. Può essere utile utilizzare gli eventi piattaforma in tempo reale per casi d'uso come Registrazione, in cui si desidera pubblicare l'evento di registrazione indipendentemente dal fatto che la transazione abbia esito positivo o meno. Tuttavia, utilizzare con molta attenzione Pubblica immediatamente con gli eventi piattaforma in tempo reale. Gli eventi possono essere consumati dagli abbonati all'interno della stessa transazione e causare blocchi delle righe o altre condizioni di gara.

### Progettazione di eventi efficaci

Quando si implementa un'architettura basata sugli eventi, una delle chiavi del successo è definire gli standard per la progettazione degli eventi stessi. Le specifiche variano a seconda dei casi d'uso dell'organizzazione, ma di seguito sono riportate alcune linee guida generali:

- **Determinare la struttura ottimale per i payload degli eventi.** Mentre le dimensioni più piccole dei messaggi riducono i tempi di elaborazione, bombardare gli abbonati con volumi elevati di messaggi può causare colli di bottiglia nelle prestazioni. Può essere necessario ripetere le dimensioni e le strutture del payload per trovare il giusto equilibrio. MuleSoft e strumenti ESB simili offrono la possibilità di progettare payload personalizzati nei messaggi associati agli eventi, che possono aiutare a visualizzare le strutture di dati per migliorare le prestazioni sul lato abbonato. (Per ulteriori informazioni, vedere [Ben progettato - Affidabilità](/docs/architect/it-it/well-architected/guide/reliability.html)).

- **Pensare ai processi end-to-end.** Assicurarsi di non creare scenari di "loop senza fine", che possono essere difficili da individuare una volta implementate le integrazioni. Ad esempio, due sistemi pubblicano gli eventi quando i record vengono aggiornati, ascoltando anche gli eventi degli altri, che attivano ulteriori eventi pubblicati quando vengono elaborati.

  È possibile correggere questo tipo di anti-schema aggiungendo una logica a entrambi i sistemi che garantisca che le modifiche apportate a seguito di un evento consumato non determinino la pubblicazione di un nuovo evento. Assicurarsi inoltre di documentare tutti gli eventi, i trigger associati e i sistemi a valle che potrebbero essere interessati. Utilizzare questa documentazione come riferimento durante le sessioni di progettazione per individuare i loop infiniti e gli scenari simili il prima possibile. (Per ulteriori informazioni, vedere [Ben progettato - Eccellenza operativa](/docs/architect/it-it/well-architected/guide/operational-excellence.html)).

- **Utilizzare le convenzioni di denominazione comuni nei vari sistemi.** Convenzioni di denominazione coerenti sono una procedura ottimale per tutto lo sviluppo software, incluse le architetture basate sugli eventi. Documentare una serie di standard per i nomi degli eventi, le strutture, gli oggetti associati e i processi di gestione degli errori per garantire la coerenza tra i sistemi. (Per ulteriori informazioni, vedere [Ben progettato - Eccellenza operativa](/docs/architect/it-it/well-architected/guide/operational-excellence.html)).

## Risorse

<table style="width:100%">
<thead>
<tr><th scope="col">Schema</th><th scope="col">Risorse</th></tr>
</thead>
<tbody>
<tr><td>Pubblica/ Abbonati</td><td><a href="/docs/architect/it-it/well-architected/guide/reliability.html">Salesforce ben progettato - Affidabilità</a><br><a href="/docs/architect/it-it/well-architected/guide/operational-excellence.html">Salesforce ben progettato - Eccellenza operativa</a><br>Post <a href="https://medium.com/salesforce-architects/achieve-architectural-efficiency-with-event-relays-c8d4ec7f07af">del blog: Come ottenere efficienza architettonica con i relay evento</a><br>Post <a href="https://medium.com/salesforce-architects/announcing-pub-sub-api-generally-available-3980c9eaf0b7">del blog: Annuncio dell'API Pub/Sub disponibile</a> in generale<br>Post <a href="https://blogs.mulesoft.com/dev-guides/api-design/moving-from-restful-to-eventful/">del blog: Passaggio da RESTful a EVENTful</a><br>Post <a href="https://blogs.mulesoft.com/dev-guides/event-driven-architectures-asyncapi/">del blog: Architetture basate sugli eventi e specifica AsyncAPI</a><br><a href="https://youtu.be/0WJjmmw1ryM">Video: Tour dimostrativo</a> Pubblica / Abbonati</td></tr>
<tr><td>Fanout</td><td>Post <a href="https://developer.salesforce.com/blogs/2021/08/how-to-work-within-platform-events-delivery-limits">del blog: Come lavorare entro i limiti</a> di consegna degli eventi piattaforma<br><a href="https://youtu.be/zSncRUcucEU">Video: Tour dimostrativo</a> dello schema Fanout</td></tr>
<tr><td>Messaggi passati</td><td><a href="https://youtu.be/U87nErhMuqw">Video: Tour dimostrativo</a> sullo schema Messaggi passati</td></tr>
<tr><td>Streaming</td><td>Post <a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">del blog: Progettazione di scritture a volume elevato in Salesforce</a><br><a href="https://youtu.be/-_1CDUI40fY">Video: Streaming Pattern Walkthrough</a> (Guida allo schema di streaming)<br><a href="https://docs.mulesoft.com/mule-runtime/4.3/streaming-about">Documentazione: Streaming nelle app Mule</a></td></tr>
<tr><td>Messa in attesa</td><td>Post <a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">del blog: Progettazione di scritture a volume elevato in Salesforce</a><br>Post <a href="https://blogs.mulesoft.com/dev-guides/api-design/event-payment-apis/">del blog: Come progettare architetture di pagamento con le API Evented</a><br><a href="https://youtu.be/jQvSKbMRbh0">Video: Tour dimostrativo</a> dello schema di area di attesa</td></tr>
</tbody>
</table>

<!-- document id=de5e3a7f0c0e4c804f5dd5faec3a8bff0c6559c42ba1b7b7fbc50939daf45965 url=/architect/current/it-it/decision-guides/guides/record-triggered.md -->

# Automazione attivata da record

Salesforce Platform ha continuamente avanzato la propria architettura di automazione per soddisfare le esigenze dei processi aziendali complessi. Le generazioni precedenti (Regole di flusso di lavoro e Process Builder) hanno fornito i passaggi iniziali della logica basata sugli eventi, ampliando le funzionalità di automazione per la logica basata sugli eventi e ampliando la portata a una gamma più ampia di generatori.

Questa evoluzione è culminata in un’architettura consolidata e ad alte prestazioni incentrata su due pilastri complementari: Flusso attivato da record e trigger Apex.

## Panoramica della guida

Questo documento fornisce il framework e le linee guida per prendere decisioni informate durante la progettazione delle automazioni dei trigger. È in grado di bilanciare i requisiti dei casi d'uso rispetto a tre punti decisionali principali che guidano l'utente nella scelta del giusto approccio per l'automazione attivata dalle modifiche ai record Salesforce.

## Prodotti nell'ambito

<table style="border:none">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Flusso</td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Salesforce Flow</a> è un potente strumento di automazione point-and-click che consente agli utenti di creare processi aziendali complessi, schermate e logica visivamente utilizzando Flow Builder, senza scrivere codice. Automatizza operazioni come l'aggiornamento dei dati, l'invio di email e la guida degli utenti, offrendo flessibilità attraverso tipi come Flussi schermata (interazione dell'utente) e Flussi attivati (eventi record/pianificati).</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Apex</td> 
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a> è un linguaggio di programmazione proprietario orientato agli oggetti per la piattaforma Salesforce, simile a Java, utilizzato per creare logiche aziendali personalizzate, automatizzare i processi ed estendere le funzionalità CRM principali oltre gli strumenti dichiarativi.</td>
    </tr>
  </tbody>
</table>

## Takeaway

La creazione di un'automazione attivata da record scalabile, manutenibile e performante in Salesforce Platform richiede un approccio disciplinato e basato sull'architettura. La scelta tra Flusso e Apex, e l'implementazione di ciascuno, è guidata da un chiaro insieme di principi. Questi punti riassumono questi principi e fungono da regole di base per la moderna progettazione dell'automazione.

- **Scegliere lo strumento giusto per il lavoro in base alla densità di automazione di Salesforce Object.**

  - Utilizzare Flusso attivato da record per gli oggetti Salesforce per le automazioni **a bassa densità**.

  - Migliorare la logica dei flussi attivati da record con Apex invocabile per le automazioni **a media densità**.

  - Utilizzare trigger Apex per gli oggetti Salesforce per le automazioni **ad alta densità**.

- **Prestare attenzione quando si attivano processi asincroni.**  
  Questa regola si applica sia quando si invocano processi asincroni in un flusso attivato da record sia quando si inserisce in area di attesa un processo accodabile da Apex. Sebbene questo schema possa essere allettante per scaricare il lavoro, può introdurre scenari complessi di gestione degli errori e aumentare il rischio di superare i limiti del governor.

- **Utilizzare un punto di ingresso per ogni oggetto Salesforce.**  
  Per un determinato oggetto Salesforce, utilizzare un meccanismo come punto di ingresso nell'automazione. Cercare di evitare di mescolare trigger Flusso e Apex come punti di ingresso per lo stesso oggetto.

## Punti decisione

Tre sono i principali punti di decisione da considerare:

- Implementazione dichiarativa e implementazione programmatica
- Densità automazione
- La matrice di selezione della densità

### Implementazione dichiarativa e implementazione programmatica

Flusso e Apex condividono una serie di funzionalità fondamentali. Ogni strumento può eseguire query sui record, eseguire logica condizionale, assegnare variabili ed eseguire operazioni DML come la creazione, l'aggiornamento e l'eliminazione di record, in sequenza per l'esecuzione in un ordine specificato.

Tuttavia, questa sovrapposizione funzionale non implica che gli strumenti siano intercambiabili. La scelta architetturale non riguarda _se_ un'operazione può essere eseguita, ma _come_ viene eseguita e quali sono le implicazioni a lungo termine per prestazioni, scalabilità e manutenibilità. Il flusso eccelle in chiarezza dichiarativa e velocità di implementazione per i processi semplici, mentre Apex offre il controllo granulare e la potenza grezza necessari per le soluzioni complesse.

### Densità automazione

La **densità di automazione** è il carico posto su un oggetto Salesforce specifico. Serve come euristica per determinare l'implementazione ottimale dell'oggetto. Man mano che la densità dell'automazione aumenta, la probabilità di superare i limiti delle transazioni aumenta.

Calcolare la densità di automazione esaminando tre dimensioni specifiche di volume e complessità:

- **Quantità di automazione:** Numero non formattato di voci di metadati di automazione univoche (flussi, azioni di trigger e così via) eseguite durante un singolo evento DML (Data Manipulation Language).

- **Volume record:** I record per transazione elaborati tramite caricamenti API o elaborazione batch pesante, in cui le prestazioni diventano critiche.

- **Diffusione delle dipendenze:** Misura delle operazioni DML a valle attivate dall'operazione CRUD iniziale. Quantifica la profondità del grafico in cui un aggiornamento si trasforma in aggiornamenti sugli oggetti correlati (ad esempio, caso → account → referente → roll-up personalizzato).

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/automation-density.png" alt="Dimensioni densità automazione">

Man mano che l'ambito e la complessità dell'applicazione Salesforce aumentano, impegnarsi in un unico punto di ingresso principale, Flusso attivato da record o Trigger Apex. Evitare di suddividere le automazioni in più meccanismi in un unico oggetto Salesforce, poiché ciò causa una scarsa manutenibilità e una governance frammentata.

### La matrice di selezione della densità

Utilizzare questa matrice per determinare lo standard architettonico richiesto per l'oggetto Salesforce.

- Il **flusso attivato da** record è la soluzione preferita per una bassa densità di automazione. Offre un equilibrio di potenza e accessibilità ideale per automazioni semplici e indipendenti l'una dall'altra.

- **Lo schema ibrido (Record-Triggered Flow with Invocable Apex)** è una scelta potente e manutenibile per le automazioni a media densità con complessità crescente. Questo schema consente ai team di mantenere coreografie ordinate in un flusso dichiarativo delegando al contempo le operazioni complesse di calcolo ad Apex, bilanciando l'accessibilità con le prestazioni.

- **I trigger Apex** forniscono i componenti base necessari per una solida base architettonica per supportare automazioni ad alta densità. Le prestazioni, il controllo granulare e l'astrazione e il polimorfismo orientati agli oggetti di Apex sono più adatti per gestire la complessità e la scala di questi scenari.

<table>
  <thead>
    <tr>
      <th scope="col" style="width:8%">Livello di densità</th>
      <th scope="col" style="width:18%">Quantità automazione</th>
      <th scope="col">Volume di dati (dimensioni batch)</th>
      <th scope="col">Dependance Sprawl (Diffusione delle dipendenze)</th>
      <th scope="col">Standard architettonico</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Basso</b></td>
      <td><b>&lt; 15</b><br>
        Automazioni</td>
      <td><b>Standard</b><br>
        Interazioni dell'interfaccia utente basate sugli utenti o piccoli carichi API (1-200 record)</td>
      <td><b>Discreto</b><br>
        Logica autonoma. 0–1 operazioni DML a valle sullo stesso oggetto o su un oggetto correlato.</td>
      <td><b>Flusso attivato da record</b></td>
    </tr>
    <tr>
      <td><b>Medio</b></td>
      <td><b>15–30</b><br>
        Automazioni</td>
      <td><b>Modera</b><br>
        Elaborazione batch standard (con logica che richiede un'attenta messa in blocco)</td>
      <td><b>Accoppiato</b><br>
        Parent/Child aggiorna da 2 a 4 operazioni DML a valle. Rischio di ricorsione</td>
      <td><b>Schema ibrido</b><br>
        Flusso + Apex invocabile</td>
    </tr>
    <tr>
      <td><b>Alto</b></td>
      <td><b>> 30</b><br>
        Automazioni</td>
      <td><b>Alto</b><br>
        Grandi volumi di dati con caricamenti API in blocco (2.000 - 10.000+ record)</td>
      <td><b>Complesso e ricorsivo</b><br>
        Grafico delle dipendenze profonde (5+ operazioni DML a valle). Rischio di loop di ricorsione triangolari</td>
      <td><b>Framework di metadati trigger Apex</b></td>
    </tr>
  </tbody>
</table>
Le decisioni architettoniche del mondo reale richiedono la ponderazione collettiva di tutte le dimensioni della densità di automazione. Considerare il potenziale ambito futuro quando si seleziona un meccanismo di automazione per un determinato oggetto Salesforce.

Considerare inoltre il numero totale giornaliero di operazioni DML poiché Salesforce impone la gestione delle risorse condivise in un ambiente multi-tenant e i [limiti del governor](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm) per impedire che le automazioni incontrollate monopolizzino le risorse condivise. Gli oggetti Salesforce con elevati volumi giornalieri di DML richiedono un'accurata selezione dell'automazione. Ad esempio, i limiti asincroni per il tempo CPU (60.000 ms) e le dimensioni dell'heap (12 MB) sono superiori ai limiti sincroni. Inoltre, il limite di 24 ore dell'organizzazione per le esecuzioni asincrone, calcolato come 250.000 o 200 volte le licenze utente, richiede di considerare il DML giornaliero totale nella progettazione architettonica per evitare eccezioni in fase di esecuzione.

## Confronto dei prodotti

Flusso attivato da record è lo strumento dichiarativo principale della piattaforma per l'automazione attivata da record. La facilità d'uso e le protezioni della piattaforma incorporate di Flow consentono ai team di creare facilmente soluzioni scalabili e affidabili. È la scelta ideale per la maggior parte dei team che creano soluzioni su Salesforce Platform.

Apex è il linguaggio di programmazione proprietario, fortemente tipizzato e orientato agli oggetti della piattaforma. Utilizzare Apex per gli oggetti Salesforce con elevata densità di automazione e per i casi d'uso che richiedono prestazioni elevate, logica sofisticata o un controllo granulare sulle transazioni.

Per facilitare il processo decisionale, questa matrice offre un confronto diretto tra Flusso e Apex nelle principali funzionalità architetturali.

<table>
  <thead>
    <tr>
      <th scope="col">Capacità</th>
      <th scope="col">Flusso attivato da record</th>
      <th scope="col">Trigger Apex</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Velocità di consegna e manutenzione</b></td>
      <td><b>Consigliato</b><br>
        L'interfaccia utente visiva di Flow Builder consente agli amministratori e ad altri generatori dichiarativi di creare e modificare l'automazione più rapidamente rispetto alla scrittura, al test e alla distribuzione di Apex Code. Questa interfaccia consente a una gamma più ampia di membri del team di offrire valore aziendale e riduce la dipendenza da risorse per sviluppatori specializzate per operazioni semplici.</td>
      <td><b>Richiede esperienza</b><br>
        Apex richiede sviluppatori di software esperti per implementare, testare e gestire il codice.</td>
    </tr>
    <tr>
      <td><b>Modularità</b></td>
      <td><b>Disponibile</b><br>
        I flussi attivati da record sono modulari per impostazione predefinita. Anziché la logica monolitica, i team creano flussi discreti per esigenze specifiche e li coreografano insieme utilizzando Explorer trigger di flusso. Questa modularità consente la modifica isolata e l'estensione semplice, riducendo notevolmente il costo di proprietà a lungo termine.</td>
      <td><b>Disponibile</b><br>
        Apex è suddiviso in moduli funzionali in base alla progettazione. Ogni classe Apex è destinata a implementare un singolo modulo di funzionalità.</td>
    </tr>
    <tr>
      <td><b>Visibilità e governance</b></td>
      <td><b>Consigliato</b><br>
        La natura visiva del flusso offre una rappresentazione intuitiva della logica aziendale. Explorer trigger di flusso offre una visualizzazione consolidata di tutti i flussi di un oggetto, semplificando la comprensione, il governo e la risoluzione dei problemi per architetti e amministratori senza leggere il codice.</td>
      <td><b>Richiede esperienza</b><br>
        L'utilizzo di un framework di metadati per organizzare i trigger è vantaggioso, ma Apex richiede un team di sviluppo disciplinato per mantenere il codice organizzato e manutenibile.</td>
    </tr>
    <tr>
      <td><b>Elaborazione in blocco dei dati ad alte prestazioni</b></td>
      <td><b>Sconsigliato</b><br>
        Esiste un rischio elevato di superare i limiti del governor quando si ha a che fare con logica complessa o volumi di dati elevati.</td>
      <td><b>Consigliato</b><br>
        Apex Code viene eseguito più vicino ai servizi principali della piattaforma e offre agli sviluppatori un controllo avanzato sull'ottimizzazione delle query, la gestione dei dati e l'efficienza algoritmica. Ciò si traduce in prestazioni e scalabilità migliori, soprattutto in scenari complessi che coinvolgono volumi di dati elevati.</td>
    </tr>
    <tr>
      <td><b>Logica e strutture di dati solide</b></td>
      <td><b>Disponibile</b><br>
        L'<a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">elemento Trasforma flusso</a> può essere utile per alcune operazioni di elaborazione complesse. Tuttavia, il flusso non dispone di strutture di dati native Map and Set (Mappa e imposta), il che rende l'elaborazione dei dati complessa complessa complessa e inefficiente dal punto di vista computazionale.</td>
      <td><b>Consigliato</b><br>
        Apex offre accesso completo ai loop Map, Set e programmatic per una manipolazione dei dati altamente efficiente e sicura in blocco. Essendo un linguaggio di programmazione completo, Apex offre anche l'accesso a costrutti logici complessi, strutture di dati e schemi di progettazione che possono aiutare a risolvere problemi aziendali complessi in modo manutenibile ed efficiente. Apex include una ricca libreria standard di funzioni avanzate (ad esempio, BusinessHours, Crypto) attualmente non disponibili negli strumenti dichiarativi.</td>
    </tr>
    <tr>
      <td><b>Controllo delle transazioni</b></td>
      <td><b>Non disponibile</b><br>
        Il flusso non fornisce alcun accesso a `Database.savepoint`, `Database.rollback` o a operazioni DML parzialmente riuscite per conferme o rollback parziali delle transazioni.</td>
      <td><b>Disponibile</b><br>
        Apex offre un controllo completo e granulare sull'integrità delle transazioni e su scenari di ripristino degli errori complessi.</td>
    </tr>
    <tr>
      <td><b>Distribuzione email</b></td>
      <td><b>Consigliato</b><br>
        L'invio di avvisi tramite email preconfigurati da un flusso attivato da record è semplice e scalabile. Gli avvisi tramite email personalizzati possono essere creati e distribuiti in fase di esecuzione. I messaggi email personalizzati sono soggetti a <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">limiti giornalieri</a>.</td>
      <td><b>Disponibile</b><br>
        Apex può generare e inviare messaggi email personalizzati. Tutte le email inviate da Apex sono soggette ai <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">limiti giornalieri</a>.</td>
    </tr>
    <tr>
      <td><b>Applicazione di protezioni piattaforma</b></td>
      <td><b>Consigliato</b><br>
        Il flusso include protezioni incorporate, ad esempio la bulkificazione automatica e i tentativi automatici. Queste protezioni aumentano la velocità di calcolo e impediscono insidie nelle prestazioni che altrimenti richiedono una codifica manuale complessa.</td>
      <td><b>Implementazione manuale richiesta</b><br>
        Le protezioni come la creazione in blocco devono essere codificate in modo esplicito (ad esempio, la gestione delle raccolte ed evitare SOQL all'interno dei loop). I tentativi automatici non sono nativi dei trigger e richiedono una complessa logica personalizzata per essere implementati.</td>
    </tr>
    <tr>
      <td><b>Elaborazione asincrona</b></td>
      <td><b>Disponibile</b><br>
        Il flusso offre meccanismi semplici per le automazioni che richiedono una transazione separata in un percorso asincrono. Queste automazioni sono soggette a limiti giornalieri.</td>
      <td><b>Disponibile</b><br>
        Apex consente il controllo completo tramite Acquisizione dati di modifica ed eventi in area di attesa gestiti da un abbonato trigger disaccoppiato.</td>
    </tr>
    <tr>
      <td><b>Elaborazione pianificata</b></td>
      <td><b>Consigliato</b><br>
        I percorsi pianificati del flusso offrono una funzionalità di pianificazione unica e potente (ad esempio, "attiva 3 giorni prima della data di chiusura"). Questa funzionalità include l'annullamento automatico e la riprogrammazione se i dati del record cambiano. Queste automazioni sono soggette a limiti giornalieri.</td>
      <td><b>Non disponibile</b><br>
        Un trigger Apex non può pianificare in modo nativo un evento temporale specifico del record con annullamento automatico. Sebbene esista Apex pianificato, si tratta di un meccanismo fondamentalmente diverso che viene eseguito in un momento specifico e non viene pianificato durante l'elaborazione di un singolo record come parte di un trigger.</td>
    </tr>
    <tr>
      <td><b>Ordinamento e coreografia</b></td>
      <td><b>Disponibile</b><br>
        Explorer trigger di flusso consente agli amministratori di definire un ordine di esecuzione relativo per più flussi sullo stesso oggetto.</td>
      <td><b>Disponibile</b><br>
        Un framework trigger offre un controllo granulare sull'ordine esatto delle automazioni.</td>
    </tr>
    <tr>
      <td><b>Aggiornamenti di campo dello stesso record</b></td>
      <td><b>Disponibile (prima del salvataggio)</b><br>
        Il flusso attivato da record è l'opzione dichiarativa più efficace per aggiornare il record di attivazione prima della conferma DML iniziale.</td>
      <td><b>Disponibile (prima del salvataggio)</b><br>
        Apex offre le prestazioni più elevate con un sovraccarico minimo.</td>
    </tr>
    <tr>
      <td><b>CRUD oggetti incrociati</b></td>
      <td><b>Disponibile (dopo il salvataggio)</b><br>
        Il flusso è adatto per operazioni DML tra oggetti semplici, di bassa complessità.</td>
      <td><b>Disponibile (dopo il salvataggio)</b><br>
        Apex offre un controllo superiore su deduplica, gestione degli errori e prestazioni per le operazioni DML oggetti incrociate.</td>
    </tr>
    <tr>
      <td><b>Deduplicazione di calcoli costosi</b></td>
      <td><b>Disponibile</b><br>
        Il flusso eccelle nell'eliminazione delle query ridondanti e delle istruzioni DML tramite il blocco automatico. Tuttavia, lo stato non può essere memorizzato nella cache o condiviso tra trigger di flusso diversi o tra più chiamate dello stesso flusso all'interno di una sola transazione. Questa limitazione può diventare importante in scenari di prestazioni estreme.</td>
      <td><b>Consigliato</b><br>
        Apex fornisce meccanismi per deduplicare operazioni costose. Gli sviluppatori possono sfruttare il caching transazionale utilizzando proprietà e variabili statiche e il caching a livello di piattaforma utilizzando la cache piattaforma per archiviare e riutilizzare i dati. Queste tecniche sono importanti per ridurre il consumo dei limiti del governor transazionale, ad esempio le query SOQL, e garantire prestazioni e scalabilità elevate.</td>
    </tr>
    <tr>
      <td><b>Gestione errori personalizzati</b></td>
      <td><b>Disponibile</b><br>
        L'elemento CustomError può bloccare un'operazione di salvataggio e visualizzare un messaggio all'utente.</td>
      <td><b>Consigliato</b><br>
        Il metodo <code>addError()</code> offre una messaggistica di errore flessibile a livello di campo e condizionale.</td>
    </tr>
  </tbody>
</table>

## Casi d'uso

Per sottolineare al meglio come utilizzare i punti decisione per guidare le decisioni, considerare i seguenti casi d'uso e punti di analisi associati.

### Consigli migliori

Questa tabella fornisce consigli generali "migliori" per i casi d'uso generali, in base alle funzionalità presentate. Infine, si terranno presenti ulteriori considerazioni per individuare la soluzione più adatta ai propri scenari specifici, ad esempio quelli inclusi nella sezione _Procedure consigliate correlate_ di questo documento. Qui, imparerai di più su quando una particolare combinazione di Flusso e Apex offre l'approccio migliore.

<table>
  <thead>
    <tr>
      <th scope="col">Caso d'uso</th>
      <th scope="col">Descrizione</th>
      <th scope="col" style="width:16%">Più adatta</th>
      <th scope="col" style="width:38%">Motivo</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Elaborazione batch ad alte prestazioni</b></td>
      <td>Qualsiasi automazione che deve elaborare migliaia di record in modo efficiente</td>
      <td>Apex</td>
      <td>Apex fornisce API complete per l'interfacciamento con la piattaforma e per la velocità di stampa.</td>
    </tr>
    <tr>
      <td><b>Elaborazione dati complessa</b></td>
      <td>Scenari che richiedono una manipolazione avanzata dei dati</td>
      <td>Apex</td>
      <td>Apex fornisce strutture di dati, ad esempio Mappa e Imposta, che non sono disponibili in modo nativo in Flusso e possono essere fondamentali per scrivere codice efficiente e sicuro in blocco.</td>
    </tr>
    <tr>
      <td><b>Controllo transazionale</b></td>
      <td>Meccanismi di controllo come savepoint, rollback e conferme parziali</td>
      <td>Apex</td>
      <td>Apex fornisce l'accesso a meccanismi come Database.savepoint e Database.rollback e ha la capacità di elaborare operazioni DML parzialmente riuscite.</td>
    </tr>
    <tr>
      <td><b>Convalida personalizzata sofisticata</b></td>
      <td>Convalida dei dati in più campi di un record</td>
      <td>Apex</td>
      <td>Sebbene il flusso possa impedire il salvataggio con l'elemento 'CustomError', non è disponibile in tutti i tipi di flusso, inclusi i sottoflussi. Il metodo Apex <code>addError()</code> fornisce più messaggi di errore specifici del campo che possono essere aggiunti a un record in qualsiasi momento durante l'elaborazione del trigger.</td>
    </tr>
    <tr>
      <td><b>Logica moderatamente complessa in un processo semplice</b></td>
      <td>Logica e manipolazione dei dati di moderata complessità, semplificate da una libreria standard di funzioni avanzate, che si verificano nell'ambito di un processo semplice</td>
      <td>Flusso + Apex</td>
      <td>Il flusso attivato da record funge da livello di orchestrazione, mentre le operazioni di elevata complessità sono incapsulate in Apex invocabile.</td>
    </tr>
    <tr>
      <td><b>Logica da semplice a moderatamente complessa</b></td>
      <td>Manipolazione dei dati di complessità da bassa a moderata, con aggiornamenti dei trigger sia agli oggetti dati principali che a quelli correlati</td>
      <td>Flusso</td>
      <td>Il flusso è in genere l'opzione da seguire, poiché è basato su un modello dichiarativo che lo rende accessibile sia agli amministratori che agli sviluppatori.</td>
    </tr>
    <tr>
      <td><b>Notifiche e messaggi in uscita</b></td>
      <td>Invio di email e messaggi in uscita</td>
      <td>Flusso</td>
      <td>Il flusso consente di inviare avvisi tramite email e messaggi in uscita sulle modifiche dei record in modo semplice e altamente scalabile.</td>
    </tr>
    <tr>
      <td><b>Elaborazione pianificata</b></td>
      <td>Automazione in una data futura e dinamica (ad esempio, 3 giorni prima di una data di chiusura)</td>
      <td>Flusso</td>
      <td>I percorsi pianificati rappresentano un punto di forza unico per il flusso, poiché la piattaforma gestisce automaticamente la pianificazione, l'annullamento e la riprogrammazione di questi percorsi se i dati del record cambiano.</td>
    </tr>
  </tbody>
</table>

### Elaborazione scalabile: Casi d'uso asincroni in dettaglio

La scalabilità è una considerazione fondamentale quando si progetta l'implementazione. Quando la logica aziendale di un'automazione attivata da record diventa complessa, di lunga durata o comporta volumi di dati elevati, i limiti del governor centrale della piattaforma Salesforce diventano un vincolo architettonico. Operazioni come aggiornamenti globali dei dati, chiamate API complesse o calcoli complessi aumentano il rischio di superare i limiti, ad esempio il tempo totale della CPU o il numero di istruzioni DML all'interno di una singola transazione del database. Un errore in un trigger sincrono dovuto a un'eccezione del limite causerà il ritiro dell'intera transazione di salvataggio dell'utente, causando una scarsa esperienza utente e una potenziale perdita di dati. Questo rischio intrinseco impone a uno schema architettonico di scaricare il lavoro complesso.

L'automazione asincrona diventa essenziale in questo caso. Utilizzando meccanismi asincroni, gli architetti possono disaccoppiare efficacemente il lavoro di lunga durata o a volume elevato dalla transazione di salvataggio dei record principale sincrona. I salvataggi vengono completati in modo rapido e affidabile, mentre l'elaborazione pesante viene delegata a una transazione separata gestita dalla piattaforma che viene eseguita in seguito. Il disaccoppiamento migliora la stabilità, previene gli errori delle transazioni ed è fondamentale per la creazione di applicazioni aziendali scalabili. La piattaforma offre diversi strumenti specializzati per questo, ciascuno con vantaggi e compromessi distinti in termini di affidabilità, volume e complessità.

### Percorso asincrono del flusso

Il percorso Esegui in modo asincrono in un flusso attivato da record offre il meccanismo più semplice per la logica asincrona "attiva e dimentica". Questo percorso viene eseguito in una transazione separata dopo che la transazione di salvataggio dei record originale è stata confermata correttamente nel database.

- **Caso d'uso ideale**: Questo è adatto per le operazioni che non richiedono un'esecuzione immediata o la gestione personalizzata degli errori. Gli esempi includono l'invio di una notifica tramite email, la creazione di un'operazione di follow-up o una semplice chiamata a un sistema esterno.

- **Limitazioni**: Questo meccanismo condivide gli stessi limiti giornalieri del governor delle altre interviste del flusso asincrono. Non è progettato per l'elaborazione a volume estremamente elevato.

### Acquisizione dati di modifica (CDC)

Acquisizione dati di modifica (CDC) è uno schema ad alta produttività, scalabile e resiliente per la gestione della logica asincrona attivata da una modifica record in scenari a volume elevato. In questo modello, l'unica responsabilità del trigger è salvare il record in modo sincronizzato. La piattaforma pubblica quindi un messaggio di evento dettagliato che contiene le modifiche apportate dal record a un bus degli eventi a volume elevato. Un trigger Apex dedicato separato si abbona a questo evento di modifica. Esegue lavori complessi, di lunga durata o asincroni.

- **Vantaggio**: Questo schema separa il processo asincrono dalla transazione utente iniziale. Un errore nell'elaborazione asincrona non causerà il ritiro del salvataggio del record dell'utente. Lo schema fornisce anche uno stream di eventi durevole che può essere utilizzato da più abbonati interni o sistemi esterni e gli eventi possono essere riprodotti per un massimo di 72 ore, offrendo una forte resilienza.

- **Limitazioni**: I messaggi degli eventi CDC non contengono lo stato precedente del record, l'equivalente di un `Trigger.oldMap` Apex. Il payload dell'evento include i nuovi valori dei campi, ma non i valori da cui sono stati modificati. Ciò rende difficile implementare una logica basata su una transizione di stato specifica (ad esempio, eseguire solo se il `Status__c` è cambiato da "In sospeso" a "Approvato"). È possibile mitigare questo problema eseguendo query nella cronologia dei campi dell'oggetto nell'abbonato evento, ma questo aumenta la complessità del processo e il tracciamento della cronologia dei campi potrebbe non essere disponibile per il campo specifico di interesse. Ciò può limitare i tipi di automazione che è possibile scaricare in CDC.

Per impostazione predefinita, CDC può essere abilitato su un massimo di cinque oggetti Salesforce. Le organizzazioni che necessitano di più possono acquistare una licenza aggiuntiva che rimuove questo limite e aumenta le allocazioni di consegne degli eventi.

### Apex in area di attesa da un trigger

L'inserimento di un processo Apex in area di attesa direttamente da un trigger deve essere considerato uno schema rischioso, utilizzato solo quando è necessario un controllo fornito da Apex (ad esempio, per logica complessa o meccanismi di tentativo personalizzati) e CDC non è un'opzione praticabile.

Se è necessario Queueable Apex, l'implementazione deve includere adeguate misure di protezione:

- **Limita controlli**: Il codice deve controllare il numero di processi già presenti nell'area di attesa della transazione prima di tentare di aggiungerne un altro.

  ```
  if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... }
  ```

- **Consapevolezza contesto**: Il codice deve rilevare se viene eseguito in un contesto asincrono, ad esempio un processo batch (`System.isBatch()`), e modificarne il comportamento per rispettare il limite più rigoroso di un processo per transazione in quel contesto.

### Considerazioni sui limiti per Apex asincrono attivato

L'invocazione di Apex asincrono da un trigger sincrono introduce rischi per la stabilità. Per evitare l'impatto a livello di organizzazione (ad esempio, il superamento dei limiti), questo schema richiede progettazione e test rigorosi.

- Il limite giornaliero per le esecuzioni Apex asincrone (`Batch`, `Queueable`, `@Future`) è condiviso in tutta l'organizzazione (in genere 250.000 o un calcolo basato sulle licenze utente). Un caricamento di dati in blocco di 20.000 record causerà l'esecuzione di un trigger in blocchi di 200, dando luogo a 100 chiamate di trigger separate, anche di più se la dimensione del batch in blocco è inferiore a 200 record. Se ogni chiamata inserisce in area di attesa un processo asincrono, è possibile che venga utilizzata una parte significativa del limite giornaliero di un singolo caricamento di dati. Questo consumo può potenzialmente ridurre alla fame altri processi aziendali critici di risorse asincrone.

- I limiti del governor per l'inserimento in area di attesa dei processi sono drasticamente diversi a seconda del contesto. Da un trigger attivato da un'azione utente nell'interfaccia utente (una transazione _sincrona_) è possibile inserire in area di attesa fino a 50 processi. Tuttavia, da un trigger attivato all'interno del metodo `execute` di una classe Batch Apex — una transazione _asincrona_ — può essere inserito in area di attesa un solo processo. Non tenere conto di questa differenza è un punto di errore comune e critico, che causa errori di `LimitException` durante le grandi operazioni sui dati.

- Chiamare Apex pianificabile (`System.schedule`) o Apex batch (`Database.executeBatch`) direttamente da un contesto trigger costituisce un anti-schema. Questi metodi non sono progettati per essere richiamati dal contesto del trigger. In questo modo si determinerà un rapido consumo dell'allocazione Apex asincrona, con conseguenti eccezioni limite.

### Scelta dello schema asincrono corretto

Ogni meccanismo asincrono ha compromessi specifici in termini di prestazioni, limiti del governor e affidabilità. Utilizzare questo albero decisionale come guida per spostarsi tra queste opzioni e scegliere il meccanismo giusto per il proprio caso d'uso.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/async-pattern.png" alt="Albero decisionale schema asincrono">

### L'alternativa al lavoro pianificato

Come indica il diagramma di flusso, quando ci si trova di fronte a operazioni DML a volume elevato ma non è possibile utilizzare Acquisizione dati di modifica (forse a causa dei limiti degli oggetti), la scelta architettonica migliore è spesso evitare completamente un processo invocato da trigger.

Valutare invece la possibilità di utilizzare un processo pianificato. Può essere un flusso pianificato o Apex pianificato. I passaggi obbligatori sono:

1. Eseguire un aggiornamento semplice e a basso costo nel trigger sincrono. Ad esempio, impostare un campo `Status__c` su "elaborazione in sospeso" o inserire un record correlato a basso costo, ad esempio un post Chatter, per indicare che il record deve essere elaborato.

2. Creare un processo pianificato, un flusso pianificato o Apex pianificato, che viene eseguito periodicamente, ad esempio ogni 15 minuti o ogni ora.

3. Fare in modo che la query del processo pianificata per tutti i record nello stato In sospeso, eseguire la logica complessa in un contesto controllato a volume elevato e quindi aggiornare i record come elaborati.

Questo schema separa completamente l'elaborazione pesante dal salvataggio sincrono dell'utente, non è soggetto al limite di un processo per transazione di un batch attivato da trigger e offre una soluzione altamente scalabile e governabile per i requisiti non in tempo reale.

Se la latenza di un processo pianificato non è accettabile per i requisiti aziendali e si è ancora costretti a non utilizzare CDC o un trigger in attesa, ciò indica una significativa non corrispondenza architettonica. A questo punto occorre considerare diversi meccanismi. Rivalutando la progettazione dell'applicazione di base si possono trarre alcune conclusioni, ad esempio:

- Acquisto del componente aggiuntivo per rimuovere i limiti degli oggetti CDC.

- È fondamentale mettere in discussione il requisito aziendale di determinare se l'elaborazione quasi in tempo reale è davvero un "must-have" o se la latenza di un processo pianificato è un compromesso accettabile per la stabilità della piattaforma.

## Considerazioni non funzionali

Oltre ai punti di decisione, è necessario tenere conto di considerazioni non funzionali come la complessità e gli standard.

### Complessità

Il livello di complessità di un'implementazione fa parte del costo totale di proprietà di una soluzione, nonché della sua capacità di adattarsi alle mutevoli esigenze aziendali. La complessità può influire su qualsiasi implementazione se non vengono seguite le procedure consigliate. Nella sezione _Procedure consigliate correlate_ di questo documento sono riportati i consigli per ridurre la complessità della soluzione, inclusi questi schemi:

- Schema ibrido: Apex invocabile per logica complessa nel flusso

- Utilizzo di un framework di metadati per trigger Apex

- Megaflussi rispetto a più flussi

### Processi e standard

La documentazione è importante tanto quanto l'automazione stessa. Non solo garantisce la manutenibilità, ma è anche fondamentale per l'intelligenza artificiale e gli strumenti basati sugli agenti. La documentazione consente di comprendere e gestire i processi aziendali.

**Nel flusso**

- Stabilire una convenzione di denominazione coerente per tutti gli elementi e le variabili.

- Utilizzare il campo Descrizione del flusso per spiegarne lo scopo generale, i criteri di attivazione e l'esito previsto.

- Utilizzare il campo Descrizione per ogni singolo elemento (ad esempio, `Get Records`, `Action`, `Transform`). Questa procedura è il modo migliore per trasmettere l'intento. È particolarmente importante per le azioni invocabili e i sottoflussi, dove la descrizione è il punto principale per spiegare la complessa logica eseguita dall'azione.

**In Apex**

- Commentare chiaramente il codice per spiegare il _perché_ della logica, non solo il _cosa_.

- Se si utilizza un framework basato sui metadati, assicurarsi che i record dei metadati includano e compilino un campo Descrizione in formato leggibile per spiegare le operazioni di ogni classe di handler e quando deve essere eseguita.

DevOps e il controllo sorgente fanno parte di un ciclo di vita di sviluppo maturo. Utilizzare sempre uno strumento di controllo sorgente come Git per i progetti Salesforce. Sia le classi Apex che i flussi Salesforce sono metadati che definiscono la logica aziendale e devono essere modificati e gestiti.

Nel contesto della gestione delle automazioni attivate da record, una pipeline DevOps moderna offre vantaggi essenziali.

- **Controlli di qualità automatici:** Strumenti come [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) possono essere configurati per l'esecuzione automatica nelle opportunità in corso di realizzazione. L'analisi statica può rilevare schemi problematici in entrambi gli strumenti di automazione prima che vengano promossi, segnalando problemi come elementi di `Get Records` inefficienti all'interno di un loop di flusso o query di `SOQL` all'interno di un loop Apex per il loop, che sono cause comuni di deterioramento delle prestazioni.

- **Prevenzione della regressione:** Man mano che la densità di automazione aumenta, la modifica a una classe Flusso o Apex può avere conseguenze indesiderate per altre automazioni sullo stesso oggetto. Una strategia di test DevOps efficace, in cui i test Apex automatici vengono eseguiti in base a qualsiasi modifica proposta, è il modo più affidabile per assicurarsi che una nuova versione del flusso non interrompa la logica Apex esistente (e viceversa).

- **Collaborazione e visibilità:** Il controllo sorgente è la "singola fonte della verità". Consente ad amministratori e sviluppatori di lavorare sull'automazione per lo stesso oggetto in parallelo. Offre anche un itinerario di controllo prezioso: quando un processo di produzione si interrompe, è possibile vedere immediatamente _chi_ ha modificato l'automazione, _quando_ l'ha modificata e, tramite messaggi di conferma, _perché_ l'ha modificata.

Per i team con un mix di amministratori e sviluppatori, [DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) fornisce un'interfaccia unificata che aiuta a coreografare tutte queste fasi, rendendo un processo di sviluppo scalabile e basato sul controllo sorgente accessibile a tutti i membri del team.

Questa disciplina combinata di documentazione e DevOps garantisce la salute e la manutenibilità a lungo termine dell'organizzazione, a vantaggio di ogni architetto e amministratore che vi segue.

## Procedure consigliate correlate

La guida alle decisioni riportata sopra è consigliabile prima di pianificare l'implementazione. Ha lo scopo di aiutare l'utente a scegliere il prodotto migliore per i propri casi d'uso. Dopo la selezione del prodotto, è importante conoscere le procedure consigliate esistenti per l'implementazione.

### Sfruttare lo schema ibrido: Apex invocabile per logica complessa nel flusso

Il principio _One Tool Per Object_ è fondamentale per la gestione dell'automazione ad alta densità, ma non lo si interpreta come una scelta binaria tra uno stack puramente dichiarativo o puramente programmatico. Un modello architetturale più efficace e manutenibile sfrutta un modello ibrido: posizionare il flusso attivato da record come livello di orchestrazione, incapsulando al contempo le operazioni di elevata complessità in Apex invocabile.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/hybrid-pattern.png" alt="Schema schema ibrido">

#### Il livello orchestrazione: Flusso

Il flusso attivato da record funge da livello di orchestrazione per il processo aziendale. È titolare dei criteri di immissione e del contesto di esecuzione (_cosa_ e _quando_). Mantenendo la logica decisionale e l'instradamento all'interno di questo livello, la topologia dei processi dell'architettura rimane trasparente e gestibile tramite Explorer trigger di flusso, evitando che la logica aziendale critica venga oscurata nel codice.

#### Il componente complesso: Apex invocabile

Un esempio comune di componente complesso è l'implementazione dei calcoli del contratto sul livello di servizio (SLA) per i record Caso. Poiché l'oggetto BusinessHours e la relativa logica, essenziali per calcoli accurati che escludono le ore non lavorative e i giorni festivi, non sono accessibili in modo nativo in Flusso, viene utilizzata una classe Apex dedicata. Questa classe, spesso denominata `ServiceLevelAgreementCalculator`, è progettata con un unico metodo statico, annotato con `@InvocableMethod`, per calcolare l'orario di ufficio trascorso, determinare se il contratto sul livello di servizio è "Entro il target" o "Violato" e restituire un output strutturato. Questo approccio incapsula la complessa logica ad alte prestazioni di Apex consentendo al contempo di eseguirla e integrarla senza problemi nel livello di orchestrazione dichiarativa di un flusso attivato da record.

Una volta definita, la classe di `ServiceLevelAgreementCalculator` Apex è disponibile per l'uso all'interno di un flusso attivato da record:

Questo schema dimostra una rigorosa separazione delle preoccupazioni. Il livello dichiarativo viene utilizzato per gestire il ciclo di vita delle transazioni e l'orchestrazione, mentre il codice viene utilizzato per l'esecuzione di elevata complessità. Considerando il codice come un'utilità funzionale anziché come la base, bilanciamo prestazioni e manutenibilità.

#### Vantaggi chiave con lo schema ibrido

**Modularità**: La decisione si allontana dalla singolarità dell'utilizzo di Apex o Flusso per l'intero processo. L'architettura incapsula invece la logica complessa in unità discrete, sicure in blocco e testabili in modo indipendente. Queste unità funzionano come componenti riutilizzabili consumati dallo strato dichiarativo, garantendo le scale di automazione senza complicare la progettazione architettonica.

**Riutilizzabilità**: La logica viene disaccoppiata dall'evento trigger. Un'unità di codice ben progettata (ad esempio un `InvocableMethod`) viene scritta una sola volta ma utilizzata in più punti di ingresso: Flussi attivati da record, flussi schermata o integrazioni esterne. Questo riutilizzo del codice elimina lo sviluppo ridondante.

**Gestibilità**: La logica del flusso del processo rimane visibile e gestibile all'interno del flusso dichiarativo. Questa centralizzazione riduce drasticamente il sovraccarico di debug e garantisce che l'ordine di esecuzione del sistema sia deterministico e trasparente.

#### Limitazioni e compromessi dello schema ibrido

Sebbene il modello ibrido di utilizzo di Apex invocabile da Flusso sia potente, non è un approccio adatto a tutti. Gli architetti devono essere consapevoli delle limitazioni e dei compromessi specifici prima di impegnarsi in una soluzione ibrida.

- **Nessun supporto prima del salvataggio**: Questa è la limitazione più importante. Le azioni invocabili sono disponibili solo nel contesto dopo il salvataggio (flussi per azioni e record correlati). Non possono essere utilizzati nel contesto prima del salvataggio ad alte prestazioni (flussi per aggiornamenti rapidi dei campi). Pertanto, questo schema non può essere utilizzato per delegare gli aggiornamenti di campo dello stesso record. Eseguire questo lavoro ad alte prestazioni utilizzando elementi Flusso nativi in un flusso before-save o all'interno di un trigger Apex before-context.

- **Nessun supporto dopo l'annullamento dell'eliminazione:** Attualmente, il flusso attivato da record non supporta il contesto di annullamento dell'eliminazione. Se un oggetto Salesforce ha un requisito aziendale per eseguire l'automazione quando un record viene ripristinato dal Cestino, l'unica soluzione è un trigger Apex.

- **Overhead delle prestazioni in scenari a volume elevato:** La transizione dal runtime del flusso al runtime Apex non è un'operazione a costo zero. Benché in genere sia veloce, l'esecuzione di un'azione invocabile dal runtime del flusso non è altrettanto veloce dal punto di vista computazionale dell'esecuzione nativa che rimane interamente all'interno di un trigger Apex. Per la maggior parte delle automazioni a media densità, questo micro-overhead è un compromesso trascurabile e utile per una maggiore accessibilità. Tuttavia, per gli scenari estremamente performanti e a volume elevato, un framework solo Apex puro avrà un vantaggio in termini di velocità di calcolo.

### Strategie per l'automazione legacy

Mentre l'euristica della densità di automazione fornisce indicazioni definitive per la nuova architettura greenfield, la realtà degli ambienti Salesforce aziendali è spesso più sfumata. Nelle organizzazioni mature, è comune trovare flussi attivati da record e trigger Apex che operano sullo stesso oggetto Salesforce. Questo scenario è distinto dallo schema ibrido spiegato in precedenza: qui, i flussi e i trigger Apex non sono accoppiati né progettati per funzionare insieme.

Questa coesistenza è spesso il risultato dell'evoluzione delle capacità della piattaforma o del debito tecnico legacy. Sebbene questo sia uno stato operativo tollerato, gli architetti devono trattarlo come un compromesso calcolato anziché come uno stato finale.

L'orchestrazione frammentata causa un notevole sovraccarico di governance e manutenzione, rendendo le attività di sviluppo, test e gestione degli incidenti disgiunte e farraginose. Ciò determina un aumento del Time to Resolution (TTR) e della complessità operativa.

- Per i nuovi oggetti Salesforce, attenersi al principio della densità di automazione come guida principale.

- Per gli oggetti Salesforce esistenti con impronta ibrida e doppio trigger Apex e punti di ingresso del flusso attivati da record, valutare la densità e quindi eseguire l'architettura per il refactoring a uno stato ibrido manutenibile.

  - Per una bassa densità, rifattorizzare i trigger Apex in flussi attivati da record e specificare l'ordine di esecuzione, riportandoli a un unico punto di ingresso dell'automazione.

  - Per una densità media, rifattorizzare i flussi mega complessi in un sottoinsieme di flussi, con il giusto ordine di esecuzione. Introdurre trigger Apex solo quando è assolutamente necessario, ad esempio per supportare dopo l'annullamento dell'eliminazione del contesto.

  - Per una densità elevata, preferire l'implementazione dei trigger Apex.

### Utilizzo di un framework di metadati per trigger Apex

Man mano che i processi aziendali di un'organizzazione sulla piattaforma Salesforce maturano, il volume e la complessità dell'automazione attivata da record aumentano inevitabilmente. Una procedura ottimale fondamentale è mantenere _un trigger Apex per oggetto Salesforce_. Questa regola è fondamentale perché la piattaforma non garantisce l'ordine di esecuzione di più trigger sullo stesso oggetto per lo stesso evento. Questa limitazione può causare comportamenti non deterministici, condizioni di gara e problemi di difficile risoluzione dei problemi.

Tuttavia, l’adesione al principio _one trigger_ introduce una sfida architettonica: come gestire e orchestrare tutta la logica aziendale richiamata da quel singolo punto di ingresso in modo manutenibile e scalabile.

#### Limitazioni degli handler trigger Classic

La prima evoluzione di questa architettura è stato lo schema Classic Trigger Handler. In questo approccio, il singolo trigger Apex delega tutta la sua logica a una classe di handler corrispondente (ad esempio, `OpportunityTriggerHandler`). Questo metodo separa la logica dal file trigger e offre agli sviluppatori un controllo deterministico sull'ordine di esecuzione all'interno dei metodi della classe handler (ad esempio, `afterInsert()`).

Sebbene sia un miglioramento, questo schema spesso porta a classi di handler monolitici. Con il passare del tempo, man mano che si aggiungono ulteriori requisiti aziendali, la classe diventa grande, difficile da gestire e difficile da testare isolatamente. L'ordine di esecuzione di tutti i singoli processi è codificato all'interno di un unico metodo, rendendo la classe soggetta a conflitti di unione, aumentando notevolmente il sovraccarico di governance e manutenzione in un ambiente aziendale di grandi dimensioni.

#### Soluzione: Framework di trigger basato sui metadati

Per risolvere i problemi principali della modularità e dell'orchestrazione, gli architetti passano a un **trigger framework basato** sui metadati. Si tratta di un salto architettonico significativo che separa la logica di automazione stessa dalla configurazione di _come_ e _quando_ viene eseguita.

Questo framework si basa su tre vantaggi chiave:

- **Partizionamento:** Anziché una singola classe di handler, la logica aziendale centrale è suddivisa in piccole classi Apex atomiche (ad esempio, una classe `RecalculateAccountValues` o una classe `NotifySalesLeads`), con ciascuna classe che aderisce al _principio responsabilità unica_. Questa modularità semplifica il test, il debug e la comprensione della logica separatamente.

- **Ordine e coreografia:** L'ordine di esecuzione non è più codificato in Apex. È invece definito in modo dichiarativo dai record di configurazione, in genere memorizzati in un tipo di metadati personalizzato (ad esempio, `TriggerAction__mdt`). Ciò consente agli amministratori di riordinare, aggiungere o rimuovere le azioni di automazione semplicemente modificando un record di metadati, che non richiede una distribuzione o una modifica del codice.

- **Funzionalità di bypass:** Il framework offre funzionalità di bypass granulari standardizzate. Ogni azione di automazione può essere configurata tramite il relativo record di metadati per essere disattivata globalmente o ignorata per utenti amministrativi specifici facendo riferimento a un'autorizzazione personalizzata.

Il trigger Apex singolo per l'oggetto funge quindi solo da dispatcher dinamico. Non contiene alcuna logica aziendale, ma istanzia una classe di `MetadataTriggerHandler` centrale. Questo handler esegue query sui record di metadati personalizzati per determinare dinamicamente la sequenza di esecuzione e invocare le classi Apex atomiche corrette nell'ordine prescritto. L'automazione è unificata sotto un unico livello trasparente e controllabile.

### Deduplicazione di operazioni costose nella transazione

Un vantaggio importante dell'utilizzo di Apex in un framework solido è la possibilità di gestire lo stato delle transazioni e ottimizzare le prestazioni eliminando il lavoro ridondante. Man mano che la logica si accumula, è comune che automazioni diverse all'interno dell'ordine di salvataggio eseguano in modo indipendente le stesse operazioni costose, consumando limiti del governor preziosi e aumentando il tempo di operazione DML.

Il framework è progettato per affrontare questo problema con due strategie principali:

- **Gestione condivisa dello stato:** Nell'ambito di una singola transazione Apex, le proprietà statiche e le variabili vengono utilizzate per memorizzare nella cache i dati. Ciò garantisce che un'operazione costosa, ad esempio una query `SOQL` per un'impostazione di configurazione, venga eseguita una sola volta, anche se la logica di automazione viene richiamata più volte in diversi record o fasi del trigger. Il consumo dei limiti delle transazioni è significativamente ridotto.

- **Utilizzo della cache piattaforma:** Per andare oltre il semplice caching intra-transazioni, utilizzare la cache della piattaforma per evitare di eseguire query sull'intero database per determinati dati. Questa cache in memoria gestita è ideale per recuperare dati non primitivi, letti spesso nella codebase e immutabili nel corso di una transazione (ad esempio profili, ruoli, orari di ufficio). Utilizzando l'interfaccia `Cache.CacheBuilder`, il sistema controlla prima la cache ed esegue la query sul database solo se i dati non sono presenti, ottimizzando le prestazioni e la scalabilità.

### Utilizzo di Prima del salvataggio per gli aggiornamenti dello stesso record

Utilizzare sempre un aggiornamento prima del salvataggio quando l'automazione deve solo modificare i valori dei campi del record che avvia la transazione. Questo vale sia per gli aggiornamenti di campo veloce nel flusso (che vengono eseguiti prima del salvataggio) che per la logica before-context nei trigger Apex (prima dell'inserimento, prima dell'aggiornamento).

Questo schema è performante, indipendentemente dallo strumento utilizzato, perché evita una seconda operazione DML e un ciclo di salvataggio ricorsivo. Le modifiche vengono apportate al record in memoria _prima_ che venga confermato nel database e vengono salvate come parte della transazione originale. Viene eliminato il sovraccarico di un secondo salvataggio, che altrimenti eseguirebbe nuovamente l'intero ordine di salvataggio e attiverebbe nuovamente tutta l'automazione.

### Impedire la ricorsione incontrollata

La ricorsione incontrollata è un'insidia comune nei trigger dopo l'aggiornamento, in cui la logica di un trigger esegue un aggiornamento DML che a sua volta provoca la riattivazione dello stesso trigger. Questo crea un loop infinito che alla fine termina con un'eccezione del limite governor. Mentre i flag booleani statici o le raccolte di ID record elaborati sono stati storicamente utilizzati per impedire tale ricorsione, uno schema più preciso e robusto è quello di bloccare la logica confrontando i valori dei campi tra la nuova e la vecchia versione del record stesso.

Eseguire la logica solo se un campo specifico di interesse è stato effettivamente modificato. Ciò impedisce al trigger di eseguire la sua logica nelle operazioni DML successive all'interno della stessa transazione in cui i dati critici rimangono invariati.

#### Controllo della ricorsione nel flusso attivato da record

In un flusso attivato da record, impedire la ricorsione incontrollata impostando l'esecuzione del flusso solo quando il record viene aggiornato per soddisfare i requisiti della condizione:

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/recursion-flow.png" alt="Controllo della ricorsione nel flusso attivato da record">

Se si sceglie di utilizzare una formula di criteri di immissione nel flusso, è possibile evitare la ricorsione in fuga confrontando la variabile globale `$Record` (che rappresenta i nuovi valori) con la variabile globale `$RecordPrior` (che rappresenta i valori originali prima del salvataggio). Ad esempio, per assicurarsi che un flusso venga eseguito solo se il campo Ammontare di un'opportunità è stato modificato, utilizzare questo criterio nei criteri di immissione:

```
$Record.Amount != $Record__Prior.Amount
```

#### Controllo della ricorsione in Apex

Confrontare i valori dei campi della nuova versione del record, `Trigger.new`, con i valori dei campi della vecchia versione del record, `Trigger.oldMap`, per vedere se si è verificata la modifica specifica desiderata. Questo approccio garantisce che l'automazione sia idempotente e venga eseguita solo quando necessario, rendendo il sistema più efficiente e prevenendo loop ricorsivi catastrofici.

### Ignorare l'automazione

Un'organizzazione Salesforce ben progettata richiede un meccanismo coerente e affidabile per ignorare l'automazione. Non si tratta di una funzione facoltativa, ma di un requisito operativo fondamentale per mantenere l'integrità dei dati e abilitare le operazioni amministrative.

Un framework di bypass è essenziale per alcuni scenari:

- Quando si caricano grandi volumi di dati, l'attivazione di trigger per ogni record può rallentare drasticamente il processo, causare eccezioni ai limiti e creare record e notifiche correlati errati. Un bypass consente di inserire i dati in modo pulito ed efficiente.

- Un utente integrazione può avere la necessità di sincronizzare i dati di un sistema di record esterno. L'automazione che normalmente viene attivata per una modifica avviata dall'utente (ad esempio, l'invio di un messaggio email, la creazione di un'operazione) può essere indesiderata o ridondante quando la modifica ha origine da un altro sistema.

- Gli amministratori o il personale di assistenza potrebbero dover eseguire aggiornamenti correttivi sui record. Un meccanismo di bypass consente di apportare queste modifiche senza attivare l'automazione aziendale standard, che potrebbe avere conseguenze indesiderate.

**Autorizzazioni personalizzate**: Lo standard moderno e scalabile per l'implementazione della logica di bypass sono le autorizzazioni personalizzate. Questi sono superiori ai metodi precedenti per diversi motivi:

- **Flessibilità:** Le autorizzazioni personalizzate possono essere assegnate agli utenti tramite gli insiemi di autorizzazioni. Questa procedura è in linea con il moderno modello di sicurezza e accesso di Salesforce, consentendo un'assegnazione granulare e flessibile. Un bypass può essere concesso a un utente specifico o anche temporaneamente con una data/ora di scadenza specifica.

- **Gestibilità:** L'uso delle autorizzazioni personalizzate evita il codificaggio dei profili o degli utenti in una logica di automazione. Se il ruolo di un utente cambia o un nuovo profilo deve ignorare l'accesso, la modifica è una semplice assegnazione di insiemi di autorizzazioni, non una modifica del codice o del flusso che richiede una distribuzione.

- **Scalabilità:** Le autorizzazioni personalizzate offrono un framework scalabile per la gestione delle eccezioni in una base di utenti complessa. Possono essere assegnati agli utenti tramite insiemi di autorizzazioni, gruppi di insiemi di autorizzazioni o profili. La loro associazione a un insieme di autorizzazioni o a un profilo è rappresentabile anche nei metadati di origine.

**Modelli di implementazione**: Applicare uno schema di bypass coerente a tutte le automazioni attivate da record dell'organizzazione.

**Ignorare un flusso attivato da record**: Il modo più efficiente per ignorare un flusso è impedirne l'esecuzione. A questo scopo, aggiungere una condizione ai criteri di immissione del flusso.

- Nell'elemento iniziale del flusso attivato da record, impostare Requisiti della condizione su La formula valuta True.

  - Nel Generatore di formule, incorporare una verifica dell'autorizzazione personalizzata utilizzando la variabile globale `$Permission`. Combinare il controllo con i criteri di immissione esistenti.

    - Schema di formula:

    ```
    ( ) && NOT($Permission.Bypass_This_Flow)
    ```

  - Questo schema garantisce che il flusso venga eseguito solo se all'utente _non_ è assegnata l'autorizzazione personalizzata specificata. Questo controllo viene eseguito prima ancora di creare l'intervista del flusso, rendendolo l'approccio più efficace.

**Ignorare un trigger framework Apex**: In Apex, integrare la logica di bypass direttamente nel framework di trigger basato sui metadati, consentendo un controllo granulare.

- Il tipo di metadati personalizzato `TriggerAction__mdt` deve includere un campo di testo, ad esempio `BypassPermission__c`.

  - Nella classe `MetadataTriggerHandler`, prima di eseguire dinamicamente un'azione, il codice deve leggere il valore di questo campo.

  - Se il campo è compilato, l'handler utilizza il metodo `FeatureManagement.checkPermission()` per determinare se l'utente corrente in esecuzione dispone dell'autorizzazione personalizzata specificata.

  - Se `checkPermission()` restituisce true, l'handler salta quell'azione specifica e passa a quella successiva nella sequenza.

  - Questo schema è efficace perché consente sia un bypass globale (se tutti i record `TriggerAction__mdt` fanno riferimento alla stessa autorizzazione) che un bypass granulare per azione (se record diversi fanno riferimento a autorizzazioni diverse o se alcuni non dispongono di alcuna autorizzazione di bypass).

### Megaflussi rispetto a più flussi

È un anti-schema per consolidare tutta l'automazione di un oggetto in un unico enorme flusso. Il consolidamento in un flusso anziché la suddivisione della logica in più flussi ben condizionati non ha un impatto significativo sulle prestazioni. I guadagni di prestazioni più significativi provengono da:

- Utilizzo dei flussi before-save per gli aggiornamenti di campo dello stesso record.

- Scrivere condizioni di immissione precise per garantire che i flussi siano esclusi dall'esecuzione per le modifiche che non influiscono sul loro caso d'uso specifico.

[Flow Trigger Explorer](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer) consente di assegnare un valore ordine a ogni flusso di un oggetto, garantendo un ordine di esecuzione sequenziale.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/trigger-explorer.png" alt="Explorer trigger di flusso">

## Risorse

<table>
  <thead>
    <tr>
      <th scope="col">Apex</th>
      <th scope="col">Flusso</th>
      <th scope="col">Operazioni</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Cos'è Apex?</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_integration_intro.htm">Utilità Apex</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Informazioni sull'automazione con il flusso Salesforce</a></li>
          <li><a href="https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer">Scopri Explorer trigger di flusso</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Elemento Trasformazione flusso</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html">Analizzatore di codice Salesforce</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5">DevOps Center</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

<!-- document id=bd2182e13aa3bf611744822e2c6bc11ceff4b45c545fd1643a3cc9c4f7818c32 url=/architect/current/it-it/decision-guides/guides/build-forms.md -->

# Creazione di moduli

Esistono diverse opzioni per la creazione di moduli in Agentforce 360 Platform e si estendono in un continuum che va dagli approcci low-code a quelli pro-code. Su un'estremità del continuum, i moduli dinamici nel Generatore di app Lightning e i flussi schermata in Flow Builder possono essere utilizzati per le soluzioni low-code. Dall'altro lato, il framework Lightning Web Component (LWC) viene utilizzato per le soluzioni pro-code. All'interno del continuum, gli strumenti possono essere combinati in diversi modi utilizzando flussi schermata estesi da LWC e moduli indirizzati ai clienti creati utilizzando OmniStudio.

## Panoramica della guida

Questa guida presenta un framework decisionale e indicazioni sulla creazione di moduli per le soluzioni dell'interfaccia utente. Nello specifico, utilizza una dozzina di punti di esecuzione e di decisione non funzionali per selezionare correttamente la tecnologia migliore per un determinato caso d'uso.

## Takeaway

- **Quando si creano/modificano/visualizzano layout per le pagine Lightning, utilizzare i moduli dinamici.** In futuro, si consiglia di utilizzare i _moduli dinamici_ nel _Generatore di app Lightning_ per configurare le pagine dei dettagli dei record.

- **Se è necessario creare, creare o modificare un modulo per un oggetto, utilizzare _Pagine Lightning_ e _Moduli dinamici_.** Questo è il modo più semplice per creare moduli in Agentforce 360 Platform. Fornisce anche funzionalità aggiuntive (ad esempio, il controllo della visibilità dei campi).

- **Se si crea un modulo multipagina o una procedura guidata e non si hanno requisiti rigorosi per l'utilizzo dell'interfaccia utente o dell'immagine aziendale, utilizzare un flusso schermata.** I flussi schermata offrono un framework di navigazione lineare per l'orchestrazione di più moduli. È possibile utilizzare i componenti LWC per creare il proprio framework per spostarsi tra i moduli, ma si consiglia di lasciare che sia il flusso a eseguire il lavoro in modo da potersi concentrare sui moduli stessi anziché sullo stato del modulo.

- **Se sono necessarie logiche o azioni aggiuntive per supportare il modulo, utilizzare un flusso schermata, OmniStudio o LWC.** Ciascuno di questi strumenti offre diversi modi per migliorare la soluzione consentendole di espandersi oltre la creazione o la modifica di un singolo record. In questo caso, il termine _più_ può riferirsi a una logica avanzata (ad esempio, ramificazione o iterazione) o ad azioni come l'integrazione con sistemi esterni, l'invio di email o l'invio di notifiche push all'app mobile di un utente.

- **Se sono presenti requisiti UX sofisticati o se è necessario gestire dinamicamente più della visibilità dell'interfaccia utente, utilizzare LWC o OmniScript.** Per i requisiti che possono essere soddisfatti utilizzando i layout a tema e basati su colonne, è possibile creare i moduli direttamente in un generatore di codice basso. Tuttavia, il controllo granulare sullo stile della forma richiede la flessibilità di LWC. Se si è un cliente di Settori e si necessita di un'immagine aziendale perfetta o di dati gerarchici complessi, utilizzare OmniStudio, che consente di creare moduli consumer in grado di gestire logiche aziendali complesse e trasformazioni dei dati.

- **Se è necessario distribuire l'automazione dei test, utilizzare LWC.** È possibile scrivere test di unità per qualsiasi LWC, indipendentemente da dove viene incorporato. Ciò consente di creare una strategia di test più efficace, che può includere test in blocco con più record e test negativi.

- **L'utente non è vincolato da decisioni "né dall'una né dall'altra".** È possibile combinare più opzioni per ottenere la soluzione migliore per i propri casi d'uso (ad esempio, se è necessario il sistema di navigazione integrato di Flow e la completa flessibilità di stile offerta da LWC, è possibile utilizzarli insieme).

## Strumenti nell'ambito

Per implementare ed estendere le esperienze dei moduli vengono comunemente utilizzati i seguenti strumenti.

### Descrizioni strumento

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">Moduli dinamici</th>
<th colspan="1" rowspan="1">I <a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_migrate.htm&language=en_US&type=5">moduli dinamici</a> del <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Generatore di app</a> suddividono i componenti monolitici Dettagli record in singoli campi e sezioni configurabili. Questa funzione consente agli amministratori di creare pagine flessibili e ad alte prestazioni posizionando i campi in qualsiasi punto e utilizzando le regole di visibilità per visualizzare o nascondere i componenti in base al profilo utente, al dispositivo o ai dati, riducendo così il disordine delle pagine.</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Un <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">flusso schermata</a> Salesforce è uno strumento di automazione interattivo all'interno di <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">Flow Builder</a> che richiede l'input dell'utente per spostarsi attraverso processi aziendali personalizzati e passo per passo. A differenza dei flussi in background automatici, i flussi schermata offrono un'interfaccia utente simile a quella di una procedura guidata per raccogliere dati, visualizzare informazioni o eseguire azioni tramite <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_page_overview.htm&type=5">pagine Lightning</a>, pulsanti o app personalizzate senza scrivere codice.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Salesforce <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omnistudio_standard.htm&type=5">OmniStudio</a> è una suite di strumenti low-code progettata per creare rapidamente esperienze digitali guidate specifiche del settore e processi aziendali complessi. Consente agli sviluppatori di creare interfacce utente pixel perfette (ad esempio flussi di lavoro guidati e cruscotti digitali dinamici) utilizzando componenti con trascinamento della selezione come <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_flexcardsbasics_8118.htm&type=5">Flexcard</a> e <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">OmniScript</a>. Con OmniStudio è possibile creare LWC in modo dichiarativo.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Componenti Web Lightning</strong></td>
<td colspan="1" rowspan="1">I <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">componenti Web Lightning</a> Salesforce sono elementi HTML personalizzati leggeri creati utilizzando HTML, CSS e JavaScript moderno e progettati per essere eseguiti in modo nativo nei browser per prestazioni superiori dell'interfaccia utente Salesforce. Consentono agli sviluppatori di creare interfacce utente personalizzate che coesistono con i componenti <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Aura</a>, il che aumenta lo sviluppo attraverso standard di settore e un ecosistema di componenti dettagliato.</td></tr></table>

### Competenze degli strumenti e requisiti delle licenze

Questa tabella descrive gli strumenti disponibili per la creazione di moduli tramite Salesforce, insieme alle competenze richieste e alle considerazioni sulla licenza.

**Nota:** Approfondiremo le funzioni specifiche supportate per ogni strumento, come scegliere tra strumenti basati su clic e strumenti basati su codice e quando combinarli in una sezione successiva.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Configurazione</th>
<th colspan="1" rowspan="1">Requisiti di licenza aggiuntivi</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Codice basso</td>
<td colspan="1" rowspan="1">Nessuno</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Codice basso</td>
<td colspan="1" rowspan="1">Nessuno</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Codice basso + Codice pro</td>
<td colspan="1" rowspan="1">Pacchetto Settori</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata più componenti Web Lightning</strong></td>
<td colspan="1" rowspan="1">Codice basso + Codice pro</td>
<td colspan="1" rowspan="1">Nessuno</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Componenti Web Lightning</strong></td>
<td colspan="1" rowspan="1">Codice professionale</td>
<td colspan="1" rowspan="1">Nessuno</td></tr></table>

## Punti decisione

Quando si selezionano prodotti e strumenti, è necessario tenere presenti diversi punti di decisione. Questa tabella delinea diversi punti decisionali e fornisce indicazioni generali.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">Punto Decisione</th>
<th colspan="1" rowspan="1">Guida</th></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Categorie di casi d'uso in fase di esecuzione</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Ambito e navigazione del modulo</strong></td>
<td colspan="1" rowspan="1">Determinare se tutti i campi del modulo si adatteranno logicamente a un'unica schermata o se gli utenti devono poter navigare tra più schermate.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Posizione</strong></td>
<td colspan="1" rowspan="1">Identificare la posizione o le posizioni in cui si desidera incorporare il modulo, che può andare da un'app Salesforce a un'app mobile o a un sito Web esterno.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Controllatore</strong></td>
<td colspan="1" rowspan="1">Identificare le azioni o la logica da eseguire in background mentre gli utenti interagiscono con il modulo, incluse le trasformazioni dei dati e le integrazioni con sistemi esterni.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Convalida</strong></td>
<td colspan="1" rowspan="1">Determinare se sono presenti ulteriori requisiti di convalida degli input che vanno oltre la convalida standard a livello di sistema fornita da Salesforce.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Progettazione di interazioni</strong></td>
<td colspan="1" rowspan="1">Identificare i tipi di interazioni o condizioni che devono attivare risposte dinamiche all'interno del modulo.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Stile</strong></td>
<td colspan="1" rowspan="1">Determinare il livello di raffinatezza necessario per lo stile desiderato e i requisiti CSS.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Layout</strong></td>
<td colspan="1" rowspan="1">Identificare i requisiti di layout del modulo (ad esempio, il numero richiesto di colonne, schede e fisarmoniche) e la possibilità di visualizzare blocchi di dati ripetuti.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Traduzione</strong></td>
<td colspan="1" rowspan="1">Determinare se il modulo deve essere localizzato per altre lingue.</td></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Considerazioni non funzionali</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Sicurezza</strong></td>
<td colspan="1" rowspan="1">Determinare se il modulo deve controllare l'accesso dell'utente prima di eseguire determinate operazioni, se si desidera controllare chi può accedere al modulo e se si desidera controllare dove il modulo può essere incorporato.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Impatto oggetto</strong></td>
<td colspan="1" rowspan="1">Determinare se il modulo funzionerà su un singolo oggetto o su più oggetti.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Automazione test interfaccia utente</strong></td>
<td colspan="1" rowspan="1">Determinare se i processi DevOps richiedono che il modulo venga sottoposto a test di unità automatici o a test end-to-end automatici.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Metriche</strong></td>
<td colspan="1" rowspan="1">Identificare come si desidera tenere traccia dell'utilizzo del modulo, incluse le visualizzazioni pagina, la quantità di tempo trascorso sul modulo, le percentuali di completamento e le percentuali di successo.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Imballaggio e distribuzione</strong></td>
<td colspan="1" rowspan="1">Determinare come distribuire o distribuire il modulo dopo che è stato creato.</td></tr></table>

**Nota:** Nelle tabelle di confronto decisioni successive sono presenti alcuni valori associati a qualsiasi coppia strumento-funzione:

- **Disponibile:** Lo strumento/la funzione funziona con le considerazioni di base.

- **Non disponibile:** Non è previsto alcun aumento del supporto entro i prossimi dodici mesi.

- **Non ideale:** Questo strumento/funzionalità può funzionare, ma non è lo strumento ottimale.

- **Non applicabile:** Lo strumento non si applica al caso d'uso specifico.

## Casi d'uso

Utilizzare questi scenari per confrontare le scelte relative agli utensili in base all'ambito, all'esperienza utente e alle esigenze operative.

### Ambito e navigazione del modulo

Se è possibile ottenere tutti gli input utente da un modulo a schermata singola, iniziare con i moduli dinamici. Tenere presente che i moduli dinamici nelle pagine dei record possono utilizzare la funzione Percorso per supportare i processi aziendali in più fasi.

#### Domande da porre

- È necessaria una schermata singola o l'utente dovrà spostarsi tra più schermate per completare un'operazione?

- Si desidera che gli utenti visualizzino lo stato di avanzamento della compilazione del modulo? Agli utenti verrà richiesto di compilare le informazioni su ogni schermata in un ordine specifico o di spostarsi avanti e indietro tra le schermate in base alle esigenze?

Se sono necessarie più funzionalità di quelle offerte dai moduli dinamici, la scelta tra Flusso, Omnistudio e LWC dipende da alcune domande aggiuntive:

- È possibile visualizzare una barra di navigazione in fondo al modulo? Se l'esperienza di navigazione Flusso schermata e OmniScript fornisce un'interfaccia utente indesiderata, propendere per LWC.

- Che cosa deve accadere dietro il modulo? Se è necessario che il comportamento sia configurabile da un amministratore, utilizzare un flusso. Per relazioni complesse tra più oggetti, utilizzare _OmniScript_ o _LWC_.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Schermata singola</th>
<th colspan="1" rowspan="1">Modulo multischermo</th>
<th colspan="1" rowspan="1">Indicatori di avanzamento</th>
<th colspan="1" rowspan="1">Navigazione saltata tra fasi/schermate</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non ideale</td>
<td colspan="1" rowspan="1">Non ideale</td>
<td colspan="1" rowspan="1">Non ideale</td></tr></table>

Se si sceglie Flusso o OmniStudio, potrebbe anche essere necessario creare un LWC per ottenere l'interfaccia utente corretta. Se si sta già creando un componente LWC per definire correttamente lo stile del modulo, valutare se è necessario [incorporare quel componente in un flusso](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow).

**Navigazione guidata**

D'altra parte, se la soluzione ha l'aspetto di una procedura guidata, in cui l'utente naviga tra più schermate, considerare Flusso o OmniStudio. I flussi e OmniStudio sono dotati di un modello di navigazione incorporato, quindi non è necessario creare e gestire componenti LWC collegati tra loro. La navigazione è lineare, con azioni di spostamento in avanti, azioni di spostamento all'indietro e un meccanismo per salvare il modulo per un secondo momento. È anche possibile creare un modulo con navigazione non lineare se adatto alle proprie esigenze.

Omnistudio offre un vantaggio di navigazione chiave fornendo indicatori di avanzamento dalla navigazione standard che evidenziano le fasi all'interno del modulo. La visualizzazione fase visualizza automaticamente la posizione di un utente in un modulo a più fasi. A differenza di Flusso, consente agli utenti di passare da una schermata all'altra facendo clic su varie fasi del modulo.

Sia che si creino moduli a schermata singola che a schermata multipla, è importante assicurarsi che i moduli siano semplificati in modo che siano facili da navigare per gli utenti.

### Fattore di forma

Se si incorpora un modulo in una pagina di record Lightning standard, tutti gli strumenti che stiamo confrontando funzioneranno; tuttavia, i moduli dinamici sono attualmente disponibili solo sul desktop. Se si desidera offrire un'esperienza che consenta agli utenti di accedere ai moduli da altre posizioni, potrebbe essere necessario considerare opzioni alternative.

#### Domande da porre

- Gli utenti avranno bisogno di accedere al modulo tramite desktop, dispositivo mobile o entrambi?

- Gli utenti devono essere in grado di accedere al modulo da qualsiasi punto dell'app tramite una barra delle utilità?

- Si desidera abilitare le azioni in modo che gli utenti possano compilare il modulo senza dover uscire dalla pagina in cui si trovano attualmente?

- Il modulo deve essere disponibile su un sito Web esterno?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Pagina record Lightning</th>
<th colspan="1" rowspan="1">Pagina iniziale o pagina dell'app Lightning</th>
<th colspan="1" rowspan="1">Siti Experience Cloud Aura</th>
<th colspan="1" rowspan="1">Siti Experience Cloud LWR</th>
<th colspan="1" rowspan="1">Snap incorporati</th>
<th colspan="1" rowspan="1">Barra delle utilità</th>
<th colspan="1" rowspan="1">Azione specifica dell'oggetto</th>
<th colspan="1" rowspan="1">Azione globale</th>
<th colspan="1" rowspan="1">App mobile Salesforce*</th>
<th colspan="1" rowspan="1">Field Service Mobile</th>
<th colspan="1" rowspan="1">Mobile SDK</th>
<th colspan="1" rowspan="1">App e siti esterni</th>
<th colspan="1" rowspan="1">LWC personalizzato</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile**</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non ideale</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="14" rowspan="1" style="border-right: 1px solid #d8dde6;">*I flussi e i componenti LWC sono supportati nell'app mobile Salesforce, ma non in tutti i modi per incorporare i flussi e i componenti LWC (ad esempio, le azioni specifiche degli oggetti sono supportate nell'app mobile, ma le voci della barra delle utilità non lo sono).<br><br>**L'app mobile Salesforce Field Service include Acquisizione dati, una soluzione offline basata sul motore di flusso con runtime offline dedicato, che supporta le funzionalità più recenti del flusso. L'app include anche i flussi Field Service Mobile legacy, che vengono eseguiti su un motore offline personalizzato più datato e non supportano molte delle funzionalità più recenti dei flussi.</td></tr></table>

Poiché richiede contesto record, la funzione Moduli dinamici è supportata solo nelle pagine di record Lightning. Tuttavia, i moduli dinamici non sono supportati nelle pagine Experience Cloud.

È possibile creare flussi che richiedono un contesto record o flussi che funzionano a livello globale. In altre parole, è possibile incorporare i flussi in una varietà di posizioni. Per i flussi contestuali a record, le posizioni possono includere: Pagine di record Lightning, pagine di record Experience Cloud, azioni specifiche di un oggetto o distribuzioni di azioni e consigli. Per i flussi globali, le posizioni possono includere: la barra delle utilità, altre pagine Lightning o Generatore di esperienze, Snap o applicazioni esterne. Attualmente, i flussi non sono supportati come azioni globali, ma è possibile racchiudere i _flussi_ in un componente _Aura_ come soluzione.

OmniStudio consente di creare FlexCard e OmniScript componibili che possono essere posizionati _quasi_ ovunque sia possibile inserire un flusso, ma anche se sono componibili, non sono inseribili in pacchetti.

LWC offre un elevato grado di riutilizzo per la creazione di componenti che possono essere associati ai target tramite metadati in Salesforce, comunità e progetti open source. I componenti LWC possono anche essere incorporati nel proprio sito Web utilizzando [Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html).
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-locationnoheader.png" alt="Lightning Out on External Sites" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

I componenti LWC possono anche avviare i flussi con il componente [Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation).

OmniStudio eccelle nell'esposizione di contenuti a siti esterni tramite la funzione OmniOut. Con OmniStudio e OmniOut è possibile compilare i moduli OmniScript e i componenti FlexCard in componenti standard e quindi eseguirli fuori piattaforma in siti o app di terze parti.

Attualmente, nessuna delle tecnologie dei moduli trattate in questa guida è ufficialmente supportata nei modelli Mobile SDK. Se Mobile SDK è essenziale per il proprio caso d'uso, si consiglia di creare il modulo in modo nativo nell'applicazione mobile o di creare una pagina Visualforce, pur tenendo presente il fattore di forma.

### Logica

I moduli dinamici sono perfetti se è necessario utilizzare i valori del modulo per creare o aggiornare un record. Sarà necessario sfruttare Flusso, OmniStudio o LWC per funzionalità esterne a tale ambito, ad esempio la creazione di livelli decisionali o di iterazione o la generazione di post o email Slack utilizzando gli input del modulo.

#### Domande da porre

- Quali azioni o logica è necessario eseguire dietro le quinte?

- È necessario utilizzare i valori di un record correlato?

- Il modulo dovrà completare le operazioni all'interno di una singola transazione o in più transazioni?

- È necessario integrarsi con sistemi esterni?

- Quali sono i requisiti di riutilizzabilità e modularità?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Registro e azioni</th>
<th colspan="1" rowspan="1">Gestione gerarchica dei dati</th>
<th colspan="1" rowspan="1">Operazione con una sola transazione</th>
<th colspan="1" rowspan="1">Operazione su più transazioni</th>
<th colspan="1" rowspan="1">Integrazione</th>
<th colspan="1" rowspan="1">Progettazione modulare e riutilizzo</th>
<th colspan="1" rowspan="1">Pacchetti</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr></table>

Il flusso offre azioni standard per la pubblicazione in Slack, l'invio di email e l'interazione con i documenti Quip e non è necessario scrivere codice per nessuna di queste operazioni. LWC offre interazioni complete con singoli record e oggetti correlati tramite adattatori che interagiscono con l'[API interfaccia utente](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm). LWC può anche interagire con più record utilizzando il wire per [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html).
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-controllernoheader.png" alt="LWC Interaction via Wire Adapters" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Omnistudio utilizza procedure di integrazione e Data Mapper per ottenere e trasformare i dati (sia esterni che interni a Salesforce). Grazie alle numerose funzioni senza codice, eccelle nell'appiattimento e nell'espansione delle serie di dati con vari livelli di relazioni.

Flusso, OmniStudio e LWC si integrano tutti con Apex, quindi è possibile chiudere facilmente eventuali lacune all'interno della soluzione scelta (ad esempio, se è necessario filtrare i record da un LWC, è possibile utilizzare l'adattatore per fili Apex per creare query SOQL complesse. Se si è influenzati dalle storie basate sui clic, valutare la possibilità di utilizzare Flusso o OmniStudio come valida alternativa a un controller Apex per le proprie esigenze lato server.

È anche opportuno valutare se si desidera confermare immediatamente le azioni o rinviarle a una particolare parte del modulo. Questo è particolarmente rilevante se si utilizza un modulo a più pagine. Il flusso consente di combinare facilmente gli input di più moduli (schermate del flusso) e di utilizzarli in seguito nella procedura guidata (flusso) per eseguire determinate operazioni, che è esattamente il modo in cui si consiglia di progettare i flussi. Eseguire azioni alla fine (nel caso in cui gli utenti rimbalzino avanti e indietro tra le schermate per modificare le risposte).

#### Controllo delle operazioni

Le transazioni e i [limiti del governatore](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) sono parte integrante di Agentforce 360 Platform. Se il caso d'uso è abbastanza semplice, potrebbe non essere altrettanto importante controllare la transazione in cui si verifica una determinata operazione. Tuttavia, esistono alcuni casi d'uso in cui è possibile combinare più operazioni in un'unica [transazione](/docs/architect/it-it/fundamentals/guide/architecture-basics#transazioni) anziché eseguirle in più transazioni.

Ecco alcuni esempi:

- **Ritiro:** Si supponga che il modulo crei più record in background. Se la creazione di un terzo record non riesce, i primi due record devono essere ritirati? Se ogni azione è indipendente l'una dall'altra, è possibile eseguirla come transazione separata. Tuttavia, se sono dipendenti l'una dall'altra e si desidera che il fallimento di una faccia retrocedere anche le altre, è necessario implementarle come singola transazione. Se il modulo è in Flusso, è possibile utilizzare l'elemento Rollback nel percorso di errore per ritirare la transazione e garantire l'integrità dei dati.

- **Impatto a valle sui limiti del governor:** Quando il modulo crea o aggiorna un record, è importante considerare le implicazioni a valle di tale operazione:

  - Quali processi, regole di flusso di lavoro, trigger di flusso, trigger Apex o altri elementi dell'ordine di salvataggio possono essere attivati in base alle modifiche dei record proposte?

  - In che modo queste modifiche collettive influiscono sui limiti del governor utilizzati all'interno di quella transazione?

  - Se una particolare modifica del record può comportare molte modifiche a valle che influiscono sui limiti, può essere consigliabile isolare la modifica del record all'interno della propria transazione.

- **Elaborazione batch:** Può essere necessario raggruppare in batch più aggiornamenti insieme (anche all'interno di un contesto dell'interfaccia utente). Si supponga che il modulo multischermo esegua l'iterazione su un gruppo di record di grandi dimensioni. Anziché confermare un aggiornamento di record dopo ogni schermata, attendere di aver raccolto gli aggiornamenti per tutti i record e quindi inviare una richiesta per aggiornare tutti i record.

Quando si utilizzano i moduli dinamici per creare o modificare un record, si esegue una sola operazione, che è sempre l'inizio di una nuova transazione.

Quando si crea un flusso schermata, si ha un controllo significativo su ciò che si verifica all'interno di una determinata transazione. Le schermate e le azioni locali fungono da confini tra le transazioni. Di seguito è riportato un riepilogo generale della gestione delle transazioni nell'architettura del flusso schermata.

1. L'utente finale interagisce con una schermata e quindi fa clic su **Avanti**.

2. Il client invia una richiesta di input all'API.

3. L'API riceve la richiesta e apre una transazione e una connessione al database. Quindi, l'API chiama il motore di flusso per invocare la richiesta.

4. Il motore di flusso prende il sopravvento e segue il percorso appropriato nella definizione del flusso, fino a quando non viene visualizzata una schermata o un nodo di azione locale. Quindi, il motore restituisce le informazioni su quel nodo all'API.

5. L'API crea un oggetto risposta che contiene i dettagli della schermata successiva da visualizzare e restituisce l'oggetto al client. A questo punto vengono confermate le modifiche al database (in base all'[esecuzione dell'ordine](/docs/architect/it-it/fundamentals/guide/architecture-basics#manipolazione-del-database) di salvataggio) e la connessione al database e la transazione vengono chiuse.

6. Il client utilizza la risposta API per visualizzare la schermata successiva con cui l'utente interagisce.

7. Iniziare dal punto 1 e ripetere il processo.

In altre parole, le schermate _interrompono le_ transazioni. In questo caso, vengono confermate tutte le azioni in sospeso o DML, la transazione precedente viene chiusa e inizia una nuova transazione.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow1.png" alt="multi-screen flow" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Tenere presente che gli elementi di progettazione specifici (le operazioni che si raggruppano in una determinata transazione) dipendono dall'utente.

Ecco alcuni esempi:
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow2.png" alt="screen flow with separate transactions" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

- All'inizio, verrà visualizzato un flusso che raccoglie gli input in più schermate ed esegue diverse azioni all'interno di una sola transazione.
- Il flusso successivo esegue ogni operazione in una transazione separata.
- I flussi possono anche utilizzare i record di ritiro per consentire di ritirare un'intera transazione se una singola operazione non riesce in una serie di operazioni del database.
  <image src="https://architect.salesforce.com/ns-assets/guide-forms-flow3.png" alt="Screen Flow with multiple create records" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
  Si supponga di avere un flusso che crea record, aggiorna record e quindi crea record aggiuntivi (illustrati nel flusso successivo).

In questo scenario, se i primi due elementi hanno esito positivo e l'ultimo ha esito negativo, le prime due operazioni DML creano e aggiornano comunque i record appropriati, ma il terzo non lo farà.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow4.png" alt="Screen Flow with Rollback" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Utilizzando l'elemento Ritiro record, è possibile assicurarsi che l'intera transazione venga ritirata se tutte e tre le operazioni devono avvenire collettivamente (come indicato nel flusso finale).

**Nota:** Per ulteriori informazioni, vedere [Flussi nelle transazioni](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) e [Bulkificazione dei flussi](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm).

La possibilità di controllare la transazione da un LWC si basa sui servizi sottostanti utilizzati da LWC per eseguire le proprie operazioni. Se si utilizza il componente Lightning-record-form base, l'operazione sottostante (creazione o aggiornamento del record) si verifica all'interno di una transazione indipendente quando viene inviato il modulo.

In generale, valgono le seguenti regole:

- Ogni chiamata API dell'interfaccia utente è isolata all'interno della propria transazione.

- Se è necessario eseguire più operazioni all'interno di una singola transazione, inviare gli input a una tecnologia lato server (ad esempio, un controller Apex o un flusso). Tenere presente che le normali regole di transazione per quella tecnologia rimangono valide.

#### Integrazioni esterne

Flusso, OmniStudio e LWC supportano tutti gli eventi piattaforma (per l'[architettura basata sugli eventi](/docs/architect/it-it/decision-guides/guide/event-driven)) e le integrazioni API. Oltre all'Apex Code personalizzato, Flow e Omnistudio dispongono di meccanismi di supporto dichiarativi che possono essere integrati anche con le API.

Se è necessario connettersi a un'API MuleSoft o a un bot RPA, utilizzare i servizi MuleSoft, poiché in questo modo viene generato un servizio esterno.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-mulesoftnoheader.png" alt="External integrations via MuleSoft" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Se l'API ha uno schema OpenAPI, creare un servizio esterno.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-openapi-noheader.png" alt="External Integrations via OpenAPI" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Per tutte le altre istanze, utilizzare la funzione di **chiamata HTTP** (generata da Servizi esterni) nel flusso o l'**azione HTTP** in Omnistudio.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-callouts-noheader.png" alt="External integrations via HTTP" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Omnistudio dispone di una serie completa di funzionalità di integrazione che possono effettuare chiamate a sistemi esterni utilizzando procedure di integrazione per trasformare i dati tramite Data Mapper.

Indipendentemente dal fatto che si utilizzi Apex Code personalizzato o un servizio esterno per l'implementazione, una **chiamata** è comunque una chiamata.

Ecco cosa devi sapere.

- L'elaborazione di una chiamata può richiedere molto tempo.

- Quando una chiamata viene eseguita in modo sincrono, viene eseguita mentre è aperta una transazione del database.

- Salesforce non consente di mantenere aperta una transazione del database se sono presenti operazioni del database in sospeso.

Tenere presente che la limitazione principale è il pericolo di lasciare i dati in uno stato incoerente, che si verifica quando si esegue un'operazione di **creazione**, **aggiornamento** o **eliminazione** e quindi si esegue una **chiamata** all'interno della stessa transazione. Questo schema non è consentito a causa della terza considerazione di cui sopra, che esiste a causa delle prime due considerazioni.

In Flusso, è possibile ignorare questa limitazione interrompendo la transazione. Ricordare che le schermate e le azioni locali reintroducono il contesto del browser. Sebbene sia possibile utilizzare schermate e azioni locali quando si utilizzano chiamate esterne, si consiglia di abilitare **Controllo transazioni** nelle impostazioni avanzate invocabili. Controllo transazione consente di terminare automaticamente la transazione prima di effettuare una chiamata. Per abilitare Controllo transazione, selezionare "**Inizia sempre una nuova transazione**" nella sezione **Avanzate** dell'azione richiamata.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow5.png" alt="External Integrations via Callouts" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
LWC consente di semplificare l'impatto delle chiamate sulla transazione. In altre parole, eseguire le operazioni sui dati utilizzando Lightning Data Service (LDS) e quindi utilizzare un controller Apex per effettuare la chiamata esterna. Poiché la chiamata LDS è isolata all'interno della propria transazione (separata dalla chiamata Apex), ciò protegge l'utente da eventuali incoerenze dei dati risultanti.

#### Riutilizzabilità e modularità

I moduli dinamici non supportano il riutilizzo. Ogni pagina è collegata a una pagina di record Lightning specifica per un oggetto specifico; tuttavia, è possibile assegnare quella pagina di record Lightning a più app, profili e così via.

Analogamente a come si possono scrivere librerie, utilità e componenti che possono essere utilizzati in più componenti, è anche possibile applicare schemi di progettazione simili durante la creazione dei flussi sfruttando la potenza dei **sottoflussi**. A questo scopo, salvare i flussi in bucket modulari più piccoli e quindi chiamarli da altri flussi utilizzando l'elemento **Sottoflusso**. Se la progettazione lo richiede, è possibile creare un flusso utile da solo e come sottoflusso.

OmniStudio è intrinsecamente costruito per la modularità. Mappatori di dati, OmniScript, FlexCard e Procedure di integrazione sono tutti creati in modo indipendente, ma possono anche funzionare in modo intercambiabile. Le FlexCard possono anche essere create come componenti LWC che possono essere incorporati in altri LWC, OmniScript, pagine di record e siti Experience Cloud.

Flussi schermata, OmniScript e LWC possono essere tutti creati per essere riutilizzati e incorporati in una varietà di posizioni, inclusi siti esterni e applicazioni Lightning Out. Quando si progettano le soluzioni in modo che siano componibili, si ottengono anche vantaggi di adattabilità e stabilità.

### Convalida

Tutte le tecnologie utilizzate per creare o aggiornare i record devono rispettare la convalida a livello di sistema, che si tratti di regole di convalida classiche o di convalide personalizzate incorporate in un trigger Apex. Indipendentemente dalla tecnologia utilizzata per eseguire le modifiche dei record, ogni modifica deve passare attraverso l'ordine di salvataggio. Ciò significa che oltre alle regole di convalida, le modifiche dei record vengono elaborate anche da un certo numero di flussi prima o dopo il salvataggio, trigger prima o dopo l'attivazione, regole di inoltro al livello superiore, regole di assegnazione e così via.

**Nota:** Se non lo si è già fatto, rivedere e inserire nei segnalibri l'[ordine di esecuzione](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) Apex.

#### Domande da porre

- Il modulo ha altri requisiti oltre alla convalida a livello di sistema?

- È necessario impostare i campi obbligatori o di sola lettura in modo dinamico all'interno del modulo?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Rispettare la convalida a livello di sistema</th>
<th colspan="1" rowspan="1">Convalida a livello di campo personalizzata specifica di questo modulo</th>
<th colspan="1" rowspan="1">Convalida a livello di campo personalizzata</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr></table>

In genere, gli input in una schermata del flusso o in una fase OmniScript non sono vincolati, quindi il modulo stesso non aderisce in modo nativo alla convalida a livello di sistema associata a un particolare oggetto. Tuttavia, i valori utilizzati per creare o aggiornare i record vengono elaborati nell'ordine di salvataggio, ovvero passano attraverso la convalida a livello di sistema dell'oggetto.

**Nota:** Non tutti i componenti Flusso schermata supportano la convalida degli input.

Analogamente ai layout di pagina, i moduli dinamici consentono di impostare lo stato **obbligatorio** e **di sola lettura** a livello di pagina. Tenere presente che non è possibile ignorare le impostazioni a livello di sistema.

Il flusso offre flessibilità per la personalizzazione della convalida dell'input del modulo. Vengono eseguiti più controlli a livello di client (ad esempio, la segnalazione di campi obbligatori mancanti e controlli dei tipi di dati, nonché formule compatibili all'interno delle regole di convalida degli input). Come ulteriore livello di sicurezza, la convalida degli input viene valutata anche sul server. Quando un utente fa clic su **Avanti**, Flusso invia nuovamente gli input al server per la convalida. Se vengono restituiti input non validi, la navigazione viene bloccata e viene visualizzato l'errore appropriato.

Il server convalida gli input controllando:

- L'impostazione **dell'obbligatorietà** dell'input o se il valore immesso è compatibile con il tipo di dati sottostante.

- Convalida personalizzata dell'input. È necessario specificare un'espressione di formula _booleana_ e un messaggio di errore da visualizzare quando l'espressione di formula non viene soddisfatta.

- Convalida personalizzata del componente sottostante. Se si crea un LWC personalizzato per un flusso, è necessario aggiungere il proprio codice di convalida al metodo validate().

È anche possibile fornire avvisi utente accessibili tramite il componente **Messaggio** in Flussi schermata, ma questo non impedisce a un utente di passare ad altre pagine o di passare alla fase successiva in un flusso guidato. Lo stato _Errore_ all'interno del componente **Messaggio** è utilizzato al meglio nelle schermate di errore dedicate che vengono attivate tramite un percorso di errore quando la navigazione è disabilitata.

OmniStudio offre una gestione avanzata degli errori e della convalida tramite l'azione [Imposta errore](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) in combinazione con [Visualizzazioni condizionali](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) e il componente [Messaggistica](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5).

Per LWC, la maggior parte dei componenti di base esegue le proprie convalide lato client (ad esempio, Lightning-record-form rispetta l'obbligatorietà a livello di sistema, ma non l'obbligatorietà a livello di pagina). Per i componenti personalizzati, è possibile Build Your Own meccanismi di convalida.

Tenere presente che i campi che richiedono l'inserimento di dati da parte degli utenti devono essere visualizzati all'inizio dei moduli. Convalidare gli input degli utenti sul lato client prima di inviare i moduli (quando possibile).

### Progettazione di interazioni

I moduli statici sono superati. Oggi, l'attenzione si è spostata sull'aggiornamento dinamico dei moduli con le proprietà e i valori appropriati per un utente _specifico_, in un momento _specifico_, in un luogo _specifico_. Vediamo più nel dettaglio cosa è possibile fare con gli strumenti di creazione di moduli Salesforce.

#### Domande da porre

- Quali tipi di interazioni o condizioni devono attivare risposte dinamiche all'interno del modulo?

- È necessario eseguire operazioni fuori campo (in background) durante la compilazione del modulo?

- È necessario impostare i campi come **visibili**, **obbligatori**, **di sola lettura** o **disabilitati** oppure modificare la formattazione in base agli input dei moduli?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Esecuzione di operazioni sui dati fuori schermo</th>
<th colspan="1" rowspan="1">Valori condizionali e calcoli</th>
<th colspan="1" rowspan="1">Visibilità condizionale</th>
<th colspan="1" rowspan="1">Requisito condizionale</th>
<th colspan="1" rowspan="1">Formattazione condizionale</th>
<th colspan="1" rowspan="1">Stato di sola lettura condizionale</th>
<th colspan="1" rowspan="1">Stato disabilitato condizionale</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="8" rowspan="1" style="border-right: 1px solid #d8dde6;">*Limitato ai componenti che utilizzano un selettore di risorse e non una casella di controllo statica</td></tr></table>

**Le schermate reattive** abilitano l'interattività del flusso schermata. La reattività consente ai singoli componenti di una schermata del flusso di comunicare tra loro, rendendo i flussi schermata più potenti.

**Esecuzione di operazioni sui dati fuori schermata**

I flussi schermata offrono un approccio dichiarativo per recuperare i dati nella stessa schermata tramite **Azioni schermata**. Le azioni schermata consentono di attivare flussi AutoLaunched su qualsiasi modifica all'interno della schermata o quando un utente fa clic su un componente **Pulsante di azione**. È possibile mappare i risultati dei flussi AutoLaunched alla stessa schermata, eliminando la necessità per gli utenti di passare a un'altra schermata.

LWC fornisce una gamma completa di adattatori che forniscono l'accesso ai dati Salesforce per compilare dinamicamente i dati nei componenti modulo, il che consente agli sviluppatori di **aggiornare**, **eliminare** e **creare** record tramite controller Apex.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-offscreendataoperations-noheader.png" alt="Lightning Web Components Off-Screen Data Operations" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

**Visibilità**

La visibilità può essere controllata dinamicamente in tutti gli strumenti di creazione di moduli. I moduli dinamici, Flow Builder e Omnistudio risolvono questo problema utilizzando le funzioni di visibilità dei componenti. È possibile **visualizzare** o **nascondere** i campi in modo dichiarativo in base ad altri valori all'interno del modulo o se l'utente sta compilando il modulo su un dispositivo mobile.

- I moduli dinamici controllano la visibilità in base ai valori dei campi dei record, ai campi di ricerca e al fattore di forma.

- Con Flusso, è possibile basare una regola di visibilità su altri input schermata, nonché su altre risorse compilate in precedenza nel flusso (ad esempio, formule o valori di altri record).

  - **Regole basate sul dispositivo:** Può non essere ovvio fin dall'inizio, ma è possibile utilizzare una formula per **visualizzare** o **nascondere** un particolare campo quando l'utente si trova su un dispositivo mobile. Scrivere una formula del flusso che controlli il valore della variabile globale **$User.UIThemeDisplayed**. Se il valore è **Theme4t**, l'utente sta compilando il modulo utilizzando l'app mobile Salesforce.

  - **Valuta altre risorse:** I riferimenti manuali alle variabili e alle formule vengono valutati solo sul server. Ciò significa che il valore che ha la risorsa quando la schermata viene visualizzata per la prima volta è il valore che avrà finché non si passa a un'altra schermata. Durante la navigazione, il runtime del flusso invia una richiesta al motore di flusso (il server) e restituisce i valori delle variabili manuali e delle formule più recenti. Se si prevede che la regola di visibilità si aggiorni quando l'utente passa attraverso una singola schermata (ad esempio, onblur), è necessario assicurarsi di fare riferimento solo ai valori degli altri componenti della schermata.

- Con OmniStudio è possibile **mostrare** o **nascondere** i componenti in modo condizionale impostando una proprietà **Visualizzazione condizionale**. Tuttavia, non è possibile aggiungere più di una proprietà Visualizzazione condizionale per un input.

**Stati di input condizionali**

Se è necessario controllare dinamicamente altre proprietà (ad esempio, se un campo è **obbligatorio**, **disabilitato** o **di sola lettura**), sono disponibili alcune opzioni. LWC offre un controllo completo e reattivo sullo stato di input. Con i componenti Flusso schermata reattivo è possibile controllare dinamicamente gli attributi dei componenti (ad esempio, **sola lettura**, **disabilitati** e **obbligatori**) per i componenti standard che lo supportano, mentre Omnistudio supporta l'intera gamma di attributi specifici dei componenti. Se le proprie esigenze richiedono Flusso e il componente non supporta uno stato attributo specifico, è possibile creare un componente LWC incorporabile per ottenere uno stato di input dinamico.

Se è necessario controllare dinamicamente qualsiasi altra proprietà (ad esempio, se un campo è **obbligatorio** o **di sola lettura**), utilizzare LWC a breve termine poiché si ha il controllo completo. Ciò è particolarmente vero se sono presenti requisiti personalizzati per la gestione di onblur o onclick.

**LWC reattivi nei flussi schermata**

Se si stanno creando componenti LWC che possono reagire e modificare altri componenti in un flusso schermata, consultare la guida [LWC Best Practices for Screen Flows](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows) per assicurarsi che i componenti si integrino con il motore di runtime del flusso e funzionino come previsto.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Gestione eventi standard (onblur, onfocus)</th>
<th colspan="1" rowspan="1">Gestione evento personalizzata</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">* Runtime standard OmniStudio non supporta Pub/Sub, ma supporta Windows postMessage</td></tr></table>

Per gli eventi personalizzati, se alcuni input (o l'intero modulo) devono comunicare con un altro elemento della pagina, LWC è l'unica opzione possibile.

- Per comunicare all'interno dello stesso albero DOM, utilizzare l'[interfaccia CustomEvent](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events).

- Per comunicare attraverso il DOM, utilizzare il [servizio Lightning Messaging](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel).

- Se Lightning Messaging Service [non è supportato](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) per il contenitore di destinazione, utilizzare il modulo pub/sub.

#### Risorse aggiuntive per Interaction Design

- Per informazioni più dettagliate, vedere [Comunicazione con eventi](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) e [Comunicazione attraverso il DOM](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub) nella _Lightning Web Components Dev Guide_.

- Per OmniStudio, vedere [Comunicazione con OmniScript da un componente Web Lightning.](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5)

### Styling

Per offrire la migliore esperienza utente, è importante assicurarsi che lo stile del modulo sia coerente con il resto dell'app o del sito in cui viene incorporato. Ciò può significare utilizzare modelli standard forniti da Salesforce o creare un CSS personalizzato che utilizza ogni pixel nella progettazione per offrire un aspetto più nitido.

#### Sostituzioni dello stile del flusso schermata

Gli amministratori possono configurare un insieme limitato di sostituzioni di stile schermata e componente (ad esempio, colori, bordi e aspetto dei pulsanti), per il contenitore schermata o per singoli componenti. Queste esclusioni vengono applicate dopo i temi e l'immagine aziendale, il che consente ai generatori di apportare modifiche visive mirate senza influire sul resto dell'applicazione.

Le esclusioni di stile sono destinate alle eccezioni visive localizzate (ad esempio, l'evidenziazione di una schermata di conferma o l'enfasi su un invito all'azione specifico; non sono un sistema di stile completo. Non offrono un controllo a livello CSS e non sono progettati per essere riutilizzati tra schermate o flussi.

Dal punto di vista architettonico, lo stile dovrebbe seguire questo ordine precedente:

1. **Temi e immagine aziendale:** Temi Lightning, set di immagini aziendali Generatore di esperienze o temi dei siti LWR

2. **Sostituzioni dello stile del flusso:** Rettifiche mirate della schermata o del componente

3. **Componenti personalizzati (LWC):** quando è necessario un controllo pixel-perfetto o modelli di progettazione riutilizzabili

L'uso di temi e sistemi di progettazione consente di garantire che lo stile rimanga coerente, scalabile e facile da mantenere nel tempo.

#### Domande da porre

- Quanto sono sofisticati lo stile desiderato e CSS?

- Hai bisogno di uno stile personalizzato e pixel-perfect o temi standard?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Stile diretto</th>
<th colspan="1" rowspan="1">Temi di organizzazioni e Generatore di esperienze</th>
<th colspan="1" rowspan="1">Stile pixel perfetto</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">* Solo FlexCard<br><br>**Alcuni attributi di stile possono essere configurati per i componenti schermata, ma non per le esclusioni CSS.</td></tr></table>

FlexCard è l'unico prodotto in questa guida che consente di controllare in modo dichiarativo lo stile e il layout dell'interfaccia utente che si sta creando all'interno dello strumento (ad esempio, margini e riempimento, tipografia, colori e così via).

I moduli e i flussi dinamici rispettano le funzioni dichiarative dei temi. Se è necessario un ulteriore controllo (oltre a quello supportato da [Temi Salesforce](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), [Set di immagini](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm) aziendali Experience Builder o [Siti Experience Cloud LWR](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm)), valutare una soluzione a livello di programmazione.

I team che utilizzano CSS hanno diverse opzioni:

- I flussi e i componenti LWC ereditano i [token di progettazione](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm).

- OmniScript e FlexCard includono il supporto del sistema di progettazione personalizzabile tramite [Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5).

- Con LWC è possibile scrivere i propri componenti e controllarne completamente HTML e CSS.

Ove possibile, si consiglia di utilizzare temi e sistemi di progettazione per garantire un aspetto uniforme in tutti i contenuti.

**Nota:** È possibile incorporare componenti Lightning nei flussi. Se hai bisogno di un controllo pixel-perfetto sull'aspetto del modulo, ma vuoi anche utilizzare gli altri vantaggi dei flussi (ad esempio, il modello di navigazione), puoi avere il meglio di entrambi i mondi! Lo stesso principio vale per OmniScript e FlexCard.

### Layout

La scelta di un buon layout è fondamentale per progettare moduli semplificati che consentano un'immissione rapida ed efficiente dei dati e aumentino l'integrità dei dati.

#### Domande da porre

- Come strutturare i layout dei moduli per ottimizzare le esperienze utente?

- Come si possono presentare i dati esistenti agli utenti in modo da semplificare l'immissione di nuovi dati nei moduli?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">2 colonne</th>
<th colspan="1" rowspan="1">4 colonne</th>
<th colspan="1" rowspan="1">Oltre 4 colonne</th>
<th colspan="1" rowspan="1">Blocchi ripetuti di dati</th>
<th colspan="1" rowspan="1">Contenitori scheda</th>
<th colspan="1" rowspan="1">Contenitori per fisarmonica</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="7" rowspan="1" style="border-right: 1px solid #d8dde6;">*Le schede possono essere utilizzate se si incorporano dati in una FlexCard in un OmniScript</td></tr></table>

I moduli dinamici supportano layout a due colonne che possono essere suddivisi in singole sezioni all'interno dei campi. Queste sezioni possono essere inserite all'interno di componenti (ad esempio, schede e fisarmoniche) per creare layout organizzati e facili da usare.

Il rendering dei flussi può essere eseguito anche con il componente **Sezione**. È possibile aggiungere fino a quattro colonne e un numero illimitato di sezioni nella schermata del flusso. Il componente sezioni è anche reattivo alla larghezza dello schermo, quindi funziona anche su schermi più piccoli. Consente di applicare la visibilità condizionale all'intera sezione, semplificando l'applicazione globale della visibilità a più campi all'interno della sezione. **Le sezioni flusso** supportano anche le intestazioni di colonna e offrono un'esperienza simile a quella di una fisarmonica in cui gli utenti possono comprimere l'intera sezione facendo clic sull'etichetta.

Gli OmniScript offrono una varietà di opzioni di layout per la visualizzazione di campi e dati. È possibile creare sezioni di dati con un massimo di 12 colonne, incluse le fisarmoniche comprimibili in modo condizionale.

Con LWC, è possibile utilizzare Lightningrecord-\[edit\|view]-form e il campo Lightning\[input\|output]-supportato per controllare il layout. Le uniche limitazioni del layout provengono da HTML e CSS. Il componente **Lightning-record-form** rispetta la configurazione della sezione nel layout di pagina associato (ad esempio, se una sezione è a due colonne nel layout di pagina, lo è anche nel componente).

### Traduzione

Se il modulo deve essere accessibile da utenti di regioni diverse o che parlano lingue diverse, è necessario assicurarsi che lo strumento utilizzato per crearlo soddisfi i requisiti di localizzazione.

**Nota:** Per i moduli in particolare, i requisiti di localizzazione in genere includono la traduzione di elementi di testo in altre lingue.

#### Domande da porre

- Il modulo verrà utilizzato in più di un paese o di una regione?

- Il testo nel modulo deve essere localizzato in altre lingue?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Etichette immesse nel Generatore</th>
<th colspan="1" rowspan="1">Etichette nel codice</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Non applicabile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*Solo intestazioni sezione campo</td></tr></table>

Se si localizzano campi personalizzati, i moduli dinamici rispettano le etichette tradotte. I moduli dinamici rispettano anche tutte le [etichette personalizzate assegnate alle etichette e agli attributi](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5) dei componenti nel Generatore di app Lightning.

Il flusso supporta la traduzione delle etichette rivolte agli utenti per tutti i componenti schermata standard e personalizzati tramite Area di lavoro traduzione.

È possibile localizzare etichette, testo della guida e messaggi di errore nei seguenti componenti schermata:

- Testo
- Area di testo lungo
- Numero
- Valuta
- Casella di controllo
- Pulsanti di opzione
- Elenco di selezione
- Elenco di selezione a selezione multipla
- Password gruppo caselle di controllo
- Data
- Data/ora

Non è disponibile un supporto per la traduzione incorporato per le azioni pronte all'uso (ad esempio, Invia email o Pubblica su Chatter), ma esiste una soluzione. Se si utilizza un'[etichetta personalizzata](https://help.salesforce.com/articleView?id=cl_about.htm) per definire le etichette tradotte, è possibile fare riferimento a tale etichetta personalizzata nell'azione o nel componente quando si configura in Flow Builder. A questo scopo, è necessario creare una formula del flusso che faccia riferimento all'etichetta personalizzata e quindi fare riferimento a tale formula nelle posizioni appropriate all'interno del flusso.

Gli OmniScript utilizzano etichette personalizzate per le traduzioni. Per ulteriori informazioni, consultare [questo documento](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm) per verificare che gli OmniScript siano pronti per l'uso in più lingue.

Per LWC, alcuni componenti di base ereditano automaticamente le traduzioni dei campi, del testo della guida e dei messaggi di convalida dell'oggetto associato se sono configurati nell'Area di lavoro traduzione (ad esempio, Lightning-record-form).

Se è necessario introdurre nuove etichette traducibili nel codice, le etichette personalizzate sono la soluzione ideale. Dichiarare l'etichetta personalizzata necessaria e quindi importarla nel componente dal modulo con ambito `@salesforce/label`.

## Considerazioni non funzionali

Utilizzare questa sezione per valutare i vincoli di sicurezza, qualità e operativi prima dell'implementazione.

### Sicurezza

La sicurezza è un argomento complesso e quando si tratta di creare moduli, ci sono una serie di considerazioni che potrebbero non essere ovvie. A livello di base, è necessario assicurarsi che il modulo venga eseguito nel contesto corretto e che gli utenti dispongano delle autorizzazioni necessarie per utilizzare i dati sottostanti. Oltre a ciò, si consiglia anche di adottare ulteriori misure per eliminare codice o URL potenzialmente dannosi dai campi di testo RTF, impedire a determinati utenti di accedere al modulo o imporre limitazioni ai tipi di posizioni in cui gli amministratori potrebbero incorporare il modulo in futuro.

Assicurarsi di documentare accuratamente i requisiti di sicurezza prima di scegliere uno strumento. Per ulteriori informazioni su questo tipo di documentazione, consultare il [modello di policy](/docs/architect/it-it/resources/guide/security-policy-template) Salesforce.

#### Domande da porre

- Il modulo deve controllare l'accesso dell'utente prima di eseguire determinate operazioni?

- È necessario disinfettare gli input degli utenti?

- Si desidera controllare chi può accedere al modulo?

- Si desidera controllare dove può essere incorporato il modulo?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Elevazione delle autorizzazioni utente</th>
<th colspan="1" rowspan="1">Controllo degli utenti autorizzati</th>
<th colspan="1" rowspan="1">Limitazione delle posizioni consentite</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">* Richiede Apex<br><br>**Anche se gli OmniScript non possono avere un insieme specificato di posizioni di destinazione, le FlexCard possono averlo.</td></tr></table>

#### Elevazione delle autorizzazioni utente

Quando un programma viene eseguito nel **contesto dell'utente**, Salesforce impone una serie di controlli dell'accesso, che includono la verifica della protezione a livello di campo, delle autorizzazioni CRUD e dell'accesso ai record in base alle regole di condivisione dell'organizzazione (ad esempio, gli utenti potrebbero eseguire un modulo di aggiornamento dei casi solo se hanno la possibilità di aggiornare i casi, la protezione a livello di campo appropriata e l'accesso al record in questione).

Che cosa accade se si desidera che gli utenti siano in grado di eseguire una determinata operazione quando utilizzano il modulo, ma non tramite qualsiasi altro modulo o interazione? È qui che entra in gioco il **contesto di sistema**!

**Contesto di sistema** consente di elevare le autorizzazioni di un utente per la durata della sessione (ad esempio, l'utente non deve aggiornare l'accesso all'oggetto Caso per completare correttamente il modulo di aggiornamento del caso). Questo è particolarmente utile per le comunità non autenticate. Anziché concedere agli utenti guest competenze potenzialmente pericolose, impostare il modulo in modo che venga eseguito nel contesto di sistema.

Contesto di sistema deve essere utilizzato solo quando è assolutamente necessario. Quando un modulo viene eseguito nel contesto di sistema, ogni operazione CRUD ignora i componenti di protezione e condivisione a livello di oggetto e di campo. Inoltre, il contesto di sistema non influisce su chi Salesforce considera l'_attore_ (il nome visualizzato nel campo **Ultima modifica di**). Per ogni operazione eseguita dal modulo (ad esempio, l'aggiornamento di un caso), l'_attore_ è l'utente corrente (anche se il modulo viene eseguito in un contesto diverso).

**Nota:** I moduli dinamici, gli OmniScript e i componenti LWC vengono sempre eseguiti nel contesto dell'utente e non è possibile ignorare questo comportamento.

I flussi schermata vengono eseguiti nel contesto dell'utente per impostazione predefinita, ma è possibile impostarli in modo che vengano eseguiti nel contesto di sistema. È possibile decidere se il flusso deve concedere l'accesso a tutti i dati o imporre l'accesso a livello di record.

- Se si incorpora un componente Lightning in un flusso eseguito nel contesto di sistema, il flusso non sovrascriverà il contesto del componente. Se è necessario ignorare i controlli dell'accesso degli utenti, utilizzare il flusso per eseguire queste operazioni e trasmettere i dati appropriati al componente Lightning o al suo esterno. Alcuni componenti pronti all'uso (ad esempio, Ricerca) non possono funzionare nel contesto di sistema.

- Se il flusso chiama azioni Apex, sono coinvolte altre differenze.

  - Se la classe Apex è impostata sulla _condivisione ereditata_, verrà eseguita nel contesto di sistema con la condivisione indipendentemente da come è impostato il flusso.

  - Se la classe non ha una dichiarazione di condivisione esplicita, verrà eseguita nel contesto di sistema senza condivisione indipendentemente da come è impostato il flusso.

  - Se la classe è impostata _con condivisione o senza condivisione_, sovrascriverà il contesto del flusso.

**Eseguire query sui record nel contesto di sistema con i siti Experience Cloud**

Se si esegue un flusso nel contesto di sistema in un sito Experience Cloud (soprattutto se non è autenticato), memorizzare solo campi specifici negli elementi **Ottieni record**. Quando si utilizza il flusso e si passano i risultati di un elemento **Ottieni record** in un sottoflusso, in un'azione invocabile o in un componente Lightning, tutti i campi di quell'oggetto possono essere ispezionati dagli strumenti per sviluppatori del browser. Nonostante le intenzioni, i campi potrebbero essere resi disponibili agli utenti di Experience Cloud. Per assicurarsi che vengano visualizzati solo i campi corretti quando è abilitato il contesto di sistema, specificare tali campi specifici negli elementi **Ottieni record**.

**Nota:** La logica OmniScript viene eseguita sul lato client, il che consente agli aggressori di modificare l'esecuzione prevista di un OmniScript e di visualizzare le risposte alle procedure di integrazione, ai data mapper e alle chiamate ai metodi Apex tramite gli strumenti per sviluppatori del browser. Quando si utilizza OmniScript, è importante eseguire la logica aziendale sul lato server (quando possibile) e implementare regole di convalida degli input per tutti i metodi Apex esposti tramite un'[annotazione @InvocableMethod](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5).

**Sanificazione degli input**

Per proteggere l'organizzazione dai malintenzionati, utilizzare la disinfettazione degli input. Si supponga di avere un input in un modulo accessibile pubblicamente che può essere mappato a un campo **RTF** dell'organizzazione. Può essere utile abilitare l'automazione che elimina qualsiasi codice HTML che potrebbe nascondere URL dannosi.

Non è l'ideale implementare la sanificazione a livello di modulo perché si può avere un numero qualsiasi di fonti che scrivono in questi campi. Per ovviare a questo problema, creare un **Flusso aggiornamento campo veloce** (prima del salvataggio) o utilizzare un **trigger Apex** esistente per eliminare o modificare qualsiasi potenziale HTML inserito nel modulo.

#### Procedure consigliate

- Consentire l'esecuzione dei flussi nel loro contesto predefinito (a meno che non sia necessario elevare l'accesso dell'utente corrente per un'operazione specifica).

- Evitare di eseguire flussi nel contesto di sistema per gli utenti guest. Creare insiemi di autorizzazioni con accesso limitato ai campi e assegnarli al profilo dell'utente guest Experience Cloud.

- Quando si eseguono query sui record nel contesto di sistema Esegui flussi nei siti Experience Cloud, memorizzare solo i campi necessari nell'elemento **Ottieni record** o **Azioni invocabili**.

- Se un flusso esegue una varietà di operazioni, tutte senza accesso elevato, utilizzare i sottoflussi per isolare le operazioni che devono essere eseguite nel contesto di sistema.

- Se si incorpora un modulo in una pagina Web esterna, può essere necessario mapparlo ai campi **RTF** per evitare potenziali attacchi di phishing. Per farlo, disinfettare gli input degli utenti per rimuovere l'HTML utilizzando un **Flusso aggiornamento campo** rapido o un **trigger Apex**.

#### Note aggiuntive

- OmniScript, FlexCard e LWC vengono eseguiti nel contesto dell'utente per impostazione predefinita.

- I componenti LWC vengono eseguiti nel contesto dell'utente per impostazione predefinita.

- I flussi vengono eseguiti nel contesto dell'utente, ma è possibile ignorarli utilizzando un controller Apex.

- Le operazioni eseguite nell'API dell'interfaccia utente vengono eseguite nel contesto dell'utente.

- Le operazioni eseguite con un controller Apex dipendono dalla classe specifica. Per eseguire queste operazioni in modalità di sistema, impostare la **classe Apex** su con o senza condivisione.

#### Controllo dell'accesso

Se è necessario controllare chi può accedere a un modulo, rivedere il contenitore in cui è incorporato il modulo (ad esempio, è possibile assegnare pagine Lightning in modo che siano disponibili per applicazioni, tipi di record o profili specifici). Se alcuni input sono sensibili, utilizzare le regole di visibilità per controllare ulteriormente gli elementi visualizzati a chi. Questa funzione si applica ai moduli dinamici e ai flussi schermata.

È possibile [restringere un flusso](https://help.salesforce.com/articleView?id=flow_distribute_security.htm) a profili o insiemi di autorizzazioni particolari (in modo simile alla classe Apex o alle pagine Visualforce). I flussi non sono soggetti a restrizioni per impostazione predefinita, il che significa che qualsiasi utente con l'autorizzazione utente **Esegui flussi** può accedervi.

Se si utilizza OmniStudio, è possibile configurare un [controllo autorizzazioni classe Apex](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5) che richiede agli utenti di avere accesso esplicito alla classe Apex che amministra le azioni remote dalle API OmniScript, Flexcard, Classic Card o REST.

**Nota:** I controlli delle autorizzazioni delle classi Apex si applicano solo alle classi Apex. Si consiglia inoltre di impostare le autorizzazioni a livello di profilo per [Procedure di integrazione e Data Mappers](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5).

#### Procedure consigliate per il controllo degli accessi

- Se si espone un flusso agli utenti guest, è necessario concedere al profilo utente guest solo l'accesso ai flussi di cui hanno assolutamente bisogno. È possibile aggiungere **Esegui flussi** ai profili utente guest; tuttavia, questa procedura può essere rischiosa.

- Prestare attenzione quando si utilizzano flussi che operano nel contesto di sistema. È consigliabile limitare questi flussi a un determinato insieme di utenti, poiché dispongono di un minor numero di controlli e bilanciamenti per proteggere i dati.

- Assicurarsi che qualsiasi OmniScript che esegue Apex all'interno di una comunità di utenti guest disponga **della condivisione** elencata nella definizione della classe Apex.

- Per i profili utente guest, assegnare solo le classi Apex che si desidera consentire agli utenti guest di chiamare. Seguendo questa procedura, si evita di esporre involontariamente ulteriore logica aziendale agli utenti guest.

Per i componenti LWC, è possibile controllare le assegnazioni delle autorizzazioni dell'utente corrente per verificare se dispone di una determinata autorizzazione standard o personalizzata. È possibile importare le autorizzazioni Salesforce dai moduli con ambito `@salesforce/userPermission` e `@salesforce/customPermission` direttamente in **JavaScript**. È anche possibile utilizzare Apex per controllare le autorizzazioni.

#### Comandi incorporati

I componenti LWC sono disponibili in una determinata posizione solo dopo essere stati aggiunti come [destinazione](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) valida (ad esempio, è possibile rendere un componente disponibile nelle pagine dei record e non disponibile come elemento della barra delle utilità).

Una volta attivato, un flusso schermata è disponibile in tutte le posizioni in cui sono supportati i flussi schermata. Flow Builder supporta più tipi di flussi con schermate. Il tipo più popolare è **Flusso schermata**, ma esistono alcuni altri tipi specializzati limitati a posizioni specifiche (ad esempio, l'**app Field Service Mobile** supporta solo i **flussi Field Service Mobile)**. Questo è simile ai **flussi Richiesta contatto**, supportati solo in Experience Cloud.

Indipendentemente dal tipo di flusso, la persona che crea il flusso non ha alcun controllo sulla posizione in cui è incorporato il flusso. I flussi sono disponibili in tutte le posizioni in cui è supportato quello specifico tipo di flusso.

Se si utilizza Salesforce Industries, viene visualizzato un piccolo avvertimento quando si tratta di OmniScript.Non è possibile specificare una destinazione per un OmniScript, ma è possibile specificare una destinazione per le FlexCard che si desidera incorporare.

### Automazione test interfaccia utente

In Salesforce sono disponibili diversi strumenti di automazione dei test end-to-end (ad esempio, [Salesforce UTAM](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam)) che consentono di simulare come un utente interagisce con i moduli. È possibile scrivere test per qualsiasi interfaccia utente standard o personalizzata, incluse le pagine Lightning e i flussi schermata.

**Nota:** Questi tipi di test non possono verificare gli output per i metodi in esecuzione. Tenere presente quanto segue quando si configurano i requisiti di automazione dei test dell'interfaccia utente.

#### Domande da porre

- Sono necessari test automatici per i moduli?

- Quali tipi di test si prevede di eseguire?

- Quale livello di dettaglio è necessario per le automazioni di test?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Test di unità</th>
<th colspan="1" rowspan="1">Automazione end-to-end</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Disponibile*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">* Richiede codice</td></tr></table>

**Considerare i requisiti di automazione dei test dell'interfaccia utente**

I **test di unità** offrono un'automazione e una convalida granulari in linea con i sistemi e gli strumenti standard del settore per i CD/informatici, che testano la logica aziendale, i controlli JavaScript e gli output di componenti specifici. Se si sceglie un approccio low-code, non sarà possibile creare test da soli; tuttavia, Salesforce testa rigorosamente tutte le offerte end-to-end.

Se i metodi del componente sono complessi, è possibile inserirli singolarmente inserendoli in file JavaScript dedicati. Ciò consente di importarli in un LWC e quindi in un **test Jest (ad esempio** importare { sort } da 'c/utils';).

È possibile utilizzare una soluzione senza codice di un ISV, creare una soluzione di automazione dei test personalizzata o utilizzare un framework di test open source (ad esempio, Selenium WebDriver o WebdriverIO) per l'automazione end-to-end. Queste soluzioni sono valide per tutte le interazioni dell'interfaccia utente Salesforce (ad esempio, un modulo dinamico in una pagina Lightning, un flusso schermata in una barra delle utilità o un flusso LWC in un flusso di azione rapida).

### Metriche

Dopo aver distribuito il modulo in un ambiente di produzione, è necessario assicurarsi che venga utilizzato in modo efficace. A seconda del caso d'uso, ciò può significare tenere traccia del numero di volte in cui il modulo è stato compilato fino al tempo trascorso dall'utente medio a compilare il modulo prima di inviare le proprie informazioni. È importante identificare i KPI tracciabili prima di scegliere uno strumento.

#### Domande da porre

- È necessario tenere traccia dell'utilizzo dei moduli?

- Quali KPI possono determinare se il modulo viene utilizzato in modo efficace?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Visualizzazioni pagina</th>
<th colspan="1" rowspan="1">Tempo trascorso sul modulo</th>
<th colspan="1" rowspan="1">Tracciamento del completamento del modulo</th>
<th colspan="1" rowspan="1">Monitoraggio della percentuale di successo</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Disponibile**</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile**</td>
<td colspan="1" rowspan="1">Disponibile*</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="5" rowspan="1" style="border-right: 1px solid #d8dde6;">*Disponibile quando è abilitato Runtime OmniStudio basato su pacchetto** Disponibile monitorando l'utilizzo delle pagine Lightning controllanti</td></tr></table>

Se è necessario tenere traccia dell'utilizzo e dell'adozione complessivi dei moduli, utilizzare strumenti low-code. I moduli dinamici e i flussi schermata sono tracciabili tramite rapporti personalizzati pronti all'uso. Tuttavia, i rapporti di tracciamento dei flussi schermata offrono una maggiore dettaglio. Se è necessario tenere traccia dell'utilizzo di LWC, la disponibilità pronta all'uso dipende da dove si utilizza LWC. Se si trova in una pagina Lightning, tutti gli elementi di tracciamento dell'utilizzo delle pagine Lightning disponibili sono validi anche per il componente LWC. Questo vale anche per i componenti LWC incorporati nei flussi.

I moduli dinamici non sono tracciabili immediatamente; tuttavia, è possibile tenere traccia dell'utilizzo della pagina Lightning controllante tramite gli [oggetti Utilizzo Lightning](https://help.salesforce.com/articleView?id=lex_usage_reports.htm). Per tenere traccia delle pagine Lightning standard, utilizzare il rapporto personalizzato **Utenti con Lightning Usage by Page Metrics**. Per le pagine Lightning personalizzate, utilizzare il rapporto personalizzato **Utenti con Lightning Usage by FlexiPage Metrics**.

I flussi possono aiutare a tenere traccia dell'adozione di moduli specifici. Utilizzare il **rapporto flusso di esempio: Schermata Flussi** per rispondere ai seguenti tipi di domande:

- Qual è la percentuale di completamento di questo modulo? Attualmente è ben adottato?

- Quanto tempo impiegano gli utenti a compilare questo modulo?

- Quale schermata viene completata più spesso dagli utenti?

- Con che frequenza gli utenti passano alle schermate precedenti?

- Con che frequenza si verificano gli errori?

Se il rapporto standard non soddisfa le proprie esigenze, è possibile clonarlo e apportare modifiche o Build Your Own report from scratch utilizzando il rapporto **Flussi schermata**.

Se si utilizza il runtime OmniScript basato su pacchetto, è anche possibile utilizzare [OmniStudio per Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5). Questo servizio tiene traccia di tutti i tipi di eventi (ad esempio, è possibile tenere traccia del tempo necessario per completare i passaggi in un OmniScript, che consente di identificare i miglioramenti del processo).

**Nota:** Non esiste un'opzione pronta all'uso per tenere traccia di un LWC che non sia incorporato in una pagina Flusso schermata, OmniScript o Lightning, ma è possibile creare una soluzione personalizzata utilizzando Apex.

### Imballaggio e distribuzione

Forse si ha familiarità con l'utilizzo delle serie di modifiche o del **DevOps Center** per distribuire la soluzione agli ambienti di test o alla produzione. Queste opzioni di distribuzione supportano completamente moduli dinamici, flussi e componenti LWC. Tuttavia, OmniStudio richiede uno strumento separato, l'Area di [lavoro IDX](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5).

#### Domande da porre

- Come si prevede di distribuire il modulo?

- Il modulo deve essere distribuito a più di un'organizzazione Salesforce?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Pacchetti gestiti di prima generazione (1GP)</th>
<th colspan="1" rowspan="1">Pacchetti gestiti di seconda generazione (2GP)</th>
<th colspan="1" rowspan="1">Pacchetti sbloccati</th>
<th colspan="1" rowspan="1">Serie di modifiche</th>
<th colspan="1" rowspan="1">DevOps Center</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile</td>
<td colspan="1" rowspan="1">Non disponibile*</td>
<td colspan="1" rowspan="1">Non disponibile*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata + LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td>
<td colspan="1" rowspan="1">Disponibile</td></tr>
<tr><td colspan="6" rowspan="1" style="border-right: 1px solid #d8dde6;">*Utilizzare Area di lavoro IDX per distribuire le soluzioni OmniStudio ad altre organizzazioni.</td></tr></table>

Se si è un ISV o un partner che prevede di inserire la soluzione in un pacchetto per la distribuzione su AppExchange, consultare Moduli dinamici, flussi e componenti LWC. Tenere presente che Omnistudio non supporta la creazione di pacchetti.

### Navigazione dal codice basso al continuo pro-codice

Questa guida ha lo scopo di illustrare le funzionalità e i livelli di personalizzazione disponibili tramite moduli dinamici, flussi schermata, OmniStudio e LWC.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-lowcode-continuum.png" alt="Low-Code to Pro-Code Continuum" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Di seguito è riportata una panoramica generale.

- Quando si tratta di costruire forme, LWC è l'opzione più robusta e personalizzabile, ma ha il minor numero di guardrail in atto. Ecco perché è fondamentale creare i propri componenti con [sicurezza](/docs/architect/it-it/well-architected/guide/trust.html) e [scalabilità](/docs/architect/it-it/well-architected/guide/reliability.html#scalability-and-capacity-planning).

- I moduli dinamici sono l'opzione meno flessibile, ma hanno molte meno possibilità di errori.

- Flusso e OmniStudio cadono leggermente nel mezzo. Sono più potenti dei moduli dinamici, ma non sono all'altezza del livello LWC. Tuttavia, hanno meno guardrail rispetto ai moduli dinamici e sono più difficili da violare rispetto al codice personalizzato.

È possibile che più strumenti soddisfino le proprie esigenze. In tal caso, la decisione dipende in ultima analisi dallo strumento più adatto al team. Per ulteriori informazioni sugli aspetti aggiuntivi da considerare, consultare le seguenti [Guide alle decisioni](/docs/architect/it-it/decision-guides) dell'architetto.

#### Domande da porre

- Quando si confrontano gli strumenti, è importante valutare quanta esperienza ha il team in relazione a ogni strumento?
- Quanti sviluppatori sono esperti di LWC o JavaScript?
- Ci sono sviluppatori nel team esperti in Flow Builder o che hanno espresso interesse a saperne di più?

Anche se non entreremo nei dettagli specifici, di seguito sono riportate alcune informazioni aggiuntive su come questi strumenti specifici sono correlati alle valutazioni che abbiamo trattato finora.

**Delega consegna**

Tenere presente che, anche se alcuni requisiti richiedono LWC, non è necessario che l'intera soluzione venga creata utilizzando LWC. È importante determinare come creare la soluzione in modo modulare. A questo scopo, è necessario identificare quali parti richiedono LWC codificato e quali no. Le parti che non richiedono LWC devono essere costruite utilizzando una soluzione low-code.

Quando si tratta di Flusso e LWC, esistono vari componenti (ad esempio, Componenti schermata reattivi e Flusso schermata) che possono essere sincronizzati tra loro nella stessa schermata per sbloccare nuovi strumenti per architetti, amministratori e sviluppatori. Gli sviluppatori possono ora creare componenti modulari mirati che possono essere riutilizzati in tutta l'organizzazione, il che contribuisce a migliorare la produttività dei team. Ciò consente agli sviluppatori di risparmiare tempo utilizzando un mix di componenti Flusso standard e personalizzati per ottenere un dinamismo della forma, che offre loro più tempo per concentrarsi sulla risoluzione di nuove sfide. Con l'introduzione dei componenti reattivi nel flusso, non c'è mai stato un momento più appropriato per combinare Flusso e LWC durante la creazione dei moduli.

**Proprietà a lungo termine e manutenibilità**

Se si sta creando un modulo a più fasi, iniziare con Flusso o un mix di Flusso e LWC. Se il team che gestisce il modulo è un team low-code, assicurarsi che la soluzione sia il più configurabile ed espandibile possibile per il pubblico a cui è destinata. Per migliorare la stabilità e la manutenibilità, è importante organizzare la soluzione in unità [componibili](/docs/architect/it-it/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity), indipendentemente dallo strumento scelto.

### Prestazioni

Le considerazioni sulle prestazioni relative a moduli dinamici, flussi schermata, OmniStudio o LWC si basano sul framework in cui sono alloggiate le tecnologie. Le tecnologie basate su LWC tendono a superare quelle basate su Aura. A causa di diverse funzionalità principali implementate in modo nativo nei motori Web (anziché in JavaScript tramite astrazioni del framework), LWC offre vantaggi in termini di prestazioni avanzate.

Quindi, come sfruttare questi vantaggi in termini di prestazioni per le nostre tecnologie di forma in Salesforce? Vediamo in dettaglio.

- I moduli dinamici (integrati nei metadati delle pagine Lightning) sono basati su una base di stack LWC, che ci consente di implementare diverse funzioni molto attese. Come ulteriore vantaggio in termini di prestazioni, i moduli dinamici utilizzano il rendering progressivo, che migliora il tempo di caricamento per le pagine con un numero elevato di campi.

- I flussi schermata sono basati su LWC. La maggior parte dei singoli componenti pronti all'uso sono stati ora convertiti in LWC, ad eccezione dei componenti **Caricamento file** e **Immagine**. Anche se il team Flusso ha convertito il client di runtime del flusso in LWC (e la maggior parte dei suoi componenti), i clienti devono comunque convertire i componenti schermata Aura in LWC. Tenere presente che Salesforce supporta solo i componenti LWC all'interno del framework **Componente reattivo** nei flussi schermata. Per ulteriori informazioni, consultare il modulo Trailhead [Lightning Web Components for Aura Developer](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers). Se stai pensando di creare un componente personalizzato per un flusso schermata (o qualsiasi altro contenitore), scegli LWC!

- Sono disponibili diverse versioni di OmniStudio. Se si è un cliente di lunga data, è possibile che si utilizzi **Angular**. Invitiamo tutti i nuovi clienti a utilizzare OmniScript e FlexCard basati su LWC. Invitiamo inoltre i clienti esistenti a migrare da Angular.

- LWC è basato su LWC.

## Risorse

<table><tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Moduli dinamici</strong></td>
<td colspan="1" rowspan="1"><a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_overview.htm&language=en_US&type=5">Suddivisione dei dettagli dei record con i moduli dinamici</a><br><a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Guida per il Generatore di app Lightning</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flusso schermata</strong></td>
<td colspan="1" rowspan="1"><a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">Utilizzo dei flussi schermata per interagire con gli utenti</a><br><a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">Automazione delle operazioni con i flussi</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>OmniStudio</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_omnistudio.htm&release=236&type=5">Omnistudio</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">OmniScript</a><br>- <a href="https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5">Applicazione desktop IDX Workbench</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">Newport Design System</a><br><a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">Personalizzazione di OmniScript e FlexCard con il sistema di progettazione Newport</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">- <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">Componenti Web Lightning</a><br><a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Guida per lo sviluppatore di componenti Lightning Aura</a><br><a href="https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers">Componenti Web Lightning per sviluppatori Aura</a></td></tr></table>

<!-- document id=43b55c7a92ef3970e996c3de33dff4ca3e13cf72b4da9e234309c8dcfb9082f7 url=/architect/current/it-it/decision-guides/guides/determining-agentic-vs-traditional-workflow-automation.md -->

# Determinazione dell'automazione dei flussi di lavoro agenti e tradizionali

Con Agentforce, le aziende possono ora sbloccare nuovi paradigmi per il lavoro automatico che non possono essere facilmente ridotti a regole. Queste nuove funzionalità includono la risoluzione degli intenti dei clienti da conversazioni non strutturate, il coordinamento dei processi multiparte tra i sistemi e la risposta alle condizioni operative in tempo reale. I flussi di lavoro agenti utilizzano l'automazione progettata per ragionare sui risultati anziché eseguire fasi predefinite. Per soddisfare questa domanda è necessaria una piattaforma che operi in tutta la gamma di complessità dell'automazione e un framework che mostri dove si adatta ogni funzionalità.

Agentforce combina Einstein Trust Layer, Motore di ragionamento, Script agente, Flusso, Apex e Data 360 in un'unica piattaforma unificata. Questa combinazione consente di gestire qualsiasi cosa, dalla semplice automazione dei trigger record alla complessa orchestrazione multi-agente per voce, visione, documenti e telemetria in tempo reale. MuleSoft estende questa piattaforma con il tessuto MuleSoft, la governance e l'orchestrazione tra sistemi necessari per connettere i flussi di lavoro degli agenti in un'azienda. Agentforce Operations (in precedenza Agentforce Supply Chain) applica queste funzionalità alle esigenze specifiche dei processi operativi e di produzione.

## Panoramica della guida

Questa guida introduce il framework Orchestration Density e le linee guida per prendere decisioni informate in questo panorama di prodotti. Il framework offre agli architetti un approccio ripetibile per selezionare gli strumenti e gli schemi giusti utilizzando i livelli di densità per i casi d'uso di automazione intelligente in Salesforce Platform.

## Prodotti nell'ambito

| Prodotto               | Descrizione                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Agentforce            | [Agenteforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5) è la piattaforma di Salesforce per creare e distribuire agenti AI. Utilizza il motore Atlas per attivare azioni basate su dati in tempo reale e dinamiche tramite Apex e Data 360.                                                                                                                                                                                                                                                                                                                           |
| Script agente          | Lo [script agente](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html) è un linguaggio dichiarativo specifico del dominio (DSL) utilizzato in Agentforce Builder per definire flussi di lavoro, regole aziendali e logica conversazionale per gli agenti                                                                                                                                                                                                                                                                                                                                         |
| Griglia Agentforce       | [Agenteforce Grid](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5) è un'interfaccia nativa AI, simile a un foglio di calcolo senza codice, per progettare e rendere operativi rapidamente flussi di lavoro AI su larga scala.                                                                                                                                                                                                                                                                                                                                                                     |
| Operazioni Agentforce | [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5) (precedentemente Agentforce Supply Chain) è una piattaforma di orchestrazione della gestione collaborativa dei flussi di lavoro basata sull'intelligenza artificiale progettata per semplificare e automatizzare i processi aziendali di back office.                                                                                                                                                                                                                                                                           |
| MuleSoft              | [MuleSoft](/docs/architect/it-it/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html) è una piattaforma completa, unificata e aperta per l'integrazione aziendale e la governance degli agenti. Attraverso la connettività basata su API e MuleSoft Agent Fabric e Agent Broker, funge da tessuto di integrazione, livello di governance e base di orchestrazione tra sistemi per la connessione dei flussi di lavoro degli agenti in tutta l'azienda                                                                                                                                                         |
| Flussi e Apex        | [Salesforce Flow](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5) è un potente strumento di automazione "point-and-click" per creare processi aziendali complessi visivamente senza codice. [Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm) è un linguaggio di programmazione proprietario orientato agli oggetti per la piattaforma Salesforce, simile a Java. È utilizzato per creare logica aziendale personalizzata, automatizzare i processi ed estendere le funzionalità CRM di base oltre gli strumenti dichiarativi. |

## Takeaway

Agentforce rappresenta un cambiamento fondamentale nel modo in cui viene svolto il lavoro in Salesforce Platform, dall'automazione basata su regole ai flussi di lavoro basati sul ragionamento. Per sbloccarne il potenziale, gli architetti devono prendere decisioni deliberate e informate su dove si inseriscono gli agenti, come sono composti e cosa orchestrano. I seguenti principi forniscono una linea guida ripetibile per le decisioni degli agenti.

- **Utilizzare lo strumento giusto per l'operazione corretta.** Utilizzare la densità di orchestrazione in base al percorso di esecuzione, al mix di modalità e alla complessità degli obiettivi per determinare la soluzione più adatta.

  - Utilizzare **l'automazione tradizionale** con flussi e Apex per il lavoro deterministico basato su regole, in cui il risultato può essere interamente definito da una serie di regole. L'automazione tradizionale si traduce in un percorso di esecuzione statico, che garantisce esiti prevedibili e ripetibili ed è fondamentale per la verificabilità. Scegliere l'automazione tradizionale per le operazioni che richiedono una stretta conformità e osservanza delle leggi.

  - Utilizzare **Agentforce Grid** per i casi d'uso di inferenza in blocco con complessità di orchestrazione da bassa a media. Questo schema utilizza il ragionamento generativo a turno singolo per classificare, calcolare il punteggio o riepilogare i dati in un volume elevato di record CRM, garantendo un'esecuzione ad alta produttività con possibilità di controllo immediata.

  - Utilizzare **Agentforce con script agente** per le operazioni con obiettivi aperti in cui l'esito desiderato è noto, ma non è possibile specificare il percorso di esecuzione esatto in fase di progettazione. Applicare questo schema ai requisiti che richiedono un ragionamento tramite determinismo guidato per garantire risultati prevedibili e tracciabili.

  - Utilizzare **Agentforce Operations** per semplificare e automatizzare i processi aziendali collaborativi con una gestione abilitata per l'intelligenza artificiale per i flussi di lavoro della supply chain.

- **Evitare di applicare flussi di lavoro agentici a casi d'uso a bassa densità di orchestrazione.** Valutare i compromessi tra automazione tradizionale e automazione agente per i requisiti funzionali e non funzionali. L'automazione tradizionale può offrire la scalabilità, l'affidabilità e le prestazioni richieste per il proprio caso d'uso.

- **Adottare un approccio** ibrido di automazione degli agenti, che combina Agentforce e l'automazione tradizionale con flussi e Apex, quando questa sinergia offre un valore maggiore rispetto all'uso dell'automazione tradizionale o agente separatamente.

## Punti decisione

L'sObject Salesforce è tradizionalmente il punto di ingresso principale per l'automazione dei record. Il sistema esegue una logica basata su regole, iniziando immediatamente dopo un evento DML (Data Manipulation Language), ad esempio insert, update o delete. Per scegliere tra gli strumenti per un'[automazione attivata da record](/docs/architect/it-it/decision-guides/guide/record-triggered.html) efficiente, abbiamo introdotto [la densità di](/docs/architect/it-it/decision-guides/guide/record-triggered#automation-density.html) automazione come mezzo per misurare la complessità del sistema, considerando la quantità di automazione, il volume dei record e l'espansione delle dipendenze. L'automazione tradizionale è limitata dall'ampio lavoro preliminare necessario per inserire i dati in un costrutto strutturato, conforme allo schema e basato su regole.

L'automazione agente aggiorna l'automazione tradizionale utilizzando l'intento dell'utente o dati non strutturati come input in cui è possibile applicare il ragionamento per raggiungere un risultato desiderato. Gli architetti devono decidere quando sfruttare il ragionamento probabilistico per i dati non strutturati multimodali e quando applicare flussi di lavoro guidati e deterministici per ridurre il rischio di esiti imprevedibili.

Quando il requisito passa dall'esecuzione di fasi basate su regole al ragionamento sui risultati, gli architetti necessitano di un framework standardizzato per valutare la profondità del ragionamento e la complessità degli obiettivi della soluzione proposta.

### Densità orchestrazione

La densità di orchestrazione è la misura della complessità all'interno di un flusso di lavoro agente. Tre fattori determinano la densità dell'orchestrazione: percorso di esecuzione, complessità degli obiettivi e mix di modalità. Mentre la densità di automazione misura la complessità fisica delle regole e del volume del sistema, la densità di orchestrazione misura la complessità di ragionamento del percorso dell'agente verso un obiettivo. Utilizzare la densità di orchestrazione composita per valutare i requisiti di progettazione e mappare allo standard architettonico.

- **Percorso di esecuzione**: Il grado in cui il flusso di lavoro può essere completamente definito e specificato in fase di progettazione. Un flusso di lavoro completamente specificato indica che il flusso di lavoro definisce ogni ramo e risultato che risulta in un percorso di esecuzione predeterminato. Un flusso di lavoro non specificabile ha un percorso che può emergere in fase di esecuzione attraverso il ragionamento rispetto a dati e istruzioni contestuali.
- **Complessità degli obiettivi**: Numero di esiti, punti decisionali e variazioni del percorso distinti che il flusso di lavoro deve risolvere in fase di esecuzione. Un flusso di lavoro a bassa complessità gestisce una singola operazione contenuta con un esito predeterminato, mentre un obiettivo ad alta complessità si estende su più fasi con obiettivi concorrenti o in conflitto con casi limite che non possono essere anticipati al momento della progettazione.
- **Modalità mix**: L'intervallo dei tipi di input che un flusso di lavoro deve elaborare e i moduli di output che deve produrre. Un mix di modalità bassa legge i campi CRM standard e genera aggiornamenti dei record. Una modalità media utilizza un mix di campi CRM strutturati e dati statici non strutturati, come i corpi delle email o le trascrizioni dei casi, per produrre aggiornamenti dei record. Un mix ad alta modalità consuma stream dinamici in tempo reale, ad esempio audio live o telemetria, e produce output multimodali in più sistemi esterni.

![Schema del framework Densità orchestrazione che mostra il percorso di esecuzione, la complessità degli obiettivi e gli assi del mix di modalità](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png)

### Sequenza fattoriale

La determinazione del livello di densità di orchestrazione appropriato richiede una valutazione sequenziale del percorso di esecuzione, della complessità degli obiettivi e del mix di modalità. Controllare prima il percorso di esecuzione. Se un percorso è completamente specificabile, iniziare con l'automazione tradizionale. L'utilizzo di una soluzione Agentic solo per orchestrare ed eseguire un percorso deterministico senza alcun requisito di ragionamento è un anti-schema. Questo provoca una proliferazione degli agenti (proliferazione eccessiva e non gestita degli agenti AI) e uno slop degli agenti (output generato da AI di bassa qualità e non necessario), con risultati di scarso valore.

Per i percorsi parziali o non specificabili, continuare a valutare la complessità degli obiettivi. Se la complessità dell'obiettivo è ben definita ma alcuni nodi del percorso richiedono valutazioni probabilistiche, valutare la possibilità di chiamare gli agenti da Flusso o Apex per soddisfare la specifica esigenza localizzata. Se invece le fasi del percorso di esecuzione richiedono uno o più requisiti basati sull'intelligenza artificiale in un insieme di record di grandi dimensioni, considerare Agentforce Grid. Griglia supporta flussi di lavoro a più fasi basati su foglio tramite più colonne AI o agente. È più adatto per l'esecuzione in blocco orientata alle righe. Questo approccio garantisce che il flusso di lavoro rimanga altamente performante e controllabile, invocando il ragionamento probabilistico solo dove il percorso non può essere predefinito.

Poiché la complessità degli obiettivi aumenta con le dimensioni concorrenti (ad esempio, la determinazione del pagamento di una richiesta di risarcimento assicurativo insieme al rilevamento delle frodi, al rispetto delle polizze e alla soddisfazione dei clienti) e i percorsi di esecuzione non specificabili, considerare Agentforce con script agente per il determinismo guidato nell'automazione. Per i casi d'uso tra aziende che coinvolgono Salesforce e sistemi di terze parti, utilizzare MuleSoft Fabric e Agent Broker.

Infine, valutare il mix di modalità per identificare le funzionalità tecniche necessarie, ad esempio la connessione multimodale o l'integrazione specializzata. Il mix di modalità funziona come selettore di capacità, non come calcolatore di densità. Aiuta a determinare l'infrastruttura necessaria per gestire la forma di input e output della soluzione, senza alterarne la logica di orchestrazione fondamentale.

### La matrice di selezione della densità

Utilizzare questa matrice per determinare lo standard architettonico per l'automazione degli agenti. Bilanciare l'automazione tradizionale e quella agente selezionando l'approccio che risolve il problema di automazione.

- **Automazione tradizionale (bassa densità di orchestrazione):** Utilizzare l'automazione tradizionale quando il processo viene attivato da una modifica del record, i dati sono strutturati, la logica è basata su regole e predeterminata e l'esito deve essere prevedibile (ad esempio, calcoli dei prezzi standard o creazione di operazioni automatiche).
- **Agenteforce Grid (densità di orchestrazione da bassa a media):** Utilizzare Griglia Agentforce quando è necessario elaborare operazioni AI in blocco in tutti i record esistenti (ad esempio, riepilogare gli ultimi 50 casi per ogni account in questo elenco, calcolare il punteggio del sentiment e mantenere il punteggio nel campo del caso).
- **Orchestrazione ibrida (automazione aumentata per ordini elevati):** Utilizzare l'orchestrazione ibrida per automatizzare un processo aziendale end-to-end complesso (ad esempio, l'elaborazione o l'orientamento delle richieste) che richiede le funzionalità di pianificazione dell'intelligenza artificiale ma l'integrità delle transazioni di Flusso e Apex.
- **Script agente Agentforce (alta complessità degli intenti):** Utilizzare Script agente quando il punto di ingresso non è strutturato (ad esempio chat, email e voce) e la risoluzione richiede una conversazione o la capacità di gestire richieste ambigue degli utenti.

| Livello di densità     | Percorso di esecuzione                                                                                                     | Complessità degli obiettivi                                                                               | Mix di modalità                                                                                                                | Standard architettonico                                                                                                                                          |
| :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Basso**           | Completamente specificabile                                                                                                  | **Basso:** Operazione singola contenuta con esiti predefiniti.                                     | **Modalità singola:** Lettura e scrittura di record Oggetto Salesforce strutturati.                                                 | Automazione attivata da record. Se il caso d'uso include almeno un'operazione di ragionamento, utilizzare Azioni agenti nel flusso di lavoro.                                              |
| **Bassa - Media** | Totalmente o parzialmente specificabile                                                                                     | **Basso:** Serie di fasi con esiti predefiniti.                                           | **Modalità miste:** L'input o l'output può avere un mix di dati strutturati e non strutturati.                                   | Utilizzare le inferenze batch griglia Agentforce per le operazioni in blocco nei record esistenti con l'azione agente.                                                                |
| **Medio**        | Completamente o parzialmente specificabile. Il percorso di esecuzione è predefinito ma le fasi intermedie richiedono un ragionamento.           | **Medio:** Serie di fasi basate su Apex o Flusso con esiti variabili.                        | **Modalità miste:** L'input o l'output può avere un mix di dati strutturati e non strutturati a basso volume.                        | Ibrido (Agentforce + Apex/Flusso): Utilizzare Agentforce per il ragionamento e la pianificazione ad alta densità, Agent Script per il determinismo guidato e Apex/Flow per l'orchestrazione. |
| **Alto**          | Parzialmente o non specificabile. L'obiettivo è predefinito, ma le fasi intermedie richiedono il contesto di esecuzione e l'intento dell'utente. | **Alto:** Più obiettivi concorrenti con esigenze di ragionamento elevate richiedono risultati deterministici. | **Modalità miste:** L'input o l'output può avere un mix di dati strutturati e non strutturati a volume elevato che arrivano in tempo reale. | Utilizzare Agent Script per bilanciare il controllo deterministico con il ragionamento. Utilizzare MuleSoft Agent Fabric per MCP di terze parti o A2A per la collaborazione complessa tra più agenti.  |

## Confronto dei prodotti

| Capacità                     | Automazione tradizionale (Flusso/Apex)                                                                                        | Griglia Agentforce                                                                                                                               | Agentforce                                                                                                                             | Agentforce con script agente                                                                                                                           |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Tipo di logica e determinismo**   | **Deterministica:** Utilizza la logica if-then-else fissa. Il percorso di esecuzione è prevedibile al 100% in base allo stato del record.           | **Misto:** Deterministica tramite fasi strutturate, mentre le singole fasi AI possono essere probabilistiche.                                                 | **Probabilistica:** Utilizza il ragionamento a turni multipli per determinare il percorso migliore verso un obiettivo.                                                 | **Determinismo guidato:** Utilizza il ragionamento per pianificare il percorso e consente l'esecuzione su percorsi nodo deterministici.                                              |
| **Velocità di consegna**          | **Consigliato (Flusso):** Gli strumenti visivi consentono la creazione rapida di logica attivata da record senza codice.                         | **Consigliato per l'automazione AI ripetitiva:** Il modo più rapido per applicare la logica AI agli insiemi di record esistenti senza creare nuovi flussi.           | **Consigliato:** Per la configurazione di agenti secondari (in precedenza Argomenti), istruzioni e mappatura delle competenze per un dominio o un problema specifico. | **Consigliato:** Per la mappatura avanzata dei grafici basati sullo stato e della logica dei bordi.                                                                            |
| **Modalità di input**             | **Consigliato solo per strutturato:** Limitato ai campi CRM e alle raccolte di record correlate.                                | **Consigliato per semistrutturato:** Elabora testo in blocco (descrizioni, trascrizioni) dai campi dei record.                                      | **Consigliato per Multimodale:** Elabora linguaggio naturale, voce e visione (dati non strutturati).                                    | **Consigliato per alta densità:** Sintetizza gli input multimodali con dati sullo stato del sistema in tempo reale.                                                     |
| **Profondità di ragionamento (pianificazione)** | **Non disponibile:** La logica è imperativa; non può "pensare" o pianificare i passi dinamicamente. Tuttavia, i dati possono essere inviati agli agenti. | **Basso:** Inferenza a fase singola applicata in un insieme di record (intelligenza artificiale batch).                                                                        | **Medio/alto:** Utilizza i loop di ragionamento (Ragione-Atto-Osserva) per risolvere intenti complessi.                                                  | **Governato:** Il ragionamento è limitato alla navigazione in un grafico predefinito degli stati di attività.                                                            |
| **Modularità e riutilizzabilità**   | **Consigliato:** Modulare per impostazione predefinita tramite sottoflussi e classi Apex.                                                        | **Limitato:** La logica è in genere legata alla riga della griglia specifica. Le impostazioni delle colonne e i flussi di lavoro basati su modelli possono essere riutilizzati nell'intero insieme di righe. | **Disponibile:** Le competenze (flussi/Apex) vengono riutilizzate in diversi agenti secondari (in precedenza Argomenti) e agenti connessi.                     | **Consigliato:** I nodi del grafico agente sono unità funzionali discrete e riutilizzabili.                                                                     |
| **Controllo transazioni e DML**  | **Consigliato (Apex):** Controllo completo su Savepoint, rollback e in blocco.                                       | **Disponibile:** Ogni riga viene elaborata in modo indipendente, quindi l'ambito di esecuzione è per record.                                                         | **Limitato:** Le azioni vengono eseguite come singole fasi disaccoppiate in una sessione.                                                         | **Consigliato:** Utilizza i nodi Flusso/Apex per fungere da anchor deterministici per tutti i DML. Il supporto del controllo delle transazioni distribuito tra gli agenti è limitato. |
| **Gestione ambiguità**         | **Non disponibile:** Richiede percorsi predefiniti. L'input imprevisto causa errori o errori statici.                        | **Limitato:** La qualità dell'output dipende dal rapido radicamento nel contesto. Il flusso di lavoro non può chiedere chiarimenti in modo interattivo.                             | **Consigliato:** Gestisce gli stati "sconosciuti" ponendo domande o selezionando competenze alternative.                                           | **Disponibile:** Utilizza i "nodi Fallback" per gestire gli errori di ragionamento o i timeout dei processi.                                                                 |
| **Visibilità e governance**    | **Consigliato:** Explorer trigger di flusso offre una mappa visiva di tutta la logica attivata da record.                               | **Disponibile:** L'interfaccia utente basata sulla griglia offre una chiara visibilità dei risultati a livello di riga e supporta la possibilità di controllare gli output.                           | **Disponibile:** I registri di monitoraggio offrono trasparenza sul modo in cui l'agente ha preso le decisioni.                                                 | **Richiede competenza:** Richiede il monitoraggio sia del registro di attraversamento grafico che del registro di inferenza LLM.                                                           |
| **Prestazioni e scalabilità**        | **Consigliato** Ottimizzato per l'elaborazione di record sincroni a volume elevato.                                                  | **Consigliato** Elabora in modo efficiente le operazioni AI in blocco su grandi volumi di dati.                                                                | **Sensibile alla latenza** Dipende dal tempo di inferenza; non adatto per aggiornamenti in blocco ad alta densità.                                           | **Moderato** Adatto per operazioni complesse a lungo orizzonte, ma ha un sovraccarico superiore.                                                                         |

## Casi d'uso

Questa tabella fornisce consigli generali più adatti a vari casi d'uso.

| Caso d'uso                                                    | Descrizione                                                                                                                                                                                                                                | Più adatta                                                                                                                                                                                                                           | Motivo                                                                                                                                                                                                                                                                                                                                                                                           |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Elaborazione dei record**                                       | Automazione attivata da un evento DML in un oggetto Salesforce strutturato in cui ogni ramo e risultato possono essere definiti completamente in fase di progettazione.                                                                                                  | Utilizzare il flusso attivato da record. Questa è un'automazione tradizionale a bassa densità.                                                                                                                                                           | Bassa densità di orchestrazione. Modalità singola (campi CRM strutturati) e un unico obiettivo contenuto con un percorso di esecuzione prevedibile e controllabile.                                                                                                                                                                                                                                                        |
| **Controllo transazionale con logica complessa**                | Automazione che richiede savepoint, rollback, conferme parziali o manipolazione dei dati in blocco per volumi elevati di record.                                                                                                                    | Utilizzare Apex per l'automazione deterministica tradizionale a bassa densità.                                                                                                                                                                    | Bassa densità di orchestrazione. Apex offre il controllo completo sull'integrità delle transazioni, la duplicazione di calcoli costosi e il caching a livello di piattaforma - funzionalità non disponibili in Flusso.                                                                                                                                                                                                         |
| **Logica moderatamente complessa all'interno di un processo strutturato**    | Automazione in cui il processo complessivo è basato su regole ma le singole fasi richiedono calcoli o manipolazioni dei dati che vanno oltre la capacità dichiarativa.                                                                                            | Utilizzare Flusso con Apex invocabile per la logica deterministica a bassa densità.                                                                                                                                                                  | Bassa densità di orchestrazione. Il flusso funge da livello di orchestrazione; Apex invocabile incapsula le operazioni di elevata complessità come componenti riutilizzabili e sicuri in blocco.                                                                                                                                                                                                                                          |
| **Elaborazione pianificata e temporale**                       | Automazione che deve essere eseguita in una data futura calcolata dinamicamente relativa a un evento record.                                                                                                                                           | Utilizzare l'automazione tradizionale (flussi attivati da record) per l'elaborazione deterministica a bassa densità.                                                                                                                                      | Bassa densità di orchestrazione. I [percorsi pianificati dei](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5) flussi forniscono la pianificazione, l'annullamento e la riprogrammazione automatici se i dati dei record cambiano - non disponibili in modo nativo nei trigger Apex.                                                                                                            |
| **Inferenza record in blocco**                                   | Applicando una singola fase di ragionamento AI in modo uniforme in un ampio insieme di record esistenti per generare una classificazione, un riepilogo o un punteggio.                                                                                                      | Utilizzare la griglia Agentforce per l'inferenza batch e per utilizzare le funzionalità agentiche ripetitive su larga scala.                                                                                                                                       | Media densità di orchestrazione. Inferenza batch con modalità singola su scala: l'agente legge i campi di record strutturati e scrive un output uniforme in ogni record. Bassa complessità degli obiettivi con un solo schema di inferenza ripetitivo.                                                                                                                                                                   |
| **Risoluzione input non strutturata**                           | Automazione in cui il punto di ingresso è una richiesta di linguaggio naturale, un'email o una conversazione che deve essere interpretata, classificata e risolta tramite il ragionamento.                                                                               | Utilizzare Agentforce per la risoluzione di input a media densità, basata sugli intenti e non strutturata.                                                                                                                                                   | Media densità di orchestrazione. Modalità mista: l'agente consuma input conversazionali non strutturati, quindi produce risposte testuali o aggiornamenti di record strutturati. L'obiettivo richiede la risoluzione dell'intento dell'utente in un insieme limitato di risultati.                                                                                                                                                            |
| **Logica moderatamente complessa all'interno di un processo probabilistico** | Automazione in cui il processo generale è basato su regole, ma le singole fasi richiedono funzionalità di intelligenza artificiale come il riepilogo o il recupero RAG.                                                                                                            | Utilizzare Flusso con Apex invocabile e modelli di prompt per i processi deterministici a bassa densità che richiedono funzionalità di intelligenza artificiale.                                                                                                               | Media densità di orchestrazione. Il flusso funge da livello di orchestrazione mentre [i modelli di](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api) prompt, l'[agente dell'assistenza Agentforce e](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5) l'agente dipendente Agentforce sono esposti come azioni invocabili. |
| **Orchestrazione guidata del processo**                            | Automazione estesa a flussi di lavoro a più fasi in cui il completamento di un'azione attiva azioni aggiuntive                                                                                                                                  | Utilizzare [Script agente con azioni](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining) per percorsi di esecuzione ad alta densità e non specificati che richiedono un'orchestrazione guidata del processo. | Alta densità di orchestrazione - modalità mista tra input e output. Risultati concorrenti e casi limite che non possono essere completamente anticipati in fase di progettazione. Agent Script fornisce un determinismo guidato.                                                                                                                                                                                                  |
| **Orchestrazione di processi tra sistemi**                      | Automazione che coordina un processo aziendale in più fasi in più sistemi di backend in cui nessun sistema è titolare del flusso end-to-end                                                                                                      | Utilizzare l'API MuleSoft Process con Agent Broker per l'orchestrazione di processi tra sistemi di media e alta densità.                                                                                                                          | Elevata densità di orchestrazione: le API dei processi incapsulano una complessa logica aziendale a più fasi in modo che gli agenti non debbano comprendere l'orchestrazione di operazioni come l'elaborazione degli ordini o i controlli dell'inventario. [Agent Broker](https://www.mulesoft.com/ai/agent-broker) sequenzia e richiama dinamicamente gli agenti e gli strumenti richiesti da un unico obiettivo di linguaggio naturale.                               |
| **Astrazione del sistema di backend**                              | Orchestrazione in cui gli agenti devono interfacciarsi con sistemi legacy, database o piattaforme SaaS di terze parti prive di connettività Agentforce nativa.                                                                                            | Utilizzare MuleSoft con il connettore MCP per avvolgere i sistemi legacy e fornire il contesto del modello.                                                                                                                                              | Media densità di orchestrazione. Le API di sistema offrono un'interfaccia sicura e astratta ai sistemi di record, garantendo che i flussi di lavoro degli agenti siano separati dalla complessità del backend. Il connettore MCP trasforma le applicazioni MuleSoft in server compatibili con MCP per un'immediata individuazione e invocazione.                                                                                                  |
| **Elaborazione di documenti a volume elevato e gestione delle eccezioni**  | Automazione che legge, interpreta e riconcilia i documenti strutturati e semi-strutturati in entrata con i record esistenti su larga scala, gestendo varianze, corrispondenze parziali ed eccezioni con un intervento manuale appropriato.          | Utilizzare Agentforce Operations per l'elaborazione di documenti a volume elevato a media densità e basata sugli intenti.                                                                                                                                       | Media densità di orchestrazione con modalità di input semi-strutturata. Complessità degli obiettivi determinata dalle regole di corrispondenza, dai percorsi delle eccezioni e dalle soglie di approvazione per documento. Richiede un ragionamento per record, non un'inferenza a turno singolo uniforme.                                                                                                                                                                |
| **Orchestrazione multi-agente tra fornitori**                | L'automazione richiede la collaborazione tra agenti specializzati creati su piattaforme o fornitori diversi.                                                                                                                                      | Utilizzare MuleSoft con connettore A2A e tessuto agente per l'orchestrazione multi-agente in sistemi diversi.                                                                                                                           | Densità di orchestrazione medio-alta. Il connettore A2A consente flussi di lavoro multi-agente peer-to-peer con governance e affidabilità di livello aziendale, indipendentemente da dove viene creato o ospitato ogni agente.                                                                                                                                                                                             |
| **Conversione da documento non strutturato a flusso di lavoro**            | Automazione in cui i processi operativi definiti in fonti non strutturate (POS, documenti delle regole dei fornitori o diagrammi di processo) devono essere convertiti in flussi di lavoro agenti eseguibili senza codifica manuale.                                     | Utilizzare Agentforce Operations per convertire documenti non strutturati emergenti ad alta densità in flussi di lavoro.                                                                                                                                | Alta densità con un mix di modalità elevato in input. Inserisce PDF, documenti Word e diagrammi basati su immagini. Complessità dell'obiettivo determinata dall'ambito e dalla ramificazione del processo inserito. Il percorso di esecuzione non può essere specificato in fase di progettazione.                                                                                                                                                           |
| **Orchestrazione multipartita**                               | Automazione che si estende all'orientamento coordinato di parti esterne - raccolta dei dati richiesti, verifica della conformità, gestione delle approvazioni e aggiornamento dei sistemi di registrazione in molte piste di orientamento simultanee.                         | Utilizzare Agentforce Operations per un'orchestrazione multipartita da media a alta densità, basata sugli intenti a emergente.                                                                                                                         | Più fasi di verifica e approvazione interdipendenti devono essere risolte in sequenza prima del completamento dell'orientamento. Il mix di modalità include record strutturati, documenti non strutturati e comunicazioni esterne.                                                                                                                                                                                 |
| **Intervento asset predittivo**                           | Automazione in cui un motore predittivo inserisce la telemetria in tempo reale per identificare le condizioni di guasto imminenti e attiva una risposta coordinata di back-office a più fasi.                                                                      | Utilizzare Agentforce Operations e Agentforce for Manufacturing per l'intervento predittivo degli asset ad alta densità.                                                                                                                         | Data Cloud gestisce la telemetria IoT ad alta modalità e il rilevamento delle anomalie. Agentforce Operations quindi orchestra il flusso di lavoro di back-office in modalità media, gestendo i record di Field Service, i dati di inventario e le comunicazioni con i clienti, risolvendo il processo end-to-end.                                                                                                                                |
| **Gestione della comunicazione dei fornitori su larga scala**           | Automazione che gestisce le comunicazioni strutturate e semi-strutturate in corso in un'ampia base di fornitori, inclusi conferme d'ordine, modifiche delle date di consegna e notifiche delle eccezioni.                                            | Utilizzare Operazioni Agentforce per le inferenze batch per la gestione della comunicazione di un fornitore a media densità.                                                                                                                              | Se le comunicazioni sono uniformi tra i fornitori, utilizzare Agentforce Grid per l'elaborazione in batch. Quando le risposte richiedono un ragionamento contestuale in base alla relazione con il fornitore, inoltrarle al livello medio con Agentforce Operations.                                                                                                                                                                         |
| **Gestione dei lead (alta velocità, instradamento intelligente)**       | Automazione che inserisce risposte di marketing in tempo reale, utilizza il calcolo del punteggio AI e l'arricchimento di Data Cloud per la qualifica e utilizza flussi per l'assegnazione intelligente di sub-minuti e l'instradamento di lead di alta qualità al team di vendita appropriato. | Utilizzare Automazione tradizionale (flusso) + Data Cloud e AI per l'instradamento intelligente dei lead a media densità ad alta velocità.                                                                                                                     | Richiede un'alta velocità (Velocità al lead < 1 min) e un instradamento complesso basato sui dati basato sul punteggio dei lead AI, sul livello di processo e sulla cronologia delle attività. Utilizza i flussi per una logica di assegnazione deterministica rapida, ottimizzata dall'intelligenza artificiale probabilistica e da Data Cloud per la qualifica e l'arricchimento dei lead.                                                                                                                   |
| **Lead Nurturing**                                          | Nutre i lead con punteggio basso finché non sono pronti per una conversazione di vendita.                                                                                                                                                                    | Utilizzare Lead Nurturing Agent per indirizzare e migliorare i lead di bassa qualità per l'automazione a densità medio-alta.                                                                                                                      | Invia email personalizzate multi-touch basate sui dati dei lead e sulle storie di successo dei clienti. Gestisce le risposte tramite email e utilizza Flusso per la consegna.                                                                                                                                                                                                                                                  |
| **Qualifica lead in entrata**                              | Qualifica e alimenta autonomamente i lead in entrata con il punteggio più alto.                                                                                                                                                                            | Utilizzare Lead Nurturing Agent per qualificare e coinvolgere i lead.                                                                                                                                                                              | Esegue email multi-touch in uscita, prenotazione di incontri, domande e risposte sui prodotti e gestione delle obiezioni. Può operare in modalità "Invia come venditore", inviando email tramite il titolare del lead assegnato.                                                                                                                                                                                                              |

## Mappatura dei casi d'uso

![Utilizza il diagramma di mappatura dei casi che mostra vari scenari di automazione tra i livelli di densità dell'orchestrazione](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png)

## Considerazioni non funzionali

**Latenza**

I flussi attivati da record sincroni vengono eseguiti all'interno della transazione della piattaforma e completati in millisecondi. Il tempo di inferenza Agentforce dipende dal Motore di ragionamento Atlas e viene scalato con la profondità di ragionamento e la complessità della modalità. Agentforce non è adatto per l'elaborazione di record sincroni a volume elevato in cui la latenza è un vincolo principale.

**Costo**

Il costo di ragionamento di un flusso di lavoro agente deve essere giustificato rispetto al valore aziendale del risultato. Per le operazioni a volume elevato e bassa densità di orchestrazione in cui esiste un percorso deterministico, l'automazione tradizionale o la griglia Agentforce potrebbero essere più economiche di un flusso di lavoro agente end-to-end. Assicurarsi che il design soddisfi lo schema di tentativo corretto con limiti massimi e interruttori espliciti. Questo guardrail limita il rischio di superamento dei costi del compounding associato alla lavorazione in blocco.

**Limitazioni del governatore**

Valutare i flussi di lavoro agenti a volume elevato rispetto ai limiti giornalieri della piattaforma per l'esecuzione asincrona. Le operazioni batch di Griglia Agentforce seguono i limiti delle transazioni standard della piattaforma. Per l'automazione che coinvolge oggetti Salesforce, considerare il numero totale giornaliero di operazioni DML, poiché Salesforce impone sia la gestione delle risorse condivise in un ambiente multi-tenant, sia i [limiti del governatore](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm?_ga=2.244979463.387753096.1774889755-1655953164.1772207150) per evitare che le automazioni incontrollate monopolizzino le risorse condivise.

**Controllabilità e conformità**

L'automazione tradizionale produce percorsi di esecuzione completamente controllabili tramite Explorer trigger di flusso e registri Apex. Gli schemi end-to-end o ibridi basati su Agentforce generano registri di ragionamento che forniscono trasparenza nel processo decisionale degli agenti, ma richiedono esperienza per essere interpretati. Il determinismo guidato tramite script agente è lo schema consigliato per i settori regolamentati in cui la piena verificabilità dell'esecuzione è un requisito di conformità.

**Inoltro al livello** superiore

I flussi di lavoro agenti che operano ad alta densità dovrebbero incorporare l'approvazione esplicita da parte delle persone o porte di inoltro al livello superiore per le azioni con conseguenze irreversibili, ad esempio transazioni finanziarie, sottomissioni normative o impegni dei fornitori. I controlli condizionali di script agente forniscono il meccanismo per imporre questi cancelli in modo deterministico all'interno di un flusso di lavoro altrimenti agente.

## Procedure consigliate correlate

**Dare priorità alla semplicità nella progettazione dell'orchestrazione**. Iniziare dal livello minimo di orchestrazione che può raggiungere l'obiettivo, convalidarlo sotto carico reale e ripetere. Ogni ulteriore agente, passaggio di consegne o dipendenza nella catena introduce una nuova superficie che può produrre un comportamento incoerente.

Nel percorso di esecuzione specificabile, in corrispondenza dei nodi in cui è richiesto il ragionamento, iniziare a incorporare un agente. Seguire le procedure consigliate per la creazione di agenti in Agentforce. Evitare di imballare numerosi agenti secondari (in precedenza "argomenti") e non gonfiare mai le istruzioni. Gli agenti distribuiti nei casi d'uso di automazione possono permettersi di essere snelli, poiché non sono l'unica interfaccia. Scegliere la primitiva giusta per il concatenamento. Uno schema di orchestrazione (delega) ha un controllo più stretto sulla sequenza di esecuzione e può delegare operazioni secondarie a specialisti. Evitare gli schemi coreografati (handoff). Se è necessario implementare una progettazione di trasferimento, fornire all'agente destinatario l'obiettivo, il contesto e lo stato in modo che possa ottimizzare gli obiettivi globali anziché locali.

**Evitare azioni o strumenti estesi**. Le azioni sono il luogo in cui viene realizzato il ragionamento degli agenti e la loro progettazione determina se producono risultati affidabili o errori. Ogni azione deve restituire una risposta strutturata e osservabile che l'agente AI può utilizzare per pianificare il turno successivo della conversazione.

Avere più di un'azione (e costrutti di output diversi) per eseguire la stessa operazione degrada la capacità dell'agente di ragionare o scegliere lo strumento giusto per il lavoro. Può causare la perdita di sfumature da parte dell'agente. La sovrapposizione delle definizioni delle azioni rischia di generare una classificazione errata. Assicurarsi che la libreria di azioni sia controllata, con versione e conforme all'ambito Subagente (in precedenza Argomento).

**Definire gli obiettivi osservabili.** Definire l'obiettivo come risultato osservabile, non come semplice procedura. Un obiettivo vago invita l'agente alla deriva. Aumentare con un percorso di esecuzione specificabile. Utilizzare Grafico agente con ragionamento ibrido per modellare l'obiettivo come nodo grafico con stato esplicito. Il runtime tiene traccia della posizione corrente dell'agente nel flusso di lavoro e la ripristina dopo gli input tangenziali; non perderà l'obiettivo quando riceve informazioni aggiuntive nella finestra di contesto.

**Testare e valutare**. Implementare un framework di test e valutazione efficace per convalidare il ragionamento dei nodi probabilistici e l'output delle automazioni agentiche. Verificare i percorsi di esecuzione rispetto a un percorso risultato previsto per assicurarsi che il modello arrivi all'esito corretto. Impedire errori silenziosi in cui un agente segnala falsamente l'esito positivo o entra in un loop infinito o non recuperabile affermando i risultati nelle fasi di esecuzione. Utilizzare il [tracciamento delle sessioni](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5) per esaminare le interazioni passo-passo, le esecuzioni dei motori di ragionamento, le azioni, gli input/output dei prompt e dei gateway, i messaggi di errore e le risposte finali.

## Risorse

<table>
  <thead>
    <tr>
      <th scope="col">Agentforce</th>
      <th scope="col">Automazione tradizionale</th>
      <th scope="col">Integrazione</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5">Agenteforce</a></li>
          <li><a href="https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html">Script agente</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5">Griglia Agentforce</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5">Operazioni Agentforce</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5">Agente dell'assistenza Agentforce e agente dipendente</a></li>
          <li><a href="https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining">Script agente con azioni</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5">Flusso Salesforce</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5">Percorsi pianificati flusso</a></li>
          <li><a href="https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api">Modelli di prompt</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="/docs/architect/it-it/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html">MuleSoft</a></li>
          <li><a href="https://www.mulesoft.com/ai/agent-broker">Broker agente</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

**Informazioni sull'autore**

Arvind Palaniswamy è un architetto di ingegneria del software presso lo Studio del Chief Architect, Well-Architected Team. Gli piace inquadrare i sistemi complessi nelle loro forme più semplici utilizzando i principi primi. Conosce l'ingegneria, le operazioni e il business attraverso decenni di esperienza e l'istruzione MS / MBA (Kellogg).

<!-- document id=814d0047cf6979d713164aa31dc981ebcf1d004d0fcf02f647d4a3fdbd71fd03 url=/architect/current/it-it/decision-guides/guides/async-processing.md -->

# Elaborazione asincrona

Utilizzare questa guida per scegliere l'approccio di elaborazione asincrona Salesforce corretto per ogni caso d'uso.

## Panoramica della guida

Questa guida consente di valutare l'approccio corretto per i requisiti di elaborazione asincrona nella piattaforma Salesforce. Spiega ogni approccio, descrivendone i punti di forza e le limitazioni. La maggior parte degli approcci sono allineati a una funzione del prodotto, ma alcuni utilizzano più funzioni in coordinamento. La guida include casi d'uso per evidenziare quando utilizzare ogni approccio.

L'elaborazione asincrona offre due vantaggi principali per l'architettura. Innanzitutto, aumenta la scalabilità perché i processi asincroni hanno limiti governor più elevati. In secondo luogo, le richieste asincrone vengono eseguite nei propri thread in modo che gli utenti possano eseguire altro lavoro mentre le operazioni asincrone vengono eseguite in background.

Tenere presente che questa guida si concentra esclusivamente sulla scelta di una tecnologia di elaborazione asincrona all'interno di Salesforce Platform. Altre risorse utili per il processo decisionale sono elencate nella [sezione Risorse](#risorse).

## Prodotti nell'ambito di questa guida

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td><a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Lightning Platform</a> è una piattaforma completa basata sull'intelligenza artificiale che unifica dipendenti, agenti autonomi dell'intelligenza artificiale, dati aziendali e applicazioni in un unico sistema affidabile per migliorare la produttività e l'esperienza dei clienti. Consente la creazione di un'"azienda autentica" collegando le app Customer 360, Data Cloud e Slack per l'automazione end-to-end.</td>
    </tr>
  </tbody>
</table>

Questo documento non tratta le tecnologie in altri ecosistemi come MuleSoft, Informatica, Commerce Cloud, Tableau e Marketing Cloud.

## Takeaway

- **Prima di utilizzare l'elaborazione asincrona, assicurarsi che i casi d'uso corrispondano allo schema.** Gli schemi asincroni non hanno SLA, sono soggetti a più meccanismi governor, possono avere limiti di capacità definiti in base alle licenze e possono causare ritardi di elaborazione a causa della natura finita delle risorse allocate all'infrastruttura asincrona all'interno di Salesforce Platform. Tenere presenti le seguenti limitazioni quando si utilizza l'elaborazione asincrona in scenari in cui un utente richiede una risposta dal sistema prima di poter continuare a lavorare.
- **L'elaborazione asincrona con Salesforce non è una soluzione per esigenze di scalabilità infinite.** Salesforce Platform non scala all'infinito e gli schemi asincroni sono soggetti a limitazioni. L'elaborazione asincrona utilizza i thread, che contengono le informazioni contestuali necessarie a una CPU per eseguire un flusso di istruzioni. I thread possono essere eseguiti in parallelo. Il numero di thread disponibili in qualsiasi CPU è limitato, quindi la piattaforma dispone di meccanismi per utilizzare i thread disponibili nel modo più efficiente possibile. Il [meccanismo di controllo](/docs/architect/it-it/fundamentals/guide/async-fundamentals#controllo-del-flusso) del flusso della piattaforma evita che le organizzazioni consumino troppi thread e influiscano negativamente sulle altre organizzazioni. L'[algoritmo di fair use](/docs/architect/it-it/fundamentals/guide/async-fundamentals#utilizzo-equo) della piattaforma controlla anche il numero di thread disponibili per un'organizzazione per ogni tipo di messaggio specifico.
- **Tenere conto degli eventi che possono causare carichi estremi.** Quando si progettano processi asincroni, assicurarsi che siano in grado di gestire in modo prevedibile picchi e pause del carico di lavoro. Considerare il modo in cui l'implementazione gestisce gli eventi imprevisti, ad esempio le interruzioni di corrente, e progettare misure di protezione che riducono la perdita di dati o di funzionalità.

## Confronto dei prodotti

Questa tabella descrive gli strumenti disponibili per l'elaborazione asincrona con Salesforce. Fare riferimento a questa tabella per esaminare le principali caratteristiche di ogni strumento durante il processo decisionale. Vedere [Casi d'uso](#casi-duso) e [punti decisionali](#punti-decisione) per informazioni sulla scelta degli strumenti più adatti alla propria architettura.

<table style="border-color:white;overflow-x:scroll;">
  <thead>
    <tr>
      <th>Approccio</th>
      <th>Descrizione</th>
      <th>Competenze richieste</th>
      <th>Licenze e limiti</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Apex in area</b> di attesa</td>
      <td>Utilizzare per processi che comportano operazioni di database di lunga durata o chiamate a servizi Web esterni. Queueable Apex offre funzioni come ID processo, supporto per tipi non primitivi e concatenamento dei processi.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Il numero di licenze può aumentare i limiti.</a></td>
    </tr>
    <tr>
      <td><b>Batch Apex</b></td>
      <td>Creare processi complessi e di lunga durata che coinvolgono milioni di record suddividendo l'insieme di record ed elaborandolo in blocchi gestibili.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Il numero di licenze può aumentare i limiti.</a></td>
    </tr>
    <tr>
      <td><b>Apex pianificato</b></td>
      <td>Eseguire Apex a un'ora pianificata definita da un'espressione cron. Sebbene l'atto di pianificare Apex tramite l'espressione cron sia un processo asincrono, il codice sottostante viene eseguito in modo sincrono all'avvio del processo.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Il numero di licenze può aumentare i limiti.</a></td>
    </tr>
    <tr>
      <td><b>Chiamate continuazione Apex</b></td>
      <td>Eseguire chiamate dai metodi Apex in esecuzione in un contesto di transazione sincrona.</td>
      <td>Pro-code</td>
      <td>No</td>
    </tr>
    <tr>
      <td><b>Percorso asincrono (flussi attivati da record)</b></td>
      <td>Eseguire un'operazione che si desidera eseguire nel proprio tempo. Evitare errori DML misti che si verificano quando si aggiorna un valore di un record correlato che non fa parte del record che ha attivato un flusso.</td>
      <td>Basso codice</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Il numero e il tipo di licenze possono aumentare i limiti.</a></td>
    </tr>
    <tr>
      <td><b>Percorso pianificato (dopo l'impegno dei flussi)</b></td>
      <td>Eseguire l'esecuzione in un momento pianificato dinamicamente dopo un evento di attivazione, ad esempio quando viene creato, aggiornato o eliminato un record.</td>
      <td>Basso codice</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Il numero e il tipo di licenze possono aumentare i limiti.</a></td>
    </tr>
    <tr>
      <td><b>Flussi pianificati</b></td>
      <td>Eseguire un flusso in background a un'ora specificata e con una frequenza ripetuta (giornaliera, settimanale o una volta) per eseguire azioni su un batch di record.</td>
      <td>Basso codice</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Il numero e il tipo di licenze possono aumentare i limiti.</a></td>
    </tr>
    <tr>
      <td><b>Trigger evento piattaforma</b></td>
      <td>Associare liberamente Salesforce a sistemi esterni e comunicare tra componenti asincroni all'interno di Salesforce Platform.</td>
      <td>Low-code + Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm">Per i casi d'uso di eventi piattaforma a volume elevato è necessaria una licenza aggiuntiva</a></td>
    </tr>
    <tr>
      <td><b>Modifica acquisizione dati</b></td>
      <td>Acquisire ed elaborare gli eventi di modifica in modo asincrono dopo la conferma della transazione del database.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm">Per scalare al di sopra dell'allocazione di base è necessaria una licenza aggiuntiva.</a></td>
    </tr>
    <tr>
      <td><b>Bulk API</b></td>
      <td>Inserire, aggiornare, inserire con aggiornamento, eseguire query o eliminare molti record in modo asincrono ed elaborare i risultati in un secondo momento.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.260.0.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_bulkapi.htm">Ci sono dei limiti.</a></td>
    </tr>
    <tr>
      <td><b>Azioni Lightning</b></td>
      <td>Consente alle pagine Lightning di interagire con il server senza costringere gli utenti ad aggiornare completamente la pagina.</td>
      <td>Basso codice</td>
      <td>No</td>
    </tr>
  </tbody>
</table>

## Punti decisione

Questa tabella contiene una panoramica dei punti da considerare quando si decide quale strumento asincrono utilizzare.

<table>
  <tbody>
    <tr>
      <td><b>Competenze richieste</b></td>
      <td>Alcuni degli strumenti descritti in questa guida richiedono codice, mentre altri possono essere configurati in modo dichiarativo. Quando si valutano le opzioni disponibili, pensare alle competenze dei membri del team. Tenere presente che anche se gli sviluppatori sono disponibili per l'implementazione iniziale (ad esempio tramite un partner di implementazione), potrebbe essere necessario modificare le soluzioni in futuro. Se il team di manutenzione non dispone di sviluppatori, un'opzione low-code può essere più adatta.</td>
    </tr>
    <tr>
      <td><b>Tipo di limiti della piattaforma applicati</b></td>
      <td>Determinare il tipo di <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">limiti</a> che si applicano all'esecuzione. Durante la progettazione delle soluzioni, riflettere attentamente su come il volume e la frequenza delle transazioni verranno conteggiati ogni giorno nei limiti stabiliti dal governor per l'approccio scelto. Calcolare il numero di esecuzioni che si verificheranno ogni giorno. Assicurarsi che i valori calcolati rientrino nei limiti associati agli strumenti selezionati.</td>
    </tr>
    <tr>
      <td><b>Latenza</b></td>
      <td>Determinare la velocità con cui i risultati dell'elaborazione saranno disponibili nella piattaforma. Per alcuni approcci, i cambiamenti saranno quasi immediati, mentre per altri possono essere minuti o ore.</td>
    </tr>
  </tbody>
</table>

## Casi d'uso

Quando si seleziona uno strumento per l'elaborazione asincrona, valutare innanzitutto i requisiti dell'organizzazione e le risorse disponibili. L'obiettivo è selezionare lo strumento o gli strumenti che riducono al minimo i costi di implementazione e manutenzione, garantendo al contempo la scalabilità e riducendo al minimo la probabilità di violazioni dei limiti. Questo obiettivo dipende dalle considerazioni tecniche descritte in precedenza e dalla composizione del team.

Si consideri un processo di ordinazione asincrono in Salesforce. Quando un ordine viene salvato, viene attivato un messaggio a un sistema di gestione del magazzino esterno con istruzioni speciali su come imballare e spedire un articolo. Poiché l'utente che effettua l'ordine non necessita di una risposta immediata dal sistema di gestione del magazzino, la richiesta può essere inviata in modo asincrono. L'elaborazione asincrona consente all'utente di continuare il lavoro senza attendere una risposta.

Per questo caso d'uso, può essere utile implementare Apex. Questo approccio funzionerà solo se nel team sono presenti sviluppatori Apex in grado di gestire la soluzione pro-code. In caso contrario, un approccio dichiarativo ha più senso. Inoltre, tenere presente che diversi insiemi di [limiti si](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) applicano a strumenti diversi.

In questa tabella sono elencati i casi d'uso comuni nella colonna più a sinistra, seguiti da una descrizione. La colonna _Prima scelta_ fornisce l'approccio più tipico utilizzato per soddisfare un caso d'uso di questo tipo, insieme alla logica dell'approccio Prima scelta. Utilizzarlo come punto di partenza nell'analisi: l'approccio Prima scelta potrebbe avere limitazioni che non funzioneranno per il proprio caso d'uso.

<table>
  <thead>
    <tr>
      <th>Caso d'uso</th>
      <th>Descrizione</th>
      <th>Approccio di prima scelta</th>
      <th>Motivo</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Elaborazione batch ad alte prestazioni</b></td>
      <td>Qualsiasi automazione che deve elaborare migliaia o milioni di record in modo efficiente</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex fornisce API complete per l'interfacciamento con la piattaforma e per la velocità di stampa.</td>
    </tr>
    <tr>
      <td><b>Processo di pulitura dati</b></td>
      <td>Un processo eseguito regolarmente o su richiesta che pulisce i dati. Gli esempi includono l'annullamento della duplicazione, la verifica dell'indirizzo o il consolidamento dei dati.</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex fornisce API complete per l'interfacciamento con la piattaforma e per la velocità di stampa.</td>
    </tr>
    <tr>
      <td><b>Nightly Roll-up Job (Lavoro di roll-up notturno)</b></td>
      <td>Processo che calcola i dati di roll-up al termine di una giornata lavorativa.</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex fornisce API complete per l'interfacciamento con la piattaforma e per la velocità di stampa.</td>
    </tr>
    <tr>
      <td><b>Logica attivata da record</b></td>
      <td>Eseguire la logica in risposta a un aggiornamento di record.</td>
      <td><i>Varia</i></td>
      <td>Vedere la guida alle decisioni associata, <a href="/docs/architect/it-it/decision-guides/guide/record-triggered">Automazione eventi attivati</a> da record. Include un albero decisionale per i casi d'uso asincroni, tra cui Apex inseribile in area di attesa, Apex batch, Apex pianificato, Flusso pianificato, Flussi percorso asincrono e Acquisizione dati di modifica.</td>
    </tr>
    <tr>
      <td><b>Aggiornamenti a catena tramite un grafico a oggetti</b></td>
      <td>Consente di completare rapidamente l'azione di salvataggio di un utente, rinviando l'esecuzione asincrona degli aggiornamenti a catena ad altri oggetti.</td>
      <td><b>Apex</b> in area di attesa</td>
      <td>Queueable Apex dispone di potenti funzioni di concatenazione che consentono alla logica di suddividere una catena di aggiornamenti in una serie di transazioni asincrone.</td>
    </tr>
    <tr>
      <td><b>Elaborazione pianificata specifica del record</b></td>
      <td>Automazione in una data futura e dinamica specifica del record (ad esempio, 3 giorni prima di una data di chiusura).</td>
      <td><b>Flusso</b> con un percorso pianificato</td>
      <td>I percorsi pianificati rappresentano un punto di forza unico per il flusso, poiché la piattaforma gestisce automaticamente la pianificazione, l'annullamento e la riprogrammazione di questi percorsi se i dati del record cambiano.</td>
    </tr>
    <tr>
      <td><b>Invocazione di più servizi esterni lenti in parallelo</b></td>
      <td>Durante un'esecuzione sincrona, più servizi esterni vengono richiamati in parallelo per ottimizzare il tempo di esecuzione complessivo.</td>
      <td>Chiamate continuazione <b>Apex</b></td>
      <td>Consentendo l'esecuzione parallela di più callout a esecuzione lenta si riduce al minimo il tempo complessivo per completare il lavoro.</td>
    </tr>
    <tr>
      <td><b>Migrazione dei dati dei record da un sistema esterno</b></td>
      <td>Spostare grandi quantità di record in Salesforce Platform da un sistema esterno. Un processo singolo o pianificato regolarmente.</td>
      <td><b>API in</b> <b>bulco</b></td>
      <td>Questo è l'approccio più efficiente e rispettoso dei limiti per la migrazione dei dati.</td>
    </tr>
    <tr>
      <td><b>Esecuzione di logica aggiuntiva in un sistema esterno</b></td>
      <td>Schema Fire-and-forget che prevede la notifica di un evento sulla piattaforma a un sistema esterno e quindi l'elaborazione asincrona dell'evento.</td>
      <td><b>Eventi piattaforma</b> o <b>acquisizione dati modifica</b></td>
      <td>Un modello pub-sub funziona meglio qui e consente al sistema esterno di elaborare l'evento quando è pronto. Per ulteriori dettagli su questo schema, vedere <a href="/docs/architect/it-it/decision-guides/guide/event-driven">Architettura basata sugli eventi</a>.</td>
    </tr>
  </tbody>
</table>

La tabella Casi d'uso è una guida all'approccio più adatto per ogni caso d'uso. Tuttavia, sarà necessario verificare se la tecnologia First Choice soddisfa le esigenze specifiche del proprio caso d'uso. In particolare, determinare se l'approccio scelto può rispettare i limiti del governor per l'organizzazione.

Dopo aver identificato un approccio candidato per il proprio caso d'uso, la [Guida ai fondamenti](/docs/architect/it-it/fundamentals/guide/async-fundamentals) sull'elaborazione asincrona può essere utile per un controllo completo della soluzione.

## Risorse

Queste risorse aggiuntive possono essere utili per il processo decisionale:

- Approfondisci la conoscenza di ciascuna delle tecnologie asincrone della piattaforma: [Nozioni di base sull'elaborazione asincrona](/docs/architect/it-it/fundamentals/guide/async-fundamentals)
- Scegliere tra Apex e Flusso per i trigger di record: [Automazione degli eventi attivati da record](/docs/architect/it-it/decision-guides/guide/record-triggered)
- Informazioni sugli schemi di integrazione asincrona: [Architettura basata sugli eventi](/docs/architect/it-it/decision-guides/guide/event-driven)

<!-- document id=c6b89250b5e292d1ae53397e3f26e20ab70672a5c5edda1406b20ed2173d3ae6 url=/architect/current/it-it/decision-guides/guides/data-integration.md -->

# Integrazione dei dati con Salesforce

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.

## Panoramica della guida

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.

## Takeaway

- **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](/docs/architect/it-it/well-architected/guide/reliability.html#scalability-and-capacity-planning) 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](/docs/architect/it-it/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-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](/docs/architect/it-it/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound) 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.

## Considerazioni comuni per la scelta degli strumenti di integrazione dei dati

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.

<table>
    <thead>
        <tr>
            <th>Area da considerare</th>
            <th>Domande comuni</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Strumenti e paesaggio esistenti</td>
            <td>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)?</td>
        </tr>
        <tr>
            <td>Flusso di dati (tempistica, esperienza utente prevista, direzionalità)</td>
            <td>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?</td>
        </tr>
        <tr>
            <td>Implementazione</td>
            <td>Qual è il livello di impegno per i sistemi non Salesforce? Quali team sono responsabili dell'implementazione delle integrazioni? Quali strumenti preferiscono utilizzare?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/it-it/well-architected/guide/resource-and-cost-optimization.html#code-organization">Gestibilità</a></td>
            <td>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?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/it-it/well-architected/guide/reliability.html#scalability-and-capacity-planning">Volume di dati</a></td>
            <td>Quanti dati sono coinvolti nell'integrazione? Lavorerai con <a href="https://trailhead.salesforce.com/content/learn/modules/large-data-volumes">grandi volumi di dati</a> (LDV)? Con che frequenza avverranno le modifiche in blocco? Che tipo di impatto avranno gli aggiornamenti Singleton? Con che frequenza si verificheranno?</td>
        </tr>
        <tr>
            <td>Limiti</td>
            <td>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)?</td>
        </tr>
    </tbody>
</table>

## Confronto dei prodotti

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.

<table>
    <thead>
        <tr>
            <th></th>
            <th>Da Salesforce al sistema esterno</th>
            <th>Dal sistema esterno a Salesforce</th>
            <th>Esecuzione</th>
            <th>Licenza aggiuntiva richiesta</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Azioni Apex</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Modifica acquisizione dati</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-no">Non disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>No*</td>
        </tr>
        <tr>
            <td><strong>Apex personalizzato (servizi Web REST e SOAP)</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Servizi esterni</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-no">Non disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>Sì</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>Sì</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>Sì</td>
        </tr>
        <tr>
            <td><strong>API native Salesforce</strong></td>
            <td class="guide-table-no">Non disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>OmniScript</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-no">Lato client***</td>
            <td>Sì</td>
        </tr>
        <tr>
            <td><strong>Procedura di integrazione OmniStudio</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>Sì</td>
        </tr>
        <tr>
            <td><strong>Messaggi in uscita</strong></td>
            <td>Non ideale</td>
            <td class="guide-table-no">Non disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Eventi piattaforma</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>No**</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Oggetti esterni</strong></td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Disponibile</td>
            <td class="guide-table-ok">Lato server</td>
            <td>Sì</td>
        </tr>
    </tbody>
</table>

[\*Componente aggiuntivo richiesto per i casi d'uso di eventi di acquisizione dati di modifica a volume elevato](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm)

[\*\*Componente aggiuntivo richiesto per i casi d'uso di eventi piattaforma a volume elevato](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)

\*\*\*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

### Altri strumenti per spostare i dati all'interno e all'esterno di Salesforce

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](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm) 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**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) 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**](http://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.

## Da Salesforce a sistemi esterni (integrazione in uscita)

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-low-code-per-le-integrazioni-in-uscita-da-salesforce)
- [Strumenti ibridi per le integrazioni in uscita](#strumenti-ibridi-per-le-integrazioni-in-uscita-da-salesforce)
- [Strumenti pro-codice per le integrazioni in uscita](#strumenti-pro-code-per-le-integrazioni-in-uscita-da-salesforce)

### Strumenti low-code per le integrazioni in uscita da Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guida</th>
            <th>Licenze</th>
            <th>Tempistica</th>
            <th>Volume e scala</th>
            <th></th>
            <th>Consegna e manutenzione</th>
            <th></th>
            <th></th>
            <th>Privacy e sicurezza</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quando utilizzare</strong></th>
            <th><strong>Licenza aggiuntiva</strong></th>
            <th><strong>Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica)</strong></th>
            <th><strong>Supporto multi-oggetto</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Test e distribuzione**</strong></th>
            <th><strong>Debug</strong></th>
            <th><strong>Comportamento di gestione/riprova degli errori incorporato</strong></th>
            <th><strong>Può essere utilizzato con dati crittografati a riposo</strong></th>
            <th><strong>Protocollo di autenticazione</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Modifica acquisizione dati</strong></td>
            <td>Quando è necessario pubblicare le modifiche a livello di record apportate in Salesforce in un sistema esterno e non è necessario un payload personalizzato.</td>
            <td>Obbligatorio</td>
            <td>Asincrono</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Servizi esterni</strong></td>
            <td>Quando si orchestra un processo utilizzando Flusso, Apex, Bot Einstein o OmniStudio e le API del sistema esterno sono descritte utilizzando specifiche OpenAPI.</td>
            <td>Non richiesto</td>
            <td>Sincronizzazione</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td>N/D</td>
            <td>Credenziali denominate</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Asincrono</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td>Con strumenti pro code</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì, tramite Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Procedura di integrazione OmniStudio</strong></td>
            <td>Quando è necessario trasformare i dati senza l'interazione dell'utente e migliorare le prestazioni elaborandoli sul server anziché sul browser.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Supporto dichiarativo</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Credenziali denominate</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Oggetti esterni</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Sincronizzazione</td>
            <td>No</td>
            <td class="guide-table-ok">Sì*</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code e un tracciatore dichiarativo</td>
            <td>No</td>
            <td>N/D</td>
            <td>Credenziali denominate</td>
        </tr>
        <tr>
            <td colspan="11">*Gli adattatori OData precedenti alla versione 4.01 sono soggetti a limiti di chiamata. Vedere <a href="https://help.salesforce.com/s/articleView?id=platform.odata_general_limits.htm&type=5">Considerazioni sui limiti</a> di traffico per ulteriori dettagli. ** Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'<a href="https://developer.salesforce.com/docs/metadata-coverage/">API dei metadati</a>, pacchetti o serie di modifiche in produzione.</td>
        </tr>
    </tbody>
</table>

### Caso d'uso: Integrazione in uscita con strumenti low-code

> 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](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1), 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.

### Strumenti ibridi per le integrazioni in uscita da Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guida</th>
            <th>Licenze</th>
            <th>Tempistica</th>
            <th>Volume e scala</th>
            <th></th>
            <th>Consegna e manutenzione</th>
            <th></th>
            <th></th>
            <th>Privacy e sicurezza</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quando utilizzare</strong></th>
            <th><strong>Licenza aggiuntiva</strong></th>
            <th><strong>Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica)</strong></th>
            <th><strong>Supporto multi-oggetto</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Test e distribuzione**</strong></th>
            <th><strong>Debug</strong></th>
            <th><strong>Comportamento di gestione/riprova degli errori incorporato</strong></th>
            <th><strong>Può essere utilizzato con dati crittografati a riposo</strong></th>
            <th><strong>Protocollo di autenticazione</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Azioni Apex</strong></td>
            <td>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.</td>
            <td>Non richiesto</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Più</td>
        </tr>
        <tr>
            <td><strong>Relay evento</strong></td>
            <td>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</td>
            <td>No</td>
            <td>Asincrono</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>HTTP/1.1 con TLS</td>
        </tr>
        <tr>
            <td><strong>Messaggi in uscita</strong></td>
            <td>Quando è necessario inviare messaggi SOAP su HTTP(S) a un endpoint designato con ricezione garantita quando attivato da una regola di flusso di lavoro.</td>
            <td>Non richiesto</td>
            <td>Asincrono</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Supporto dichiarativo</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>TLS bidirezionale</td>
        </tr>
        <tr>
            <td><strong>Eventi piattaforma</strong></td>
            <td>Quando è necessario un payload strutturato e definito su misura per le modifiche quasi in tempo reale in Salesforce o in un sistema esterno.</td>
            <td>Non obbligatorio*</td>
            <td>Asincrono</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Oggetti esterni (con adattatori Apex personalizzati)</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td>N/D</td>
            <td>Più</td>
        </tr>
         <tr>
            <td><strong>Data 360</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Più</td>
        </tr>
    </tbody>
</table>

[\*Componente aggiuntivo](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) 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](https://developer.salesforce.com/docs/metadata-coverage/), pacchetti o serie di modifiche in produzione.

### Caso d'uso: Integrazione in uscita con strumenti ibridi

> 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](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm), è 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](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm) 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.

### Strumenti pro-code per le integrazioni in uscita da Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guida</th>
            <th>Licenze</th>
            <th>Tempistica</th>
            <th>Volume e scala</th>
            <th></th>
            <th>Consegna e manutenzione</th>
            <th></th>
            <th></th>
            <th>Privacy e sicurezza</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quando utilizzare</strong></th>
            <th><strong>Licenza aggiuntiva</strong></th>
            <th><strong>Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica)</strong></th>
            <th><strong>Supporto multi-oggetto</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Test e distribuzione**</strong></th>
            <th><strong>Debug</strong></th>
            <th><strong>Comportamento di gestione/riprova degli errori incorporato</strong></th>
            <th><strong>Può essere utilizzato con dati crittografati a riposo</strong></th>
            <th><strong>Protocollo di autenticazione</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex personalizzato</strong></td>
            <td>Quando sono necessarie più funzionalità di quelle disponibili negli strumenti low-code.</td>
            <td>Non richiesto</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td class="guide-table-ok">Sì*</td>
            <td>Più</td>
        </tr>
        <tr>
            <td><strong>Servizi esterni</strong></td>
            <td>L'integrazione da codice con le API di sistema esterne è descritta utilizzando le specifiche OpenAPI.</td>
            <td>Non richiesto</td>
            <td>Sincronizzazione</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td>N/D</td>
            <td>Più</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td class="guide-table-ok">Sì*</td>
            <td>Più</td>
        </tr>
    </tbody>
</table>

\*L'abilitazione di Shield Platform Encryption modifica alcuni comportamenti, vedere [Considerazioni generali Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) per ulteriori dettagli.

\*\*Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'[API dei metadati](https://developer.salesforce.com/docs/metadata-coverage/), pacchetti o serie di modifiche in produzione.

### Caso d'uso: Integrazione in uscita con strumenti Pro-Code

> 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](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm), 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](https://www.mulesoft.com/platform/cloud-connectors) 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).

## Dati dei sistemi esterni a Salesforce (integrazione in entrata)

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-low-code-per-le-integrazioni-in-entrata-in-salesforce)
- [Strumenti ibridi per le integrazioni in entrata](#strumenti-ibridi-per-le-integrazioni-in-entrata-in-salesforce)
- [Strumenti pro-codice per le integrazioni in entrata](#strumenti-pro-code-per-le-integrazioni-in-entrata-in-salesforce)

### Strumenti low-code per le integrazioni in entrata in Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guida</th>
            <th>Licenze</th>
            <th>Tempistica</th>
            <th>Volume e scala</th>
            <th></th>
            <th>Consegna e manutenzione</th>
            <th></th>
            <th></th>
            <th>Privacy e sicurezza</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quando utilizzare</th>
            <th>Licenza aggiuntiva</th>
            <th>Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica)</th>
            <th>Supporto multi-oggetto</th>
            <th>LDV/Bulk</th>
            <th>Test e distribuzione*</th>
            <th>Debug</th>
            <th>Comportamento di gestione/ritentativo degli errori incorporato</th>
            <th>Può essere utilizzato con dati crittografati a riposo</th>
            <th>Protocollo di autenticazione</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Asincrono</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td>Con strumenti pro-code</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì, tramite Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Procedura di integrazione OmniStudio</strong></td>
            <td>Quando è necessario importare e trasformare dati da fonti di terze parti senza interazione dell'utente.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Supporto dichiarativo</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Credenziali denominate</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Oggetti esterni</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Sincronizzazione</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td>N/D</td>
            <td>Più</td>
        </tr>
    </tbody>
</table>

\*Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'[API dei metadati](https://developer.salesforce.com/docs/metadata-coverage/), pacchetti o serie di modifiche in produzione.

### Caso d'uso: Integrazione in entrata con strumenti low-code

> 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](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio). 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.

### Strumenti ibridi per le integrazioni in entrata in Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guida</th>
            <th>Licenze</th>
            <th>Tempistica</th>
            <th>Volume e scala</th>
            <th></th>
            <th>Consegna e manutenzione</th>
            <th></th>
            <th></th>
            <th>Privacy e sicurezza</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quando utilizzare</th>
            <th>Licenza aggiuntiva</th>
            <th>Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica)</th>
            <th>Supporto multi-oggetto</th>
            <th>LDV/Bulk</th>
            <th>Test e distribuzione**</th>
            <th>Debug</th>
            <th>Comportamento di gestione/ritentativo degli errori incorporato</th>
            <th>Può essere utilizzato con dati crittografati a riposo</th>
            <th>Protocollo di autenticazione</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Eventi piattaforma</strong></td>
            <td>Quando è necessario un payload strutturato e definito su misura per le modifiche quasi in tempo reale in Salesforce o in un sistema esterno.</td>
            <td>Non obbligatorio*</td>
            <td>Asincrono</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Oggetti esterni (con adattatori Apex personalizzati)</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td>N/D</td>
            <td>Più</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Più</td>
        </tr>
    </tbody>
</table>

\*[Componente aggiuntivo](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) 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](https://developer.salesforce.com/docs/metadata-coverage/), pacchetti o serie di modifiche in produzione.

### Caso d'uso: Integrazione in entrata con strumenti ibridi

> 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](#caso-duso-integrazione-in-uscita-con-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.

### Strumenti pro-code per le integrazioni in entrata in Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guida</th>
            <th>Licenze</th>
            <th>Tempistica</th>
            <th>Volume e scala</th>
            <th></th>
            <th>Consegna e manutenzione</th>
            <th></th>
            <th></th>
            <th>Privacy e sicurezza</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quando utilizzare</th>
            <th>Licenza aggiuntiva</th>
            <th>Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica)</th>
            <th>Supporto multi-oggetto</th>
            <th>LDV/Bulk</th>
            <th>Test e distribuzione****</th>
            <th>Debug</th>
            <th>Comportamento di gestione/ritentativo degli errori incorporato</th>
            <th>Può essere utilizzato con dati crittografati a riposo</th>
            <th>Protocollo di autenticazione</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Servizi Web Apex REST &amp; SOAP personalizzati</strong></td>
            <td>Quando sono necessarie più funzionalità di quelle fornite dagli endpoint API nativi, ad esempio l'elaborazione oggetti incrociata o un'altra logica complessa.</td>
            <td>Non richiesto</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td class="guide-table-ok">Sì***</td>
            <td>Più</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>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.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td class="guide-table-ok">Sì***</td>
            <td>Più</td>
        </tr>
        <tr>
            <td><strong>API native Salesforce</strong></td>
            <td>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.</td>
            <td>Non obbligatorio*</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì*****</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td class="guide-table-ok">Sì**</td>
            <td class="guide-table-ok">Sì***</td>
            <td>Più</td>
        </tr>
    </tbody>
</table>

\*Si applicano i [limiti e le](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm) 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](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm))

\*\*\*L'abilitazione di Shield Platform Encryption modifica alcuni comportamenti, vedere [Considerazioni generali Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) per ulteriori dettagli.

\*\*\*\*Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'[API dei metadati](https://developer.salesforce.com/docs/metadata-coverage/), pacchetti o serie di modifiche in produzione.

\*\*\*\*\*Le API composite hanno il supporto multi-oggetto.

### Caso d'uso: Integrazione in entrata con strumenti Pro-Code

> 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](https://www.mulesoft.com/platform/cloud-connectors) 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](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) sull'API REST sObjects Contact nell'organizzazione Salesforce.

## Integrazioni da Salesforce a 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.

### Strumenti per l'integrazione dei dati nelle organizzazioni Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guida</th>
            <th>Costo</th>
            <th>Tempistica</th>
            <th>Volume e scala</th>
            <th></th>
            <th></th>
            <th>Consegna e manutenzione</th>
            <th></th>
            <th>Privacy e sicurezza</th>
            <th></th>
            <th>Strumenti da implementare</th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quando utilizzare</strong></th>
            <th><strong>Licenza aggiuntiva</strong></th>
            <th><strong>Sincronizzazione (Richiesta/Risposta) o Asincrona (Attiva/Dimentica)</strong></th>
            <th><strong>Supporto multi-oggetto</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Test e distribuzione*</strong></th>
            <th><strong>Debug</strong></th>
            <th><strong>Comportamento di gestione/riprova degli errori incorporato</strong></th>
            <th><strong>Può essere utilizzato con dati crittografati a riposo</strong></th>
            <th><strong>Protocollo di autenticazione</strong></th>
            <th><strong>Codice basso → Pro Code</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>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</td>
            <td>Obbligatorio</td>
            <td>Asincrono</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>No</td>
            <td>Con strumenti pro-code</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì, tramite Shield Connect</td>
            <td>OAuth</td>
            <td>Codice basso</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>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</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td class="guide-table-ok">Sì**</td>
            <td>Più</td>
            <td>Codice professionale</td>
        </tr>
        <tr>
            <td><strong>API native Salesforce</strong></td>
            <td>Quando Salesforce o Heroku Connect non sono un'opzione o è necessaria un'elaborazione più complessa</td>
            <td>Non richiesto</td>
            <td>Entrambi</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>No</td>
            <td class="guide-table-ok">Sì**</td>
            <td>Più</td>
            <td>Codice professionale</td>
        </tr>
        <tr>
            <td><strong>Modifica acquisizione dati</strong></td>
            <td>Quando è necessario pubblicare le modifiche a livello di record apportate in Salesforce in un sistema esterno e non è necessario un payload personalizzato.</td>
            <td>Obbligatorio</td>
            <td>Asincrono</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>OAuth</td>
            <td></td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect con adattatore tra organizzazioni</strong></td>
            <td>Quando si desidera che gli utenti di un'organizzazione visualizzino o modifichino i record di un'organizzazione diversa senza replica dei dati</td>
            <td>Obbligatorio</td>
            <td>Asincrono</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td>N/D</td>
            <td>N/D</td>
            <td>Più</td>
            <td>Codice basso</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>Quando si desidera che gli utenti di un'organizzazione visualizzino o modifichino i record di un'organizzazione diversa con dati replicati in Data 360.</td>
            <td>Obbligatorio</td>
            <td>Entrambi</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Con strumenti pro-code</td>
            <td class="guide-table-ok">Sì</td>
            <td class="guide-table-ok">Sì</td>
            <td>Più</td>
            <td>Ibrido</td>
        </tr>
    </tbody>
</table>

\*Test e distribuzione si riferisce alla capacità di creare in un ambiente inferiore e distribuire tramite l'[API dei metadati](https://developer.salesforce.com/docs/metadata-coverage/), pacchetti o serie di modifiche all'ambiente di produzione

\*\*L'abilitazione di Shield Platform Encryption modifica alcuni comportamenti, vedere [Considerazioni generali Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) 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._

### Caso d'uso: Connessione di più organizzazioni Salesforce

> 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](#takeaway)._

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](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5) 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](https://docs.mulesoft.com/design-center/about-designing-a-mule-application) 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](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (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](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1). 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.

## Osservazioni di chiusura

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.

### Dicci cosa ne pensi

Aiutaci a pubblicare ciò che è più rilevante per te. [Rispondere al sondaggio](https://sfdc.co/J0cWb) per fornire un feedback su questo contenuto e dirci cosa si desidera vedere dopo.

<!-- document id=83c1587d6aef0e7ce9d78ead85123171c424d5cb90a3dd45ae10c6ec133960ab url=/architect/current/it-it/decision-guides/guides/data-360-interoperability.md -->

# Interoperabilità di Data 360

Le aziende spesso archiviano i dati in Salesforce e in altri data lake esterni (ad esempio, _Snowflake_, _Google BigQuery_, _Databricks_, _Redshift_ o memoria oggetti come _Amazon S3_). L'inserimento dei dati in più sistemi rappresenta una sfida per le aziende che desiderano sfruttare tutto il valore dei propri dati per potenziare le esperienze basate sull'intelligenza artificiale. Salesforce _Data 360_ è il livello di intelligenza di base utilizzato da ogni agente AI Agentforce per accedere al contesto corretto al momento giusto.

Gli architetti che lavorano per riunire i dati in più data lake devono affrontare le principali decisioni architettoniche relative al modo migliore per integrare i dati. _Data 360_ offre diverse opzioni per l'integrazione dei dati, ognuna con vari pro e contro.

## Panoramica della guida

Questa guida fornisce un framework per valutare quale schema si adatta meglio alle proprie esigenze in termini di latenza, costo, scalabilità, governance e complessità durante l'integrazione dei dati, consentendo di scegliere quando utilizzare l'inserimento dati, la federazione dati Copia zero o un approccio ibrido. La guida consente inoltre di scegliere tra diversi metodi di inserimento dati e federazione dei dati, ognuno dei quali risponde a esigenze diverse.

L'integrazione di data lake house esterni con _Data 360_ richiede un'attenta considerazione dei compromessi tra aggiornamento dei dati, governance ed efficienza delle opportunità in corso di realizzazione. Ad esempio, l'utilizzo delle query live della federazione dei dati Copia zero ottimizza la freschezza dei dati ma può ridurre l'efficienza delle opportunità in corso di realizzazione poiché più dati passano attraverso la rete. Per la maggior parte delle implementazioni del mondo reale, combinare l'inserimento e la federazione in un ecosistema di case sul lago multi-cloud è il percorso ottimale. Questo approccio ibrido garantisce un'architettura scalabile, gestita e interoperabile che supporta carichi di lavoro operativi a bassa latenza (ad esempio, personalizzazione in tempo reale e rilevamento delle frodi) e carichi di lavoro analitici (ad esempio, reportistica normativa e analisi del trend storico). Questa guida consente di determinare come gestire questi compromessi utilizzando una strategia appropriata.

## Punti salienti

- **L'inserimento dati** copia i dati in Salesforce _Data 360_ e crea modelli di dati canonici governati. Questo è l'ideale per quando è necessario:
  - **Costruire un Customer 360 completo.** Ciò consente di unificare e trasformare fonti diverse in un unico profilo affidabile.
  - **Rispettare la rigorosa conformità normativa.** Ciò consente di creare una copia controllabile centralizzata in modo che l'accesso ai dati e la discendenza possano essere controllati da vicino.
- **Zero Copy Federation** esegue query sulle fonti esterne in tempo reale senza duplicazioni, abilitando la personalizzazione in tempo reale, i cruscotti digitali live e l'orientamento rapido delle fonti. Questo approccio offre due opzioni principali, ma vi sono dei compromessi che devono essere bilanciati:
  - **Query live:** Utilizzarlo per l'analisi interattiva e i cruscotti digitali dei dati in tempo reale che vivono in piattaforme dati esterne (ad esempio, _Snowflake_, _BigQuery_, _Redshift_ o _Databricks_). Ciò consente di evitare duplicazioni dei dati lente e costose inviando l'elaborazione delle query al sistema di origine e restituendo solo i risultati necessari. Questo approccio è ottimizzato per le query rare o ad hoc in cui la freschezza è fondamentale. È adatto per carichi di lavoro _QPS (query al secondo_) bassi (i costi delle query possono aumentare in modo significativo con QPS elevato).
  - **Caching (query accelerata):** Utilizzarlo per le query frequenti sui dati che non cambiano spesso. Le query accelerate mantengono una cache locale che viene aggiornata a intervalli configurabili (da 15 minuti a 7 giorni), riducendo così i ripetuti colpi alla fonte. Questo approccio bilancia le prestazioni dei cruscotti digitali e i carichi di lavoro di costo, segmentazione e BI in cui i risultati leggermente obsoleti sono accettabili. Questo non è adatto per il processo decisionale sub-secondo.
  - **Federazione file:** Utilizzarlo per l'elaborazione batch su larga scala e l'addestramento del modello AI per i dati nel data lake del cloud (ad esempio, _S3_ o _ADLS_). Questo approccio evita l'inserimento lento e costoso eseguendo query dirette sui file in formati di tabella aperti, sbloccando serie di dati ETL di grandi dimensioni e carichi di lavoro di data science.
- I **modelli ibridi** fondono l'inserimento per i _profili unificati_ con la federazione per la freschezza, che supporta il coinvolgimento Omnicanale, le azioni basate su Agentforce e l'addestramento AI/ML.

### Considerazioni importanti

- **Utilizzare un'architettura ibrida.** Spesso è necessario combinare l'inserimento dei dati e la federazione.
  - Utilizzare _l'inserimento dati_ sui dati critici per i modelli di dati canonici e la governance di base.
  - Utilizzare _Copia zero_ per tutte le altre federazioni di dati per mantenere la freschezza e ridurre al minimo il sovraccarico operativo di creazione e manutenzione delle opportunità in corso di realizzazione per l'inserimento dei dati.
- **Questioni di frequenza di inserimento dati.** Scegliere la frequenza in base al valore aziendale, alle esigenze di latenza e alla complessità operativa.
  - Utilizzare _in tempo reale_ per i flussi di lavoro sensibili al tempo (ad esempio, personalizzazione, cruscotti digitali live e azioni Agentforce).
  - Utilizzare _Quasi in tempo reale_ per i processi moderatamente urgenti (ad esempio, campagne e rapporti operativi).
  - Utilizzare il batching per le serie di dati storiche o a bassa velocità.
- **Abbinare gli schemi di federazione a latenza e prestazioni.** Scegliere l'opzione più adatta ai propri schemi di accesso e requisiti di freschezza, prestazioni e costo.
  - Utilizzare _Live Query_ per i cruscotti digitali operativi e la personalizzazione in tempo reale in cui la latenza bassa è fondamentale.
  - Utilizzare il _caching (query accelerata)_ quando le query sono frequenti e i risultati leggermente obsoleti sono accettabili, il che consente di bilanciare prestazioni e costi.
  - Utilizzare _Federazione file_ per carichi di lavoro analitici o batch su larga scala e molto produttivi, ideali per le serie di dati storiche o meno sensibili al tempo.
- **Allineare la governance ai requisiti di residenza dei dati.**
  - Utilizzare _l'inserimento_ quando la governance centralizzata è fondamentale.
  - Utilizzare la _federazione_ quando la governance decentralizzata è accettabile, applicando anche una governance rigorosa alla fonte esterna.
  - Utilizzare _Copia zero_ per le policy a livello di origine (ad esempio, _protezione a livello_ di riga e mascheramento dei dati).
- **Dare priorità all'inserimento per i flussi di lavoro di alto valore.** Applicare l'inserimento in modo selettivo ai processi critici (ad esempio, risoluzione dell'identità, reporting normativo e attivazione operativa).
- **Costo e complessità determinano le decisioni.** L'inserimento in tempo reale può essere costoso e complesso. Ecco perché è importante che gli architetti soppesino i costi di inserimento, archiviazione e trasformazione dei dati rispetto ai costi di esecuzione delle query direttamente tramite _Zero Copy_.

La scelta dello schema di integrazione corretto (_inserimento dati_, _copia zero_ o approccio _ibrido_) influisce direttamente su latenza, governance, efficienza operativa e costi nelle piattaforme multi-cloud. Questa decisione determina il modo in cui gli approfondimenti in tempo reale, l'attivazione basata sull'intelligenza artificiale e il coinvolgimento personalizzato vengono forniti in modo affidabile e su larga scala.

## Confronto dei prodotti

Questa tabella confronta gli schemi _di inserimento dati_ e _copia zero_ in Salesforce _Data 360_, concentrandosi su funzionalità, compromessi e vantaggi, nonché casi d'uso e risultati aziendali. Utilizzare questa opzione come riferimento per progettare piattaforme dati ibride multi-cloud che bilanciano prestazioni, costi e conformità.

<table>
  <thead>
    <tr>
      <th align="left" valign="top"><strong>Tipo di schema</strong></th>
      <th align="left" valign="top"><strong>Modalità/Strumento</strong></th>
      <th align="left" valign="top"><strong>Vantaggi</strong></th>
      <th align="left" valign="top"><strong>Considerazioni</strong></th>
      <th align="left" valign="top"><strong>Esiti</strong></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="left" valign="top"><strong>Inserimento dati</strong></td>
      <td align="left" valign="top">
        <strong>In tempo reale:</strong>
        <ul>
          <li>Inserimento di latenza al di sotto del secondo tramite le API di inserimento con supporto CDC.</li>
          <li>Pipeline di streaming continue.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Fornisce approfondimenti immediati</li>
          <li>Include casi d'uso operativi e di personalizzazione a bassa latenza</li>
          <li>Supporta flussi di lavoro basati sugli eventi</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Costo elevato</li>
          <li>Architettura complessa</li>
          <li>Requisiti del sistema sorgente a bassa latenza</li>
          <li>Fonti a volume elevato possono causare uno streaming eccessivo, che porta a pipeline sature</li>
          <li>I/O intensivo</li>
          <li>I campi selettivi e i filtri possono contribuire a ridurre il sovraccarico</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agenteforce:</strong>
        <ul>
          <li>Avvisi frodi in tempo reale, personalizzazione della vendita al dettaglio e avvisi operativi</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Cruscotti digitali subsecondi e monitoraggio dei KPI</li>
        </ul>
        <strong>Conformità:</strong>
        <ul>
          <li>Aggiornamenti continui dei record cliente per i flussi di lavoro regolamentati</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Streaming:</strong>
        <ul>
          <li>Inserimento in micro batch ogni 1–3 minuti tramite connettori nativi</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Saldi costo vs freschezza</li>
          <li>Presenta un'architettura più semplice rispetto al tempo reale</li>
          <li>Supporta gli aggiornamenti incrementali</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Lieve latenza</li>
          <li>Può non essere adatto a decisioni critiche relative ai subsecondi</li>
          <li>Le dimensioni del batch influiscono sulla memoria/calcolo</li>
          <li>Modera I/O</li>
          <li>Adatto a schemi di aggiornamento prevedibili e ripetitivi</li>
          <li>L'aggregazione in finestra può contribuire a ridurre il carico di elaborazione</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agenteforce:</strong>
        <ul>
          <li>Trigger di campagna tempestivi e coinvolgimento quasi live</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Motori di consigli e cruscotti digitali quasi live</li>
        </ul>
        <strong>Conformità:</strong>
        <ul>
          <li>Aggiornamenti frequenti con possibilità di controllo</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Lotto:</strong>
        <ul>
          <li>Fornisce carichi pianificati a volume elevato tramite connettori o API.</li>
          <li>Supporta l'archiviazione di oggetti e le opportunità in corso di realizzazione ETL/ELT.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Supporta l'efficienza economica per serie di dati di grandi dimensioni</li>
          <li>Funzionalità di facile implementazione</li>
          <li>Offre affidabilità per l'analisi storica</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Latenza dei dati</li>
          <li>Non adatto per operazioni sensibili al tempo</li>
          <li>I/O intensivo durante le finestre di carico</li>
          <li>La produttività della rete può diventare un collo di bottiglia per i file di grandi dimensioni</li>
          <li>Adatto per l'aggregazione storica o i flussi di lavoro di generazione di rapporti regolamentati</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agenteforce:</strong>
        <ul>
          <li>Biglietti di assistenza IT (Jira/ServiceNow) e flussi di lavoro aggregati</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Analisi storica e valutazione del trend</li>
        </ul>
        <strong>Conformità:</strong>
        <ul>
          <li>Rapporti normativi e aggregazione dei dati paziente/richiesta</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"><strong>Copia zero</strong></td>
      <td align="left" valign="top">
        <strong>Query live:</strong>
        <ul>
          <li>Fornisce query dirette su sistemi esterni e schema in lettura senza duplicazione dei dati</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Fornisce la massima freschezza</li>
          <li>Offre un sovraccarico di memoria minimo</li>
          <li>Supporta approfondimenti operativi in tempo reale</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Dipende dalle prestazioni della fonte</li>
          <li>Un volume elevato di query può influire sulla latenza</li>
          <li>Adatto per query con pushdown del predicato e aggregazione per ridurre al minimo l'I/O</li>
          <li>Evitare di utilizzare query non filtrate su serie di dati di grandi dimensioni</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agenteforce:</strong>
        <ul>
          <li>Flussi di lavoro dinamici che si adattano alle attività live</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Cruscotti digitali operativi e rapporti live</li>
        </ul>
        <strong>Conformità:</strong>
        <ul>
          <li>Rispetta la protezione a livello di riga e il mascheramento all'origine</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Query accelerata (Caching):</strong>
        <ul>
          <li>Fornisce copie locali memorizzate nella cache per le query federate configurabili da 15 min a 7 giorni.</li>
          <li>Fornisce un'esecuzione ottimizzata delle query</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Riduce la latenza</li>
          <li>Offre costi inferiori rispetto alle query live ripetitive</li>
          <li>Migliora le prestazioni per gli schemi di accesso frequenti</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Gestione della cache richiesta</li>
          <li>La stabilità dipende dagli intervalli di cache</li>
          <li>Adatto per query ad alta frequenza</li>
          <li>Non adatto per decisioni subsecondarie</li>
          <li>L'aggiornamento incrementale supporta solo gli inserimenti con aggiornamento; i record eliminati non vengono rimossi dalla cache.</li>
          <li>Periodicamente richiede un aggiornamento completo manuale per mantenere la cache sincronizzata con l'origine</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agenteforce:</strong>
        <ul>
          <li>Metriche di coinvolgimento preaggregate per prendere decisioni rapide</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Cruscotti digitali BI, segmentazione e rapporti analitici</li>
        </ul>
        <strong>Conformità:</strong>
        <ul>
          <li>Cruscotti digitali regolamentati in modo coerente con registri di controllo</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Federazione file:</strong>
        <ul>
          <li>Fornisce l'accesso diretto a serie di dati storiche di grandi dimensioni in negozi di oggetti o laghi (ad esempio, <em>S3</em>, <em>Iceberg</em>, <em>Google BigQuery</em> e <em>Redshift</em>).</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Elabora serie di dati su larga scala</li>
          <li>Richiede una memoria minima in <em>Data 360</em></li>
          <li>Supporta i carichi di lavoro AI/ML</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Sola lettura</li>
          <li>Le prestazioni delle query dipendono dalla produttività del sistema esterno</li>
          <li>Adatto per lavori intensivi e con un volume elevato di produzione</li>
          <li>Non adatto per i cruscotti digitali in tempo reale</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agenteforce:</strong>
        <ul>
          <li>Non tipico (pesante in batch)</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Formazione ML/AI, analisi storica e rapporti su scala petabyte</li>
        </ul>
        <strong>Conformità:</strong>
        <ul>
          <li>Gestisce l'accesso alle serie di dati esterne senza duplicazioni</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## Schemi di integrazione di Data 360

Esistono tre schemi di integrazione principali per Data 360: inserimento dati, federazione dati copia zero e approccio ibrido.

### Inserimento dati

Con _l'inserimento dati_, i dati vengono copiati fisicamente in _Data 360_ e completamente gestiti, a differenza di _Copia zero_ in cui i dati rimangono all'origine. In altre parole, l'elaborazione per le trasformazioni avviene all'interno di _Data 360_, che fornisce una governance e un controllo centralizzati.

#### Casi d'uso di inserimento dati

Utilizzare _l'inserimento dati_ per archiviare le serie di dati canoniche governate in Salesforce _Data 360_ per la conformità e il controllo operativo. Utilizzare l'inserimento quando sono necessari controllo completo, controllo e tracciabilità. L'inserimento dati è ideale per i flussi di lavoro regolamentati o di valore elevato in cui l'elaborazione centralizzata e la governance sono fondamentali.

L'inserimento è adatto per creare una base affidabile per la risoluzione dell'identità, la generazione di rapporti normativi e i flussi di lavoro mission-critical basati sull'intelligenza artificiale e il coinvolgimento dei clienti.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360  Ingestion.png" alt="Panoramica dell&apos;inserimento dati" />

#### Metodi di inserimento dati

I metodi _di inserimento dati_ possono variare a seconda del connettore utilizzato per inserire i dati. Alcuni connettori offrono una varietà di metodi di inserimento, mentre altri funzionano solo in modalità batch o streaming. Per un elenco completo dei connettori _Data 360_ e dei metodi disponibili, vedere [Data 360: Integrazioni e connettori](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5).

- **In tempo reale:**
  - Fornisce l'inserimento al di sotto del secondo utilizzando _Acquisizione dati (CDC)_
  - Adatto a flussi di lavoro sensibili al tempo (ad esempio, rilevamento di frodi, personalizzazione e cruscotti digitali operativi)
  - Le funzioni spingono le trasformazioni e le aggregazioni all'interno di _Data 360_, il che consente di ridurre l'I/O a valle e ottimizzare l'utilizzo del calcolo
  - Supporta l'utilizzo di CDC incrementale per ridurre al minimo lo shuffle dei dati
- **Streaming:**
  - Fornisce l'inserimento ogni 1–3 minuti in piccoli incrementi
  - Equilibrio tra freschezza e costo
  - Adatto per l'orchestrazione delle campagne, il coinvolgimento quasi live e la generazione di rapporti operativi
  - Supporta l'utilizzo di micro batch per controllare i picchi di I/O
  - Aggrega i dati alla fonte (se possibile) per ridurre i volumi di trasferimento e ottimizzare l'archiviazione
- **Batch (carichi pianificati):**
  - Fornisce l'inserimento periodico di serie di dati di grandi dimensioni (ad esempio, ogni ora, ogni giorno e ogni settimana)
  - Offre efficienza e affidabilità in termini di costi per le serie di dati storiche, i rapporti normativi e i casi d'uso di conformità
  - Garantisce che la località di calcolo si trovi nella stessa regione dello storage di origine per migliorare le prestazioni e ottimizzare i costi

#### Playbook architetto

- **Casi d'uso di inserimento dati:**
  - **Generazione di profili unificati Customer 360.** Creare un'unica fonte di dati per le identità e gli attributi dei clienti.
  - **Gestire le serie di dati di conformità ai regolamenti.** Imponi governance, discendenza e verificabilità per i dati sensibili.
  - **Centralizzare l'orchestrazione delle campagne.** Assicurarsi che marketing, vendite e assistenza funzionino tutti da serie di dati coerenti e affidabili.
- **Pratiche di progettazione:**
  - Consente l'inserimento in batch per esigenze storiche o tolleranti la bassa latenza (ad esempio, rapporti di archiviazione o istantanee periodiche).
  - Utilizzare le API CDC o streaming per mantenere la freschezza dei flussi di lavoro operativi e di personalizzazione e garantire aggiornamenti quasi in tempo reale.
  - Controllare la crescita dello storage e del calcolo applicando carichi incrementali per ottimizzare i costi e l'efficienza (anziché ricaricare intere serie di dati).
  - Allineare le opportunità di inserimento in corso di realizzazione con la località di calcolo e l'elaborazione incrementale per ridurre gli I/O della rete.
  - Applicare trasformazioni all'interno di _Data 360_ per evitare di spostare dati non elaborati inutilmente.
- **Considerazioni sui costi:**
  - **L'inserimento in tempo reale** presenta i costi di calcolo e pipeline più elevati, il che può essere giustificato per flussi di lavoro sensibili al tempo e di valore elevato (ad esempio, personalizzazione, cruscotti digitali operativi o azioni basate su Agentforce).
  - **L'inserimento streaming** ha costi di elaborazione e archiviazione moderati, che possono essere adatti per aggiornamenti frequenti che possono tollerare lievi ritardi (ad esempio, l'orchestrazione delle campagne o la generazione di rapporti operativi).
  - **L'inserimento batch** ha costi di calcolo inferiori e memoria prevedibile, adatti per le serie di dati storiche o gli aggiornamenti a bassa frequenza. L'inserimento di dati batch da organizzazioni Salesforce utilizzando determinati connettori è gratuito.
  - **Modalità di aggiornamento** Consente di selezionare la modalità di _aggiornamento incrementale_, che riduce i costi totali di inserimento e calcolo. In Salesforce, si consiglia di utilizzare _l'aggiornamento incrementale_ ove possibile per ottimizzare l'efficienza in tutti i tipi di inserimento.
  - Il **costo** è influenzato anche dal volume di I/O dalla fonte a _Data 360_. L'ottimizzazione delle dimensioni dei batch, delle partizioni e dell'allineamento regionale riduce i costi di trasferimento e migliora le prestazioni.
- **Scenari di settore:**
  - **Finanza:** Le serie di dati di inserimento sono necessarie per _conoscere il cliente_, _Antiriciclaggio (AML)_ e il rilevamento di frodi in cui la verificabilità e la conformità non sono negoziabili.
  - **Assistenza sanitaria:** Utilizzare l'inserimento per la risoluzione dell'identità del paziente e i record conformi all'HIPAA, che consente visualizzazioni unificate e protette.
  - **Dettaglio:** Consolidare i dati dei _punti vendita (POS)_, dell'eCommerce e dei programmi fedeltà in profili unificati per la segmentazione e la personalizzazione.
  - **Telecom:** Supportare la prevenzione dell'abbandono e l'analisi dell'utilizzo con dati canonici degli abbonati regolati.

#### Criteri decisionali del metodo di inserimento dati

| Funzione                              | Inserimento in tempo reale                                                                                                                                                                         | Inserimento streaming                                                                                                                                           | Inserimento batch                                                                                                                                                                            |
| :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Latenza e freschezza**            | Include l'inserimento di latenza al di sotto del secondo tramite le API di inserimento con supporto per l'_acquisizione dati (CDC)_. Fornisce opportunità in streaming continue. Adatto a casi d'uso operativi a bassa latenza. | Include l'inserimento di micro batch ogni 1–3 minuti tramite connettori nativi. Supporta gli aggiornamenti incrementali. È prevista una leggera latenza.                             | La latenza dei dati è prevista. Consente carichi pianificati a volume elevato. Include l'inserimento periodico (orario, giornaliero e settimanale). Non adatto per operazioni sensibili al tempo.                        |
| **Casi d'uso principali**                | Ideale per casi d'uso operativi e di personalizzazione a bassa latenza. Utilizzare per i flussi di lavoro sensibili al tempo. Supporta i flussi di lavoro basati sugli eventi. Utilizzare per gli avvisi di frode in tempo reale e gli avvisi operativi.  | Adatto per processi moderatamente urgenti. Utilizzare per l'orchestrazione delle campagne, il coinvolgimento quasi live e la generazione di rapporti operativi. Utilizzare per trigger campagna tempestivi.  | Economico per serie di dati di grandi dimensioni. Affidabile per l'analisi storica. Utilizzare per l'aggregazione storica o i flussi di lavoro dei rapporti regolamentati. Adatto a serie di dati storiche o a bassa velocità. |
| **Complessità architettonica e I/O** | Include un costo elevato e un'architettura complessa. Richiede sistemi di origine a bassa latenza. I/O intensivo. Fonti a volume elevato possono causare pipeline sature.                                         | Presenta un'architettura più semplice rispetto a quella in tempo reale. I/O è moderato. Adatto a schemi di aggiornamento prevedibili e ripetuti. Le dimensioni del batch influiscono sulla memoria e sul calcolo. | Facile da implementare. I/O intensivo durante le finestre di carico. La produttività della rete può diventare un collo di bottiglia per batch di grandi dimensioni.                                                                        |
| **Considerazioni sui costi**              | Include i costi di elaborazione e pipeline più elevati. Giustificabile solo per i flussi di lavoro di valore elevato e sensibili al tempo.                                                                                 | Include costi moderati di elaborazione e memoria. Offre un approccio bilanciato tra costo e freschezza. Adatto per aggiornamenti frequenti che possono tollerare lievi ritardi.   | Offre costi di calcolo inferiori e memoria prevedibile. Consigliato per le serie di dati storiche o gli aggiornamenti a bassa frequenza. L'inserimento tramite pipeline interne Salesforce è gratuito.                   |
| **Processi di progettazione**                 | Utilizzare CDC incrementale per ridurre al minimo il rimescolamento dei dati. Filtrare e utilizzare i campi selettivi per ridurre il sovraccarico.                                                                                         | Utilizzare i micro batch per controllare i picchi di I/O. Considerare l'aggregazione con finestre per ridurre il carico di elaborazione.                                                             | Utilizzare per rapporti di archivio o istantanee periodiche. Assicurarsi che la località di calcolo si trovi nella stessa regione dello spazio di archiviazione sorgente per ottimizzare i costi.                                              |

### Federazione dati copia zero

#### Casi d'uso copia zero

Utilizzare _Copia zero_ per eseguire query in tempo reale su sistemi esterni senza duplicazione dei dati per consentire agilità, freschezza e accesso scalabile a serie di dati di grandi dimensioni o temporanee. È adatto per cruscotti digitali live, analisi esplorative, formazione sui modelli AI/ML e coinvolgimento dei clienti in tempo reale direttamente tramite Salesforce _Data 360_.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360 Zero Copy.png" alt="Panoramica della federazione dei dati con copia zero" />

#### Metodi copia zero

Quando si utilizza _Zero Copy_, gli architetti devono scegliere tra tre metodi di federazione dei dati disponibili, ciascuno dei quali offre i propri compromessi tra freschezza, prestazioni e costo.

- **Query live**
  - Esegue query direttamente sui sistemi esterni (ad esempio, _Snowflake_, _Google BigQuery_, _Redshift_, _Databricks_ e così via) senza duplicazione dei dati.
  - Riduce al minimo lo spostamento dei dati sulla rete e riduce l'I/O nel calcolo di Salesforce _Data 360_, che è ottimale quando predicati e aggregazioni possono essere sottoposti a push.
  - Adatto per approfondimenti in tempo reale e cruscotti digitali operativi a bassa latenza.
  - Dipende dalle prestazioni del sistema esterno.
- **Caching (query accelerata)**
  - Archivia temporaneamente le copie memorizzate nella cache dei dati federati in Salesforce _Data 360_.
  - Riduce i costi di query ripetute e la latenza per le serie di dati a cui si accede di frequente con durata configurabile (da minuti a giorni).
  - Poiché i dati non vengono copiati in modo permanente o completamente governati, l'aggiornamento viene gestito tramite aggiornamenti pianificati dall'origine.
  - L'_aggiornamento incrementale_ supporta solo gli inserimenti con aggiornamento. I record eliminati non vengono rimossi dalla cache.
  - Eseguire periodicamente un aggiornamento completo per assicurarsi che la cache rimanga sincronizzata con l'origine.
  - **Nota:** Il connettore _Snowflake_ supporta la funzione _Scarica_, che migliora le percentuali di accelerazione utilizzando un bucket di gestione temporanea avviato da Snowflake. Questa opzione è abilitata per impostazione predefinita, ma può essere disabilitata modificando la connessione.
- **Federazione file**
  - Fornisce accesso diretto in sola lettura alle serie di dati su larga scala negli archivi di oggetti (ad esempio, _S3_ e _GCS_ con _Iceberg_).
  - Adatto per carichi di lavoro AI/ML, analisi storica e rapporti su scala petabyte senza spostare i dati.
  - Le prestazioni delle query dipendono fortemente dal formato dell'oggetto, dal partizionamento e dall'ingresso/uscita di rete. Le analisi di grandi dimensioni possono generare I/O sostanziali se non sono ottimizzate.

#### Playbook architetto

- **Casi d'uso**
  - La **personalizzazione in tempo reale e** i flussi di lavoro adattativi offrono offerte dinamiche, consigli e azioni Next Best quando cambiano i comportamenti dei clienti.
  - I **cruscotti digitali live e** i cruscotti digitali e i KPI business critical vengono utilizzati direttamente dai magazzini esterni.
  - L'**addestramento del modello AI/ML con serie di dati esterne di grandi dimensioni** sfrutta i dati su scala petabyte di data lake e magazzini senza spostarli tramite federazione file.
- **Scenari di settore**
  - **Retail/Media:** Abilitare i consigli personalizzati e il coinvolgimento dei clienti in tempo reale federando i dati di clickstream o di interazione con i contenuti.
  - **Finanza:** Eseguire il rilevamento delle frodi e il calcolo del punteggio del rischio quasi in tempo reale eseguendo query sui magazzini esterni senza duplicare dati sensibili.
  - **Tecnologia/impresa:** Supportare i rapporti tra cloud, i cruscotti digitali dei servizi IT e l'analisi operativa quando le serie di dati risiedono in più sistemi.
- **Processi di progettazione**
  - **Query live**
    - Utilizzare per query con QPS elevato e bassa latenza quando la freschezza è critica.
    - Inviare tramite push predicati e aggregazioni al sistema esterno per ridurre il rimescolamento dei dati sulla rete.
    - Evitare query che eseguono inutilmente analisi di volumi di dati elevati.
    - Considerare invece la potatura delle partizioni e i filtri.
  - **Federazione file**
    - Accedere alle serie di dati su scala petabyte negli archivi di oggetti senza inserimento.
    - Ridurre al minimo i costi di latenza e uscita mantenendo lo spazio di archiviazione degli oggetti nella stessa area Cloud del calcolo Salesforce.
    - Utilizzare formati partizionati e colonnari (Parquet/ORC) e filtri pushdown per ridurre il trasferimento di I/O e di rete.
    - Sfruttare il pushdown di query e predicati per filtrare e aggregare i dati alla fonte, riducendo così lo spostamento dei dati.
    - Evitare l'accesso ai dati tra regioni, a meno che non sia assolutamente necessario, perché aumenta I/O, latenza e costi.
  - **Caching (query accelerata)**
    - Inserire nella cache le serie di dati a cui si accede di frequente per bilanciare costi e prestazioni.
    - Configurare gli intervalli di aggiornamento per bilanciare freschezza e costo delle query.
  - **Conformità:** Applicare la governance all'origine sfruttando la _protezione a livello_ di riga e mascherando le policy direttamente all'interno dei sistemi federati.
    - Di seguito sono riportate alcune procedure consigliate per uniformare l'RLS e il mascheramento tra le piattaforme:
      - **Utilizzare un ID Enterprise centralizzato.** Mappare utenti ed entità in Salesforce _Data 360_ a un identificatore aziendale centralizzato univoco che corrisponde alle identità nei sistemi esterni.
      - **Allineare le policy di sicurezza.** Assicurarsi che le policy di protezione dal traffico e mascheramento nei sistemi federati vengano applicate in base all'identità mappata. Ciò mantiene la conformità durante le query sui dati esterni.
      - **Standardizzare gli schemi di identità.** Mantenere attributi di identità coerenti (email, ID utente, ID cliente e così via) in tutte le fonti di dati per evitare mancate corrispondenze e violazioni dell'accesso.
- **Considerazioni sui costi**
  - **Query live:** Nel modello pay-per-query, i costi si accumulano per il calcolo delle case sul lago esterne, che può causare picchi con QPS elevato. Questo è adatto per i casi d'uso critici per la freschezza in cui il valore è maggiore della variabilità dei costi.
  - **Query accelerata (Caching):** Questo metodo riduce il costo delle query (rispetto a _Live Query)_ riducendo gli attacchi al sistema di origine; tuttavia, aumenta i costi di inserimento dati batch per il riempimento e l'aggiornamento della cache. È adatto per le serie di dati a cui si accede di frequente.
  - **Federazione file:** Questa è l'opzione di archiviazione più economica come dati nell'archivio oggetti; tuttavia, i costi delle query dipendono dalle dimensioni del file, dal partizionamento e dalla potatura. Questo è adatto per i dati storici o in blocco su scala petabyte.

#### Criteri decisionali metodo copia zero

| Punto Decisione           | Live query                                                                                                                                                                                                                    | Caching (query accelerata)                                                                                                                                | Federazione file                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Posizione fonte di dati** | Case data lake esterni (ad esempio, _Snowflake_, _Google BigQuery_, _Redshift_ e _Databricks_)                                                                                                                         | Case data lake esterni (ad esempio, _Snowflake_, _Google BigQuery_, _Redshift_ e _Databricks_)                                                      | Object Store o data lake Cloud (ad esempio, _S3_, _ADLS_ e _GCS_), che spesso utilizzano formati di tabelle aperte come _Iceberg_.                                                                                                                                                                                                                                                                                                                                                     |
| **Scopo/Caso d'uso**     | Adatto per analisi interattive e cruscotti digitali in tempo reale. Adatto alla personalizzazione in tempo reale e ai flussi di lavoro dinamici.                                                                                                     | Adatto per quando le query sono frequenti, ma i risultati leggermente obsoleti sono accettabili. Adatto per cruscotti digitali BI e segmentazione.                            | Adatto per l'elaborazione batch su larga scala e l'addestramento del modello AI/ML. Adatto per analisi storiche e rapporti su scala petabyte.                                                                                                                                                                                                                                                                                                                                              |
| **Freschezza/latenza**    | Esegue le query direttamente in tempo reale. Supporta le decisioni al di sotto dei secondi quando il sistema di origine è ottimizzato per le query a bassa latenza con pushdown del predicato efficace.                                 | Utilizzare quando i risultati leggermente obsoleti sono accettabili. La freschezza dipende dall'intervallo di cache, che è configurabile da 15 minuti a 7 giorni.                  | Adatto per lavori intensivi e con un'elevata produttività. Non adatto per il cruscotto digitale in tempo reale.                                                                                                                                                                                                                                                                                                                                                                                    |
| **Schema di accesso**       | Adatto per query rare o ad hoc in cui la freschezza è fondamentale e il volume delle query è basso. I costi aumentano in modo significativo con QPS elevato, quindi è importante valutare il caching (query accelerata) quando la frequenza delle query è elevata. | Adatto a scenari di lettura ad alta frequenza. Migliora le prestazioni per gli schemi di accesso frequenti.                                                             | Fornisce l'accesso *di sola lettura*. Adatto per serie di dati su scala petabyte senza inserimento.                                                                                                                                                                                                                                                                                                                                                                                             |
| **Driver delle prestazioni**  | Molto dipendente dalle prestazioni del sistema sorgente esterno. Adatto per quando predicati e aggregazioni possono essere inviati alla fonte.                                                                                     | Riduce la latenza rispetto alle query live ripetute. Le prestazioni dipendono dalla gestione della cache e dagli intervalli.                                             | Le prestazioni dipendono fortemente dal formato dell'oggetto, dal partizionamento e dalla produttività del sistema esterno. Utilizzare formati partizionati e colonnari (Parquet/ORC).                                                                                                                                                                                                                                                                                                                                     |
| **Implicazioni sui costi**    | Questo è un modello pay-per-query, quindi i costi si accumulano sui calcoli delle case sul lago esterne. È conveniente per le query poco frequenti, ma le spese possono aumentare con un volume QPS elevato.                                                  | Il costo è inferiore rispetto alle query live ripetute. Riduce la necessità di eseguire ripetutamente query sulla fonte esterna, ma aggiunge memoria cache e sovraccarico di aggiornamento. | Questa è l'opzione di memoria più economica. Per le impostazioni AWS same-region e same-cloud (ad esempio, _S3_ in US-East-1 con un tenant _Data Cloud_ presente anche in US-East-1), i crediti non vengono consumati per le righe a cui si accede. Le configurazioni tra regioni o tra cloud (ad esempio, _Azure_, _GCS_ o regioni _AWS_ diverse) comportano il consumo di credito per le righe a cui si accede. I costi delle query dipendono anche dalle dimensioni del file, dal partizionamento e dall'ottimizzazione del pushdown del predicato. |
| **Considerazione chiave**    | Evitare le query non filtrate che eseguono la scansione di volumi di dati elevati inutilmente.                                                                                                                                                        | Questo approccio richiede la gestione della cache. Non adatto per decisioni subsecondarie.                                                                          | Le prestazioni delle query dipendono fortemente dall'ottimizzazione tramite partizionamento e pushdown del predicato.                                                                                                                                                                                                                                                                                                                                                                                        |

### Approccio ibrido

Le architetture ibride consentono agli architetti di ancorare le serie di dati critiche in _Data 360_ per una governance centralizzata, sfruttando al contempo le query federate per garantire freschezza, riduzione delle duplicazioni e accesso scalabile a serie di dati esterne di grandi dimensioni. Questo approccio bilancia I/O, località di calcolo, costi e requisiti di conformità.

#### Casi d'uso ibridi

Utilizzare un approccio ibrido per una governance equilibrata, freschezza ed efficienza operativa combinando l'inserimento dei dati e la copia zero per offrire approfondimenti fruibili in tempo reale. Utilizzare l'inserimento per le serie di dati regolamentate di valore elevato in cui sono richiesti tracciabilità, RLS e mascheramento e la federazione per le serie di dati effimere o a volume elevato in cui freschezza e prestazioni sono fondamentali.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Copy of Hybrid.png" alt="Panoramica dell&apos;approccio ibrido" />

#### Playbook architetto

- **Casi d'uso**
  - **Coinvolgimento Omnicanale:** Combinare i dati storici dei clienti con il comportamento in tempo reale per offrire esperienze coerenti e sensibili al contesto.
  - **Condotte AI/ML:** Addestrare i modelli su serie di dati canoniche curate arricchendole con segnali grezzi o in tempo reale provenienti da fonti esterne.
  - **Conformità mista e agilità richiedono:** Applicare una governance rigorosa per i dati sensibili e una federazione per l'agilità operativa.
- **Scenari di settore**
  - **Dettaglio:** Utilizzare _l'inserimento_ per la risoluzione dell'identità e l'unificazione dei profili e _la federazione_ per le offerte e la personalizzazione in tempo reale.
  - **Assistenza sanitaria:** Gestire i record paziente dorati tramite _inserimento_ utilizzando _federation sugli_ stream di dispositivi IoT e i dati dei sensori per il contesto immediato.
  - **Servizi finanziari:** Inserire i dati regolamentati in un lago regolamentato dalla conformità utilizzando _federation_ per il rilevamento delle frodi esterne e le query di monitoraggio del rischio.
- **Processi di progettazione**
  - **Ancora governance con inserimento:** Inserire dati di valore elevato o regolamentati nei modelli canonici per garantire Trust e conformità.
  - **Utilizza Federation for Freshness:** Consente alle case sul lago esterne di fornire l'accesso ai dati in tempo reale o su larga scala senza duplicazioni.
  - **Costo del bilanciamento rispetto alle prestazioni:** Profilare i carichi di lavoro per determinare quando utilizzare _l'inserimento_ rispetto alla _federazione_, riducendo al minimo i costi di archiviazione e query non necessari.
  - **Applica governance a livelli:** Applicare una governance centralizzata per i dati inseriti sfruttando i controlli di sicurezza dei sistemi federati (ad esempio, RLS e mascheramento).
  - **Nota:** Quando si progettano opportunità ibride in corso di realizzazione, è importante garantire l'inserimento incrementale delle serie di dati storiche e inviare aggregazioni push o filtri alle fonti federate per ottimizzare l'I/O e l'utilizzo del calcolo.
- **Considerazioni sui costi**
  - Soppesare il costo totale rispetto alle prestazioni combinando _l'inserimento_ di dati critici o di conformità con la _federazione_ quando è necessario un aggiornamento.
  - Tenere conto degli I/O e della distribuzione dei calcoli quando si combinano _inserimento_ e _federazione_. Per ridurre il costo di calcolo delle query ripetute rispetto ai sistemi di origine, utilizzare il caching (Query accelerata) per le serie di dati federate di lettura elevata e accesso frequente.
  - Utilizzare questa regola per guidare la decisione di inserimento e federazione: quando l'accesso ai dati è frequente ma le modifiche non sono frequenti, la _query accelerata_ è in genere più conveniente. Tuttavia, quando i dati cambiano spesso (in base alla frequenza di accesso), è più appropriato eseguire _una Live Query_ o _un'inserimento_. Ecco alcuni esempi di costi:
    - **L'accelerazione vince:** Un cruscotto digitale creato a partire da 1 milione di record e aggiornato quotidianamente con circa 10.000 modifiche viene visualizzato 20 volte al giorno. I costi _di accelerazione_ equivalgono a circa ~600 crediti/mese rispetto a ~4.200 crediti/mese per _le query live_.
    - **La Live Query vince:** Segmenti pubblicati 20 volte al giorno utilizzando dati che cambiano ogni 30 minuti. _Le query live_ costano circa ~ 4.200 crediti/mese rispetto a ~ 28.800 crediti/mese per l'_accelerazione_ con questa frequenza di aggiornamento.

## Guida alle decisioni dei casi d'uso

Vediamo più in dettaglio alcuni archetipi comuni che illustrano come applicare questa logica.

- **L'archetipo "Un'unica fonte di verità": Centralizzare e gestire**
  - **Scenario:** È necessario creare profili _Customer 360_ unificati conformi per l'intera azienda globale. I dati provengono da una dozzina di sistemi diversi, devono rispettare rigidi regolamenti _GDPR_ e _CCPA_ e fungeranno da fonte di verità per tutte le interazioni di marketing e servizio.
  - **Schema consigliato:** **Inserimento dati.** La priorità qui è governance, Trust e controllo. L'inserimento dei dati in _Data 360_ è l'unico modo per creare un profilo canonico completamente controllabile e isolato dai sistemi di origine.
- Archetipo **di "Approfondimenti in tempo reale": Analisi senza spostamento**
  - **Scenario:** Il team di data science deve eseguire query esplorative su una tabella di transazioni massiccia e in costante aggiornamento in _Snowflake_. Allo stesso tempo, il team direttivo desidera un cruscotto digitale _BI_ live basato sugli stessi dati. Lo spostamento giornaliero di petabyte di dati è lento e costoso.
  - **Schema consigliato:** **Federazione copia zero.** La priorità in questo caso sono velocità, agilità ed efficienza economica su larga scala. _Zero Copy_ consente di sfruttare la potenza del data warehouse esistente per le query in tempo reale senza sovraccarico e latenza di duplicazione dei dati.
- Archetipo **di "Intelligenza ibrida": Governare il core, federare l'edge**
  - **Scenario:** Si desidera arricchire i profili cliente governati e inseriti con segnali comportamentali in tempo reale (ad esempio, clic sul sito Web) provenienti da un data lake. È necessaria la stabilità del profilo centrale ma l'immediatezza dei dati live per favorire la personalizzazione immediata.
  - **Schema consigliato:** **Un approccio ibrido.** Utilizzare _l'inserimento dati_ per creare un nucleo stabile governato per i dati dei clienti. Utilizzare _Copia zero_ per federare i dati volatili in tempo reale e unirli insieme al momento della query per una visualizzazione completa e aggiornata.

## Percorso in avanti

La strategia per i dati aziendali non si concentra più sulla scelta di un unico modello di integrazione, ma sull'architettura di una flessibilità controllata all'interno di un ecosistema di dati interoperabile. L'approccio corretto mappa ogni sistema di origine allo schema più adatto ai suoi requisiti di freschezza, governance, costo e accesso:

- Inserire serie di dati regolamentate mission-critical in Salesforce _Data Cloud_ per la conformità, la risoluzione dell'identità e i flussi di lavoro operativi.
- Federare i dati tramite _Zero Copy_ per analisi live, esplorative e basate sull'intelligenza artificiale senza duplicare l'archiviazione.
- Applicazione del _caching (query accelerata)_ per ridurre il carico del sistema di origine e il consumo di credito quando la frequenza delle query è alta e la frequenza di modifica dei dati è bassa

Salesforce _Data 360_ su _Hyperforce_ offre resilienza e scalabilità multiregione. La sua casa sul lago aperta con tabelle _Iceberg_ consente la separazione dei calcoli e l'interoperabilità con piattaforme come _Snowflake_, _Databricks_ e _S3 Iceberg,_ che costituisce la spina dorsale di un ecosistema di dati multi-cloud davvero interoperabile.

Man mano che gli ecosistemi di dati si evolvono, dobbiamo bilanciare costantemente freschezza, costo, prestazioni e conformità per mantenere l'agilità dell'architettura. Ecco perché è importante rendere la piattaforma a prova di futuro unificando i dati gestiti inseriti con accesso federato. Ciò consente l'intelligenza in tempo reale, l'attivazione dell'intelligenza artificiale e la personalizzazione su scala aziendale in cloud, regioni e domini aziendali.

Tenere presente che le soluzioni valide per tutti non sono adatte alla maggior parte delle aziende. La strategia ottimale mappa lo schema corretto al driver aziendale corretto.

## Informazioni sugli autori

**Yugandhar Bora** è un architetto di ingegneria del software di Salesforce specializzato in architettura dei dati all'interno della piattaforma Data and Intelligence Applications. Dirige iniziative dell'_Enterprise Architecture Review Board_ incentrate sulla governance dei dati e sui modelli di dati unificati, contribuendo anche alle soluzioni di provisioning automatico della piattaforma.

**Jan Fernando** è Principal Architect presso lo _Office of the Chief Architect (_OCA) di Salesforce, che è entrato a far parte di Salesforce nel 2012. Prima di entrare nell'OCA, ha trascorso oltre un decennio nell'organizzazione _Platform_, dove ha guidato diverse trasformazioni tecnologiche chiave.

<!-- document id=0e2dcc8ef124c51aa70ddfb1943491574722b0e7fb6a02ce615f464259e7d73e url=/architect/current/it-it/decision-guides/guides/data-360-provisioning.md -->

# Provisioning di Data 360

Salesforce Data 360 è una piattaforma dati basata su [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/) che unifica Salesforce e i dati esterni in una visione chiara, completa e affidabile a 360 gradi di ogni cliente o account.

Le aziende spesso gestiscono più organizzazioni Salesforce a causa di fusioni e acquisizioni, operazioni regionali, separazione funzionale o per motivi storici. Gli architetti devono prendere diverse decisioni su Data 360, che influiscono su governance, conformità, costo, latenza e capacità dell'organizzazione di scalare l'intelligenza artificiale e le funzionalità tra organizzazioni.

## Panoramica della guida

Questa guida fornisce un framework per prendere decisioni sul provisioning con Data 360\. Queste decisioni includono:

- Selezione di una singola organizzazione iniziale rispetto a una configurazione multi-organizzazione

- Provisioning di più istanze di Data 360 indipendenti

  - Utilizzare Data Cloud One per unificare le organizzazioni in un'unica istanza

  - Collaborazione tra istanze di Data 360 indipendenti che utilizzano la condivisione dei dati tra le organizzazioni Data 360

Data 360 viene eseguito automaticamente il provisioning in qualsiasi organizzazione di produzione che riceve una licenza Data 360. Data Cloud One è l'architettura di connettività multi-organizzazioni di Salesforce che consente a una singola organizzazione domestica di ospitare l'istanza di Data 360, mentre le altre organizzazioni Salesforce si connettono come organizzazioni secondarie. La scelta dell'organizzazione che detiene la licenza Data 360 e che quindi diventa un'organizzazione di casa Data 360 è una decisione architettonica critica con conseguenze a lungo termine.

Il modo in cui si esegue il provisioning di Salesforce Data 360 è una decisione architettonica fondamentale. Determina in che modo l'azienda unifica i dati dei clienti, impone la governance e abilita le funzioni critiche della piattaforma, in particolare AI, Agentforce e Analytics in tutta l'organizzazione. L'ancoraggio di un cluster di organizzazioni a un unico Data 360 fornisce un modello di dati unificato, una governance centralizzata e consente la preparazione dell'intelligenza artificiale a livello aziendale. Le organizzazioni associate possono accedere ai metadati e alle funzioni condivise come se i dati fossero locali. Al contrario, più istanze indipendenti di Data 360 sono appropriate quando i requisiti normativi, di conformità o di autonomia impediscono la centralizzazione. La condivisione dei dati tra le organizzazioni Data 360 consente la collaborazione selettiva e senza copia tra queste istanze.

Questa decisione influenza chi controlla la governance dei dati, dove risiedono i dati, come sono abilitate le funzioni della piattaforma e quanto facilmente le integrazioni future e le iniziative di intelligenza artificiale possano scalare. Anche per le organizzazioni che attualmente non dispongono di Data 360, può essere importante sviluppare una strategia per aggiungere l'accesso a Data 360 in futuro. Sempre più spesso, le funzioni di Salesforce in Sales, Service, Marketing, Commerce, Industries e Agentforce sono basate su Data 360\. Le organizzazioni che desiderano utilizzare queste funzioni della piattaforma devono eseguire il provisioning di Data 360 o connettersi a Data 360 condiviso come organizzazioni secondarie.

Questa guida aiuta gli architetti a progettare una strategia di provisioning che bilancia semplicità, coerenza a livello aziendale, conformità e scalabilità, garantendo che l'organizzazione possa sfruttare con sicurezza Data 360 per Customer 360, AI e innovazione multipiattaforma. Utilizzare questa guida per determinare quali organizzazioni richiedono Data 360 e se utilizzare Data Cloud One o la condivisione dei dati tra le organizzazioni Data 360. Questa strategia getta le basi per un futuro incentrato su Data 360.

## Prodotti nell'ambito

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/data360-logo.png" alt="Logo Salesforce Platform"></td>
      <td>Salesforce Data 360 è la piattaforma dati iperscala in tempo reale di Salesforce che armonizza e unifica i dati di qualsiasi fonte (CRM, Web, mobile o data lake esterni) in un unico profilo cliente fruibile. Come componente fondamentale della piattaforma <a href="https://www.salesforce.com/products/what-is-customer-360/">Customer 360</a>, supporta l'intelligenza artificiale, l'analisi e le esperienze personalizzate in termini di vendite, assistenza e marketing.</td>
    </tr>
  </tbody>
</table>

## Takeaway

- **Ogni organizzazione deve pianificare l'accesso a un'istanza di Data 360.** Ogni organizzazione deve ospitare un'organizzazione iniziale Data 360 o essere un'organizzazione associata connessa tramite Data Cloud One.

- **Pensare a livello aziendale, non organizzazione per organizzazione.** Evitare decisioni unilaterali sulla linea di business prese isolatamente. L'ideale è che un'architettura aziendale o un consiglio di governance dei dati decidano collettivamente la strategia di provisioning. Anticipare sempre le esigenze future di intelligenza artificiale e analisi, che dipendono da serie di dati ampie e unificate.

- **Pianificare la governance e la proprietà in anticipo.** Decidere se gestire Data 360 in modo centralizzato (modello Centro di eccellenza) o delegato alle linee di business. Definire i ruoli per amministratori, team di sicurezza e lead di conformità. Evitare ambiguità, poiché la proprietà non chiara può essere problematica.

- **Ricordare che il provisioning è legato alla licenza.** L'organizzazione in cui viene acquistata la licenza Data 360 determina dove viene eseguito il provisioning di Data 360 e la posizione dell'organizzazione determina la regione.

- **Comprendere le considerazioni sul supporto delle fonti di dati.** Prestare molta attenzione alle regioni supportate per i vari cloud pubblici e le fonti di dati a copia zero. Determinare inoltre se Private Connect è necessario per il proprio comportamento di sicurezza per connettersi a tali fonti di dati e se sono supportate le connessioni in-region o tra regioni.

- **Eseguire il provisioning a seconda che si disponga di un'organizzazione singola o multipla.** Per i clienti con una sola organizzazione, eseguire il provisioning di Data 360 nell'organizzazione di produzione esistente per ottimizzare il time-to-value. Per i clienti multi-organizzazione, ridurre al minimo la complessità creando il minor numero possibile di istanze di Data 360, idealmente utilizzando la configurazione Data Cloud One.

- **Utilizzare** **più istanze di Data 360 solo quando necessario.** Più istanze devono essere utilizzate solo quando richiesto dalla conformità, dalla residenza o dall'autonomia organizzativa. In questi casi, utilizzare la [condivisione dei dati](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5) tra le organizzazioni Data 360 per consentire una collaborazione sicura.

- **Impostare la condivisione dei dati tra le organizzazioni Data 360 per la collaborazione, non per le pipeline ETL personalizzate.** Condividere oggetti specifici (DMO, approfondimenti calcolati, segmenti) tramite condivisioni dati. Ricordare che i tag non vengono condivisi e che il consumo viene fatturato all'organizzazione di origine.

- **Evitare le scelte rapide.** Non creare più organizzazioni Data 360 per la prova dei concetti (POC) senza un piano a lungo termine. Allineare le distribuzioni pilota e iniziali alla strategia di provisioning a livello aziendale.

## Punti decisione

Valutare ogni scelta di provisioning (scelta tra Data Cloud One, condivisione dei dati tra le organizzazioni Data 360 o designazione dell'organizzazione di residenza) in base a queste considerazioni trasversali.

<table>
  <tr>
    <th>Considerazione</th>
    <th>Perché è importante</th>
    <th>Scenari di esempio</th>
  </tr>
  <tr>
    <td>Data Residency e conformità</td>
    <td>Determina dove vengono memorizzati ed elaborati i dati. Le norme normative possono richiedere regioni specifiche o più istanze.</td>
    <td>Una banca globale esegue il provisioning di un tenant Data 360 in un'organizzazione Salesforce geolocalizzata a Francoforte per la conformità al GDPR. Fornisce un altro tenant in un'organizzazione in Virginia per la divisione statunitense.</td>
  </tr>
  <tr>
    <td>Governance e sicurezza</td>
    <td>Identificare un amministratore e la proprietà di Data 360, incluse la gestione delle policy e le strategie di delega.</td>
    <td>Una multinazionale con forte centralità IT crea un'organizzazione home dedicata gestita da un Centro di Eccellenza.</td>
  </tr>
  <tr>
    <td>Autonomia e centralizzazione</td>
    <td>Leader diversi possono volere una proprietà separata dei dati. L'autonomia favorisce più organizzazioni Data 360. La centralizzazione favorisce Data Cloud One.</td>
    <td>Una holding con società controllate indipendenti consente a ogni unità operativa di eseguire il proprio Data 360.</td>
  </tr>
  <tr>
    <td>Latenza e prestazioni</td>
    <td>Influisce sulla velocità e l'esperienza delle query, in particolare per le organizzazioni associate a un tenant di Data 360 nelle varie regioni.</td>
    <td>Un team di vendita di Londra che esegue query sui dati di un tenant di Data 360 negli Stati Uniti può riscontrare una latenza più elevata.</td>
  </tr>
  <tr>
    <td>Complessità dell'integrazione</td>
    <td>Altri tenant di Data 360 = altre opportunità in corso di realizzazione, API e middleware. Il consolidamento semplifica l'integrazione.</td>
    <td>Un rivenditore evita la creazione di 10 pipeline ETL consolidandole in una configurazione Data Cloud One.</td>
  </tr>
  <tr>
    <td>Regione fonte di dati copia zero</td>
    <td>I requisiti di accesso tra regioni per alcuni connettori possono limitare la regione o la posizione dell'organizzazione Data 360.</td>
    <td>Una società ha un'istanza Snowflake nella regione AWS eu-west-1. Possono utilizzare Copia zero per federare i dati in un Data 360 nella loro regione, ma non possono utilizzare Copia zero per federare in un Data 360 nella regione degli Stati Uniti.</td>
  </tr>
  <tr>
    <td>Compatibilità tra regioni di Private Connect</td>
    <td>A volte, il supporto di Private Connect dipende dal fatto che la fonte di dati si trovi nella stessa regione del tenant di Data 360.</td>
    <td>Una società ha un'istanza Snowflake nella regione aws-east-1 che desidera connettersi a Data 360 tramite copia zero. Possono stabilire una connessione di rete Private Connect solo se l'organizzazione di casa Data 360 si trova nella stessa regione.</td>
  </tr>
  <tr>
    <td>Costo e licenze</td>
    <td>Ogni tenant di Data 360 aggiunge un costo. Il raggruppamento in meno istanze ottimizza la spesa.</td>
    <td>Un operatore sanitario riduce i costi delle licenze adottando Data Cloud One anziché più istanze di Data 360 indipendenti.</td>
  </tr>
  <tr>
    <td>Scalabilità futura</td>
    <td>Le scelte di provisioning oggi gettano le basi per la crescita.</td>
    <td>Una società SaaS inizia con una singola istanza di Data 360 ma prevede di espandersi a Data Cloud One quando acquisisce società controllate con organizzazioni Salesforce.</td>
  </tr>
  <tr>
    <td>Preparazione AI a livello aziendale</td>
    <td>Le funzioni AI e Agentforce richiedono un tenant Data 360 connesso in ogni organizzazione. Le decisioni di provisioning influiscono sul modo in cui i modelli di intelligenza artificiale si addestrano e si attivano in tutta l'azienda.</td>
    <td>Una società di servizi finanziari unifica i dati in Data Cloud One in modo che i suoi modelli Einstein AI abbiano accesso ai dati dei clienti a livello aziendale.</td>
  </tr>
</table>

## Casi d'uso

Esistono tre casi d'uso principali che richiedono decisioni per il provisioning di Data 360:

- Scelta dell'organizzazione di origine
- Applicazione di una strategia multi-organizzazioni
- Condivisione dei dati tra le organizzazioni Data 360

### Scelta dell'organizzazione di origine

Quando si acquista una licenza Data 360, l'istanza di Data 360 viene fornita nell'organizzazione Salesforce associata a quella licenza. Questa organizzazione è detta organizzazione iniziale di Data 360. L'organizzazione iniziale è l'anchor per l'istanza di Data 360. Ciò include:

- Gestione dell'archiviazione e del calcolo di Data 360 (nella regione selezionata al provisioning).

- Applicazione delle policy di amministrazione, governance e sicurezza

- Esecuzione di inserimento dati, armonizzazione, risoluzione dell'identità, segmentazione e attivazione

Negli scenari multi-organizzazione, l'organizzazione di origine gestisce l'istanza centrale di Data 360 per le altre organizzazioni Salesforce "companion".

**L'organizzazione iniziale:**

- Determina la posizione geografica dell'istanza di Data 360.

- Determina chi è il titolare e l'amministratore dell'istanza di Data 360. Gli amministratori dell'organizzazione iniziale Data 360 possono accedere a tutti i dati inseriti in Data 360.

- Controlla le connessioni dell'organizzazione associata in una configurazione Data Cloud One.

- Imposta le basi per la strategia dei dati aziendali: modificarla in seguito è difficile e dirompente.

Per ulteriori informazioni sulle organizzazioni Data 360 Home, vedere [Modelli e procedure](/docs/architect/it-it/fundamentals/guide/data360_integration_patterns_and_practices) di integrazione.

#### Decisione: Organizzazione esistente o Nuova organizzazione come organizzazione di origine?

La prima decisione importante è se eseguire il provisioning di Data 360 in un'organizzazione di produzione esistente o creare una nuova organizzazione dedicata che funga da organizzazione di origine.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Existing_Org_vs_New_Dedicated_Org.png" alt="Diagramma decisioni che mostra l&apos;organizzazione esistente rispetto alla nuova organizzazione come organizzazione iniziale" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**Opzione A: Provisioning di Data 360 in un'organizzazione esistente**

**Funziona meglio per:** Clienti con una singola organizzazione Salesforce o clienti multi-organizzazione che hanno già un'organizzazione centralizzata principale in cui vengono eseguiti la maggior parte dei processi aziendali.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_an_existing.png" alt="Schema che mostra il provisioning di Data 360 nell&apos;organizzazione esistente" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **Punti positivi:**

  - Percorso più semplice: Data 360 viene eseguito il provisioning nella posizione in cui si trovano i dati CRM.

  - Accesso immediato ai dati di vendita, assistenza e marketing locali.

  - Non è necessaria alcuna integrazione aggiuntiva.

  - Meno licenze e ambienti da gestire.

  - Accelera l'adozione precoce, i casi d'uso pilota e di produzione.

- **Contro:**

  - Può ereditare la governance o il debito tecnico di un'organizzazione esistente.

  - Se non esiste una singola "organizzazione principale", selezionandone una si possono creare dibattiti sulla proprietà.

  - Le prestazioni sono legate alla posizione dell'organizzazione; potrebbero non essere in linea con le esigenze di residenza a livello aziendale.

  - Se più unità operative utilizzano organizzazioni diverse, il provisioning locale può causare frammentazione se non abbinato a Data Cloud One.

**Esempio:**

Una società SaaS con un'organizzazione Salesforce esegue il provisioning di Data 360 in tale organizzazione per unificare i dati di abbonamento e assistenza dei clienti.

**Opzione B: Provisioning di Data 360 in una nuova organizzazione dedicata**

**Funziona meglio per:** Clienti con più organizzazioni Salesforce che non possono allinearsi su una singola organizzazione principale o aziende con un modello di Centro di eccellenza (CoE) forte.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_new_dedicated_org.png" alt="Schema che mostra il provisioning di Data 360 nella nuova organizzazione dedicata" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **Punti positivi:**

  - Parte pulita per la governance, senza complessità dell'organizzazione ereditate.

  - Controllo centralizzato in più linee di business.

  - Flessibilità di scegliere una regione in base alle esigenze di conformità.

  - Agisce come un'organizzazione di "servizio condiviso" neutrale, non collegata a un'unità operativa.

  - Impostazione per la futura architettura Data Cloud One (organizzazione iniziale con più organizzazioni associate).

- **Contro:**

  - I clienti devono disporre della licenza per una nuova organizzazione Salesforce in cui eseguire il provisioning di Data 360.

  - Integrazione aggiuntiva necessaria per connettere l'organizzazione a Data 360 tramite una connessione Data Cloud One.

  - Può aggiungere spese amministrative (gestione utenti, sicurezza, identità).

  - Time-to-value più lento rispetto al provisioning in un'organizzazione di produzione esistente.

**Esempio:**

Una società multinazionale di servizi finanziari crea un'organizzazione domestica dedicata per il provisioning di Data 360.Tutte le organizzazioni unità operative (Retail, Wealth, Commercial Banking) si connettono come organizzazioni secondarie tramite Data Cloud One.

**Criteri decisionali**

<table>
  <tr>
    <th>Considerazione</th>
    <th>Organizzazione esistente come organizzazione iniziale (predefinita preferita)</th>
    <th>Nuova organizzazione come organizzazione iniziale (alternativa)</th>
  </tr>
  <tr>
    <td>Semplicità</td>
    <td>Si basa sulla struttura di utenti e dati esistente per un'impostazione più rapida.<br> Data 360 è integrato per impostazione predefinita con l'organizzazione iniziale.</td>
    <td>Richiede la licenza e l'impostazione di una nuova organizzazione Salesforce e ulteriori oneri amministrativi per la gestione</td>
  </tr>
  <tr>
    <td>Time-to-Value</td>
    <td>Utilizzo immediato dei dati CRM locali</td>
    <td>È necessaria una rampa e un'integrazione più lente.</td>
  </tr>
  <tr>
    <td>Governance</td>
    <td>Eredita il modello di governance di base dell'organizzazione esistente: utenti e insiemi di autorizzazioni esistenti (può essere accettabile se l'organizzazione è già centrale).</td>
    <td>Da zero per la governance. Ideale per modelli con COE.</td>
  </tr>
  <tr>
    <td>Conformità</td>
    <td>Residenza legata alla regione dell'organizzazione esistente</td>
    <td>Flessibilità di selezionare una regione indipendente dalle organizzazioni esistenti</td>
  </tr>
  <tr>
    <td>Prestazioni</td>
    <td>Migliori prestazioni per le query CRM locali</td>
    <td>A seconda della connettività dell'organizzazione associata, sia che si tratti della stessa regione o di un'area trasversale alle altre organizzazioni</td>
  </tr>
  <tr>
    <td>Scalabilità futura</td>
    <td>Funziona bene se abbinato a Data Cloud One. Più difficile spostarsi in seguito se viene scelta l'organizzazione sbagliata</td>
    <td>Scala facilmente con Data Cloud One. Progettato per la neutralità.</td>
  </tr>
  <tr>
    <td>Costo</td>
    <td>Minor costo incrementale</td>
    <td>Maggiore sovraccarico da ambienti aggiuntivi</td>
  </tr>
</table>

#### Consigli

Come principio generale, utilizzare un'organizzazione principale esistente come organizzazione di origine per ridurre al minimo l'impegno iniziale e accelerare l'adozione. Creare una nuova organizzazione home dedicata solo se la strategia di governance o conformità a lungo termine lo richiede. La creazione di una nuova organizzazione home dedicata è una scelta comune per le aziende più grandi con un Centro di Eccellenza (COE).

**Ambiente organizzazione singola**

Eseguire il provisioning di Data 360 nell'organizzazione di produzione esistente. Ciò massimizza la semplicità e il valore immediato. Evita inutili sovraccarichi di integrazione.

**Ambiente con più organizzazioni**

Preferire selezionare una delle organizzazioni principali, in genere quella in cui si svolge la maggior parte delle attività, o l'organizzazione che funge da CRM centralizzato, per fungere da organizzazione di origine. Ciò riduce la complessità, riduce al minimo il lavoro di impostazione e consente di realizzare rapidamente il valore di Data 360. L'utilizzo di un'organizzazione principale esistente evita inoltre i costi e le operazioni di integrazione della gestione di un nuovo ambiente.

**Quando considerare una nuova organizzazione domestica dedicata**

La creazione di un'organizzazione home offre flessibilità e neutralità, ma in questi casi il time-to-value è più lento.

- Se l'organizzazione ha un Centro di eccellenza (CdE) forte e desidera una governance separata dalle organizzazioni delle unità operative.
- Se nessuna organizzazione esistente è adatta per motivi di conformità o vincoli organizzativi.

### Applicazione di una strategia multi-organizzazioni

#### La sfida multi-organizzazioni

Le aziende spesso gestiscono più organizzazioni Salesforce e questo non è un caso limite, ma la norma. A febbraio 2024, circa 19.000 clienti Salesforce gestivano già più di un'organizzazione Salesforce.

Perché succede?

- **Acquisizioni e fusioni:** Le società appena acquisite apportano le proprie istanze Salesforce.
- **Operazioni regionali:** Organizzazioni separate per UE, Nord America, Asia-Pacifico e così via, spesso per soddisfare le leggi sulla residenza dei dati.
- **Separazione funzionale:** Diverse unità operative (ad esempio Retail Banking, Wealth Management, Insurance) mantengono le proprie organizzazioni per l'autonomia.
- **Isolamento normativo o di sicurezza:** Alcuni settori impongono organizzazioni logicamente distinte per motivi di conformità.
- **Motivi storici o tecnici:** Nel tempo, i clienti accumulano organicamente più organizzazioni.

Ogni motivo ha senso singolarmente, ma insieme creano una frammentazione dei dati. Senza un livello di unificazione, ogni organizzazione ha solo una visione parziale del cliente.

La sfida architettonica: Come si uniscono i dati di tutte le organizzazioni in un'unica fonte di dati veritieri rispettando i requisiti di conformità, governance e autonomia?

---

#### Data Cloud One

Data Cloud One è l'architettura di connettività multi-organizzazione di Salesforce che consente a più organizzazioni Salesforce di condividere una singola istanza di Data 360. È lo schema consigliato per le aziende con più organizzazioni Salesforce.

In qualsiasi cluster Data Cloud One, un'organizzazione Salesforce è designata come organizzazione di origine, che ospita l'istanza di Data 360. Le altre organizzazioni Salesforce si connettono come organizzazioni secondarie, utilizzando i dati unificati e i metadati di Data 360 dell'organizzazione di origine.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies Data 360 DC One.png" alt="Schema che mostra l&apos;architettura di Data Cloud One" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**Come funziona Data Cloud One**

- **Inserimento e unificazione dei dati (organizzazione iniziale)**

  - Tutte le configurazioni di inserimento dati (Salesforce CRM, fonti esterne, streaming, batch) avvengono solo dall'organizzazione di origine.

  - Il tenant di Data 360 collegato all'organizzazione di origine esegue operazioni di risoluzione dell'identità, armonizzazione, modellazione e unificazione in profili cliente affidabili.

  - L'amministrazione, le policy di governance, i tag e il mascheramento di Data 360 vengono applicati centralmente dall'organizzazione di origine.

- **Architettura spazio dati**

  - Dall'organizzazione iniziale, i dati sono organizzati in spazi dati, che fungono da contenitori logici per dati, metadati e processi.

  - Le aziende possono creare spazi dati per marchi, regioni o linee di business.

  - Condivisione spazio dati: Dall'organizzazione iniziale, spazi dati specifici vengono condivisi in modo selettivo con le organizzazioni associate. Ciò garantisce che solo i dati pertinenti (e i metadati associati) vengano trasferiti alle organizzazioni giuste.

- **Condivisione dei metadati**

  Le organizzazioni associate ricevono definizioni dei metadati dall'organizzazione di origine, inclusi oggetti modello di dati (DMO), schema del profilo unificato, approfondimenti calcolati, segmenti [e altro](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) ancora. Questi vengono visualizzati in modo nativo all'interno dell'organizzazione compagna come se fossero asset locali, ma sono collegati all'organizzazione di origine.

- **Funzioni nelle organizzazioni Home Org vs. Companion**
  L'accesso alle funzioni è diverso tra le organizzazioni iniziali e le organizzazioni secondarie. Le organizzazioni associate non possono inserire o unificare i dati e si affidano all'organizzazione di origine per l'inserimento, la modellazione e l'unificazione. Le organizzazioni associate possono accedere ai dati di Data 360 per potenziare le funzioni della piattaforma basate su Data 360 e possono creare approfondimenti locali, segmenti e flussi oltre ai dati condivisi e affidabili. Nella visione futura, possono anche accedere alle funzioni di attivazione.

<table>
  <tr>
    <th>Capacità</th>
    <th>Organizzazione iniziale</th>
    <th>Organizzazione compagna</th>
  </tr>
  <tr>
    <td>Configurare i connettori, creare stream di dati, inserire o federare i dati</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>Creazione ed esecuzione di trasformazioni dati e risoluzione dell'identità</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>Protezione dei dati con spazio dati e autorizzazioni</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Segmentare e prevedere Creare segmenti, approfondimenti e creare modelli Einstein Studio</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Attiva attivazioni Ovunque, azioni dati</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Funzioni della piattaforma: Generatore di prompt, flussi, rapporti, arricchimento [e altro](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&amp;type=5)</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Funzioni basate su Data 360: Centro clienti potenziali, funzioni di Sales e Service Cloud, Agentforce e altro ancora</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
</table>

- **Parità delle funzioni piattaforma**
  Dal punto di vista degli utenti e dei generatori, una volta condivisi i metadati, esistono alcune differenze funzionali tra le organizzazioni home e companion in termini di utilizzo delle funzioni della piattaforma Salesforce. L'elenco delle funzioni supportate è disponibile in [Funzioni Data 360 nelle organizzazioni Companion](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5).

  - Le funzioni di Salesforce Platform, ad esempio flussi, rapporti, Generatore di prompt, cruscotti digitali e altri strumenti nativi della piattaforma, funzionano sia nella pagina iniziale che nelle organizzazioni associate quando i metadati sono disponibili.

  - Le funzioni basate su Data 360, ad esempio Agentforce, Prospecting Center, Sales Cloud Einstein e Service Cloud AI, funzionano perfettamente sia nelle organizzazioni domestiche che nelle organizzazioni associate. Alcune funzioni potrebbero essere in procinto di raggiungere la completa compatibilità, ma l'obiettivo generale è avere la parità di funzioni tra le organizzazioni di casa e le organizzazioni associate per tutte le funzioni cross-cloud che dipendono da Data 360.

- **Modello di consumo**
  Tutta l'attività dell'organizzazione associata (query, esecuzioni di segmenti, flussi attivati da Data 360, utilizzo dell'intelligenza artificiale, registrazione Einstein Trust Layer e così via) consuma crediti Data 360 dall'organizzazione di origine. I flussi di consumo sono unidirezionali: i crediti vengono centralizzati, fatturati e tracciati rispetto all'allocazione di credito dell'organizzazione di origine. Tuttavia, è possibile visualizzare i dettagli per vedere quanti crediti ogni singola organizzazione ha utilizzato in Digital Wallet.
- **Principio di progettazione: Costruzione orizzontale**
  Il costrutto orizzontale in Data 360 è un principio di progettazione fondamentale, implementato principalmente tramite Data Cloud One, che consente a una singola istanza di Data Cloud di estendersi a più organizzazioni Salesforce CRM distinte. L'obiettivo è che ogni nuova funzione rilasciata funzioni sia nella pagina iniziale che nelle organizzazioni associate senza impostazione aggiuntiva. Questa funzionalità garantisce che Data Cloud One non sia solo una scelta dell'architettura dei dati, ma un elemento fondamentale della piattaforma Salesforce in futuro.

---

#### Decisione: Più organizzazioni dati rispetto a Data 360 condiviso (Data Cloud One)

Le aziende con più organizzazioni devono scegliere come e dove localizzare Data 360 all'interno del proprio ecosistema. Vogliono eseguire il provisioning di organizzazioni Data 360 indipendenti in ogni organizzazione o utilizzare Data Cloud One per unificare le organizzazioni in un'unica organizzazione domestica?

**Opzione A: Più organizzazioni Data 360 indipendenti**

Ogni organizzazione Salesforce esegue il provisioning della propria istanza di Data 360.

**Punti positivi:**

- **Autonomia:** Ogni unità operativa o area geografica controlla il proprio Data 360.

- **Semplicità all'interno di ogni organizzazione:** Governance, sicurezza e personalizzazioni sono localizzate.

- **Conformità normativa:** Utile quando è richiesta una rigorosa separazione normativa (ad esempio, i dati non devono attraversare le frontiere).

**Contro:**

- **Silos di dati:** I profili unificati non possono essere raggiunti tra le organizzazioni.

- **Costo maggiore:** Ogni istanza richiede licenza, amministrazione e integrazione. I clienti finiscono per inserire gli stessi dati di origine più volte in più organizzazioni diverse.

- **Lavoro duplicato:** La risoluzione dell'identità, la segmentazione e l'arricchimento devono essere ripetuti in ogni istanza di Data 360.

**Opzione B: One Shared Data 360 (Data Cloud One Cluster)**

Viene eseguito il provisioning di un singolo Data 360 in un'organizzazione domestica, con altre organizzazioni Salesforce connesse come organizzazioni secondarie.

**Punti positivi:**

- **Singola fonte di verità (SSOT):** Tutte le organizzazioni condividono un modello di dati unificato.

- **Efficienza dei costi:** Gestire una sola licenza e infrastruttura Data 360.

- **Governance unificata:** Policy applicate centralmente, controlli di sicurezza e conformità.

- **Arricchimento tra organizzazioni:** Accedere a profili, approfondimenti e segmenti armonizzati nelle organizzazioni associate.

- **Preparazione AI:** Una serie di dati a livello aziendale consente una migliore formazione e attivazione dei modelli AI.

- **Prova futura:** L'aggiunta di nuove organizzazioni complementari è semplice, poiché non sono necessarie nuove organizzazioni Data 360.

**Contro:**

- **Preparazione aggiuntiva:** One Data 360 richiede la pianificazione della connettività da organizzazione a casa.

- **Considerazioni sulla latenza:** Le organizzazioni associate in regioni diverse possono vedere query più lente.

- **Governance complessa:** Se ogni organizzazione ha esigenze di personalizzazione diverse, la governance può essere complessa.

**Opzione C: Più cluster Data Cloud**

A **volte**, la governance, la conformità o altri requisiti aziendali possono rendere impraticabile raggruppare tutte le organizzazioni. Ciò può comportare la necessità di implementare una soluzione ibrida in cui l'azienda gestisca diverse organizzazioni Data 360, ciascuna delle quali è l'organizzazione di origine di un cluster diverso di organizzazioni associate.

**Esempio:**

Una società multinazionale ha organizzazioni Salesforce in varie regioni, tra cui Europa, Stati Uniti e Asia. Per rispettare i regolamenti regionali sulla residenza dei dati, forniscono un Data 360 per ogni regione separata.

**Criteri decisionali**

<table>
  <tr>
    <th>Considerazione</th>
    <th>Più organizzazioni Data 360 indipendenti</th>
    <th>Una condivisione di dati 360 (Data Cloud One)</th>
  </tr>
  <tr>
    <td>Autonomia</td>
    <td>Elevata autonomia per ogni organizzazione o unità operativa</td>
    <td>Governance centralizzata, minore autonomia per organizzazione</td>
  </tr>
  <tr>
    <td>Conformità</td>
    <td>Utile quando è richiesta una separazione rigorosa (ad esempio, leggi regionali)</td>
    <td>Funziona meglio quando la residenza consente la centralizzazione</td>
  </tr>
  <tr>
    <td>Costo</td>
    <td>Licenze e costi amministrativi più elevati</td>
    <td>Più conveniente; una licenza per molte organizzazioni</td>
  </tr>
  <tr>
    <td>Governance</td>
    <td>Frammentato; le policy variano a seconda dell'organizzazione</td>
    <td>Policy centralizzate e coerenti tra le organizzazioni</td>
  </tr>
  <tr>
    <td>Silos di dati</td>
    <td>Ogni organizzazione con la propria visualizzazione Nessuna azienda 360</td>
    <td>Serie di dati unificata, nessuna duplicazione</td>
  </tr>
  <tr>
    <td>AI/Analytics</td>
    <td>Limitato ai dati di ogni organizzazione</td>
    <td>Modelli Enterprise con una maggiore precisione</td>
  </tr>
  <tr>
    <td>Complessità</td>
    <td>Più istanze da gestire, più integrazioni</td>
    <td>Architettura più semplice, meno parti mobili</td>
  </tr>
  <tr>
    <td>Prestazioni</td>
    <td>Ideale per i casi d'uso all'interno dell'organizzazione</td>
    <td>Potenziale aumento della latenza con l'accesso all'organizzazione companion</td>
  </tr>
</table>

---

#### Consigli

**Schema preferito: Data Cloud One**

Per semplificare la governance e ottimizzare i costi nelle aziende multi-organizzazioni, utilizzare una singola organizzazione di residenza con organizzazioni associate connesse.

**Quando utilizzare più organizzazioni Data 360:** Utilizzare più organizzazioni Data 360 solo se la conformità, la residenza o l'autonomia organizzativa lo richiedono strettamente (ad esempio, se le operazioni europee devono rimanere completamente separate dalle operazioni statunitensi a causa della regolamentazione).

**Come scegliere l'organizzazione di origine in Data Cloud One:** Iniziare prendendo in considerazione una delle organizzazioni principali, in genere quella in cui opera la maggior parte delle attività. Il provisioning di Data 360 può ridurre al minimo la complessità e ottimizzare il valore iniziale.

Valutare la possibilità di creare un'organizzazione home dedicata gestita da un team COE, solo se non è adatta alcuna organizzazione esistente.

**Principio generale:**

Negli ambienti multi-organizzazioni, ridurre al minimo il numero di organizzazioni Data 360. Privilegiare Data Cloud One come schema predefinito per ridurre le duplicazioni, abilitare la preparazione all'intelligenza artificiale e semplificare la governance.

### Condivisione dei dati tra le organizzazioni Data 360

#### Necessità di condivisione dei dati

Sebbene Data Cloud One sia l'approccio consigliato per la maggior parte delle aziende, esistono scenari in cui i clienti devono eseguire il provisioning di più istanze di Data 360, tra cui:

- **Conformità regionale.** Un rivenditore multinazionale fornisce un Data 360 nell'UE e un altro negli Stati Uniti. La condivisione dei dati di 360 a Data 360 consente all'azienda di creare approfondimenti dai dati locali e di condividerli con la sede centrale degli Stati Uniti.
- **Collaborazione tra unità operative.** Un conglomerato gestisce organizzazioni Data 360 separate per Retail e Insurance. La condivisione dei dati tra le organizzazioni Data 360 consente agli utenti di accedere a un'unica fonte di dati autorevole senza spostare o copiare. Con la condivisione dei dati tra le organizzazioni Data 360, l'organizzazione Insurance riceve il segmento "High-Value Customer" di Retail per le campagne di cross-selling mirate.
- **Fusioni e acquisizioni.** Una società controllante acquisisce una società controllata con il proprio Data 360.Con due istanze da gestire, la conservazione di silos di dati a breve termine preserva la sicurezza dei dati e l'integrità SSOT. Contemporaneamente, la condivisione dei dati tra due istanze di Data 360 consente la collaborazione necessaria durante la transizione.
- **Cruscotto digitale esecutivo federato.** Una multinazionale diffusa in tutti i continenti fornisce singole organizzazioni Data 360 per regione. I dirigenti desiderano una visualizzazione federata delle prestazioni trimestrali. Ogni Data 360 regionale condivide gli approfondimenti calcolati aggregati con un'"organizzazione esecutiva", abilitando la generazione di rapporti a livello aziendale.

#### Funzionamento della condivisione dei dati

Quando esistono più organizzazioni Data 360, l'unificazione tra di esse non è automatica. La condivisione dei dati da Data 360 a Data 360 consente ai clienti di condividere oggetti specifici tra le istanze di Data 360 senza duplicazioni o opportunità in corso di realizzazione personalizzate. Si tratta di un meccanismo di condivisione dei metadati a copia zero progettato per la collaborazione tra le organizzazioni Data 360.

- Ogni Data 360 viene fornito nella propria organizzazione di origine.

- Gli amministratori possono creare una condivisione dati, un raggruppamento di oggetti specifici che desiderano condividere.

- L'accesso ai dati selezionati è condiviso con Data 360 di un'organizzazione di destinazione, dove gli oggetti vengono visualizzati come se fossero definiti localmente. Solo l'accesso è condiviso, i dati sottostanti rimangono in Data 360 di origine.

- I tag non sono condivisi. Vengono resi disponibili solo gli oggetti non elaborati; l'organizzazione di destinazione deve riapplicare tutti i tag di governance, operativi o AI in base alle esigenze.

#### Differenze principali rispetto a Data Cloud One

- In Data Cloud One, più organizzazioni associate condividono una singola istanza di Data 360. Per garantire la coerenza, funzioni della piattaforma come Agentforce, Prospecting Center e Tableau Next vengono eseguite sugli stessi dati sottostanti.

- Quando si utilizza la condivisione dei dati tra le organizzazioni Data 360, ogni organizzazione ha il proprio Data 360\. Funzioni come Agentforce nell'organizzazione A e nell'organizzazione B operano ciascuna indipendentemente dalla propria istanza locale. Nessuna condivisione avviene automaticamente: è necessario creare condivisioni dati deliberate solo per collaborare su oggetti specifici.

#### Pro e contro della condivisione dei dati tra le organizzazioni Data 360

<table>
  <tr>
    <th>Fattore</th>
    <th>Pro</th>
    <th>Contro</th>
  </tr>
  <tr>
    <td>Residenza dati</td>
    <td>Supporta la separazione regionale abilitando la collaborazione.</td>
    <td>Non elimina la necessità di gestire più organizzazioni Data 360.</td>
  </tr>
  <tr>
    <td>Duplicazione dei dati</td>
    <td>Copia zero; nessuna duplicazione di oggetti.</td>
    <td>Richiede la selezione deliberata degli oggetti da includere in ogni condivisione dati.</td>
  </tr>
  <tr>
    <td>Governance</td>
    <td>La condivisione è esplicita e deliberata (a livello di oggetto).</td>
    <td>Nessun flusso di tag o policy; l'organizzazione di destinazione deve riapplicare la governance.</td>
  </tr>
  <tr>
    <td>Complessità</td>
    <td>Abilita la collaborazione selettiva senza centralizzazione.</td>
    <td>Richiede la gestione di più organizzazioni Data 360 e condivisioni dati.</td>
  </tr>
  <tr>
    <td>**AI/Analytics**</td>
    <td>Analisi artificiale regionale possibile; gli approfondimenti possono essere condivisi tra le organizzazioni.</td>
    <td>Nessuna intelligenza artificiale a livello aziendale a meno che i dati non vengano deliberatamente condivisi.</td>
  </tr>
  <tr>
    <td>**Funzioni della piattaforma**</td>
    <td>Le funzioni basate su Data 360 di ogni organizzazione vengono eseguite in modo indipendente.</td>
    <td>Nessuna condivisione automatica. Rischio di duplicazione se non accuratamente progettato.</td>
  </tr>
  <tr>
    <td>Costo</td>
    <td>Può ridurre la necessità di pipeline ETL.</td>
    <td>Sostiene comunque il costo di più organizzazioni Data 360. Consuma crediti per le query sui dati e la condivisione dei dati.</td>
  </tr>
</table>

#### Criteri decisionali

<table>
  <tr>
    <th>Considerazione</th>
    <th>Data Cloud One (Preferito per più organizzazioni)</th>
    <th>Condivisione dei dati tra organizzazioni Data 360</th>
  </tr>
  <tr>
    <td>Singola fonte di verità</td>
    <td>Sì: tutte le organizzazioni condividono un modello di dati.</td>
    <td>No: ogni Data 360 ha il proprio modello di dati.</td>
  </tr>
  <tr>
    <td>Conformità</td>
    <td>Funziona solo quando la residenza consente la centralizzazione.</td>
    <td>Necessario quando le leggi sulla residenza impediscono la centralizzazione.</td>
  </tr>
  <tr>
    <td>Governance</td>
    <td>Centralizzato, coerente.</td>
    <td>Federato; condivisioni deliberate a livello di oggetto.</td>
  </tr>
  <tr>
    <td>Complessità</td>
    <td>Meno parti mobili, più semplice.</td>
    <td>Più complesso: richiede condivisioni dati di configurazione e più organizzazioni Dati.</td>
  </tr>
  <tr>
    <td>AI/Analytics</td>
    <td>Modelli di intelligenza artificiale a livello aziendale.</td>
    <td>AI regionale. Condividere gli approfondimenti in modo selettivo.</td>
  </tr>
  <tr>
    <td>Funzioni della piattaforma</td>
    <td>Shared Data 360 significa che tutte le funzioni funzionano in modo coerente in casa + compagni.</td>
    <td>Le funzioni vengono eseguite in modo indipendente in ogni Data 360; la condivisione deve essere esplicita.</td>
  </tr>
</table>

#### Consigli

**Se l'azienda ha più organizzazioni Data 360**

- Utilizzare la condivisione dei dati tra le organizzazioni Data 360 per collaborare tra loro anziché creare opportunità in corso di realizzazione personalizzate o duplicare i dati.

- Condividere oggetti specifici (DMO, approfondimenti calcolati, segmenti) creando condivisioni dati e concedendole alle organizzazioni di destinazione.

- I tag non vengono condivisi: l'organizzazione destinataria deve riapplicare i tag per governance, classificazione o arricchimento AI.

**Utilizzare la condivisione dei dati tra le organizzazioni Data 360**

- Per soddisfare i requisiti normativi che impediscono la centralizzazione.

- Mantenere l'autonomia dell'unità operativa abilitando la collaborazione selettiva.

- Fornire cruscotti digitali esecutivi federati in più regioni.

- Collegare gli scenari di M&A in cui il consolidamento non è immediatamente possibile.

**Progettare con attenzione**

Considerare la condivisione dei dati da Data 360 a Data 360 come una strategia di federazione, non come una sostituzione di Data Cloud One.

- Utilizzare la condivisione specifica degli oggetti.
- Evitare la condivisione eccessiva.
- Allineare le condivisioni dati alle esigenze aziendali e di conformità.

#### Ricorda

Pianificare la strategia dati per il provisioning di Data 360 è una decisione architetturale critica a lungo termine che deve essere affrontata a livello aziendale, non organizzazione per organizzazione. Questa prima scelta strategica determina come vengono unificati i dati dei clienti, come viene applicata la governance e come le funzioni essenziali della piattaforma, in particolare intelligenza artificiale e analisi, vengono scalate in tutta l'organizzazione. Pianificare in anticipo i modelli di governance e proprietà ed evitare scelte rapide a breve termine che in seguito potrebbero causare frammentazione e maggiore complessità.

## Risorse

[Cos'è Customer 360?](https://www.salesforce.com/products/what-is-customer-360/)

[Modelli e procedure di integrazione di Data 360](/docs/architect/it-it/fundamentals/guide/data360_integration_patterns_and_practices)

[Architettura di Data 360](/docs/architect/it-it/fundamentals/guide/data-360-architecture)

[Architettura di sicurezza di Data 360](/docs/architect/it-it/fundamentals/guide/data360_security_architecture)

**Informazioni sugli autori**

Kunal Goyal è Direttore della gestione dei prodotti di Salesforce, con l'obiettivo di migliorare l'architettura multi-organizzazioni e la scalabilità all'interno di Data 360.Dal 2017, ha guidato diverse iniziative e prodotti incentrati sulla collaborazione tra organizzazioni e la progettazione di sistemi multi-tenant. Kunal è uno dei lead di Data 360 Best Practices Architecture e titolare del prodotto per le esperienze di Data Cloud One, impostazione, provisioning e amministrazione.

Erin Wagner Tidwell è una delle principali scrittrici tecniche e designer di contenuti di Data 360\. Lavora in Salesforce dal 2013\. Si dedica a semplificare la comprensione e l'utilizzo di Data 360 attraverso una documentazione tecnica chiara, coerente e accurata e la comunicazione in app.

Yugandhar Bora è un architetto di ingegneria del software di Salesforce, specializzato in architettura dei dati all'interno della piattaforma Data and Intelligence Applications. Dirige iniziative del Comitato di revisione dell'architettura aziendale (EARB) incentrate sulla governance dei dati e sui modelli di dati unificati, contribuendo al contempo alle soluzioni di provisioning automatico della piattaforma.

Samarpan Jain è un Principal Architect di Salesforce specializzato in Commerce Cloud, integrazione di piattaforme e architettura tra organizzazioni. Uno dei dipendenti di Salesforce più longevi, dirige iniziative chiave tra cui la conformità della residenza dati per i clienti governativi e i sistemi di attribuzione dell'utilizzo di Data 360.

<!-- document id=a5983a0413cd3b8790f60025811c3d419033dbca74949e8ebe9e76bcb334531f url=/architect/current/it-it/decision-guides/guides/get-started-data-360-decision-guides.md -->

# Suggerimenti introduttivi sulle guide alle decisioni di Data 360

Questa sezione fornisce indicazioni pratiche per prendere decisioni critiche sull'architettura di Salesforce Data 360, incluse le strategie di provisioning, la connettività multi-organizzazione e gli schemi di integrazione. Utilizzare queste guide per progettare e implementare architetture di dati efficaci che unifichino i dati dei clienti e abilitino funzioni basate sull'intelligenza artificiale.

---

## Provisioning di Data 360

[Il provisioning Data 360](/docs/architect/it-it/decision-guides/guide/data-360-provisioning) copre le decisioni fondamentali durante il provisioning di Salesforce Data 360:

- **Selezione dell'organizzazione iniziale**: Decidere se eseguire il provisioning di Data 360 in un'organizzazione di produzione esistente o creare un'organizzazione dedicata, considerando governance, conformità e time-to-value.
- **Strategia multi-organizzazioni**: Scegliere tra più istanze di Data 360 indipendenti o utilizzare Data Cloud One per unificare più organizzazioni Salesforce, bilanciando autonomia, conformità e costi.
- **Architettura Data Cloud One**: Abilitare più organizzazioni partner per condividere una singola istanza di Data 360 con governance centralizzata, condivisione dei metadati e parità di funzioni tra le organizzazioni.
- **Condivisione dei dati tra organizzazioni Data 360**: Utilizzare la condivisione dati copia zero tra istanze indipendenti per la conformità regionale, la collaborazione tra unità operative o i cruscotti digitali esecutivi federati.
- **Considerazioni sul provisioning**: Fattori come residenza dei dati, modelli di governance, latenza, complessità dell'integrazione, costo e preparazione dell'intelligenza artificiale per le distribuzioni a livello aziendale.

Aiuta gli architetti a progettare strategie di provisioning che garantiscano semplicità, coerenza aziendale, conformità e scalabilità per Customer 360, AI e innovazione multipiattaforma.

---

## Interoperabilità di Data 360

[Data 360 Interoperability](/docs/architect/it-it/decision-guides/guide/data-360-interoperability) fornisce un framework per l'integrazione di Data 360 con piattaforme esterne e data lake:

- **Schemi di inserimento**: Inserimento in tempo reale, streaming e batch per la creazione di serie di dati canoniche governate ideali per Customer 360, conformità e governance centralizzata.
- **Federazione dati copia zero**: Metodi di query live, query accelerate (caching) e federazione file per accedere a sistemi esterni in tempo reale senza duplicazioni, abilitando personalizzazione, cruscotti digitali e carichi di lavoro AI/ML.
- **Approccio ibrido**: Combinare l'inserimento governato per le serie di dati principali con la federazione copia zero per freschezza e scalabilità, supportando il coinvolgimento Omnicanale, le azioni basate su Agentforce e l'analisi aziendale.
- **Quadro decisionale**: Valutare i compromessi in latenza, costo, scalabilità, governance e complessità per selezionare lo schema di integrazione corretto per fonte di dati.
- **Architect Playbook**: Linee guida specifiche del settore, procedure di progettazione e considerazioni sui costi per gli scenari finanziari, sanitari, di vendita al dettaglio e delle telecomunicazioni.

Guida gli architetti nel bilanciare la freschezza dei dati, la governance e l'efficienza delle opportunità in corso di realizzazione per creare architetture di dati scalabili, interoperabili e pronte per l'intelligenza artificiale che supportano carichi di lavoro operativi e analitici.

<!-- document id=9472229019ed2969262c3e64a90d173052c103953710959fe76ad6147cdf0d71 url=/architect/current/it-it/decision-guides/guides/get-started-integration-decision-guides.md -->

# Suggerimenti introduttivi sulle guide alle decisioni di integrazione

Questa sezione fornisce indicazioni pratiche per scegliere gli strumenti e gli approcci di integrazione dei dati giusti per Salesforce. Include integrazioni in uscita, integrazioni in entrata e scenari tra organizzazioni, aiutando gli architetti a progettare e implementare integrazioni a livello di dati che bilanciano prestazioni, manutenibilità e costi.

---

## Integrazione dei dati con Salesforce

L'[integrazione dati con Salesforce](/docs/architect/it-it/decision-guides/guide/data-integration) offre una panoramica completa degli strumenti e delle procedure consigliate per l'integrazione dei dati Salesforce:

- **Paesaggio strumento integrazione**: Panoramica degli strumenti di integrazione dei dati di Salesforce, incluse le opzioni low-code, ibride e pro-code, con indicazioni sulla selezione dello strumento giusto per casi d'uso specifici.
- **Integrazioni in uscita**: Metodi per inviare dati da Salesforce a sistemi esterni, tra cui Acquisizione dati di modifica, Servizi esterni, Heroku Connect, Procedure di integrazione OmniStudio, Salesforce Connect, MuleSoft Anypoint e soluzioni Apex personalizzate.
- **Integrazioni in entrata**: Approcci per l'inserimento di dati esterni in Salesforce, con indicazioni sulla replica dei dati rispetto alla virtualizzazione e su quando utilizzare ogni strumento.
- **Integrazioni tra organizzazioni**: Metodi consigliati per la condivisione dei dati tra le organizzazioni Salesforce, tra cui MuleSoft Anypoint, Heroku Connect, API Salesforce native, Acquisizione dati di modifica e Salesforce Connect con adattatore tra organizzazioni, incluse istruzioni per la sostituzione delle implementazioni Salesforce a Salesforce precedenti.
- **Quadro decisionale**: Considerazioni chiave per la selezione degli strumenti di integrazione, ad esempio gli strumenti esistenti e la panoramica, i requisiti dei flussi di dati (tempistica, direzionalità, esperienza utente prevista), la complessità dell'implementazione, la manutenibilità, il volume di dati e i limiti della piattaforma.

Consente agli architetti di scegliere gli strumenti e gli schemi di integrazione giusti per ogni scenario, riducendo al minimo la replica inutile dei dati, sfruttando le soluzioni ESB/ETL esistenti e garantendo integrazioni scalabili e manutenibili in linea con i principi dell'architettura aziendale.

<!-- document id=dbd04720b87d533ef9a8bc36e44431bec3a081d27cd141c116d1ff4c1f254686 url=/architect/current/it-it/decision-guides/guides/get-started-platform-decision-guides.md -->

# Suggerimenti introduttivi sulle guide alle decisioni per la piattaforma

Questa sezione fornisce indicazioni pratiche per prendere decisioni critiche sull'architettura riguardo alle funzionalità di Salesforce Platform. Copre l'elaborazione asincrona, gli eventi attivati da record, la creazione di moduli, l'automazione dei flussi di lavoro agentici e tradizionali, l'architettura basata sugli eventi e i framework asincroni basati su fasi per aiutare gli architetti a progettare soluzioni di piattaforma scalabili, manutenibili e ad alte prestazioni.

---

## Elaborazione asincrona

[Elaborazione asincrona](/docs/architect/it-it/decision-guides/guide/async-processing) fornisce indicazioni sugli strumenti e gli approcci per le operazioni asincrone in Salesforce:

- **Strumenti di elaborazione**: asincrona Confronto tra Apex in area di attesa, Apex pianificato, Trigger di eventi piattaforma, Acquisizione dati di modifica, Percorso pianificato (dopo l'impegno dei flussi) e Percorso asincrono (flussi attivati da record), con indicazioni sui casi d'uso appropriati.
- **Elaborazione asincrona lato server**: Schemi per operazioni di database di lunga durata, chiamate esterne ed elaborazione di record a volume elevato.
- **Elaborazione asincrona lato client**: Tecniche come le chiamate continuazione Apex e l'elaborazione asincrona lato client che può essere eseguita nei browser o nelle app mobili.
- **Quadro decisionale**: Valutare la convalida dei casi d'uso, la scalabilità, la comprensione dei casi in cui le transazioni sono realmente asincrone, il monitoraggio e la gestione di eventi di carico estremo.
- **Best practice e anti-schemi**: Guida per un uso corretto, incluse le integrazioni in uscita, il monitoraggio e l'eliminazione delle insidie comuni.

Consente agli architetti di implementare schemi asincroni scalabili, affidabili e mantenibili, evitando insidie che compromettono le prestazioni.

---

## Creazione di moduli

[Building Forms](/docs/architect/it-it/decision-guides/guide/build-forms) guida gli architetti nelle opzioni di creazione dei moduli Salesforce:

- **Strumenti di creazione**: moduli Confronto tra moduli dinamici, flusso schermata, OmniStudio, flusso schermata con componenti Web Lightning (LWC) e LWC, incluse le competenze e le considerazioni sulle licenze.
- **Quadro decisionale**: Considerare l'impatto degli oggetti, l'ambito del modulo, la navigazione, la posizione (app, dispositivi mobili, Web), l'esperienza utente e l'automazione dei test.
- **Guida alla selezione degli strumenti**: Consigli da layout di record semplici a procedure guidate multipagina e moduli indirizzati ai clienti con immagine aziendale.
- **Schemi combinati**: Guida per la combinazione di strumenti, ad esempio la navigazione del flusso schermata con lo stile LWC.
- **Funzioni avanzate**: Approfondimenti sulle funzionalità e le limitazioni per orientare la scelta degli strumenti.

Aiuta gli architetti a selezionare l'approccio di creazione delle forme giusto per i loro requisiti specifici di integrazione, funzionalità e interfaccia utente.

---

## Determinazione dell'automazione dei flussi di lavoro agenti e tradizionali

[Determinazione dell'automazione](/docs/architect/it-it/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html) del flusso di lavoro fornisce un quadro per la scelta tra automazione tradizionale e Agentforce utilizzando il framework Densità orchestrazione:

- **Framework densità orchestrazione**: Valuta la complessità dell'automazione in base al percorso di esecuzione (completamente specificabile e non specificabile), alla complessità degli obiettivi (operazione singola e obiettivi concorrenti) e al mix di modalità (input strutturati e multimodali).
- **Paesaggio del prodotto**: Confronto tra flussi, Apex, Agentforce, script agente, griglia Agentforce, operazioni Agentforce e MuleSoft per scenari di automazione diversi.
- **Matrice di selezione della densità**: Mappa i livelli di densità dell'orchestrazione (bassa, media, alta) agli standard architettonici, dall'automazione attivata da record all'orchestrazione ibrida al determinismo guidato con Agent Script.
- **Quadro decisionale**: Processo di valutazione sequenziale (ispezionare prima il percorso di esecuzione, poi la complessità degli obiettivi e infine il mix di modalità) per determinare lo strumento giusto.
- **Utilizza guida caso**: Consigli specifici per l'automazione tradizionale (basata su regole, deterministica), Agentforce Grid (operazioni AI in blocco), orchestrazione ibrida (processi end-to-end complessi) e script agente (punti di ingresso non strutturati con esigenze di ragionamento).

Consente agli architetti di prendere decisioni informate in tutto lo spettro dell'automazione, bilanciando le capacità di ragionamento con il controllo deterministico per soluzioni scalabili, controllabili e mantenibili.

---

## Architettura basata sugli eventi

[Event-Driven Architecture](/docs/architect/it-it/decision-guides/guide/event-driven) fornisce una guida completa agli strumenti e agli schemi di evento Salesforce:

- **Strumenti per eventi**: Panoramica di eventi piattaforma, acquisizione dati di modifica, API Pub/Sub, MuleSoft Anypoint, Streaming API e considerazioni sull'integrazione.
- **Schemi basati sugli eventi**: Include schemi di pubblicazione/abbonamento, fanout, messaggi passati, streaming e aree di attesa per vari casi d'uso basati sugli eventi.
- **Integrazione con MuleSoft**: Utilizzo di connettori Anypoint (Pub/Sub, JMS, Kafka, Solace, MQ, MQTT, AMQP) per architetture aziendali.
- **Eventi piattaforma e acquisizione dati di modifica**: Guida sui meccanismi preferiti per la pubblicazione delle modifiche di record e campi, con migrazione da PushTopic/Eventi generici.
- **Schemi di implementazione**: Procedure consigliate per scalabilità, coerenza, gestione degli errori e monitoraggio.

Consente agli architetti di progettare sistemi scalabili, quasi in tempo reale, basati sugli eventi, che connettono più sistemi in modo efficiente.

---

## Framework asincrono basato su fasi

Il [framework asincrono step-based](/docs/architect/it-it/decision-guides/guide/step-based-async-framework) fornisce un framework per l'elaborazione modulare e scalabile dei processi asincroni:

- **Architettura frame**: I componenti includono Apex in area di attesa, Finalizzatori, Flusso pianificato, Cursori Apex, Azioni invocabili e integrazioni Slack.
- **Elaborazione basata su fasi**: Le interruzioni funzionano in fasi indipendenti che possono essere eseguite, riprovate e riavviate con governance condivisa e visibilità operativa.
- **Guida all'implementazione**: Schemi per interfaccia fase, Processore fase, livello Apex invocabile, gestione dei ritardi e notifiche.
- **Best practice**: Consigliato quando la maggior parte delle informazioni è presente in CRM, per carichi di lavoro a volume elevato ed elaborazione dei record gerarchica o ad albero; indicazioni su quando non utilizzarlo.
- **Funzioni di livello aziendale**: Governance, conformità, stato distribuito, tracciamento dell'avanzamento, monitoraggio degli SLA, diagnostica dei guasti e registrazione a livello di controllo.

Offre agli architetti un'alternativa scalabile ai processi batch monolitici e alle chiamate asincrone concatenate, supportando carichi di lavoro Salesforce a volume elevato con piena trasparenza operativa.

---

## Automazione attivata da record

[Record-Triggered Automation](/docs/architect/it-it/decision-guides/guide/record-triggered) fornisce il framework per progettare l'automazione attivata da record in Salesforce Platform:

- **Selezione strumento**: Quando utilizzare il flusso attivato da record rispetto ai trigger Apex, in base alla densità di automazione (bassa, media, alta) e alla matrice di selezione della densità.
- **Densità di automazione**: Come valutare la quantità dell'automazione, il volume dei record e l'espansione delle dipendenze per scegliere trigger Flusso, ibrido (flusso con Apex invocabile) o Apex.
- **Punti di ingresso e governance**: Un punto di ingresso per oggetto Salesforce; istruzioni sulle condizioni di immissione, il controllo della ricorsione e l'esecuzione ordinata.
- **Invocazione asincrona**: Quando e come invocare i processi asincroni dai flussi attivati da record o Apex, con cautela nella gestione degli errori e nei limiti del governor.
- **Best practice**: Schemi per la messa in blocco, progettazione ibrida FlussoApex ed evitare le insidie comuni nell'automazione dei trigger.

Consente agli architetti di progettare un'automazione attivata da record scalabile, manutenibile e performante in linea con gli standard della piattaforma.