# architect Ben progettato (well-architected) - Full Documentation

<!-- document id=4a90ff0f97f24b0b68859ae853cb838d548a6abf4f390689dabd636d819b528b url=/architect/next/it-it/well-architected/guides/adaptable-overview.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

Una soluzione Salesforce **adattabile** si evolve con l'azienda. Una soluzione ben progettata per essere **adattabile** è resistente e componibile.

Le soluzioni **resilienti** gestiscono bene il cambiamento.<br>
Le soluzioni **componibili si** adattano rapidamente e con maggiore stabilità.

La necessità di un cambiamento nel business può provenire da molte fonti: richieste dei clienti, sconvolgimenti del mercato o del settore o opportunità di trasformazione digitale. A volte le modifiche sono piccole. A volte i cambiamenti sono profondi. Ai livelli più profondi, un cambiamento può richiedere alle aziende di ripensare e spostare le loro ragioni principali per operare e rivalutare cosa, come e dove delle loro offerte ai clienti. Architetture **adattabili** non solo aiutano le aziende a sopravvivere e a riprendersi dalle interruzioni, ma creano il potenziale per le aziende di innovare e prosperare in tempi di profondi cambiamenti.

Creare sistemi **adattabili** richiede un pensiero architettonico profondamente creativo e preciso. È necessario iniziare con una comprensione accurata della traiettoria a breve e lungo termine del business. Quando si valutano i singoli dettagli dell'implementazione, è necessario considerare gli impatti su più dimensioni e livelli di dettaglio. Bisogna pensare in termini di persone, processi e tecnologia. Inoltre, è necessario prevedere simultaneamente gli impatti a livello macro e micro, per lo stato corrente e gli eventuali stati futuri.

Le sezioni seguenti offrono indicazioni più approfondite per ciascuno dei comportamenti principali di un'architettura di soluzioni **adattabili**.

## Panoramica adattabile

<table>
<tbody>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/resilient">Resiliente</a></th>
        </tr>
        <tr>
        <td colspan="3">Le soluzioni resilienti gestiscono bene il cambiamento. Le architetture resilienti possono tornare al comportamento e alle operazioni previsti in modo rapido e prevedibile.</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1">Gestione del ciclo di <a href="/docs/architect/it-it/well-architected/guide/resilient#gestione-del-ciclo-di-vita-delle-applicazioni">vita delle applicazioni</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/resilient#risposta-incidente">Risposta agli incidenti</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/resilient#pianificazione-della-continuità">Pianificazione della continuità</th>
        </tr>
        <tr>
            <td>Gestione dei rilasci <br>Strategia ambientale <br>Strategia di test</td>
            <td>Tempo di recupero <br>Capacità di triage <br>Monitoraggio e avviso</td>
            <td>Continuità operativa <br>Continuità tecnologica</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/composable">Componibile</a></th>
        </tr>
        <tr>
        <td colspan="3">Le soluzioni componibili si adattano rapidamente e con maggiore stabilità. Le architetture componibili sono costruite in unità che funzionano in modo elegante l'una con l'altra e possono essere scambiate in e fuori servizio.</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/composable#separazione-delle-preoccupazioni">Separazione delle preoccupazioni</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/composable#interoperabilità">Interoperabilità</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/composable#inserimento-in-pacchetti">Confezionabilità</th>
        </tr>
        <tr>
            <td>Unità funzionali <br>Gestione statale</td>
            <td>Messaggistica ed eventi <br>Gestione API</td>
            <td>Accoppiamento allentato <br>Gestione delle dipendenze</td>
        </tr>
        </tbody>
</table>

<!-- document id=6345481d11a0cf6fc444153f135e7179a43fc4f8daf189edc5433e99e4a0bf63 url=/architect/next/it-it/well-architected/guides/reliable.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

Soluzioni affidabili funzionano in modo efficace e affidabile. Sono disponibili, funzionano in modo coerente e scalabile per supportare le aziende in crescita.

Un sistema affidabile non è soggetto a errori, si comporta come previsto e fornisce risultati in modo tempestivo. Al contrario, un sistema inaffidabile è lento, non funziona come previsto o si guasta in momenti critici. I sistemi inaffidabili forniscono informazioni imprecise, quindi gli stakeholder non possono Trust per le decisioni aziendali.

L'affidabilità del sistema non è costante. Un sistema affidabile oggi può diventare inaffidabile se non progettato per la crescita. Un sistema inaffidabile può richiedere costose operazioni di manutenzione, refactoring o reimplementazione, sottraendo fondi a progetti strategici.

Migliorare l'affidabilità delle soluzioni Salesforce concentrandosi su tre principi: [disponibilità](/docs/architect/it-it/well-architected/guide/reliable#disponibilità), [prestazioni](/docs/architect/it-it/well-architected/guide/reliable#prestazioni) e [scalabilità](/docs/architect/it-it/well-architected/guide/reliable#scalabilità). [La suite Salesforce](https://www.salesforce.com/platform/application-scaling-performance-testing/) offre funzionalità native per aiutare gli architetti a rendere operative implementazioni affidabili.

## Disponibilità

La disponibilità è una misura della percentuale di tempo in cui il sistema è operativo. Salesforce Platform gestisce la maggior parte dei problemi di disponibilità [a livello di](https://trust.salesforce.com/) infrastruttura. Tuttavia, la disponibilità delle soluzioni create sulla piattaforma e sperimentate dai clienti è una responsabilità condivisa. È importante capire che anche con l'[alta disponibilità](https://trust.salesforce.com/en/#systemStatus) di Salesforce, il rischio di interruzione del servizio non è mai zero.

Gli architetti devono prepararsi a eventuali interruzioni del servizio Salesforce, come la manutenzione pianificata o circostanze impreviste. Oltre alle interruzioni del servizio, valutare come mantenere prestazioni elevate e crescere con l'azienda. Scelte architettoniche limitate possono causare problemi di disponibilità a lungo termine.

Pensare alla disponibilità durante la fase di progettazione, _prima_ di creare la soluzione. Più a lungo si rinvia l'architettura per la disponibilità, più alto sarà il costo effettivo dei problemi di disponibilità nel lungo periodo. Per ridurre i rischi potenziali, utilizzare Test di scalabilità Salesforce nell'ambiente di test. In questo ambiente, è possibile eseguire test su larga scala in produzione prima di distribuire il codice in produzione.

Gli architetti utilizzano il linguaggio dell'azienda, formulando le preoccupazioni tecniche per gli stakeholder aziendali per ottenere il consenso e assegnare la priorità al lavoro di disponibilità. Per ridurre i rischi potenziali, utilizzare Test di scalabilità Salesforce nell'ambiente di test. In questo ambiente, è possibile eseguire test su larga scala in produzione prima di distribuire il codice in produzione.

È possibile progettare per una maggiore disponibilità delle soluzioni Salesforce attraverso la [gestione dei rischi](/docs/architect/it-it/well-architected/guide/reliable#gestione-dei-rischi) e la [riduzione dei guasti](/docs/architect/it-it/well-architected/guide/reliable#mitigazione-degli-errori).

### Gestione dei rischi

La gestione dei rischi nel contesto dell'architettura Salesforce prevede l'identificazione dei potenziali pericoli per il funzionamento del sistema, per i suoi utenti, inclusi dipendenti, partner e clienti, e per i processi aziendali. Spesso, il processo formale di esecuzione dell'analisi del rischio rientra nelle responsabilità dei responsabili di progetto. In qualità di architetto, assicurarsi che l'analisi dei rischi rappresenti adeguatamente le preoccupazioni degli stakeholder tecnici e aziendali. È anche responsabilità dell'utente identificare i casi d'uso critici per l'azienda per i quali è necessario eseguire il test su larga scala in base ai punti caldi di picco della produzione.

Alcune delle insidie più grandi nella gestione del rischio derivano dal non dedicarvi abbastanza tempo e riflessione. I team spesso saltano la valutazione del rischio o confondono la risoluzione del [backup e ripristino](/docs/architect/it-it/well-architected/guide/resilient#creazione-di-funzionalità-di-backup-e-ripristino), una parte importante della riduzione dei rischi per l'integrità dei dati, con una valutazione e una riduzione complete del rischio.

Per valutare il rischio per le soluzioni Salesforce, utilizzare questi metodi:

- **Utilizzare un framework di valutazione del rischio**. Alcune grandi imprese possono già disporre di matrici di rischio pertinenti. In tal caso, utilizzarli per determinare come classificare i pericoli, quali tipi di informazioni raccogliere, quali misure adottare per porvi rimedio e altro ancora. Se non si dispone già di un framework di valutazione del rischio, trovarne uno da una fonte affidabile e utilizzarlo.
- **Valutare la gravità dell'impatto e le categorie di rischio dal punto di vista dei clienti**. Proactive Monitoring e Scale Center offrono avvisi e cruscotti digitali configurabili. Valutano continuamente i rischi di prestazioni e scalabilità e riducono la dipendenza dagli elenchi di controllo manuali. Trust e percezione del cliente sono fondamentali per ogni azienda. In termini di impatto sul business, i rischi per i problemi che raggiungono i clienti di solito superano i rischi per i problemi che non li raggiungono. I clienti potrebbero non pensare o percepire i rischi allo stesso modo dei team interni. Se un cliente non riesce ad accedere al proprio account, probabilmente non si preoccupa della causa principale del problema. Hanno più a cuore la loro esperienza immediata.
- **Dare priorità ai rischi**. L'ideale è che ogni rischio sia legato a un solido piano di mitigazione e risposta. In realtà, avrai lacune che dovrai colmare nel tempo. È importante adottare un approccio "consegna valore in anticipo e ripeti". L'utente e i suoi team di consegna e manutenzione possono svolgere solo una quantità di lavoro in un dato momento. In Salesforce, un'espressione comune è "Se tutto è importante, niente è importante". Utilizziamo i V2MOM per definire le priorità e allineare il lavoro in tutta l'azienda, in tutti i team e fino a ogni singolo individuo. (Puoi [saperne di più su V2MOMs](https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom/msfw_oav2m_writing_a_v2mom) su Trailhead.) Utilizzare le valutazioni del rischio, che offrono la possibilità di collaborare con gli stakeholder per definire le priorità e impegnarsi nelle attività di gestione del rischio più importanti. Utilizzare Test di scalabilità - Creazione del piano di test per identificare i rischi da assegnare alle priorità e per mitigarli utilizzando i test di scala.

Utilizzare Proactive Monitoring per rilevare i rischi di disponibilità precoce. Mette in evidenza anomalie come picchi di limite delle richieste API, errori di blocco delle righe o errori Apex simultanei, fornendo approfondimenti concreti prima che i problemi degenerino in interruzioni del servizio.

Gli [schemi e gli](/docs/architect/it-it/well-architected/guide/reliable#modelli-di-disponibilità-e-anti-schemi) schemi di disponibilità mostrano una gestione del rischio corretta e scarsa all'interno di una soluzione Salesforce. Utilizzare gli schemi per convalidare i progetti prima di creare o per identificare le aree di refactoring nel sistema.

Per ulteriori informazioni sugli strumenti Salesforce relativi alla gestione del rischio, vedere [Salesforce Tools For Reliability](/docs/architect/it-it/well-architected/guide/reliable#strumenti-salesforce-per-laffidabilità).

### Mitigazione degli errori

Un punto di errore è una vulnerabilità che rende un sistema inaffidabile. Una buona mitigazione degli errori non consiste nell'individuare ogni potenziale punto di errore. Si tratta invece di classificare e assegnare priorità ai punti di errore in modo che i team di manutenzione e assistenza possano rispondere in modo efficace. Vedere [Risposta all'incidente](/docs/architect/it-it/well-architected/guide/resilient#risposta-incidente).

Per sviluppare strategie di mitigazione degli errori migliori:

- **Classificare i trigger per i punti di errore in termini di persone, processi e tecnologia**. Così come si classificano i rischi in termini di persone, processi e tecnologia, applicare lo stesso pensiero al modo in cui vengono attivati i punti di errore con priorità alta. Questo approccio consente di identificare potenziali trigger di errore e di sviluppare e organizzare le risposte. A volte è possibile mitigare trigger di errore apparentemente divergenti con approcci di mitigazione simili, in base al modo in cui vengono classificati.

<table style="border-color:white;">
    <tbody>
        <tr>
            <th scope="colgroup" colspan="1">Classificazione/tipo di trigger</th>
            <th scope="colgroup" colspan="1">Attenuazione</th>
        </tr>
        <tr>
            <td>Persone</td>
            <td>Policy</td>
        </tr>
        <tr>
            <td>Processo</td>
            <td>Playbook, piani di continuità</td>
        </tr>
        <tr>
            <td>Tecnologia</td>
            <td>Ridondanza</td>
        </tr>
    </tbody>
</table>

- **Identificare l'aspetto della mitigazione di base, intermedia e matura**. Ci vorrà tempo per definire le strategie di mitigazione. Definire i livelli di mitigazione per aiutare l'utente e il suo team a vedere dove è possibile implementare immediatamente i controlli e come concentrare gli sforzi nel tempo. Cercare sempre opportunità per utilizzare l'automazione negli approcci di mitigazione, non appena possibile. Per illustrare l'aspetto pratico di questo approccio, questo esempio mostra un trigger orientato alle persone e la mitigazione basata sulle policy a livello di base, intermedio e maturo.

<table style="border-color:white;overflow-x:scroll;">
    <tbody>
        <tr>
            <th scope="colgroup" colspan="1">Trigger</th>
            <th scope="colgroup" colspan="1">Attenuazione</th>
            <th scope="colgroup" colspan="1">Base</th>
            <th scope="colgroup" colspan="1">Intermedio</th>
            <th scope="colgroup" colspan="1">Maturo</th>
        </tr>
        <tr>
            <td>Modifica dell'accesso utente per un dipendente nuovo o in partenza</td>
            <td>Contratto sul livello di servizio (SLA) e requisiti per il provisioning o l'annullamento del provisioning degli utenti</td>
            <td>Eseguire manualmente il provisioning e l'annullamento del provisioning degli utenti, in base agli SLA per le modifiche manuali.</td>
            <td>Elaborare le modifiche degli utenti tramite processi pianificati, in base agli SLA per le modifiche pianificate.</td>
            <td>Automatizzare il provisioning e il deprovisioning degli utenti tramite una soluzione SSO/IDM.</td>
        </tr>
    </tbody>
</table>

Oltre a utilizzare i playbook architettonici e la pianificazione della continuità, utilizzare Proactive Monitoring. Con Proactive Monitoring è possibile impostare avvisi in tempo reale sui trigger di errore, ad esempio errori di accesso, eccezioni di timeout della CPU o errori simultanei delle richieste API. Questo approccio all'avviso migliora la mitigazione dei guasti assicurando che gli stakeholder tecnici e aziendali siano informati in tempo utile per ridurre l'impatto dei guasti.

Gli [schemi e anti-schemi di disponibilità](/docs/architect/it-it/well-architected/guide/reliable#modelli-di-disponibilità-e-anti-schemi) mostrano l'aspetto della corretta e scarsa mitigazione degli errori in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare le aree del sistema da rifattorizzare.

Per ulteriori informazioni sugli strumenti Salesforce per la risoluzione degli errori, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/reliable#strumenti-salesforce-per-laffidabilità) l'affidabilità.

### Modelli di disponibilità e anti-schemi

Questa tabella mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la riparazione.

✨ Scopri altri schemi per la disponibilità in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-availability).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr><td rowspan="2"><b>Gestione dei rischi</b></td>
        <td class="check-col"><b>Nel tuo business:</b>
        <br> - È in uso un quadro di valutazione del rischio consolidato.
        <br> - I rischi sono classificati in persone, processi e aree tecnologiche.</td>
        <td class="check-col"><b>Nel tuo business:</b>
        <br> - Il framework di valutazione del rischio per Salesforce è ad hoc.
        <br> - I rischi non sono chiaramente identificati.</td></tr>
        <tr>
        <td class="check-col"><b>Nella documentazione:</b>
        <br> La gravità del rischio viene classificata e valutata in base all'impatto sul cliente.
        <br> - I piani di mitigazione del rischio e di risposta hanno la priorità.</td>
        <td class="check-col"><b>Nella documentazione:</b>
        <br> La prospettiva del cliente non viene considerata quando si valuta la gravità del rischio o la categoria.
        <br> - I piani di mitigazione del rischio e di risposta cercano di catturare ogni rischio immaginabile.</td>
        </tr>
        <tr><td rowspan="1"><b>Mitigazione degli errori</b></td>
        <td class="check-col"><b>Nella propria organizzazione:</b>
        <br> - I trigger di punti di errore e i relativi piani di mitigazione sono classificati in base alle persone, ai processi e alla tecnologia.
        <br> I controlli di mitigazione vengono implementati immediatamente, maturano nel tempo e incorporano l'automazione il prima possibile.
        <br> - Per garantire una scalabilità ottimale, vengono completati test e ottimizzazioni completi prima che le modifiche vengano rilasciate in produzione.
        <br> - Prima degli eventi critici per l'azienda, vengono eseguiti test e ottimizzazione della scala, in base agli SLA.
        </td>
        <td class="check-col"><b>Nella propria organizzazione:</b>
        <br> - I trigger punto di errore non sono classificati. Gli approcci di mitigazione non esistono o vengono utilizzati solo ad hoc.
        <br> - I controlli di mitigazione non vengono rivisti o migliorati.
        <br> - L'automazione non viene utilizzata nella mitigazione.
        </td></tr>
        <tr><td rowspan="1"><b>Monitoraggio e osservabilità</b></td>
        <td class="check-col"><b>Nella propria organizzazione:</b>        
        <br> - Per i controlli e il rilevamento delle anomalie, è abilitato Proactive Monitoring.
        <br> - Per una visibilità continua, gli avvisi Proactive Monitoring sono integrati con Scale Center.
        </td>
        <td class="check-col"><b>Nella propria organizzazione:</b>
        <br> - Vengono eseguiti solo controlli manuali dello stato e non è in atto alcun monitoraggio continuo.
        </td></tr>
    </tbody>
</table>

## Prestazioni

Le prestazioni dell'architettura di sistema sono una misura di quanto un sistema elabora (throughput) e quanto velocemente risponde (latenza). In genere si comprendono le prestazioni del sistema attraverso i test e il monitoraggio in produzione.

Un sistema efficiente completa i processi in modo tempestivo a ogni livello di domanda previsto.

Le scarse prestazioni vanno di pari passo con una latenza più elevata e una produttività più bassa, che portano a una minore produttività e a una maggiore frustrazione degli utenti. Correggere i problemi di prestazioni è urgente perché possono causare una perdita di Customer Trust e perdite finanziarie.

È possibile migliorare le prestazioni delle soluzioni ottimizzando la produttività e la latenza.

> Nota: L'ottimizzazione della produttività e della latenza sono aspetti essenziali per migliorare l'elaborazione e la reattività del sistema. È importante ricordare, tuttavia, che le prestazioni complessive del sistema dipendono anche dalla qualità dell'architettura in [scala](/docs/architect/it-it/well-architected/guide/reliable#scalabilità). È necessario considerare entrambe le dimensioni nei progetti.

### Rendimento

Nel contesto dell'architettura Salesforce, la produttività è il numero di richieste simultanee che un sistema può completare in un determinato intervallo di tempo. Le soluzioni Salesforce dei clienti progettate e ottimizzate per la produttività funzionano meglio entro i [limiti](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) predefiniti di Salesforce Platform.

L'ottimizzazione della produttività in Salesforce inizia con il calcolo preciso dei carichi di lavoro nel sistema e la pianificazione della loro crescita. Senza proiezioni accurate per le esigenze che verranno poste al sistema, non è possibile individuare potenziali problemi con le capacità di produzione del sistema.

Quando si pensa ai carichi di lavoro, considerare le tre dimensioni seguenti.

- **Numero di transazioni** che il sistema deve elaborare in un determinato periodo di tempo
- **Numero di utenti** che devono accedere contemporaneamente al sistema
- **Complessità complessiva della logica delle transazioni** nel sistema

Quando si pensa alle prestazioni, i team a volte si concentrano troppo sull'elaborazione e sui vincoli relativi al tempo CPU massimo, che sono tra i limiti del governor della piattaforma. I team con un focus ristretto sul tempo CPU trascurano altri metodi per ottimizzare la produttività. Espandere l'attenzione e applicare questi metodi migliora la produttività complessiva e l'efficienza dell'architettura Salesforce. Questi miglioramenti, a loro volta, contribuiranno a ridurre la latenza e ad aumentare le prestazioni complessive del sistema. ApexGuru rileva in modo proattivo gli schemi anti-limitazione della produttività come SOQL nei loop, DML nei loop, chiamate GGD inefficienti e metodi costosi. Questi approfondimenti aiutano i team a eliminare i rischi del governor limit che limitano la produttività.

Per ottimizzare la produttività nel sistema:

- **Favorire l'elaborazione asincrona**. Salesforce Platform utilizza i contesti delle transazioni per controllare l'integrità dei dati e limitare il codice in fuga. Vedere le [transazioni in Architecture Basics](/docs/architect/it-it/fundamentals/guide/architecture-basics#transazioni) in Architecture Basics. Per questo motivo, l'uso dell'elaborazione asincrona (asincrona), ove possibile, può contribuire a ridurre al minimo i potenziali colli di bottiglia nei contesti di esecuzione sincrona. Vedere [Gestione dei dati](/docs/architect/it-it/well-architected/guide/automated#gestione-dei-dati). L'uso del calcolo asincrono non è una cura per ogni tipo di problema di prestazioni e sarà necessario tenere in considerazione la latenza quando si incorporano i processi asincroni. Alcune funzionalità della piattaforma, ad esempio Apex in area di attesa, possono aumentare la latenza durante i picchi di traffico perché causano una maggiore attesa dei messaggi in un'area di attesa. A seconda del caso d'uso, è possibile decidere di tollerare una potenziale diminuzione della reattività per mantenere o migliorare la produttività. In altri casi, si può decidere che una latenza maggiore non è accettabile. Con il Test di scalabilità, è possibile convalidare questi compromessi simulando i picchi di traffico in un Sandbox Completo. Qui è possibile misurare in che modo i processi influiscono su produttività e latenza.
- **Utilizzare sempre bulking**. Ad alto livello, la messa in blocco significa eseguire operazioni contro le raccolte. Spesso, i team che discutono dell'esecuzione in blocco delle loro soluzioni Salesforce si concentrano sulla semplificazione delle operazioni sui dati rispetto alle raccolte. Vedere [Logica operativa](/docs/architect/it-it/well-architected/guide/automated#logica-operativa). Tuttavia, l'esecuzione in blocco a livello di sistema non riguarda solo le operazioni sui dati. Considerare anche alcune operazioni, ad esempio chiamate o calcoli complessi, come candidati per l'esecuzione in blocco. Un corretto ingombro riduce il sovraccarico. Esegue più operazioni con una sola richiesta anziché con una sola richiesta per operazione. ApexGuru mette in evidenza schemi anti-bulkification come [DML o SOQL all'interno](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5) dei loop, che è possibile correggere prima di scalare in produzione. Vedere [Operazioni in blocco](/docs/architect/it-it/fundamentals/guide/platform-multitenant-architecture#operazioni-in-blocco).
- **Utilizzare SOSL per le ricerche e trattare SOQL come un'operazione dati**. Può sembrare ovvio che l'uso di istruzioni SOQL eccessivamente complesse aumenterà la quantità di tempo necessaria al sistema per recuperare i record. SOQL aggiunge un sovraccarico al [database relazionale sottostante](/docs/architect/it-it/fundamentals/guide/platform-multitenant-architecture#livello-di-dati-piattaforma), rallentando l'elaborazione. Quando si utilizzano criteri di testo o caratteri jolly, SOSL è più performante. SOSL utilizza il motore di ricerca della piattaforma, ottimizzato per l'indicizzazione full-text e le ricerche universali. Per ottimizzare gli schemi di recupero dei record, assicurarsi che gli standard di progettazione specifichino quando utilizzare SOSL per trovare i dati nel sistema. Assicurarsi inoltre che specifichino come utilizzare SOQL per operazioni sui dati efficienti. Vedere [Logica operativa](/docs/architect/it-it/well-architected/guide/automated#logica-operativa)).
- **Utilizzare Cache piattaforma e ApexGuru**. Il livello [Lightning Platform Cache](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm) offre prestazioni più rapide e una migliore affidabilità durante il caching dei dati delle sessioni e dell'organizzazione Salesforce. La cache piattaforma migliora le prestazioni distribuendo lo spazio della cache in modo che alcune applicazioni o operazioni non rubino capacità ad altre. ApexGuru rileva le opportunità mancate per memorizzare nella cache query ripetute (ad esempio, [Platform Cache for SOQL Results](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5)), il che migliora la produttività in ambienti su larga scala.

Gli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/reliable#modelli-di-prestazioni-e-anti-schemi) per le prestazioni mostrano l'aspetto corretto e scarso della produttività in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare opportunità di ulteriore ottimizzazione.

Per ulteriori informazioni sugli strumenti Salesforce per l'ottimizzazione della produttività, vedere [Salesforce Tools For Reliability](/docs/architect/it-it/well-architected/guide/reliable#strumenti-salesforce-per-laffidabilità).

### Latenza

La latenza è una misura della velocità con cui un sistema completa un percorso di esecuzione. L'ottimizzazione della produttività del sistema contribuirà a migliorare la latenza. Un'altra dimensione della latenza è la percezione delle prestazioni, ovvero la reattività del sistema agli utenti.

Le persone non vogliono attendere il caricamento delle pagine o il completamento dei processi. Gli utenti del sistema si sentiranno frustrati se sperimenteranno spesso lunghi tempi di caricamento quando proveranno a navigare nelle visualizzazioni elenco, nelle pagine dei record, nei rapporti e così via. Quando ciò accade, i clienti o i partner possono decidere di spostare la propria attività altrove anziché occuparsi di sistemi con prestazioni scadenti. Internamente, i dipendenti possono creare soluzioni per evitare di utilizzare il sistema come progettato, il che può causare problemi a valle per la sicurezza e l'integrità dei dati.

Le prestazioni percepite possono essere difficili da diagnosticare. Quando un utente segnala prestazioni lente, i team di assistenza potrebbero non essere in grado di riprodurre il problema. L'aumento della latenza è spesso il risultato di una combinazione di problemi più piccoli che si basano l'uno sull'altro, il che può rendere difficile diagnosticare la causa esatta dei problemi di prestazioni percepiti.

Per ridurre la latenza e migliorare la reattività nel sistema Salesforce:

- **Ottimizzare i rapporti**. Assicurarsi che ogni rapporto abbia un unico scopo specifico. Identificare chiaramente il pubblico e lo scopo di ogni rapporto nel sistema. Includere nei rapporti solo la quantità minima di dati necessaria ai membri del pubblico per prendere decisioni. La rimozione delle colonne non allineate allo scopo di un rapporto migliorerà le prestazioni del rapporto riducendo la quantità di dati che devono essere recuperati e visualizzati.
- **Ottimizzare i filtri**. Filtri efficaci velocizzano le prestazioni dei rapporti e delle visualizzazioni elenco definendo con precisione gli ambiti del numero di righe recuperate dal database. In generale, più specifica è la logica dei filtri, più efficiente sarà la query sottostante per i dati. I metodi per ottimizzare i filtri includono:
  - Utilizzo di "uguale a" e "non uguale a" anziché "contiene" e "non contiene"
  - Evitare di filtrare in base ai campi formula
- **Semplificare il modello** di condivisione. Un modello di condivisione eccessivamente complesso può rallentare una varietà di processi perché il sistema deve controllare il modello di condivisione e visibilità per determinare se un utente ha accesso ai dati da visualizzare o elaborare. I calcoli di condivisione complessi possono aumentare la latenza nei rapporti, nelle visualizzazioni elenco e nell'automazione eseguiti nel contesto dell'utente. Vedere [Condivisione e visibilità](/docs/architect/it-it/well-architected/guide/secure#condivisione-e-visibilità).
- **Ottimizzare componenti interfaccia utente personalizzati**. I componenti dell'interfaccia utente (UI) personalizzati possono aumentare la latenza. Per ottimizzare le prestazioni nei componenti dell'interfaccia utente personalizzati, valutare le seguenti operazioni.
  - **Utilizzare Componenti Web Lightning (LWC)**. Il framework LWC è strettamente allineato ai moderni standard Web. I componenti personalizzati scritti in LWC vengono visualizzati in modo più efficiente nei browser Web e consentono agli sviluppatori di utilizzare metodi JavaScript più efficaci. Cercare sempre di utilizzare LWC anziché le tecnologie dell'interfaccia utente più datate, come Aura o Visualforce.
  - **Utilizzare Lightning Data Service**. Lightning Data Service gestisce la creazione e la manutenzione di caching protetti, performanti e condivisi tra i componenti. Utilizzarlo per evitare inutili viaggi di andata e ritorno al server per i dati e per aumentare la reattività complessiva delle applicazioni.
  - **Utilizzare l'ordinamento e i filtri lato client per i dati degli elenchi**. Sia per i componenti LWC (preferiti) che per i componenti Aura (altrimenti), gli sviluppatori possono utilizzare la funzionalità standard della matrice JavaScript per ordinare, filtrare e selezionare i valori sul lato client, riducendo il numero di viaggi necessari al server.

Gli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/reliable#modelli-di-prestazioni-e-anti-schemi) mostrano l'aspetto della latenza corretta e scarsa in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare opportunità di ulteriore ottimizzazione.

Per ulteriori informazioni sugli strumenti Salesforce per l'ottimizzazione della latenza, vedere [Salesforce Tools For Reliability](/docs/architect/it-it/well-architected/guide/reliable#strumenti-salesforce-per-laffidabilità).

### Modelli di prestazioni e anti-schemi

Questa tabella mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la riparazione.

✨ Scopri altri modelli per le prestazioni in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-performance).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="2"><b>Portata</b></td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Guida per l'utilizzo della cache piattaforma aderisce alle <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_platform_cache_best_practices.htm" target="_blank">best practice della</a> cache piattaforma
            </td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Se sono presenti indicazioni per l'utilizzo della cache piattaforma, non sono chiare o non sono in linea con le procedure consigliate.
            </td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Bulkification è utilizzato per le operazioni di dati e di sistema.
            <br> - I metodi DML o di database operano sempre contro le raccolte in Apex.
            <br> - I campi utilizzati durante DML per un tempo trascorso più breve nel database sono limitati.
            <br> - Tutti i criteri dei caratteri jolly vengono utilizzati in SOSL.
            <br> - Le istruzioni SOQL sono selettive.:
            <br> -- Non utilizzano confronti LIKE o confronti di testo parziale.
            <br> -- Gli operatori di confronto utilizzano la logica positiva (in altre parole INCLUDE o IN) come logica principale o solo logica.
            <br> -- = NULL e != NULL vengono utilizzati solo raramente segue sempre un operatore di confronto positivo. 
            <br> Per ridurre al minimo il carico di dati e ottimizzare le prestazioni, vengono recuperati solo i campi necessari nelle query SOQL.
            <br> -- Non vengono utilizzate istruzioni LIMIT 1.
            <br> -- La parola chiave ALL ROWS non viene utilizzata.
            <br> - L'elaborazione asincrona è favorita ove possibile.
            <br> - Le partizioni cache piattaforma sono configurate.
            </td>
            <td><b>Nella propria organizzazione:</b>
                <br> - Le istruzioni DML non sono in blocco.
                <br> - I metodi DML o di database operano su singoli record in Apex.
                <br> SOSL è raramente o non in modo coerente utilizzato per i criteri di selezione dei caratteri jolly.
                <br> - Le istruzioni SOQL non sono selettive:
                <br> -- Includono criteri di filtro LIKE e caratteri jolly.
                <br> -- I confronti che utilizzano i criteri !=, NOT o NOT IN vengono utilizzati come operatore di confronto principale o unico.
                <br> -- Utilizza = NULL e != NULL come operatori di confronto principali o unici.
                <br> -- Vengono utilizzate le istruzioni LIMIT 1.
                <br> -- Viene utilizzata la parola chiave ALL ROWS.
                <br> - SOQL viene visualizzato all'interno dei loop.
                <br> - I processi sincroni sono favoriti.
            </td>
        </tr>
        <tr>
            <td rowspan="1"><b>Latenza</b></td>
            <td><b>Nella propria organizzazione:</b>
            <br> I rapporti hanno un unico scopo specifico e contengono il numero minimo di righe e colonne necessarie per prendere decisioni.
            <br> - I filtri utilizzano "uguale a" e "non uguale a".
            <br> - I filtri non contengono campi formula.
            <br> - I modelli di condivisione sono semplificati il più possibile.
            <br> - I componenti dell'interfaccia utente personalizzati utilizzano componenti Web Lightning (LWC).
            <br> - LWC utilizza Lightning Data Service per le operazioni sui dati.
            <br> - L'ordinamento e il filtraggio dei dati degli elenchi viene gestito sul lato client in JavaScript.
            <br> Salesforce Edge è abilitato.
            </td>
            <td><b>Nella propria organizzazione:</b>
            <br> - I rapporti hanno più scopi o contengono righe e colonne aggiuntive che non sono necessarie per prendere decisioni.
            <br> - I filtri utilizzano "contiene" e "non contiene".
            <br> - I filtri contengono campi formula.
            <br> - I modelli di condivisione sono complessi.
            <br> - I componenti dell'interfaccia utente personalizzati utilizzano framework che possono risultare in un rendering meno efficiente di LWC (ad esempio Aura o Visualforce).
            <br> - LWC utilizza Apex per le operazioni sui dati.
            <br> - L'ordinamento e il filtraggio dei dati degli elenchi viene gestito sul lato server utilizzando Apex.
            <br> Salesforce Edge non è abilitato.
            </td>
        </tr>
    </tbody>
</table>

## Scalabilità

La scalabilità è la capacità di un sistema di funzionare in modo coerente mentre si evolve e cresce. Un sistema scalabile gestisce grandi aumenti dei volumi delle transazioni o l'accesso simultaneo senza modifiche sostanziali. I servizi piattaforma di Salesforce sono progettati per supportare la scalabilità delle applicazioni. Vedere [Elaborazione interna piattaforma](/docs/architect/it-it/fundamentals/guide/platform-multitenant-architecture#elaborazione-piattaforma-interna). Detto questo, man mano che l'organizzazione cresce e la domanda di prodotti e servizi aumenta, si è responsabili della creazione di un sistema in grado di funzionare in modo efficace e come previsto. L'architettura per la scalabilità fin dall'inizio si traduce in una consegna più rapida delle nuove funzioni e in un minor numero di interruzioni del servizio man mano che il traffico degli utenti aumenta. All'inizio della fase di progettazione, prima di distribuire nuove funzioni alla produzione, utilizzare **Test di scalabilità** per simulare i carichi di lavoro previsti e confermare che l'architettura può scalare per supportarli.

I sistemi non progettati per la scalabilità richiedono la risoluzione dei problemi, la riprogettazione e il refactoring costanti e costosi. I problemi di scalabilità si aggravano nel tempo, peggiorando le prestazioni in tutto il sistema. In alcuni casi, le aziende si trovano a spendere la maggior parte delle risorse di sviluppo e manutenzione per risolvere i problemi di scalabilità anziché per nuove funzioni che creano valore.

A volte, un'azienda raggiunge un punto critico. Il design originale del sistema non è in grado di supportare la crescita dell'azienda e gli eventi imprevisti rendono instabile il sistema. Utilizzare gli approfondimenti di **Scale Center** per identificare tempestivamente i punti critici della scalabilità. Scale Center mette in evidenza le aree calde delle eccezioni, le transazioni di lunga durata e i colli di bottiglia dell'area di attesa che peggiorano nel tempo.

È possibile progettare meglio la scala concentrandosi sull'ottimizzazione del modello di dati e sulla gestione del volume di dati.

_Nota: Anche se non viene discusso qui, il test della scalabilità è una parte fondamentale della convalida delle architetture delle applicazioni. Per indicazioni, vedere [Strategia di test](/docs/architect/it-it/well-architected/guide/resilient#strategia-di-test)._

### Modellazione dei dati

La modellazione dei dati consiste nel strutturare gli oggetti dell'organizzazione e correlarli tra loro in modo da consentire agli utenti e ai processi automatizzati di recuperare i dati di cui hanno bisogno il più rapidamente possibile. L'adozione di misure per [migliorare la produttività](/docs/architect/it-it/well-architected/guide/reliable#rendimento) risolve molti problemi di prestazioni, ma gli sforzi non saranno altrettanto efficaci senza un modello di dati ottimizzato.

Gli impatti negativi di un modello di dati mal progettato non sono immediatamente evidenti; i suoi punti deboli vengono esposti man mano che il sistema cresce in termini di volume di dati, processi, utenti e integrazioni. Un modello di dati ben progettato semplifica il refactoring continuo dell'applicazione man mano che i requisiti vengono aggiunti ed estesi. **ApexGuru** mette in evidenza gli schemi anti-accesso ai dati, ad esempio SOQL non selettivo, campi non utilizzati e inefficienze dello schema che influiscono direttamente sulla scalabilità del modello di dati.

Per ottimizzare il modello di dati:

- **Utilizzare i modelli di dati predefiniti di Salesforce**. Salesforce fornisce modelli di dati predefiniti per Sales, Service e una varietà di verticali di settore. L'uso dei modelli di dati forniti da Salesforce garantisce che le funzionalità del sistema vengano definite una sola volta, eliminando ridondanza e silos e stabilendo un'unica fonte di dati in tutto il sistema. Poiché per quell'unica fonte sono stati utilizzati modelli di dati predefiniti Salesforce, è più facile comprendere i dati delle applicazioni con gli analytics e utilizzare i servizi di intelligenza artificiale predefiniti di Salesforce. Inoltre, riducendo le personalizzazioni che è necessario supportare, si riducono i costi di manutenzione e l'indebitamento tecnico.
- **Scegliere i tipi di dati giusti**. Di seguito sono descritti i diversi tipi di campi supportati da Salesforce e le relative limitazioni. Considerare i requisiti di creazione di rapporti e crittografia per evitare di dover convertire i dati tra i tipi in futuro.
- **Scegliere le relazioni giuste**. Salesforce supporta due tipi di relazioni tra gli oggetti: record principale-record dettaglio e ricerca. Le relazioni record principale-record dettaglio offrono due vantaggi principali. Una è costituita dalle funzionalità di riepilogo di roll-up incorporate, che contano e aggregano i dettagli dei record secondari. L'altra è una funzionalità di eliminazione a cascata incorporata, tramite la quale l'eliminazione di un record controllante elimina anche i relativi record controllati. Tuttavia, assicurarsi di comprendere le [implicazioni di condivisione](/docs/architect/it-it/well-architected/guide/reliable#volume-di-dati) delle relazioni record principale-record dettaglio prima di decidere di utilizzarle.
- **Denormalizzare la scala.** La normalizzazione è il processo di strutturazione del modello di dati per ridurre la ridondanza dei dati e migliorare l'integrità dei dati. Sfortunatamente, la normalizzazione a volte causa problemi di scalabilità. Le tabelle denormalizzate possono avere prestazioni migliori su larga scala, ma ricordare di considerare l'integrità e la ridondanza dei dati.

Gli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/reliable#modelli-di-scalabilità-e-anti-schemi) mostrano l'aspetto corretto e inadeguato dell'ottimizzazione del modello di dati in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare opportunità di ulteriore ottimizzazione.

Per ulteriori informazioni sugli strumenti Salesforce per l'ottimizzazione del modello di dati, vedere [Salesforce Tools For Reliability](/docs/architect/it-it/well-architected/guide/reliable#strumenti-salesforce-per-laffidabilità).

### Volume di dati

Il volume di dati è una misura della quantità di dati archiviati nel sistema, in base ai conteggi e alle dimensioni dei record. Se l'organizzazione ha decine di migliaia di utenti, decine di milioni di record o centinaia di gigabyte di memoria record totale, si dispone di un volume di dati elevato. Il volume dei dati e le relazioni tra gli oggetti nell'organizzazione influiscono sulla scalabilità e probabilmente avranno un impatto maggiore sulla scalabilità rispetto al solo numero di record.

Per migliorare la scalabilità delle organizzazioni con volumi di dati elevati:

- **Distribuire record secondari**. Evitare la distorsione dei dati controllante-controllato assicurandosi che nessun controllante abbia un numero elevato di record controllati. Si consiglia in generale che nessun controllante abbia più di 10.000 record controllati. Ad esempio, in una distribuzione che ha molti referenti ma non utilizza account, valutare la possibilità di impostare più record account e di distribuire i record referente correlati tra di essi.
- **Distribuire la proprietà dei record**. Evitare la distorsione della proprietà assicurando che nessun utente o area di attesa sia titolare, né che tutti i membri di un singolo ruolo o gruppo pubblico siano titolari, di più di 10.000 record dello stesso oggetto. I dati di “parcheggio” con un “utente fittizio” sono una pratica che spesso porta a una distorsione della proprietà. Se si verifica questo problema, tenere presente l'impatto che avrà sui [calcoli di condivisione](/docs/architect/it-it/well-architected/guide/reliable#latenza). Se non è possibile ridistribuire i record per alleviare la distorsione della proprietà, evitare di assegnare l'utente titolare dei dati a un ruolo. Se il modello di condivisione dell'organizzazione richiede un'assegnazione di ruolo, collocare l'utente titolare dei dati in un ruolo distinto in cima alla gerarchia di condivisione. Non consentire modifiche frequenti o non pianificate nel ruolo dell'utente, poiché eventuali modifiche avranno impatti significativi sulle prestazioni a causa di ricalcoli della condivisione. Tenere l'utente fuori dai gruppi pubblici a cui si potrebbe fare riferimento in qualsiasi regola di condivisione.
- **Ridurre la quantità di dati dei record in Salesforce**. Salesforce è progettato per offrire alle aziende un'unica visualizzazione dei clienti. Può sembrare controintuitivo che la limitazione dei dati in Salesforce sia una procedura ottimale. Tuttavia, la potenza della visualizzazione singola risiede nel modo in cui consente agli utenti aziendali di comprendere e intervenire sui dati dei clienti. Man mano che il volume dei dati aumenta, i dati che non sono aggiornati o rilevanti per i processi quotidiani o gli analytics possono causare diversi problemi. Questi problemi includono il peggioramento delle prestazioni dell'app, un aumento del rischio per la sicurezza dei dati e impatti negativi su ricerca, rapporti e analisi. Per evitare questi problemi, definire un ciclo di vita dei dati per ogni oggetto del modello di dati, con tempistiche e classificazioni per i dati man mano che invecchiano e perdono valore aziendale immediato. In base al ciclo di vita dei dati, implementare le seguenti procedure per gestire i dati nel tempo.
  - **Archiviazione ed eliminazione** dei dati: per mantenere i volumi di dati il più bassi possibile, rimuovere i record che non sono necessari all'azienda per ridurre al minimo i volumi di dati. Utilizzare la funzione di eliminazione definitiva dell'API in blocco 2.0 per eliminare grandi volumi di dati.
  - **Aggregazione dei dati:** creare oggetti personalizzati di aggregazione che riassumono le tendenze storiche chiave o i dati di riepilogo in un formato compatibile con i rapporti. Compilare gli oggetti personalizzati utilizzando [Batch Apex](/docs/architect/it-it/well-architected/guide/reliable#rendimento). Gli utenti possono quindi eseguire rapporti basati sui record degli oggetti aggregati.
  - **Livello dei dati**. Gestire serie di dati di grandi dimensioni in un'applicazione diversa se non sono necessarie per i rapporti Salesforce o per il lavoro quotidiano. Rendere disponibili i dati in Salesforce in base alle esigenze tramite mashup, chiamate o oggetti esterni.

In pratica, potrebbe non essere sempre possibile affrontare immediatamente la causa principale di un problema di scalabilità quando si verificano problemi. Per questo motivo, Salesforce offre opzioni che consentono di alleviare i punti deboli immediati. È importante sapere che l'abilitazione di queste funzioni nell'organizzazione non è una strategia architetturale praticabile a lungo termine per gestire grandi volumi di dati. Queste soluzioni a breve termine possono contribuire a ridurre la latenza nei sistemi con un'architettura dei dati scadente, ma possono anche aumentare il debito tecnico dell'organizzazione.

Le soluzioni a breve termine per i problemi di scala includono:

- **Indici personalizzati Gli** indici sono memorizzati in una tabella interna speciale utilizzata dall'ottimizzazione delle query della piattaforma per velocizzare le operazioni di accesso ai dati. Vedere [Indici multi-tenant](/docs/architect/it-it/fundamentals/guide/platform-multitenant-architecture#indici)). La piattaforma indicizza automaticamente alcuni tipi di campi per impostazione predefinita. Per velocizzare le query con scarse prestazioni, è possibile richiedere indici personalizzati aggiuntivi contattando l'Assistenza clienti Salesforce. Utilizzare lo strumento Query Plan (Piano di esecuzione query) per determinare se gli indici personalizzati miglioreranno le prestazioni delle query.
- **Tavoli magri**. Se è necessario ottimizzare ulteriormente le query per insiemi di campi comuni su oggetti con più di 1 milione di record, le tabelle semplici possono essere utili. Le tabelle semplici eliminano il [join in background](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm) che si verifica quando si utilizzano campi standard e personalizzati dello stesso oggetto in un rapporto o in un'automazione. Per utilizzare le tabelle "snelle", l'Assistenza clienti Salesforce deve abilitarle per l'organizzazione.

Gli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/reliable#modelli-di-scalabilità-e-anti-schemi) per la scalabilità mostrano l'aspetto di una corretta e scarsa gestione del volume di dati in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare opportunità di ulteriore ottimizzazione.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione dei volumi di dati, vedere [Salesforce Tools For Reliability](/docs/architect/it-it/well-architected/guide/reliable#strumenti-salesforce-per-laffidabilità).

### Modelli di scalabilità e anti-schemi

Questa sezione mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o da correggere.

✨ Scopri altri schemi per la scalabilità in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-scalability).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Modellazione dei dati</b></td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Gli standard e le linee guida per i quali esistono giustificazioni aziendali che giustificano l'esistenza di un oggetto personalizzato.
            </td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Non esistono standard per la creazione di oggetti personalizzati.
            </td>
        </tr>
         <tr>
            <td><b>Nel modello di dati:</b>
                <br> Ove possibile, vengono utilizzati oggetti standard.
                <br> - I controlli ApexGuru per gli anti-schemi confermano che le query SOQL sono selettive ed evitano l'utilizzo inefficiente dello schema.
                <br> - Le tabelle sono denormalizzate per la scala.
            </td>
            <td><b>Nel modello di dati:</b>
                <br> - Sono stati replicati oggetti standard.
                <br> - Le tabelle vengono normalizzate per evitare ridondanze.
            </td>
        </tr>
         <tr>
            <td><b>All'interno della tua azienda:</b>
                <br> I generatori low-code conoscono i diversi tipi di campi supportati da Salesforce e valutano i requisiti di creazione di rapporti e crittografia prima di selezionare i tipi di dati dei campi.
                <br> - Prima di decidere di stabilire una relazione record principale-record dettaglio tra gli oggetti, valutare le implicazioni di condivisione e distorsione dei dati di tale relazione.
            </td>
            <td><b>All'interno della tua azienda:</b>
                <br> - I generatori low-code selezionano i tipi di dati senza valutare i requisiti di creazione di rapporti e crittografia a valle.
                <br> - Prima di decidere di stabilire relazioni record principale-record dettaglio tra gli oggetti, non si valutano le implicazioni di condivisione e distorsione dei dati di tale relazione.
            </td>
        </tr>
        <tr>
            <td rowspan="3"><b>Volume di dati</b></td>
            <td><b>Nei dati:</b>
                <br> - Nessun record controllante ha più di 10.000 record controllati.
                <br> - Nessun utente è assegnato a più di 10.000 record dello stesso tipo di oggetto.
                <br> - Nessuna istanza include più di 10.000 record con campi di ricerca che puntano allo stesso record.
                <br> - I caricamenti di dati in blocco vengono ordinati in batch in base ai valori dei campi ParentId.
                <br> - Per assicurarsi che le strategie batch non si interrompano contemporaneamente, viene utilizzato Test di scalabilità per convalidare gli schemi di carico in blocco su scala di produzione.
                <br> - I caricamenti di dati in blocco in produzione non avvengono durante gli orari di punta.
                <br> - I caricamenti di dati in blocco includono solo i dati minimi necessari per le decisioni aziendali.
            </td>
            <td><b>Nei dati:</b>
                <br> - Esistono record con più di 10.000 record controllati.
                <br> - Gli utenti vengono assegnati a più di 10.000 record dello stesso tipo.
                <br> - Esistono istanze in cui più di 10.000 record hanno campi di ricerca che puntano allo stesso record.
                <br> - I caricamenti di dati in blocco non vengono ordinati in batch in base ai valori dei campi ParentId.
                <br> - I caricamenti di dati in blocco in produzione si verificano durante l'orario di ufficio di punta.
                <br> - I caricamenti di dati in blocco non sono limitati ai dati minimi necessari per le decisioni aziendali.
            </td>
        </tr>
         <tr>
            <td><b>In Flusso e Apex:</b>
                <br> - Esiste una logica per distribuire il numero di record controllati in più record controllanti in scenari in cui la distorsione dei dati è un problema.
                <br> - Quando si importano o replicano record tramite integrazione, la logica li assegna agli utenti umani appropriati.
                <br> - Per le raccolte Apex, ad esempio elenchi e insiemi, esiste una logica per elaborare più record per ridurre al minimo le query e ottimizzare la gestione dei dati.
                <br> - Viene scritto e distribuito Apex Code efficiente che segue gli standard e le procedure consigliate per il codice scalabile. 
            </td>
            <td><b>In Flusso e Apex:</b>
                <br> - I record controllati vengono assegnati arbitrariamente ai record controllanti, indipendentemente dal numero di record controllati già assegnati.
                <br> - I record creati tramite caricamenti di dati o integrazioni vengono assegnati a un "utente integrazione" generico.
                <br> - Più query SOQL ricorsive dallo stesso oggetto sono in transazioni sincrone, causando un elevato utilizzo dell'heap.
                <br> - Quando gli sviluppatori scrivono Apex Code, introducono inefficienze e <a href="https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipatterns.htm&type=5">schemi anti-</a>prestazioni.
            </td>
        </tr>
         <tr>
            <td><b>All'interno della tua azienda:</b>
                <br> - Hai documentato e implementato una strategia di archiviazione ed eliminazione dei dati
            </td>
            <td><b>All'interno della tua azienda:</b>
                <br> - Non si dispone di una strategia di archiviazione ed eliminazione dei dati o la strategia è stata documentata ma non implementata
            </td>
        </tr>
    </tbody>
</table>

## Strumenti Salesforce per l'affidabilità

<table class="tools-table"><tbody><tr><th>Strumento</th><th>Descrizione</th><th>Disponibilità</th><th>Prestazioni</th><th>Scalabilità</th></tr>
  <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.bigobjects.meta/bigobjects/big_object.htm">Big Object</a></td>
      <td>Archiviare e gestire grandi volumi di dati sulla piattaforma.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://github.com/forcedotcom/code-analyzer">Scanner di codice</a></td>
      <td>Analizzare Apex Code per rilevare eventuali problemi di prestazioni.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_indexes.htm">Indici personalizzati</a></td>
      <td>Migliorare le prestazioni delle query con gli indici personalizzati.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_techniques_deleting_data.htm">Eliminazione dei dati</a></td>
      <td>Rimuovere i dati non necessari per migliorare le prestazioni.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_divisions.htm">Divisioni</a></td>
      <td>Partizionare i dati per limitare i conteggi dei record nelle query e nei rapporti.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=xcloud.scale_test_overview.htm&type=5">Test <a href="https://help.salesforce.com/s/articleView?id=sf.technical_requirements_performance_assistant.htm&type=5"></a>di scala</a> </td>
      <td>Testare le prestazioni del sistema e interpretare i risultati. Prima della distribuzione in produzione, per convalidare la scalabilità e le prestazioni, simulare carichi di lavoro API e interfaccia utente su larga scala utilizzando script Playwright o JMeter.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=xcloud.scale_center_overview.htm&type=5">Centro scala</a></td>
      <td>Ottenere approfondimenti self-service e in tempo reale sulle prestazioni del sistema. Individuare transazioni di lunga durata, punti salienti delle eccezioni e colli di bottiglia della produttività. Diagnosticare i problemi di scala nelle prime fasi del ciclo di sviluppo.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_apexguru.htm&release=258&type=5">ApexGuru</a></td>
      <td>Utilizzare questa funzione basata su GenAI in Scale Center per rilevare gli schemi anti-classe Apex, SOQL e di test in fase di esecuzione. Tramite l'integrazione di ApexGuru con Salesforce Code Analyzer, è possibile ottenere consigli basati sull'intelligenza artificiale e correzioni in linea nel flusso di lavoro di sviluppo. Utilizzare questi consigli e correzioni per risolvere gli hotspot e migliorare la selettività delle query, l'ingombro, l'utilizzo della cache e la qualità dei test.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://github.com/forcedotcom/code-analyzer">Analizzatore di codice Salesforce</a></td>
      <td>Analizzare il codice con IDE, CLI o CI/CD per assicurarsi che rispetti le procedure consigliate. Tramite l'integrazione di Salesforce Code Analyzer con ApexGuru, è possibile ottenere informazioni sugli schemi anti-prestazioni direttamente nel flusso di lavoro dello sviluppatore.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=sf.domain_name_edge_network_route_my_domain.htm&type=5">Salesforce Edge Network</a></td>
      <td>Migliorare i tempi di download e l'esperienza utente instradando il <a href="https://help.salesforce.com/s/articleView?id=xcloud.domain_name_overview.htm&language=en_US&type=5">Dominio personale</a> attraverso Salesforce Edge Network.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm">Tavole Skinny</a></td>
      <td>Evitare i join nelle tabelle che hanno campi utilizzati di frequente.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=000382042&type=1">Proactive Monitoring</a></td>
      <td>Monitorare costantemente le anomalie nella crescita dei record, la distorsione della proprietà e le regressioni delle prestazioni. Avvisare i problemi su larga scala prima che diventino critici.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
</table>

## Risorse Salesforce per l'affidabilità

<table class="tools-table"><tbody><tr><th>Risorsa</th><th>Descrizione</th><th>Disponibilità</th><th>Prestazioni</th><th>Scalabilità</th></tr>
  <tr>
      <td><a href="https://www.salesforce.com/blog/scalability/">Le sfide di scalabilità costano milioni di euro: ecco come rendere il business a prova di futuro</a></td>
      <td>Scopri in che modo implementare la scalabilità porta a una crescita sostenibile e a un successo a lungo termine.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/blogs/2023/07/salesforce-scale-center-is-generally-available">Creazione e distribuzione di applicazioni scalabili con Scale Center</a></td>
      <td>Informazioni su come valutare e risolvere in modo proattivo i problemi di prestazioni nelle implementazioni Salesforce.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/blogs/2022/05/analyze-performance-scale-hotspots-in-complex-salesforce-apps">Analisi degli hotspot di prestazioni e scalabilità nelle app Salesforce complesse</a></td>
      <td>Risolvere i problemi di prestazioni e scalabilità nell'organizzazione.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://www.salesforce.com/blog/scale-testing/">L'app non deve andare nel panico nel traffico dell'ora di punta - Ecco come prepararsi</a></td>
      <td>Di seguito sono descritti quattro passaggi chiave per eseguire correttamente il test su scala.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/blogs/2025/06/the-apexguru-ai-engine-explained">Spiegazione del motore AI ApexGuru</a></td>
      <td>Di seguito viene descritto come ApexGuru utilizza i modelli addestrati su misura, la telemetria dell'organizzazione reale e i filtri intelligenti per offrire approfondimenti precisi, contestuali e di immediato valore pratico.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://trailhead.salesforce.com/content/learn/modules/apexguru/optimize-apex-code-with-apexguru">Ottimizzazione di Apex per app e Agentforce con ApexGuru</a></td>
      <td>Di seguito viene descritto come ApexGuru aiuta gli sviluppatori a rilevare e correggere gli schemi anti-prestazioni, inclusi SOQL, DML, debug e test delle inefficienze., Utilizzare ApexGuru come coach basato sull'intelligenza artificiale per lo sviluppo scalabile delle app e l'implementazione di Agentforce.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipatterns.htm&type=5">Antipattern ApexGuru</a></td>
      <td>Informazioni sulla libreria ufficiale degli schemi anti-pattern rilevati da ApexGuru, aggiornata per ogni rilascio principale di Salesforce.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_introduction.htm">Procedure consigliate per le distribuzioni con grandi volumi di dati</a></td>
      <td>Comprendere l'impatto dei processi di grandi volumi di dati.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=xcloud.domain_name_edge_network_considerations.htm&type=5">Considerazioni per Salesforce Edge Network</a></td>
      <td>Di seguito viene descritto come preparare l'organizzazione all'utilizzo di Salesforce Edge Network.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="/docs/architect/it-it/resources/guide/design-standards-template">Modello Design Standards (Standard di progettazione)</a></td>
      <td>Creare standard di progettazione per la propria organizzazione.</td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://medium.com/salesforce-architects/data-model-design-considerations-when-building-salesforce-applications-part-1-4e605f504b54">Considerazioni sulla progettazione del modello di dati</a></td>
      <td>Ottimizzare i modelli di dati per la scalabilità e la manutenzione.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_preface.htm">Progettazione dell'accesso ai record su scala aziendale</a></td>
      <td>Ottimizzare le prestazioni del controllo degli accessi tramite la configurazione.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_for_performance.htm">Infrastruttura per sistemi con grandi volumi di dati</a></td>
      <td>Informazioni sulle funzionalità che supportano le prestazioni del sistema per le distribuzioni con volumi di dati elevati.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_rebates_additional_resources_for_batch_management.htm&type=5">Risorse didattiche per la gestione dei batch</a></td>
      <td>Informazioni su Gestione batch.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://trailhead.salesforce.com/content/learn/modules/lightning-experience-performance-optimization">Ottimizzazione delle prestazioni Lightning Experience</a></td>
      <td>Migliorare Lightning Experience nell'organizzazione per aiutare gli utenti a lavorare più velocemente.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/blogs/engineering/2013/04/managing-lookup-skew-to-avoid-record-lock-exceptions">Gestione della deviazione di ricerca in Salesforce per evitare le eccezioni del blocco dei record</a></td>
      <td>Di seguito viene descritto come ridurre al minimo gli effetti delle distorsioni della ricerca.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_best_practices_soql_and_sosl.htm">Procedure consigliate SOQL e SOSL</a></td>
      <td>Seguire le procedure consigliate SOQL e SOSL per le distribuzioni con volumi di dati elevati.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_tools.htm">Strumenti per riallineamenti su larga scala</a></td>
      <td>Pianificare ed eseguire i riallineamenti in modo efficace.</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_techniques_using_mashups.htm">Utilizzo dei mashup</a></td>
      <td>Gestire serie di dati di grandi dimensioni in un'applicazione diversa.</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
</table>

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.

<!-- document id=56d89990cbfae066ddc2357ba70740966da1610ec7e6ce80e131f9598e95ec1b url=/architect/next/it-it/well-architected/guides/trusted-overview.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

Una soluzione Salesforce **affidabile** protegge le aziende e gli stakeholder. Una soluzione ben progettata per essere **affidabile** è sicura, conforme e affidabile.

Le soluzioni **protette** controllano l'accesso e proteggono i dati.<br>
Le soluzioni **conformi** seguono le linee guida legali ed etiche.<br>
Soluzioni **affidabili** funzionano in modo efficiente e affidabile.<br>

La creazione di una soluzione **affidabile** richiede un'attenta pianificazione. È necessario comprendere il contesto dell'azienda e/o del settore in cui opera la soluzione. Qual è la tolleranza di rischio complessiva dell'azienda? Quali tipi di dati entreranno e usciranno dal sistema? Salesforce fungerà da sistema di record o punto di archiviazione per i dati con sicurezza, conformità o considerazioni etiche specializzate? Quali sono i regolamenti e gli standard di conformità pertinenti? Esistono ulteriori standard specifici dell'azienda? Salesforce è un sistema business-critical? Ci sono picchi stagionali o circostanziali nel traffico o nell'utilizzo del sistema che è necessario prendere in considerazione?

Per arrivare a una soluzione **affidabile**, è necessario collaborare con gli stakeholder di tutta l'azienda. È necessario avere una visione chiara dei tipi di utenti e sistemi che dovranno accedere alla soluzione, nonché dei dati e delle autorizzazioni necessari per eseguire il lavoro. È necessario conoscere i requisiti legali e di settore, nonché le politiche e gli standard interni. È necessario collaborare con i team di sviluppo e manutenzione per garantire che le funzioni siano accessibili e servano equamente gli utenti. Sarà necessario pianificare la disponibilità e le prestazioni delle soluzioni, anche in caso di interruzione o rapida crescita. Niente è più essenziale per una soluzione ben progettata che essere **fidati**.

Le sezioni seguenti offrono indicazioni più approfondite per le considerazioni principali di un'architettura di soluzioni **attendibile**.

## Panoramica affidabile

<table>
<tbody>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/secure">Sicuro</a></th>
        </tr>
        <tr>
        <td colspan="3">Un sistema sicuro protegge l'azienda, gli stakeholder e i dati. Le architetture protette garantiscono che solo gli utenti approvati possano accedere, limitare l'accesso degli utenti a ciò che è essenziale per il lavoro e proteggere i dati all'interno del sistema dalla compromissione.</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/secure#sicurezza-organizzativa">Sicurezza organizzativa</a></th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/secure#sicurezza-della-sessione">Sicurezza della sessione</a></th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/secure#sicurezza-dei-dati">Sicurezza dei dati</a></th>
        </tr>
        <tr>
            <td>Autenticazione <br>Autorizzazione</td>
            <td>Gestione sessioni<br>Accesso dispositivo <br>Rilevamento e risposta alle minacce</td>
            <td>Condivisione e visibilità <br>Uso della crittografia</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/compliant">Conforme</a></th>
        </tr>
        <tr>
        <td colspan="3">Le soluzioni conformi seguono le linee guida legali ed etiche. Le architetture conformi sono conformi ai regolamenti legali e agli standard di settore, rispettano le policy etiche e servono tutti gli utenti in modo equo.</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/compliant#aderenza-giuridica">Conformità giuridica</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/compliant#standard-etici">Standard etici</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/compliant#accessibilità">Accessibilità</th>
        </tr>
        <tr>
            <td>Privacy dei dati <br>Localizzazione</td>
            <td>Policy aziendali <br>Intelligenza artificiale</td>
            <td>Immissione dati <br>Navigazione</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/reliable">Affidabile</a></th>
        </tr>
        <tr>
        <td colspan="3">Soluzioni affidabili funzionano in modo efficiente e affidabile, in una serie di condizioni. Architetture affidabili sono disponibili quando e dove gli utenti si aspettano, funzionano in modo coerente e scalano con l'azienda.</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/reliable#disponibilità">Disponibilità</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/reliable#prestazioni">Prestazioni</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/reliable#scalabilità">Scalabilità</th>
        </tr>
        <tr>
            <td>Gestione dei rischi <br>Mitigazione degli errori </td>
            <td>Rendimento <br>Latenza</td>
            <td>Modellazione dei dati <br>Volume di dati </td>
        </tr>
        </tbody>
</table>

<!-- document id=786cbb083b9e065e8c5a51cc6e8b5281c2151dc739c7b680a74b65a9450dafc9 url=/architect/next/it-it/well-architected/guides/automated.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

I sistemi dimostrano il comportamento automatico consentendo all'azienda di raggiungere gli obiettivi chiave più rapidamente e su larga scala. Una sana automazione consente agli utenti di concentrarsi su lavori di valore elevato e riduce il tempo dedicato a operazioni manuali ripetitive o all'immissione di dati complessi.

Molto spesso, l’automazione significa tradurre i processi aziendali da una forma all’altra: dalla forma cartacea alla forma digitale, da un vecchio sistema a uno nuovo. Con ogni traduzione dei processi aziendali viene offerta un'opportunità di trasformazione.

Trasformazione non significa utilizzare le nuove tecnologie per introdurre cambiamenti dirompenti e confusi per gli utenti. Trasformazione significa creare modi più semplici per svolgere il lavoro, consentire al business di crescere senza frizioni e consentire agli utenti aziendali di concentrarsi più a fondo su ciò che conta davvero per i loro stakeholder. Da un punto di vista architettonico, si tratta di identificare le operazioni che possono essere eliminate del tutto o gestite automaticamente. Richiede una chiara connessione tra le modalità di utilizzo della tecnologia e il suo impatto misurabile sul business.

Una cosa importante da notare sull'automazione con Salesforce: può essere eseguita con una varietà di strumenti, utilizzando serie di competenze programmatiche e dichiarative. Progettare automazioni ben progettate non significa scegliere di creare con un solo strumento di automazione. Si tratta di utilizzare approcci coerenti e prevedibili e di consentire ai team di sviluppare, testare, distribuire e gestire le automazioni progettate. Le automazioni devono assumere la forma più [manutenbile e leggibile](/docs/architect/it-it/well-architected/guide/intentional) possibile.

Questa sezione descrive come progettare e rifattorizzare le automazioni per consentire alle aziende di raggiungere gli obiettivi chiave più rapidamente e su larga scala. È possibile migliorare l'architettura delle automazioni in Salesforce concentrandosi sull'efficienza e l'integrità dei dati.

## Efficienza

Creare efficienza nelle automazioni non significa ricreare correttamente il business come al solito con le tecnologie Salesforce. Si tratta di comprendere a fondo le metriche chiave e i risultati aziendali di cui i team saranno responsabili per l'incontro o il tracciamento e di fare un passo indietro per vedere le [unità funzionali](/docs/architect/it-it/well-architected/guide/composable#unità-funzionali) all'interno e in tutto il lavoro che si sta automatizzando. Si tratta di identificare come creare schemi con le automazioni che consentono all'azienda di operare in modo più efficace e rapido, su larga scala.

Una logica di automazione efficiente renderà i sistemi:

- Più scalabile e utile per l'azienda
- Più utile per gli utenti
- Più [adattabile](/docs/architect/it-it/well-architected/guide/adaptable-overview) e in grado di soddisfare le esigenze aziendali in continua evoluzione

È possibile migliorare l'efficienza delle automazioni tramite la progettazione dei processi e la logica operativa.

### Progettazione dei processi

La progettazione dei processi prevede la definizione delle modalità di esecuzione del lavoro. Costruire processi realmente efficienti ed efficaci significa che i progetti non si limitano a replicare i metodi di lavoro correnti. È essenziale identificare ed eliminare le fasi inefficaci o poco chiare. I processi ottimizzati dovrebbero creare un valore aziendale misurabile (vedere [KPI](/docs/architect/it-it/well-architected/guide/automated#kpis)) senza passaggi inutili. Passaggi poco chiari o non necessari probabilmente creeranno debito tecnico e determineranno automazioni ingestibili.

Spesso, la responsabilità di individuare e documentare i processi aziendali ricadrà sotto la responsabilità di un analista aziendale o anche di un amministratore di sistema. Gli architetti sono responsabili della collaborazione con questi membri del team per assicurarsi che i progetti dei processi siano tecnicamente solidi e ben strutturati. Applicare la propria Knowledge della piattaforma Salesforce il prima possibile aiuterà il team a identificare i processi da semplificare attraverso l'automazione o i processi che devono cambiare per evitare costose personalizzazioni.

Per creare processi ottimizzati per Salesforce, tenere presente quanto segue:

- **Definire accuratamente i processi**. È più probabile che i processi con scopi poco chiari o definizioni ambigue vengano interpretati in modo errato in fase di progettazione. Ciò porterà a progetti difettosi basati su presupposti, che determineranno automazioni errate o inefficienti. Assicurarsi che i processi aziendali che si desidera automatizzare soddisfino i seguenti standard:

  - Limitato a una singola funzione specifica (vedere [Unità funzionali](/docs/architect/it-it/well-architected/guide/composable#unità-funzionali))
  - Ha output chiaramente definiti e misurabili (vedere [Valore aziendale](/docs/architect/it-it/well-architected/guide/automated#valore-aziendale))
  - Ha input e output chiaramente definiti

- **Chiarire le fasi** del processo.\* Anche se a volte può essere allettante aggiungere ulteriori fasi che "potrebbero essere utili in futuro", questo non è mai un buon approccio. Ogni fase di un'automazione è rilevante per l'esito del processo complessivo. Assicurarsi che ogni fase del processo abbia le seguenti caratteristiche:
  - Esegue un'operazione specifica e granulare (vedere [componibile](/docs/architect/it-it/well-architected/guide/composable))
  - Obbligatorio per il processo per generare l'output definito (rimuovere tutte le fasi non essenziali)
  - Può essere completato utilizzando un numero minimo di risorse
  - Utilizza i dati di sistema esistenti anziché richiedere gli input dell'utente dove possibile (vedere [Coinvolgimento](/docs/architect/it-it/well-architected/guide/engaging))
  - Fornisce opzioni di input che gli utenti possono comprendere senza dover sapere come funzionano i sistemi sottostanti (vedere [utile](/docs/architect/it-it/well-architected/guide/engaging#utile))

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/automated#schemi-di-efficienza-e-anti-schemi) riportato di seguito mostra l'aspetto corretto (e scadente) dell'ottimizzazione in un'organizzazione Salesforce. È possibile utilizzarli per convalidare i progetti di automazione prima di crearli o identificare le automazioni che devono essere ottimizzate ulteriormente.

Per ulteriori informazioni sugli strumenti di automazione dei processi disponibili in Salesforce, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/automated#strumenti-rilevanti-per-lautomazione) l'automazione.

### Logica operativa

La logica operativa si occupa dell'efficacia con cui un processo viene tradotto dalla sua progettazione in un'implementazione effettiva. Le automazioni con una forte logica operativa continuano a funzionare bene, indipendentemente dai picchi di volume delle transazioni o dal numero di istanze simultanee in esecuzione. Automazioni logicamente valide aiutano le aziende a scalare più facilmente per operare a livelli di domanda più elevati. La creazione di una forte logica operativa nelle automazioni è direttamente correlata all'[affidabilità](/docs/architect/it-it/well-architected/guide/reliable) complessiva del sistema.

Le automazioni che non funzionano in modo efficace offrono esperienze utente e cliente scadenti, causando potenziali perdite di reddito e perdita di Trust dei clienti. Hanno anche costi di manutenzione più elevati e possono diventare colli di bottiglia che ritardano i processi correlati, contribuendo a problemi di prestazioni complessive del sistema.

Per creare una logica operativa efficace nelle automazioni, considerare quanto segue:

- **Assicurarsi che tutti coloro che creano automazioni conoscano il modo giusto per farlo**. Scelte di progettazione sbagliate possono essere effettuate con qualsiasi tipo di strumento di automazione. Il codice non è meno soggetto a errori o scelte di implementazione inadeguate rispetto agli strumenti basati sui clic. L'uso di ID riferimento codificati, ad esempio, è un anti-schema che appare sia nel flusso che nel codice. Gli strumenti basati su clic non devono essere visti come una licenza per consentire a chiunque di rilasciare un'automazione in produzione. Ogni membro del team che crea un'automazione deve sapere come crearla nel modo giusto. Per ulteriori informazioni su come definire e applicare standard efficaci nei vari sistemi, vedere [gli standard di](/docs/architect/it-it/well-architected/guide/intentional#leggibilità) [progettazione](/docs/architect/it-it/well-architected/guide/intentional#design-standards).
- **Documentare chiaramente tutti i percorsi di esecuzione**. L'aumento dell'utilizzo delle automazioni non solo aumenta i potenziali volumi di dati, ma aumenta anche i contesti di chiamata non pianificata. È necessario capire in che modo è possibile invocare automazioni diverse e assicurarsi che in tutte le automazioni con più punti di ingresso compaiano controlli delle transazioni adeguati (vedere Gestione dei dati). Ad esempio, i flussi schermata non verranno eseguiti con caricamenti di dati in blocco, ma probabilmente verranno eseguiti trigger Apex e flussi attivati (e AutoLaunched). Documentare chiaramente i percorsi di esecuzione pianificati e potenziali per le automazioni è un aspetto chiave per capire quali condizioni logiche sarà necessario soddisfare durante l'implementazione.
- **“Bulkify” tutte le operazioni sui dati (incluso SOQL)**. Ogni operazione sui dati (inserimento, aggiornamento e così via) deve essere eseguita sulle raccolte. Sempre. Senza eccezioni. Questo è ciò che si intende per operazioni di “bulkification”. Benché la piattaforma possa supportare operazioni sui dati singleton, non è mai consigliabile consentire l'implementazione di schemi singleton.
- **Utilizzare SOSL per operazioni** di ricerca. Esiste l'errata convinzione che le operazioni sui dati non possano essere eseguite sui record restituiti tramite SOSL. È vero che DML non può essere invocato direttamente sui risultati SOSL, ma il codice può analizzare i risultati SOSL e creare una raccolta a cui si può fare riferimento nei metodi DML o nelle classi Database. Le differenze principali tra SOSL e SOQL sono i tipi di risultato per ciascuno e il modo in cui rispondono alle ricerche generalizzate o con caratteri jolly. SOSL può funzionare con diversi tipi di sObject (motivo per cui il tipo restituito è diverso) e può gestire ricerche di caratteri jolly e stringhe generalizzate con prestazioni migliori di SOQL.
- **Trattare SOQL come un'operazione dati**. Non utilizzare SOQL per trovare i record, ma per perfezionare le operazioni sui dati. Le operazioni SOQL e sui dati possono avere un impatto molto simile sulle prestazioni del [database relazionale sottostante](/docs/architect/it-it/fundamentals/guide/platform-multitenant-architecture#livello-di-dati-piattaforma). SOQL può anche passare [un indicatore DML esplicito](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update) che blocca le righe del database in previsione delle operazioni sui dati. Per creare automazioni scalabili, assicurarsi di trattare l'SOQL con una dovuta diligenza simile: non utilizzarlo senza criteri di selezione molto specifici e ben formati, non consentire riferimenti a campi estranei e richiedere un'attenta corrispondenza dei tipi di dati tra i campi e gli input dei filtri nella logica delle istruzioni `WHERE`. Il codice deve inoltre disporre di controlli appropriati per garantire che una query non venga mai eseguita in contesti non in blocco o in base a criteri di filtro nulli o vuoti.
- **Mantenere le operazioni sincrone strettamente concentrate sul lavoro che aiuta un utente in tempo reale**. Durante l'[ottimizzazione dei processi](/docs/architect/it-it/well-architected/guide/automated#progettazione-dei-processi), identificare la logica pertinente a ciò che gli utenti devono fare in tempo reale o quasi in tempo reale e a ciò che può essere rinviato in una transazione asincrona (asincrona). Vedere [Gestione dei dati](/docs/architect/it-it/well-architected/guide/automated#gestione-dei-dati) per ulteriori considerazioni sulla progettazione delle operazioni di sincronizzazione/asincronismo.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/automated#schemi-di-efficienza-e-anti-schemi) riportato di seguito mostra la logica operativa corretta (e scadente) nell'automazione di Salesforce. È possibile utilizzarli per convalidare i progetti di automazione prima di crearli o identificare le automazioni che devono essere ottimizzate ulteriormente.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce che possono aiutare a pianificare la scalabilità, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/automated#strumenti-rilevanti-per-lautomazione) l'automazione.

### KPIs

I KPI di automazione misurano l'impatto di un'automazione nel tempo. Senza di loro, non sarà possibile capire se un'automazione sta davvero aggiungendo valore aziendale o creando complessità indesiderata per gli utenti. Ogni automazione creata deve essere collegata a una serie di KPI chiari e misurabili.

I KPI corretti sono definiti da un valore misurabile e da un intervallo di tempo associato. Gli esempi includono:

- \[Numero X] ore lavorative salvate al mese
- Errori di elaborazione dovuti all'immissione manuale dei dati ridotti di \[Y%] alla settimana

Una volta ottenuti KPI chiari e misurabili, è necessario anche capire se e come un'automazione in Salesforce genererà dati rilevanti per la generazione di rapporti rispetto a tali KPI.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/automated#schemi-di-efficienza-e-anti-schemi) riportato di seguito mostra l'aspetto dei KPI corretti (e scadenti) quando si tratta di automazioni Salesforce. È possibile utilizzarli per convalidare i KPI esistenti o identificare dove è necessario identificare meglio i KPI prima di crearli.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce per assistenza con gli indicatori di prestazione chiave (KPI), vedere [Strumenti pertinenti all'automazione](/docs/architect/it-it/well-architected/guide/automated#strumenti-rilevanti-per-lautomazione).

### Schemi di efficienza e anti-schemi

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per l'efficienza in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/easy-efficiency).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="2"><b>Processo di progettazione</b></td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Ogni flusso serve un unico scopo specifico
            <br> - Ogni fase esegue un'operazione specifica e granulare
            <br> - I flussi sono organizzati in una struttura gerarchica costituita da un flusso principale e da sottoflussi di supporto
            <br> - Tutti gli input utente hanno uno scopo chiaro all'interno del flusso
            <br> - Agli utenti viene chiesto di fornire dati solo quando non è possibile utilizzare i dati di sistema esistenti</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - I flussi servono a più scopi e richiedono input aggiuntivi per fornire contesto
            <br> - I flussi richiedono input i cui dati non vengono utilizzati
            <br> - Gruppi di fasi correlate contengono funzionalità che si sovrappongono a gruppi di fasi in altri flussi
            <br> - I flussi richiedono gli input dell'utente quando è possibile utilizzare i dati memorizzati</td>
        </tr>
        <tr>
            <td><b>In Apex:</b>
            <br> - Ogni classe serve un unico scopo specifico
            <br> - Ogni metodo esegue un'operazione specifica e granulare
            <br> - Tutte le variabili di input hanno uno scopo chiaro all'interno della classe<br> - L'esecuzione del codice richiede un numero minimo di risorse</td>
            <td><b>In Apex:</b>
            <br> - Le classi servono a più scopi
            <br> - I metodi eseguono più operazioni o i metodi eseguono operazioni non in linea con lo scopo dichiarato della classe di cui fanno parte
            <br> - Le variabili di input non vengono effettivamente utilizzate nei metodi
            <br> - I metodi recuperano inutilmente i dati dal database o da sistemi esterni</td>
        </tr>
        <tr>
            <td rowspan="3"><b>Logica operativa</b></td>
            <td><b>Nel flusso:</b>
            <br> - Nessuna variabile fa riferimento a valori codificati (per tipi di record, utenti, ecc.)
            <br> - Tutti i flussi e i processi AutoLaunched utilizzano elementi decisionali e/o di pausa per valutare i criteri di immissione e impedire loop o esecuzioni infinite su grandi volumi di dati
            <br> - I flussi (compresi i processi) passano la logica ad Apex in contesti con grandi volumi di dati
            <br> - I sottoflussi vengono utilizzati per le sezioni di un processo che devono essere riutilizzate in tutta l'azienda</td>
            <td><b>Nel flusso:</b>
            <br> - Le variabili hanno valori codificati
            <br> - I flussi (compresi i processi) devono essere disattivati manualmente prima del caricamento in blocco dei dati
            <br> - I flussi (compresi i processi) attivano avvisi di "eccezione non gestita"
            <br> - Anche i flussi semplici causano regolarmente errori relativi ai limiti del governor
            <br> - Porzioni di un flusso vengono ripetute tra i flussi anziché utilizzare i sottoflussi</td>
        </tr>
        <tr>
            <td><b>In Apex:</b>
            <br> - Nessuna variabile fa riferimento a valori codificati (per tipi di record, utenti, ecc.)
            <br> - Tutti i criteri dei caratteri jolly vengono visualizzati in SOSL
            <br> - SOQL è racchiuso in <code>try-catch</code>
            <br> - Nessun SOQL viene visualizzato all'interno di un loop
            <br> - Le istruzioni SOQL sono selettive, tra cui:
                <br> -- nessun utilizzo di confronti <code>LIKE</code> o confronti di testo parziali
                <br> -- gli operatori di comparizione utilizzano la logica positiva (cioè <code>INCLUDE</code>, <code>IN</code>) come logica principale o solo logica
                <br> -- l'utilizzo di <code>= NULL</code>, <code>!= NULL</code> è raro e/o segue sempre un operatore di comparizione positivo
                <br> -- non vengono visualizzate istruzioni <code>LIMIT 1</code>
                <br> -- nessun utilizzo della parola chiave <code>ALL ROWS</code>
            <td><b>In Apex:</b>
            <br> - Le variabili hanno valori codificati
            <br> - SOSL è raramente o non costantemente utilizzato per i criteri di selezione dei caratteri jolly
            <br> - SOQL non è racchiuso in <code>try-catch</code>
            <br> - SOQL viene visualizzato all'interno dei loop
            <br> - Le istruzioni SOQL non sono selettive, tra cui:
                <br> -- vengono visualizzati i criteri di filtro per <code>Mi piace</code> e caratteri jolly
                <br> -- i confronti che utilizzano i criteri <code>NOT</code>, <code>NOT IN</code> vengono utilizzati come operatore principale o unico di confronto
                <br> -- <code>= NULL</code>, <code>!= NULL</code> vengono utilizzati come operatore principale o unico di confronto
                <br> -- Vengono visualizzate le istruzioni <code>LIMIT 1</code>
                <br> -- viene utilizzata la parola chiave <code>ALL ROWS</code>
        </tr>
        <tr>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
                <br> - I percorsi di esecuzione pianificati e potenziali per le automazioni sono delineati chiaramente
                <br> - I casi d'uso per le operazioni sincrone e asincrone all'interno delle automazioni sono delineati chiaramente come parte degli standard di progettazione
            </td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
                <br> - L'invocazione dell'automazione non è documentata
                <br> - I casi d'uso per le operazioni sincrone e asincrone non sono affrontati
            </td>
        </tr>
        <tr>
            <td rowspan="2"><b>KPIs</b></td>
            <td><b>Nella documentazione:</b>
            <br> - Gli output per ogni automazione sono misurabili e temporizzati
            <br> - Gli stakeholder responsabili sono elencati per ogni KPI</td>
            <td><b>Nella documentazione:</b>
            <br> - Non esistono KPI per le automazioni o hanno intervalli di tempo non chiari per le misurazioni
            <br> - Esistono KPI senza stakeholder responsabili</td>
        </tr>
        <tr>
            <td><b>All'interno di rapporti e cruscotti digitali:</b>
            <br> - Tutte le metriche correlate ai KPI sono incluse in almeno un rapporto o cruscotto digitale</td>
            <td><b>All'interno di rapporti e cruscotti digitali:</b>
            <br> - I rapporti KPI non esistono o mancano metriche correlate ad alcuni KPI</td>
        </tr>
    </tbody>
</table>

## Integrità dei dati

L'integrità dei dati riguarda la qualità con cui un sistema mantiene dati precisi e completi. Salesforce Platform mantiene una [logica di elaborazione](/docs/architect/it-it/fundamentals/guide/architecture-basics#manipolazione-del-database) solida progettata per proteggere l'integrità dei dati memorizzati nel database relazionale di una singola organizzazione. Uno dei fondamenti della creazione di automazioni sane è comprendere i comportamenti di integrità dei dati incorporati in Salesforce e assicurarsi che tutti i progetti di automazione siano in linea con (e riconoscano) questi comportamenti.

I più grandi modelli anti-pattern nella progettazione dell'automazione derivano dal mancato riconoscimento dei potenti [servizi di integrità](/docs/architect/it-it/fundamentals/guide/architecture-basics#manipolazione-del-database) e dal mancato utilizzo delle [funzionalità standard](/docs/architect/it-it/well-architected/guide/intentional#funzionalità-standard-e-personalizzata) che sfruttano questi servizi. Per progettare automazioni che proteggano e mantengano l'integrità dei dati è necessario conoscere l'ordine fondamentale dei comportamenti operativi di Salesforce.

Estendendo correttamente l'integrità dei dati nelle automazioni personalizzate, il sistema può:

- operare su volumi di dati in blocco e ingenti senza intervento manuale,
- applicare le policy di sicurezza degli utenti quando necessario e passare al contesto di sistema quando necessario,
- riscontrare errori in fase di esecuzione e seguire percorsi di ripristino o errore prevedibili.

È possibile migliorare l'integrità dei dati nelle automazioni Salesforce attraverso una gestione corretta dei dati e degli errori.

### Gestione dei dati

Il primo passo per progettare una gestione corretta dei dati in Salesforce è capire come la piattaforma multitenant gestisce le [transazioni](/docs/architect/it-it/fundamentals/guide/architecture-basics#transazioni). Ciò include la comprensione del comportamento [di esecuzione](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) incorporato utilizzato da Salesforce Platform per garantire l'integrità dei dati durante le operazioni sui dati a livello di record. Per ulteriori informazioni sugli impatti di questo comportamento, vedere [Manipolazione del database](/docs/architect/it-it/fundamentals/guide/architecture-basics#manipolazione-del-database) in Nozioni di base sull'architettura Salesforce.

Una cattiva gestione dei dati nelle automazioni può essere uno degli anti-schemi più difficili da identificare e risolvere completamente. La natura ricorsiva e sovrapposta dell'ordine di esecuzione della piattaforma può rendere difficile individuare l'origine dei problemi. La sezione specifica di codice o di flusso che genera un errore fatale o supera i limiti del governor potrebbe non essere la causa principale di un problema di gestione dei dati sottostante.

La _conoscenza delle transazioni_ è fondamentale per creare automazioni che funzionino in modo affidabile e su larga scala con Salesforce. Ciò significa assicurarsi che ogni fase di un'automazione sia progettata con la Knowledge di dove si trova in relazione all'[ordine di esecuzione](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) controllato dalla piattaforma, possa svolgere correttamente la sua funzione e trasmetta correttamente le informazioni alla fase successiva.

Indipendentemente dallo strumento di automazione in uso, una corretta consapevolezza delle transazioni segue schemi simili e richiede considerazioni comuni:

- Si supponga che a ogni automazione venga chiesto di eseguire volumi di dati elevati senza preavviso, in qualsiasi momento. Le automazioni devono avere percorsi che consentano l'esecuzione in batch o in blocco (vedere [Scalabilità](/docs/architect/it-it/well-architected/guide/reliable#scalabilità)).
- Non mescolare le operazioni sui dati di sistema e contesto utente nella stessa transazione.
- Prenotare le operazioni sui dati di sincronizzazione per i [_contesti prima_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm) e utilizzare le operazioni asincrone per tutte le azioni _dopo_ il contesto.
- Utilizzare [messaggistica e notifiche](/docs/architect/it-it/well-architected/guide/engaging#notifiche-e-messaggi) per evitare di creare esperienze in app che richiederebbero all'utente di attendere i dati in base ai risultati di un'operazione asincrona.

Oltre alla consapevolezza delle transazioni, esiste una seconda dimensione nella gestione dei dati: sapere quando eseguire la logica in diversi [contesti di esecuzione](/docs/architect/it-it/fundamentals/guide/architecture-basics#contesto-di-esecuzione). I motivi più comuni per suddividere le automazioni in contesti di esecuzione diversi sono:

- **Operazioni su grandi volumi e/o dati complessi**
  - Le [operazioni di blocco](/docs/architect/it-it/well-architected/guide/automated#gestione-dei-dati) non garantiscono che un'automazione gestisca correttamente grandi volumi di dati. Se il volume di operazioni sui dati all'interno di un'automazione supera i limiti per transazione, sarà necessario eseguire operazioni sui dati utilizzando funzionalità specifiche per volumi di dati elevati (ad esempio tramite batch Apex o l'[API Bulk 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm)). Questi hanno limiti di transazione distinti, adatti a volumi di dati elevati.
  - Le operazioni sui dati che devono attraversare gerarchie di relazioni complesse o eseguire ricalcoli complessi (esclusi i campi formula) tra i record possono facilmente superare i limiti per transazione se eseguite in blocco. Considerare quanto sia "rumoroso" un aggiornamento a un record, in termini di operazioni sui dati correlate o SOQL necessarie per completare le azioni successive nel sistema.
  - I tipi di sObject coinvolti nell'intera catena di un'automazione possono richiedere di suddividere le operazioni sui dati in transazioni separate per evitare errori "[DML misti](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm)".
- **Logica che deve essere eseguita nel contesto dell'utente o del sistema**
  - Salesforce Platform impone [condivisione e visibilità](/docs/architect/it-it/well-architected/guide/secure#condivisione-e-visibilità) nel contesto dell'utente. Se è necessario eseguire operazioni che si estendono oltre i livelli di autorizzazione degli utenti dell'automazione, è necessario assicurarsi che tali operazioni vengano eseguite nel contesto di sistema.
  - Strumenti diversi verranno eseguiti o meno in contesti diversi:
    - Apex verrà eseguito nel contesto di sistema per impostazione predefinita. È possibile controllare se e come i comportamenti Apex applicano le regole di condivisione a livello di utente utilizzando le [parole chiave di](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user) condivisione in una definizione di classe Apex.
    - Il flusso non ha un singolo comportamento predefinito. Un flusso verrà eseguito nel contesto dell'utente o del sistema in [base al modo](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5) in cui viene avviato. È possibile imporre la condivisione nel contesto di sistema.
    - I processi (ovvero le automazioni create con Process Builder) vengono eseguiti nel contesto di sistema senza condividere considerazioni. (Nota: Si consiglia di creare automazioni low-code con Flusso.
- **Logica che deve essere eseguita in modo asincrono**
  - Operazioni di sistema esterno: le chiamate sincrone o le azioni che accedono a dati esterni non sono incluse in alcun comportamento di ritiro della piattaforma. Per sfruttare questi comportamenti, è necessario inserire le azioni che coinvolgono sistemi esterni in transazioni separate (utilizzando metodi [Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm) asincroni, [percorsi asincroni](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234) o [azioni invocabili](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm)).
  - Evento e messaggistica - Per controllare il flusso di eventi o messaggi correlati alle operazioni sui dati (e sfruttare i comportamenti di ritiro della piattaforma), collocare tutte le azioni correlate alla messaggistica o agli eventi in [_contesti_ successivi](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm), utilizzando metodi Apex asincroni.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/automated#schemi-di-integrità-dei-dati-e-schemi-anti-pattern) riportato di seguito mostra l'aspetto di una corretta (e scarsa) gestione dei dati nelle automazioni Salesforce. È possibile utilizzarli per convalidare i progetti di automazione prima di crearli o identificare le automazioni che devono essere rifattorizzate per migliorare la gestione dei dati.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce per la gestione dei dati nell'automazione, vedere [Strumenti pertinenti all'automazione](/docs/architect/it-it/well-architected/guide/automated#strumenti-rilevanti-per-lautomazione).

### Gestione degli errori

La gestione degli errori è fondamentale per l'integrità dei dati. Una gestione avanzata degli errori aiuta anche il sistema a scalare e invecchiare con maggiore [resilienza](/docs/architect/it-it/well-architected/guide/resilient).

Una gestione errata degli errori nelle automazioni può causare:

- Incoerenze dei record e altri problemi di integrità dei dati
- Invio di notifiche imprecise agli utenti e ad altri sistemi
- Spreco di tempo e risorse per l'elaborazione manuale o ripetuta
- Mancanza complessiva di [Trust](/docs/architect/it-it/well-architected/guide/trusted-overview) in un sistema

La gestione degli errori nelle automazioni richiede di fornire a qualsiasi processo in esecuzione la possibilità di analizzare un errore alla ricerca di informazioni, la logica di accesso su quali dovrebbero essere le fasi successive in base alle informazioni sugli errori e quindi seguire il percorso corretto. Queste funzionalità non devono essere create più e più volte in ogni automazione (è un [anti-schema di ottimizzazione](/docs/architect/it-it/well-architected/guide/automated#progettazione-dei-processi)). Ogni automazione del sistema dovrebbe invece avere la possibilità di collegarsi ai [componenti](/docs/architect/it-it/well-architected/guide/composable#accoppiamento-allentato) di gestione degli errori pertinenti.

Per inserire controlli corretti per la gestione degli errori nelle automazioni, porre le seguenti domande:

- Che cos'è un errore "fatale"?
- Che cos'è un errore "ripristinabile"?
- Per le automazioni attivate da azioni dell'utente, come può l'automazione rilevare e informare l'utente degli errori prima di tentare di confermare le modifiche?

Dopo aver deciso come gestire questi errori, è possibile iniziare a creare una gestione efficace degli errori nelle automazioni. L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/automated#schemi-di-integrità-dei-dati-e-schemi-anti-pattern) riportato di seguito mostra l'aspetto di una corretta (e scarsa) gestione degli errori in un'automazione Salesforce. È possibile utilizzarli per convalidare i progetti di automazione prima della creazione o identificare le automazioni che devono essere rifattorizzate per migliorare la gestione degli errori.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce per la gestione degli errori, vedere [Strumenti pertinenti all'automazione](/docs/architect/it-it/well-architected/guide/automated#strumenti-rilevanti-per-lautomazione).

### Schemi di integrità dei dati e schemi anti-pattern

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per l'integrità dei dati in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/easy-data-integrity).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="4"><b>Gestione dei dati</b></td>
            <td><b>Nel dizionario dei dati:</b>
            <br> - Esistono dati a livello di campo e logica di assegnazione delle priorità per tutte le fonti di dati e gli oggetti data lake
            <br> - La mappatura dei campi dall'oggetto data lake all'oggetto modello di dati esiste</td>
            <td><b>Nel dizionario dei dati:</b>
            <br> - I dati a livello di campo e la logica di assegnazione delle priorità per le fonti di dati e gli oggetti data lake non sono inclusi
            <br> - La mappatura dei campi dagli oggetti data lake agli oggetti modello di dati non è inclusa</td>
        </tr>
        <tr>
            <td><b>In Apex:</b>
            <br> - Tutte le istruzioni DML sincrone o i metodi delle classi Database vengono eseguiti in contesti di esecuzione <i>precedenti</i> all'attivazione
            <br> - Le invocazioni Apex asincrone utilizzano aree di attesa per 'concatenare' DML complessi tra le transazioni
            <br> - Batch Apex viene utilizzato esclusivamente per grandi volumi di dati
            <br> - <code>@future</code> Apex non viene usato o usato con parsimonia, per chiamate o DML oggetto di sistema</td>
            <td><b>In Apex:</b>
            <br> - Le istruzioni DML vengono visualizzate regolarmente nel codice che verrà richiamato nei contesti <i>after</i> trigger
            <br> - Apex asincrono è usato raramente
            <br> - Le funzioni Apex asincrone vengono utilizzate in modo arbitrario, tra cui:
            <br> -- Metodi futuri e Apex in area di attesa vengono utilizzati in modo incoerente o intercambiabile
            <br> -- Le operazioni di database non hanno una logica chiara e coerente per passare l'esecuzione ad Apex batch quando necessario</td>
        </tr>
        <tr>
            <td><b>Nel flusso:</b>
            <br> - Tutti i flussi avviati nel contesto utente astraggono tutte le transazioni del contesto di sistema ai sottoflussi, che vengono posizionati in modo coerente dopo un elemento Pausa, <a href="https://help.salesforce.com/s/articleView?id=flow_concepts_transaction.htm&type=5&language=en_US">per creare una nuova transazione</a>
            <br> - Sequenze complesse di operazioni sui dati correlate vengono create con Orchestrator (invece di invocare più sottoflussi all'interno di un flusso monolitico)
            <br> - Tutti i flussi attivati da record hanno <a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_trigger_order.htm&type=5&release=236">valori ordine trigger compilati</a>
            <br> - I flussi che coinvolgono chiamate di sistema esterne o processi di lunga durata utilizzano percorsi asincroni</td>
            <td><b>Nel flusso:</b>
            <br> - Grandi flussi monolitici tentano di coordinare sequenze complesse di operazioni sui dati correlate (con o senza sottoflussi)
            <br> - I flussi attivati da record non utilizzano affatto gli attributi dell'ordine di attivazione o non utilizzano i valori dell'ordine di attivazione in modo coerente
            <br> - I percorsi asincroni non vengono utilizzati in modo coerente o per nulla</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le regole di riconciliazione per la risoluzione dell'identità seguono la logica di assegnazione delle priorità nel dizionario dei dati</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le regole di riconciliazione per la risoluzione dell'identità non seguono la logica di assegnazione delle priorità nel dizionario dei dati</td>
        <tr/>
        <tr>
            <td rowspan="4"><b>Gestione errori</b></td>
            <td><b>In Apex:</b>
            <br> - Il codice racchiude tutti i DML, SOQL, callout e altre fasi critiche del processo in blocchi <code>di prova</code>
            <br> - Le eccezioni personalizzate vengono utilizzate per creare messaggi di errore avanzati e logica<br> - In contesti asincroni e in blocco, vengono utilizzati <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_dml_database.htm">metodi di classe</a> Database anziché DML
            <br> - I metodi delle classi database possono essere utilizzati esclusivamente per tutte le operazioni sui dati (anziché DML)</td>
            <td><b>In Apex:</b>
            <br> - DML, SOQL, callout o altre fasi critiche del processo non sono racchiuse in blocchi <code>di prova</code>
            <br> - Le istruzioni <code>System.debug</code> vengono visualizzate nel codice di produzione (e non vengono commentate)
            <br> - Non vengono utilizzati metodi di classe Database
            <br> - Le operazioni sui dati vengono eseguite esclusivamente con DML</td>
        </tr>
        <tr>
            <td><b>Nei componenti Web Lightning (LWC):</b>
            <br> - JavaScript racchiude tutte le operazioni sui dati e le fasi critiche del processo nei blocchi <code>if ()</code>/<code>else if ()</code>
            <br> - Tutte le funzioni <code>@wire</code> utilizzano <code>dati</code> e proprietà <code>di errore</code> fornite dall'API
            <br> - Tutte le istruzioni <code>if (error)</code>/<code>else if (error)</code> contengono logica per elaborare gli errori e fornire messaggi informativi</td>
            <td><b>In LWC:</b>
            <br> - JavaScript non viene utilizzato in modo coerente <code>se ()</code>/<code>altro se ()</code> blocca operazioni sui dati o fasi critiche del processo
            <br> - Le funzioni <code>@wire</code> non utilizzano i <code>dati</code> e le proprietà <code>di errore</code> fornite dall'API (o non li utilizzano in modo coerente)
            <br> - Se utilizzato, <code>se (errore)</code>/<code>altro se (errore)</code> le istruzioni non contengono effettivamente logica per elaborare gli errori e fornire messaggi di errore utili</td>
        </tr>
        <tr>
            <td><b>In Aura:</b>
            <br> - JavaScript racchiude tutte le operazioni sui dati e le fasi cruciali del processo in blocchi <code>try-catch</code>
            <br> - All'interno dei blocchi <code>try-catch</code>, <code>Errore</code> JavaScript nativo viene utilizzato nelle istruzioni throw (nessun utilizzo di <code>$A.error()</code>)
            <br> - Tutta la logica di errore recuperabile viene visualizzata all'interno delle istruzioni di <code>cattura</code> e fornisce messaggi utente chiari</td>
            <td><b>In Aura:</b>
            <br> - JavaScript non racchiude in modo coerente le operazioni sui dati e le fasi critiche del processo nei blocchi <code>try-catch</code>
            <br> - I componenti utilizzano <code>$A.error()</code>
            <br> - La logica di errore recuperabile non viene visualizzata in modo coerente all'interno delle istruzioni di <code>cattura</code> e i messaggi di errore agli utenti non sono chiari</td>
        </tr>
        <tr>
            <td><b>Nel flusso:</b>
            <br> - I flussi schermata utilizzano costantemente connettori di errore per mostrare gli errori agli utenti
            <br> - I messaggi di errore personalizzati sono configurati per gli errori che verranno visualizzati sullo schermo
            <br> - I flussi con operazioni sui dati, chiamate e altre logiche di elaborazione critiche hanno percorsi di errore per tutte le azioni chiave</td>
            <td><b>Nel flusso:</b>
            <br> - I flussi non utilizzano i percorsi di errore in modo coerente o per nulla
            <br> - I messaggi di errore personalizzati non vengono utilizzati, quindi gli utenti visualizzano il messaggio predefinito "Si è verificato un errore non gestito in questo flusso"</td>
        </tr>
    </tbody>
</table>

## Valore aziendale

Il concetto di valore aziendale, nel contesto dell'automazione, riguarda la qualità dei processi che creano un impatto positivo misurabile per gli stakeholder aziendali. Idealmente, l'automazione dei processi consente agli utenti di dedicare meno tempo a operazioni ripetitive e di basso valore. Aiuta anche a migliorare l'integrità dei dati eliminando le attività di elaborazione manuali che potrebbero introdurre errori. Proprio come [Process Design](/docs/architect/it-it/well-architected/guide/automated#progettazione-dei-processi), l'identificazione e la fornitura di automazioni in grado di generare valore aziendale reale richiedono un lavoro che va oltre le scoperte di base e l'analisi aziendale.

A volte può sembrare che il modo migliore per offrire valore all'azienda sia automatizzare semplicemente ogni processo richiesto da un utente aziendale, nell'ordine in cui appare nel backlog (o nell'area di attesa di biglietteria) o in base a fattori politici dell'organizzazione. Questo può portare a due problemi correlati: costruire automazioni in un ordine non ottimale e costruire completamente automazioni sbagliate. Il primo problema, la scarsa definizione delle priorità, impedisce che i processi di alto valore vengano implementati come dovrebbero, rallentando potenzialmente la crescita. Il secondo problema, la creazione di automazioni errate, non solo ritarda la consegna di automazioni di valore elevato, ma porta anche a tempo perso, costi inutili e maggiore frustrazione tra i team di consegna.

È possibile offrire un valore aziendale maggiore concentrandosi sugli indicatori di prestazione chiave e sulla definizione delle priorità.

## Strumenti rilevanti per l'automazione

<table class="tools-table"><tbody><tr><th>Strumento</th><th>Descrizione</th><th>Efficienza</th><th>Integrità dei dati</th><th>Valore aziendale</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_batch.htm">Batch Apex</a></td><td>Raggruppare i record in batch ed elaborarli in blocchi gestibili</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_invoking_future_methods.htm">Metodi futuri Apex</a></td><td>Eseguire metodi Apex in background in modo asincrono</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm">Apex Area di attesa</a></td><td>Aggiungere processi Apex a un'area di attesa e monitorarli</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_scheduler.htm">Apex Scheduler</a></td><td>Eseguire classi Apex in modo asincrono a orari specifici</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=what_are_approvals.htm&type=5&language=en_US">Approvazioni</a></td><td>Specificare i passaggi necessari per approvare i record</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm">Apex asincrono</a></td><td>Eseguire Apex Code in modo asincrono</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customize_automatedactions.htm&type=5&language=en_US">Azioni automatiche</a></td><td>Eseguire aggiornamenti di campo, invii di email e altre azioni in background</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=einstein_next_best_action.htm&type=5&language=en_US">Einstein Next Best Action</a></td><td>Mostrare i consigli giusti alle persone giuste al momento giusto</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customize_wfalerts.htm&type=5&language=en_US">Avviso tramite email</a></td><td>Creare e inviare email automatiche</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.rules_escalation_actions.htm&type=5">Azioni di inoltro</a> al livello superiore</td><td>Specificare le azioni automatiche da eseguire per l'inoltro dei casi al livello superiore</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=workflow_managing_field_updates.htm&type=5&language=en_US">Aggiornamento di campo</a></td><td>Aggiornare i valori dei campi in base all'automazione</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_flow_fbuilder.htm&type=5&release=230">Flow Builder</a></td><td>Creare automazioni con un'interfaccia "point-and-click"</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_flow_extend.htm&type=5&language=en_US&release=230">Estensioni flusso</a></td><td>Accedere alle variabili memorizzate come input di componenti nei flussi</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/products/platform/workflow-automation/workflow-library/flow-index/?#service">Libreria di modelli di flusso</a></td><td>Utilizzare i modelli per progettare flussi specifici del settore</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=creating_workflow_flow_actions.htm&type=5&language=en_US">Trigger di flusso</a></td><td>Automatizzare processi aziendali complessi</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_actions_invocable.htm">Azioni invocabili</a></td><td>Aggiunta di funzionalità Apex ai flussi</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=orchestrator_flow_orchestrator.htm&type=5&language=en_US">Orchestratore</a></td><td>Creare e gestire automazioni a più fasi</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=workflow_managing_outbound_messages.htm&type=5&language=en_US">Messaggio in uscita</a></td><td>Inviare informazioni da un processo automatico con conferme e tentativi </td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_publish_flow.htm">Pubblicazione di eventi piattaforma con il flusso</a></td><td>Pubblicazione di eventi tramite interazioni utente e automazioni</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_salesforce_query_optimizer.htm">Query Optimizer</a></td><td>Utilizzare la selettività e gli indici per migliorare le prestazioni di query, rapporti e visualizzazioni elenco</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_lightning_flow.htm&type=5">Flusso Salesforce</a></td><td>Creazione di automazioni dichiarative dei processi con Flow Builder</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=livemessage_automatic_notifications_flows.htm&type=5&language=en_US">Invio di notifiche con i flussi</a></td><td>Inviare messaggi tramite SMS, WhatsApp o Facebook Messenger</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=livemessage_automatic_message_notifications_process.htm&type=5&language=en_US">Invio di notifiche con i processi</a></td><td>Inviare messaggi tramite SMS, WhatsApp o Facebook Messenger</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for+update">Modificatore SOQL FOR UPDATE</a></td><td>Bloccare i record per evitare condizioni di gara e problemi di sicurezza del thread</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=nba_strategy_builder.htm&type=5&language=en_US">Strategie Builder</a></td><td>Identificare i consigli da visualizzare nelle pagine dei record</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_about_subflows.htm">Sottoflussi</a></td><td>Ridurre la complessità dei flussi tramite il riutilizzo</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_subscribe_flow.htm">Abbonamento agli eventi piattaforma con il flusso</a></td><td>Ricevi messaggi pubblicati tramite automazioni</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customize_wftasks.htm&type=5&language=en_US">Azioni operazione</a></td><td>Determinare i dettagli dell'assegnazione dati a un utente da un'automazione</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
</table>

## Risorse rilevanti per l'automazione

<table class="tools-table"><tbody><tr><th>Risorsa</th><th>Descrizione</th><th>Efficienza</th><th>Integrità dei dati</th><th>Valore aziendale</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">Governatori e limiti dell'esecuzione Apex</a></td><td>Informazioni su come il motore di runtime Apex impone i limiti</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_rebates_additional_resources_for_batch_management.htm&type=5">Risorse di gestione dei batch</a></td><td>Creare, gestire, pianificare e monitorare i processi batch</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_best_practices_soql_and_sosl.htm">Procedure consigliate per SOQL e SOSL</a></td><td>Migliorare le prestazioni delle query delle applicazioni con volumi di dati elevati</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/design-standards-template">Modello Design Standards (Standard di progettazione)</a></td><td>Creare standard di progettazione per l'organizzazione</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_concepts_bulkification.htm&type=5">Bulkification dei flussi nelle transazioni</a></td><td>Flussi di progettazione da utilizzare per le raccolte</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_considerations_trigger_schedule.htm&type=5">Considerazioni sui dati dei flussi</a></td><td>Informazioni sui flussi attivati da pianificazione per i dati batch</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_flow_debug.htm&type=5&release=230">Debug del flusso</a></td><td>Testare e risolvere i problemi dei flussi</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/how_requests_are_processed.htm">Come vengono elaborate le richieste</a></td><td>Informazioni su come Salesforce elabora rapidamente i processi e riduce al minimo gli errori</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/kpi-spreadsheet-template">Modello di foglio di calcolo KPI</a></td><td>Determinare il valore aziendale di una determinata metrica</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm">Effettuazione di chiamate a sistemi esterni da azioni invocabili</a></td><td>Chiamata di sistemi esterni da un flusso utilizzando Apex</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm">Operazioni DML miste</a></td><td>Sapere quali sObject possono essere utilizzati insieme per DML nella stessa transazione</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm">Ordine di esecuzione</a></td><td>Informazioni sull'ordine degli eventi per inserimenti, aggiornamenti e inserimenti con aggiornamento</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=000334796&type=1">Domande frequenti sul piano di query</a></td><td>Ottimizzare le query che coinvolgono grandi volumi di dati</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_considerations_trigger_schedule.htm&type=5">Considerazioni sui flussi attivati da pianificazione</a></td><td>Comprendere i comportamenti speciali dei flussi attivati da pianificazione</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_transaction_control.htm">Controllo delle transazioni</a></td><td>Genera un punto di salvataggio che specifica lo stato corrente del database</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_build_logic_fault.htm&type=5">Cosa accade quando un flusso non riesce?</a></td><td>Informazioni sulla gestione degli errori nei flussi</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=000355199&type=1">Guida alle procedure consigliate per l'automazione dei flussi di lavoro</a></td><td>Suggerimenti introduttivi sull'automazione di Salesforce</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SOQL_VLSQ.htm">Utilizzo di query SOQL molto grandi</a></td><td>Scrittura di query SOQL più efficienti</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.

<!-- document id=62615689783fa94f1cb6de2e5bf0c987d765bcfcd52f2765b79e669979aa3232 url=/architect/next/it-it/well-architected/guides/engaging.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

I sistemi dimostrano comportamenti coinvolgenti facilitando l'accesso e l'utilizzo delle app da parte delle persone, facendo sentire agli utenti di svolgere un lavoro di qualità superiore e facendo sì che le persone desiderino utilizzare le app nel sistema.

Offrire un comportamento coinvolgente è importante per l'azienda perché è direttamente correlato all'adozione da parte degli utenti e alla soddisfazione complessiva dei lavoratori e dei clienti. Comportamenti coinvolgenti aiutano anche a ridurre le richieste di assistenza e possono migliorare la qualità delle richieste di funzioni da parte degli utenti.

Una delle sfide della creazione di un comportamento coinvolgente è che è difficile misurare solo in base a metriche oggettive. È invece misurato dalle esperienze soggettive degli utenti; gli utenti ritengono che le app coinvolgenti forniscano un valore reale. Le app coinvolgenti sono [accessibili](/docs/architect/it-it/well-architected/guide/compliant#accessibilità), non intrusive e facili da capire. Richiedono una quantità minima di orientamento e formazione. Inoltre, utilizzano metodi chiari per prevenire in modo proattivo gli errori degli utenti.

Un'altra sfida è che gli obiettivi di coinvolgimento spesso variano a seconda dei diversi tipi di interazioni utente nel sistema. Ad esempio, si può avere un insieme di obiettivi per gli utenti interni che gestiscono i casi e un altro per gli utenti esterni che inviano informazioni tramite un modulo sul sito Web. Per progettare sistemi di coinvolgimento, è necessario considerare attentamente il tipo di coinvolgimento che si sta tentando di creare e il motivo per cui gli utenti vorrebbero partecipare prima di iniziare a assemblare funzioni e pagine.

Collaborare con gli utenti Designer di esperienze utente (UX) ti aiuterà a prendere decisioni molto più efficaci quando si tratta di fornire app coinvolgenti. Da un punto di vista architettonico, l'adozione e la conservazione degli utenti sono componenti cruciali di un sistema sano. Architetture coinvolgenti riducono la probabilità di Problemi di qualità dei dati causati da utenti che affrettano i processi o saltano i passaggi per evitare di dover trascorrere del tempo in un sistema che non amano utilizzare. Per i sistemi rivolti all'esterno, un'architettura coinvolgente può aumentare il reddito e la fidelizzazione dei clienti, poiché i clienti che trovano più facile lavorare con i sistemi scelgono di fare più affari con l'organizzazione.

È possibile creare app più coinvolgenti concentrandosi sulla fornitura di esperienze semplificate e utili.

## Semplificato

Le app semplificate sono facili da navigare, presentano informazioni e operazioni di immissione dati in modo chiaro e si adattano a vari fattori di forma. Le app semplificate presentano anche schemi di esperienza a cui gli utenti si sono abituati in altre applicazioni di uso comune. Ad esempio, la maggior parte dei browser Web presenta "apri in una nuova scheda" come opzione superiore quando gli utenti fanno clic con il pulsante destro del mouse su un link. Un'app semplificata contenente schede seguirà lo stesso schema.

L'impatto delle esperienze inefficienti delle app può estendersi ben oltre una singola app. Le esperienze scadenti delle app erodono il Trust degli utenti. Man mano che sempre più tipi di app business critical e indirizzate ai clienti passano ai canali digitali, questo può costare alle aziende la fedeltà dei principali stakeholder.

È possibile semplificare meglio le app adottando un approccio intenzionale alla complessità delle app, alla progettazione dei moduli e ai fattori di forma.

### Complessità dell'applicazione

Ridurre al minimo la complessità delle applicazioni significa che gli utenti visualizzano solo le voci di menu, le schede e i controlli di navigazione pertinenti. Sarà necessario creare mappature tra gruppi di utenti, autorizzazioni utente e l'esperienza dell'app corretta. Utilizzare queste mappature per capire quale esperienza dell'app presentare a un determinato utente e quindi assicurarsi che l'app disponga dei controlli logici necessari per offrire quell'esperienza.

Le app che presentano agli utenti troppa complessità possono causare una serie di esperienze negative:

- Gli utenti visualizzano spesso schede inutili o non pertinenti, passano a schermate vuote e incontrano link disabilitati o bloccati.
- Istruzioni inutili o inutili come "ignora questa scheda se il tuo ruolo è X..." vengono visualizzate nei materiali di formazione e abilitazione.
- I menu di navigazione confusi costringono gli utenti a dedicare più tempo a individuare gli elementi necessari per completare il lavoro.

Queste scarse esperienze portano a bassi tassi di adozione e livelli di soddisfazione.

Durante la determinazione del giusto livello di complessità dell'app, tenere presente quanto segue:

- Organizzare menu, schede e altri controlli di navigazione in base alla priorità del lavoro che gli utenti devono svolgere.
- Evitare di introdurre nuovi comportamenti che un utente deve imparare solo per poter utilizzare l'app.
- Non rimuovere l'accesso alle funzioni che consentono agli utenti di personalizzare aspetti dell'interfaccia utente.
- Utilizzare gli insiemi di autorizzazioni per offrire opzioni di navigazione estese o ridotte.
- Semplificare le [assegnazioni delle attivazioni](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm) delle pagine Lightning. Ridurre al minimo il numero di pagine Lightning attive per app. Utilizzare moduli dinamici, insiemi di autorizzazioni e rendering condizionale per aggiungere elementi alle pagine Lightning nell'app. Eseguire questa operazione anziché gestire più pagine Lightning, attivate e assegnate dal profilo.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/engaging#schemi-e-anti-schemi-semplificati-dellapp) riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione della complessità delle app in un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare i progetti delle applicazioni.

Per ulteriori informazioni sugli strumenti Salesforce che possono aiutare a gestire la complessità delle applicazioni, vedere [Strumenti pertinenti per](/docs/architect/it-it/well-architected/guide/engaging#strumenti-rilevanti-per-il-coinvolgimento) il coinvolgimento.

### Moduli

I moduli semplificati organizzano le informazioni in sequenze logiche, supportano l'immissione rapida dei dati e riducono al minimo i passaggi necessari. Consentono inoltre di inviare messaggi di convalida dei dati lato client [utili](/docs/architect/it-it/well-architected/guide/engaging#utile) ed eliminano i cicli di invio di moduli ripetuti.

Durante la progettazione dei moduli, tenere presente quanto segue:

- **Raggruppare i campi** correlati. Raggruppare i campi correlati alla stessa fase di un processo o di un'operazione di immissione dati. Eliminare i campi che non sono direttamente pertinenti all'operazione da eseguire.
- **Inserimento e convalida** dei dati. I campi che richiedono l'inserimento di dati da parte degli utenti devono essere visualizzati in anticipo nei moduli. È consigliabile segnalare problemi di formattazione dei dati o dati mancanti a livello di campo e il più rapidamente possibile (ovvero prima che un utente tenti di passare alla fase successiva o di inviare il modulo). Inoltre, evitare di visualizzare errori a livello di campo prima che gli utenti abbiano avuto la possibilità di inserire dati nei campi.
- **Ridurre al minimo** le operazioni di input. Precompilare o autocompilare il maggior numero possibile di campi, per ridurre al minimo gli errori di immissione dei dati e migliorare l'efficienza. Chiedere agli utenti di inserire solo dati essenziali o critici. Eliminare tutti gli input di dati non pertinenti al processo aziendale in corso. Ove possibile, utilizzare gli elenchi di selezione anziché i campi di testo in formato libero per imporre la selezione di opzioni valide e ridurre le variazioni della stessa risposta.
- **Ridurre al minimo gli invii al server**. I moduli multifase non inviano i dati al server più volte. Assicurarsi che tutti i componenti [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) o [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) personalizzati utilizzino il caching lato client per gestire le azioni di navigazione o paginazione. (Salesforce Lightning Experience e l'app mobile Salesforce utilizzano il caching lato client per impostazione predefinita). Progettare i moduli in modo che gli utenti inviino i dati al server una sola volta. Convalidare gli input degli utenti sul lato client prima di inviare i moduli. Ciò ridurrà al minimo gli invii non intenzionali da parte degli utenti, impedirà che le transazioni duplicate o sporche consumino larghezza di banda nel back-end e aiuterà a progettare per una migliore [gestione dei dati](/docs/architect/it-it/well-architected/guide/automated#gestione-dei-dati).
- **Gestisci stato modulo**. Il caching lato client non solo aiuta con comportamenti come la navigazione e la paginazione, ma aiuta anche a ridurre al minimo la perdita di dati dovuta a problemi di connettività intermittenti. Gestire efficacemente lo stato significa anche che le app possono orchestrare adeguatamente l'invio dei dati al server e impedire transazioni duplicate, oltre a presentare messaggi pertinenti e tempestivi agli utenti in base allo stato delle azioni lato server. I moduli semplificati inviano le operazioni sui dati una sola volta e non richiedono agli utenti di attendere il completamento delle operazioni di lunga durata sul server.
- **Seguire gli standard**. Per aumentare al massimo il pubblico delle app e garantire che siano comprensive di tutti i clienti, applicare gli standard di [accessibilità](/docs/architect/it-it/well-architected/guide/compliant#accessibilità) nelle strutture dei moduli.

I moduli semplificati consentono di aumentare l'[integrità dei dati](/docs/architect/it-it/well-architected/guide/automated#integrità-dei-dati) nelle app e l'[utilità](/docs/architect/it-it/well-architected/guide/engaging#utile) delle app per gli utenti. Possono anche ridurre i ticket di assistenza e le richieste, poiché gli utenti sono più in grado di risolvere gli errori e comprendere chiaramente lo stato degli invii dei moduli. Inoltre, i moduli semplificati consentono un'immissione rapida ed efficiente dei dati e assicurano che gli utenti non debbano attendere il completamento dei processi più lunghi per eseguire ulteriori operazioni.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/engaging#schemi-e-anti-schemi-semplificati-dellapp) riportato di seguito mostra l'aspetto corretto (e scadente) della struttura della forma in un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare le strutture dei moduli.

Per ulteriori informazioni sugli strumenti di Salesforce che possono aiutare a creare moduli più semplici, vedere [Strumenti pertinenti al coinvolgimento](/docs/architect/it-it/well-architected/guide/engaging#strumenti-rilevanti-per-il-coinvolgimento). Per indicazioni più specifiche sulla scelta dello strumento di calcolo più adatto al proprio caso d'uso, consultare la Guida alle decisioni dell'[architetto per la creazione di moduli con Salesforce](/docs/architect/it-it/decision-guides/guide/build-forms#punti-salienti).

### Fattore di forma

Le app coinvolgenti si adattano perfettamente a dispositivi e tipi di interazioni o fattori di forma diversi. A seconda del tipo di dispositivo, diversi tipi di interazioni utente saranno più facili (o più difficili) e la leggibilità di moduli e campi cambierà. Tenere presente che oltre alle dimensioni dello schermo, il fattore di forma si riferisce anche al modo in cui gli utenti interagiscono con lo schermo. Un numero crescente di dispositivi ora dispone di touch screen e alcuni utenti possono anche utilizzare dispositivi speciali per l'[accessibilità](/docs/architect/it-it/well-architected/guide/compliant#accessibilità). Assicurarsi di tenere presenti questi fattori quando si progettano i moduli.

Se non si tiene conto delle variazioni dei fattori di forma, si possono verificare diversi problemi, tra cui:

- Scarsa qualità dei dati
- Interfacce app inutilizzabili
- Altre sessioni di risoluzione dei problemi o "ordine per conto" per gli agenti dell'assistenza
- Scarsa adozione da parte degli utenti, basso numero di utenti attivi e alti tassi di abbandono delle app

Per progettare l'interoperabilità tra i fattori di forma nelle app Salesforce, tenere presente quanto segue:

- **Identificare i fattori di forma supportati per ogni app**.
- **Identificare i metodi di input e le esigenze di accessibilità degli utenti**. Per ulteriori informazioni, vedere [Accessibilità](/docs/architect/it-it/well-architected/guide/compliant#accessibilità).
- **Utilizzare le [funzionalità standard](/docs/architect/it-it/well-architected/guide/intentional#funzionalità-standard-e-personalizzata) per offrire esperienze adattive su tutti i dispositivi, ove possibile**.
  - I [modelli Lightning Page](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5) forniti da Salesforce supportano diversi fattori di forma per impostazione predefinita. Se si sceglie di sviluppare modelli di pagina Lightning personalizzati con Aura, gli sviluppatori dovranno incorporare le informazioni sui fattori di forma nel file di progettazione del componente.
  - I [componenti pagina standard](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5) forniti da Salesforce gestiscono automaticamente il rendering nei fattori di forma supportati. Se si creano componenti personalizzati con LWC o Aura, gli sviluppatori dovranno gestire la consapevolezza della larghezza (ci sono differenze di implementazione tra [Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) e [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware)) e dichiarare il supporto del fattore di forma nel file di progettazione dei loro componenti.
- **Seguire le istruzioni per semplificare i [moduli su tutti](/docs/architect/it-it/well-architected/guide/engaging#moduli)** i dispositivi.
- **Creare piani di test (e test validi) per i fattori di forma chiave.** L'ideale sarebbe eseguire il test per tutti i dispositivi e i fattori di forma per tutte le app. Tuttavia, l'impostazione dei dispositivi (o simulatori di dispositivi) corretti per i test del fattore di forma può essere un investimento significativo. Se si sa che una determinata app o insieme di app avrà un insieme significativo di utenti su dispositivi mobili o tablet, assegnare la priorità a test accurati per tali app sui fattori di forma di dispositivi mobili e tablet.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/engaging#schemi-e-anti-schemi-semplificati-dellapp) riportato di seguito mostra l'aspetto appropriato (e scarso) della consapevolezza dei fattori di forma in un'organizzazione Salesforce. È possibile utilizzarli per convalidare i progetti prima di creare o identificare le pagine che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per una progettazione efficace dei fattori di forma, vedere [Tools Relevant to Engaging](/docs/architect/it-it/well-architected/guide/engaging#strumenti-rilevanti-per-il-coinvolgimento).

### Schemi e anti-schemi semplificati dell'app

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per le app semplificate in [Explorer schemi e](/docs/architect/it-it/well-architected-tools/guide/easy-streamlined) antischegge.

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="1"><b>Complessità dell'app</b></td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le app hanno meno di 10 schede nella configurazione predefinita fornita dall'amministratore
            <br> - Nessuna app ha "Disabilita personalizzazione utente finale delle voci di navigazione in questa app" impostato su true</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le applicazioni hanno regolarmente più di 10 schede nella configurazione predefinita fornita dall'amministratore
            <br> - Molte app hanno "Disabilita personalizzazione utente finale degli elementi di navigazione in questa app" impostato su true o l'autorizzazione a personalizzare gli elementi di navigazione è disabilitata a livello di organizzazione</td>
        </tr>
        <tr>
            <td rowspan="2"><b>Moduli</b></td>
            <td><b>Nelle app:</b>
            <br> - I campi seguono raggruppamenti logici<br> - I campi di input dati vengono visualizzati insieme, in gruppi di cinque o meno
            <br> - Gli errori di immissione dei dati sono chiari e vengono visualizzati a livello di campo, prima che gli utenti si allontanino o inviino dati
            <br> - I controlli di paginazione abilitano lo spostamento tra le fasi<br> - L'invio dei dati avviene una volta
            <br> - Le etichette per le azioni e la navigazione sono chiare
            <br> - Viene fornito un feedback tempestivo e visivo per confermare le azioni dell'utente come i clic sui pulsanti
            <br> - I pulsanti di navigazione (ad esempio, "vai", "avanti" e "indietro") sono posizionati in modo coerente in tutta l'interfaccia utente</td>
            <td><b>Nelle app:</b>
            <br> - I campi di input dei dati non sono raggruppati logicamente, richiedendo un'ampia quantità di passaggi di contesto da parte degli utenti che compilano i moduli
            <br> - Gli errori di immissione dei dati contengono informazioni criptiche che possono essere interpretate solo da qualcuno che comprende il funzionamento interno del sistema
            <br> - Gli errori di immissione dati vengono visualizzati solo quando si fa clic sul pulsante di invio di un modulo
            <br> - Le fasi e i raggruppamenti non sono chiaramente definiti, rendendo difficile la navigazione
            <br> - L'invio dei dati avviene più volte durante il processo di immissione dei dati
            <br> - Le etichette per le azioni e la navigazione confondono gli utenti che non hanno familiarità con le funzionalità di sistema sottostanti
            <br> - Il riconoscimento visivo delle azioni dell'utente non è fornito
            <br> - I pulsanti di navigazione vengono visualizzati in posizioni arbitrarie in tutta l'interfaccia utente</td>
        </tr>
        <tr>
            <td><b>Nella logica dei moduli:</b>
            <br> - I campi vengono precompilati o autocompilati il più possibile
            <br> - Gli utenti non sono tenuti ad attendere il completamento delle azioni lato server di lunga durata
            <br> - I componenti personalizzati utilizzano <code>cacheable=true</code> per le azioni basate su server che non includono operazioni sui dati
            <br> - Le operazioni sui dati vengono eseguite una sola volta
            <br> - In LWC gli adattatori <code>@wire</code> gestiscono tutte le azioni che non includono operazioni sui dati</td>
            <td><b>Nella logica dei moduli:</b>
            <br> - I campi che potrebbero essere precompilati o autocompilati richiedono l'immissione manuale
            <br> - Gli utenti devono smettere di lavorare durante il processo di invio per attendere il completamento delle azioni lato server
            <br> - Componenti personalizzati impostati <code>cacheable=false</code></td>
        </tr>
        <tr>
            <td rowspan="3"><b>Fattore di forma</b></td>
            <td><b>Nella propria organizzazione:</b>
            <br> - I modelli di pagina Lightning forniti da Salesforce vengono utilizzati per tutte o per la maggior parte delle pagine
            <br> - I modelli di pagina Lightning personalizzati utilizzano <code>design:supportedFormFactors</code> e <code>design:supportedFormFactor</code> nei file di progettazione dei componenti Aura
            <br> - I componenti LWC o Aura personalizzati disponibili nel Generatore di app dichiarano i fattori di forma supportati nei rispettivi file di progettazione e implementano schemi di stile sensibili alla larghezza</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Classic è ancora attivo
            <br> - I modelli di pagina Lightning personalizzati non utilizzano in modo uniforme <code>design:supportedFormFactors</code> e <code>design:supportedFormFactor</code> nei file di progettazione dei componenti Aura
            <br> - I componenti LWC o Aura personalizzati disponibili nel Generatore di app non dichiarano in modo coerente i fattori di forma supportati nei rispettivi file di progettazione
            <br> - Nei componenti LWC o Aura personalizzati, lo stile attento alla larghezza non è implementato dalle interfacce fornite da Salesforce
            <br> - Nei componenti LWC o Aura personalizzati, lo stile per i diversi fattori di forma è basato esclusivamente su valori <code>px</code> o <code>%</code> codificati in CSS</td>
        </tr>
        <tr>
            <td><b>Su desktop:</b>
            <br> - I campi di input dei dati e i controlli di navigazione si adattano allo schermo e possono essere interagiti come previsto
            <br> - Le pagine di record e app vengono visualizzate correttamente, in base alle regole di assegnazione delle attivazioni pagina</td>
            <td><b>Su desktop:</b>
            <br> - I campi di input dei dati e i controlli di navigazione non vengono visualizzati nella posizione prevista sullo schermo
            <br> - Le interazioni con i campi di input dei dati e i controlli di navigazione non corrispondono ai comportamenti obbligatori
            <br> La mancanza di regole di assegnazione di attivazione pagina indica che tutti gli utenti visualizzano le stesse pagine di record e app</td>
        </tr>
        <tr>
            <td><b>Su dispositivi mobili e tablet:</b>
            <br> - Gli input di dati e i controlli di navigazione vengono visualizzati correttamente
            <br> - Gli utenti possono inserire facilmente i dati
            <br> - Vengono visualizzati i menu di navigazione mobile, ottimizzati per fattori di forma più piccoli
            <br> - I layout compatti vengono visualizzati a livello di record</td>
            <td><b>Su dispositivi mobili e tablet:</b>
            <br> - Gli input di dati e i controlli di navigazione non vengono visualizzati in modo coerente o corretto
            <br> - Gli utenti non possono inserire facilmente i dati
            <br> - I menu di navigazione mobile non sono distinguibili dalla navigazione desktop
            <br> - I layout compatti non sono configurati a livello di record</td>
        </tr>
    </tbody>
</table>

## Utile

Applicazioni utili consentono agli utenti di sentirsi più responsabili ed efficaci, con meno distrazioni o interruzioni.

Applicazioni utili aiutano a mantenere l'[integrità dei dati](/docs/architect/it-it/well-architected/guide/automated#integrità-dei-dati) riducendo gli errori manuali e fornendo feedback agli utenti quando e dove ne hanno bisogno. Aiutano gli utenti a capire su quali azioni devono concentrarsi ora e in seguito e forniscono informazioni pertinenti per aiutare gli utenti a risolvere più rapidamente i propri problemi. Offrono un collegamento chiaro tra le azioni di un utente e l'impatto significativo o i risultati.

È possibile creare applicazioni più utili con tre abitudini chiave: notifiche e messaggi, guida in app e riconoscimento e premi.

### Notifiche e messaggi

Le notifiche e i messaggi aiutano gli utenti a rimanere informati.

Un sistema di notifica e messaggistica ben progettato può aumentare il coinvolgimento e la produttività fornendo agli utenti le informazioni necessarie per prendere decisioni critiche in modo tempestivo. Un sistema di notifica e messaggistica mal progettato, che presenta messaggi non pertinenti né tempestivi, avrà l'effetto opposto. Gli utenti interni disabiliteranno o ignoreranno rapidamente le notifiche, facendogli perdere messaggi legittimi che potrebbero influire sui processi aziendali essenziali. I clienti o altri utenti esterni che si stancano di ricevere notifiche senza senso possono decidere di interrompere completamente l'utilizzo dei sistemi.

Per decidere in che modo le app gestiranno l'invio di notifiche e messaggi agli utenti, tenere presente quanto segue:

- **In caso di errori, utilizzare notifiche e messaggi come ultima risorsa**. Progettare la [gestione degli errori](/docs/architect/it-it/well-architected/guide/automated#gestione-degli-errori) nel sistema con un'elaborazione back-end in grado di correggere alcuni tipi di errori senza intervento umano. Inviare agli utenti solo messaggi relativi a errori critici che impediranno loro di completare le operazioni. Analogamente, inviare agli utenti aziendali solo messaggi di errore quando è presente un'azione correttiva che possono (e devono) eseguire da soli. Ulteriori messaggi di errore o dettagli possono essere resi disponibili tramite rapporti e/o inviati al personale dell'assistenza tecnica utilizzando metodi asincroni per un ulteriore follow-up.
- **Scegliere i tipi di messaggio in base a pertinenza, urgenza e tempestività**. I diversi tipi di messaggi hanno diversi livelli di blocco o comportamento interruttivo. Gli avvisi sono un tipo di messaggio "bloccante", in quanto richiedono agli utenti di confermarli prima di poter continuare il loro lavoro. Come per i messaggi di errore, gli avvisi devono essere usati con parsimonia. Le notifiche toast [non bloccano](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast), possono avere comportamenti di persistenza diversi e supportare diversi tipi di casi d'uso dei messaggi. I messaggi meno invadenti sono le [notifiche in app](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5) o le email. Questi sono utilizzati al meglio per fornire informazioni che gli utenti possono gestire quando e come preferiscono.
- **Pensate a cosa deve accadere dopo**. Mentre alcune notifiche sono informative (ad esempio, i messaggi di esito positivo), altre possono richiedere agli utenti di eseguire qualche tipo di azione. Quando si progettano le notifiche, assicurarsi di considerare non solo la notifica in sé, ma anche tutte le informazioni aggiuntive di cui un utente potrebbe aver bisogno per intraprendere un'azione. Includere istruzioni chiare o link a dove gli utenti possono trovare informazioni aggiuntive o completare le fasi di follow-up in tutte le notifiche fruibili.
- **Concentrarsi sulla leggibilità**. Assicurarsi di comunicare chiaramente lo scopo di ogni notifica e i passaggi successivi che un utente deve eseguire in risposta. I messaggi devono essere comprensibili per gli utenti aziendali che non hanno familiarità con il funzionamento interno dei sistemi sottostanti. Quando si creano messaggi, attenersi agli [standard di accessibilità](/docs/architect/it-it/well-architected/guide/compliant#accessibilità) e assicurarsi che siano localizzati per supportare gli utenti nelle regioni in cui possono essere visualizzati.

Includere schemi per quando utilizzare le notifiche o diversi tipi di errori negli [standard di progettazione](/docs/architect/it-it/well-architected/guide/intentional#design-standards) per garantire che i generatori di app seguano procedure coerenti.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/engaging#schemi-e-anti-schemi-dellapp-utili) riportato di seguito mostra l'aspetto corretto (e scadente) delle notifiche e della messaggistica in un'organizzazione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare gli utilizzi che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per le notifiche e la messaggistica, vedere [Strumenti pertinenti per](/docs/architect/it-it/well-architected/guide/engaging#strumenti-rilevanti-per-il-coinvolgimento) il coinvolgimento.

### Guida in app

La guida in app può essere un modo efficace per demistificare flussi di lavoro complessi (anche se è necessario assicurarsi di averli prima [ottimizzati](/docs/architect/it-it/well-architected/guide/automated#progettazione-dei-processi)) o aiutare a inserire nuovo personale. Può essere un ottimo sistema per introdurre modifiche ai processi, evidenziare nuove funzionalità o distribuire la formazione in modo automatico e scalabile. Se non viene implementata con attenzione, tuttavia, la guida in app può essere utilizzata in modo eccessivo. Popup o avvisi frequenti possono creare una quantità enorme di rumore e interruzioni per gli utenti, causando una perdita di produttività. Anche la guida in app può essere sottoutilizzata, con conseguenti processi di rilascio e gestione del cambiamento più complessi (soprattutto per le funzioni semplici). Infine, sia l'abuso che il sottoutilizzo della guida in app portano a una serie di problemi che pongono rischi per l'azienda, tra cui:

- Minore integrità dei dati
- Aumento degli errori degli utenti
- Livelli di frustrazione degli utenti più elevati e minore soddisfazione degli utenti
- Minor produttività degli utenti

Tenere presente che può essere opportuno utilizzare la guida in app in modo diverso nei diversi scenari, poiché la mentalità di un utente determinerà la quantità di guida "troppa" rispetto a "non sufficiente". Gli utenti che vengono introdotti a un nuovo sistema per la prima volta probabilmente avranno bisogno di messaggi più frequenti rispetto agli utenti che stanno semplicemente imparando a conoscere una nuova funzione in un sistema che hanno già familiarità.

Di seguito sono riportati alcuni suggerimenti chiave per creare una guida in app efficace:

- **Sviluppare standard di progettazione**. È importante ricordare che la sovraesposizione alla guida in app può far sì che gli utenti inizino ad ignorare o ignorare regolarmente i messaggi. A questo punto, la guida in app diventa un fastidio, non una risorsa. Definire [standard di progettazione](/docs/architect/it-it/well-architected/guide/intentional#design-standards) per chiarire quando utilizzare prompt, tour dimostrativi, testo della guida a livello di campo, messaggi di convalida, percorsi, flussi schermata e così via.
- **Creare un sistema di assegnazione delle priorità per le implementazioni dell'orientamento**. Non tutti i casi d'uso per la guida in app devono essere implementati. Considerare invece le seguenti domande per stabilire la priorità. Dove è possibile utilizzare nomi di campo migliori, etichette più esplicite sui pulsanti, una migliore [progettazione dei moduli](/docs/architect/it-it/well-architected/guide/engaging#moduli) e l'[ottimizzazione dei processi](/docs/architect/it-it/well-architected/guide/automated#progettazione-dei-processi) per creare flussi di lavoro più intuitivi? Dove è possibile aggiungere testo o link più utili a un percorso? Quale [impatto sui costi](/docs/architect/it-it/resources/guide/kpi-spreadsheet-template) avrà la guida in app? Con che frequenza si desidera consegnare i messaggi agli utenti? Assicurarsi inoltre che tutte le implementazioni siano incluse nella [roadmap](/docs/architect/it-it/well-architected/guide/intentional#roadmapping), in modo che tutti gli stakeholder abbiano visibilità.
- **Mappare gli utenti alla guida in app attiva (e proposta)**. La mappatura degli utenti alla guida in app aiuterà a identificare e prevenire il "sovraccarico di assistenza" dovuto a una quantità eccessiva di guida in app visualizzata per un utente. Spesso questo è il risultato dello sviluppo in silo, poiché i team pensano troppo ristrettamente al loro caso d'uso particolare. Mantenere una visione olistica di ciò a cui saranno esposti gli utenti è particolarmente importante per le grandi organizzazioni. Può essere utile anche includere implementazioni di orientamento nella roadmap.
- **Raccogliere e utilizzare i commenti per migliorare**. Esaminare i dati sull'utilizzo della guida in app e utilizzarli per giudicare l'efficacia delle distribuzioni della guida in app. Assicurarsi di fornire agli utenti dei modi per fornire anche feedback aperti per aiutare i generatori di orientamento.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/engaging#schemi-e-anti-schemi-dellapp-utili) riportato di seguito mostra l'aspetto corretto (e scadente) della guida in app in un'organizzazione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli e identificare le implementazioni che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la guida in app, vedere [Strumenti pertinenti per](/docs/architect/it-it/well-architected/guide/engaging#strumenti-rilevanti-per-il-coinvolgimento) il coinvolgimento.

### Riconoscimenti e premi

Creare riconoscimenti e premi in un'app aiuta le persone che la utilizzano a sentirsi più connesse all'impatto del proprio lavoro e a comprendere meglio il valore dei loro contributi, della loro produttività e delle loro prestazioni. È anche un modo efficace per sbloccare la fedeltà e il coinvolgimento.

Non progettare per il riconoscimento o premiare le esperienze dell'app può contribuire a una serie di problemi, tra cui:

- Utenti che faticano a capire il loro progresso o la loro velocità
- Confusione sull'avanzamento verso gli obiettivi o sul lavoro non completato
- Utenti più improduttivi, che non vedono una connessione tra le loro operazioni e il "quadro generale"
- Tempo sprecato dalla gestione con rapporti manuali sugli obiettivi di basso livello

L'assegnazione di premi alle esperienze dell'app può essere difficile da progettare e offrire, poiché dipende dalla cultura, dalle policy e dagli standard aziendali, nonché dal contesto e dalle preferenze dei singoli utenti. Le funzioni che possono aiutare gli utenti desktop a provare momenti di gioia o apprezzamento possono diventare un'irritazione per un utente su dispositivo mobile o un utente che tenta di lavorare da un ufficio domestico rumoroso e occupato. Le persone che utilizzano un'app per lavorare con informazioni private o estremamente sensibili potrebbero non apprezzare la comunicazione sui punti salienti sotto forma di festeggiamenti con coriandoli o badge. Un team di vendita distribuito, al contrario, può vedere tale ludicizzazione come un'esperienza dell'app adeguatamente gratificante. In ultima analisi, gli schemi di implementazione scelti possono essere determinati al meglio collaborando con i designer di esperienze utente (UX) in un team.

Quando si tratta di architettura, è importante identificare come e dove le app possono implementare funzioni che aiutano gli utenti a sentirsi riconosciuti e premiati. È anche fondamentale capire come e dove queste funzioni potrebbero rendere le app meno [riutilizzabili](/docs/architect/it-it/well-architected/guide/composable) o distogliere l'attenzione dal fornire [valore aziendale reale](/docs/architect/it-it/well-architected/guide/automated#valore-aziendale).

Di seguito sono riportate alcune domande da considerare quando si valutano i riconoscimenti e i premi nelle app Salesforce:

- **Come e dove gli utenti possono vedere i propri progressi, oltre alle statistiche complessive del team?** I rapporti sono importanti, ma spesso contengono dati di riepilogo che possono non rientrare nel contesto del lavoro quotidiano. È possibile utilizzare uno strumento come il Generatore di app Lightning per incorporare grafici o cruscotti digitali nelle schermate dei record nel contesto di un'app, aiutando gli utenti a comprenderne l'impatto o l'avanzamento durante le attività quotidiane.
- **Come devono essere riconosciuti gli utenti?** Questo può variare a seconda del team o delle preferenze individuali. In alcuni casi, i supervisori potrebbero voler visualizzare messaggi sull'avanzamento degli utenti in modo da poterli condividere con un gruppo più ampio. Il riconoscimento può anche essere un ulteriore vantaggio per aiutare il morale dei dipendenti. E in altri casi, gli utenti potrebbero semplicemente preferire essere gli unici a ricevere notifiche sull'avanzamento di una determinata operazione o progetto.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/engaging#schemi-e-anti-schemi-dellapp-utili) riportato di seguito mostra l'aspetto corretto (e scarso) del riconoscimento e dei premi in un'organizzazione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli e identificare le implementazioni che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per il riconoscimento e i premi, vedere [Strumenti pertinenti per](/docs/architect/it-it/well-architected/guide/engaging#strumenti-rilevanti-per-il-coinvolgimento) il coinvolgimento.

### Schemi e anti-schemi dell'app utili

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per applicazioni utili in [Explorer schemi e](/docs/architect/it-it/well-architected-tools/guide/easy-helpful) antischegge.

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Notifiche e messaggi</b></td>
            <td><b>Gli standard di progettazione includono:</b>
                <br> Casi d'uso approvati per notifiche, brindisi e avvisi
                <br> - Modelli di progettazione per le varianti e le notifiche dei brindisi
                <br> - Modelli di progettazione per la messaggistica di errore</td>
            <td>Se gli standard di progettazione sono definiti, non riguardano gli errori e le notifiche</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
                <br> - Le notifiche sono il formato di messaggistica predominante
                <br> - I messaggi toast utilizzano varianti
                <br> - I messaggi toast con <code>modalità</code> impostata su <code>sticky</code> non esistono
                <br> - Gli avvisi sono usati raramente, o del tutto
                <br> - Le risposte generative identificano sempre le fonti di dati utilizzate
                <br> - I bot si identificano chiaramente prima della prima interazione con gli utenti
                <br> - Le dichiarazioni di non responsabilità per i rischi associati all'intelligenza artificiale generativa vengono visualizzate agli utenti prima della prima interazione
                <br> Le dichiarazioni di non responsabilità AI sono in un linguaggio chiaro e comprensibile per gli utenti</td>
            <td><b>Nella propria organizzazione:</b>
                <br> - Email sono il formato di messaggistica predominante
                <br> - Non esiste un approccio coerente ai tipi di messaggi
                <br> - I messaggi toast non utilizzano costantemente le varianti
                <br> - I messaggi brindisi con <code>la modalità</code> impostata su <code>sticky</code> esistono
                <br> - Gli avvisi vengono utilizzati ad hoc
                <br> - Le risposte generative non identificano le fonti di dati utilizzate
                <br> - I bot non si identificano chiaramente prima della prima interazione con gli utenti
                <br> - Nessuna dichiarazione di non responsabilità per i rischi generativi dell'intelligenza artificiale viene visualizzata agli utenti
                <br> Le dichiarazioni di non responsabilità AI non sono in un linguaggio chiaro e comprensibile per gli utenti</td>
        </tr>
        <tr>
            <td><b>Nelle app:</b>
                <br> - Nessuna risposta generativa viene inviata direttamente agli utenti finali senza punti di coinvolgimento umano</td>
            <td><b>Nelle app:</b>
                 <br> - Le risposte generative vengono inviate direttamente agli utenti finali senza punti di coinvolgimento umano</td>
        </tr>
        <tr>
            <td colspan="2">Vedere anche: <a href="https://staging.architect.salesforce.com/docs/architect/it-it/well-architected/easy/automated#error-handling">Gestione errori</a></td>
        </tr>
        <tr>
            <td rowspan="2"><b>Guida in app</b></td>
            <td><b>Gli standard di progettazione e la documentazione includono:</b>
                <br> - Casi d'uso approvati per la guida in app
                <br> - Modelli di progettazione per prompt e tour dimostrativi
                <br> Una chiara matrice di utenti, app e guida in app attiva</td>
            <td>Se esistono standard e documentazione di progettazione, essi:
                <br> - Non indirizzare la guida in app
                <br> - Non includere una matrice chiara che mostra utenti, app, guida in app attiva</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
                <br> - L'impostazione "Ritardo tra la guida in app" utilizza il valore predefinito o un valore personalizzato <i>più lungo</i> del periodo predefinito (24 ore) fornito da Salesforce
                <br> - Nessuna app ha più di un tour dimostrativo attivo
                <br> - Nessun tour dimostrativo ha un'impostazione "Times to show" superiore a 10
                <br> - Non vengono attivati prompt per "Qualsiasi pagina, qualsiasi app" o "Questa pagina, qualsiasi app"</td>
            <td><b>Nella propria organizzazione:</b>
                <br> - L'impostazione di "Ritardo tra la guida in app" è impostata su un periodo più breve del periodo predefinito (24 ore) fornito da Salesforce
                <br> - Le app hanno più di un tour dimostrativo attivo
                <br> - Molti tour dimostrativi hanno un'impostazione "Times to show" superiore a 10 (e alcuni hanno il valore massimo di 30)
                <br> - I prompt vengono attivati ad hoc, molti con l'impostazione "Qualsiasi pagina, qualsiasi app" o "Questa pagina, qualsiasi app"
                </td>
        </tr>
        <tr>
            <td><b>Riconoscimenti e premi</b></td>
            <td><b>Nella propria organizzazione:</b>
                <br> - Le app utilizzano Analytics incorporata per mostrare agli utenti le statistiche pertinenti sull'avanzamento degli obiettivi e sulla produttività
                <br> - I festeggiamenti del percorso sono abilitati solo con il consenso dell'utente
                <br> - Le notifiche e la messaggistica includono il riconoscimento degli utenti e riflettono le preferenze degli utenti nella progettazione di chi riceve la notifica e cosa attiva le notifiche
            </td>
            <td><b>Nella propria organizzazione:</b>
                <br> - Analytics relative all'avanzamento degli obiettivi e alle statistiche di produttività sono disponibili solo nei rapporti o nei cruscotti digitali dei responsabili
                <br> - I festeggiamenti del percorso sono abilitati senza verificare il consenso dell'utente
                <br> Le notifiche e la messaggistica non includono alcun tipo di riconoscimento utente o non riflettono le preferenze degli utenti e si sentono rumorosi o espedienti
            </td>
        </tr>
    </tbody>
</table>

## Strumenti rilevanti per il coinvolgimento

<table class="tools-table"><tbody><tr><th>Strumento</th><th>Descrizione</th><th>Semplificato</th><th>Utile</th></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm&type=5">Attivazione della pagina dell'app Lightning</a></td><td>Gestisci disponibilità, denominazione, visibilità e posizionamento delle pagine</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N30000004gHhLEAU">Cruscotto digitale adozione</a></td><td>Esaminare la cronologia accessi, l'adozione delle funzioni e la produttività</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/components/alert/">Avviso</a></td><td>Persistere negli avvisi sulle sessioni e visualizzarli senza l'avvio dell'utente</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching">Caching lato client dei risultati del metodo Apex</a></td><td>Valutazione delle prestazioni con i dati memorizzati nella cache lato client</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.dynamic_forms_overview.htm&type=5">Moduli dinamici</a></td><td>Visualizzare agli utenti solo i campi obbligatori e le sezioni di pagina</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.networks_insights_enable.htm&type=5">Approfondimenti partecipazione</a></td><td>Monitorare l'attività recente degli utenti e intervenire in base alle esigenze</td><td class="check-col">X</td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.customhelp_lexguid.htm&type=5">Guida in app</a></td><td>Utilizzare prompt e tour dimostrativi per la formazione e l'orientamento</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.customhelp_lex_learning_intro.htm&type=5">Percorsi di apprendimento</a></td><td>Personalizzazione delle esperienze di apprendimento degli utenti</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_app_builder_overview.htm&type=5">Generatore di app Lightning</a></td><td>Creazione di pagine mobili e Lightning personalizzate senza codice</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.data_ui_api">Servizio dati Lightning</a></td><td>Inserimento nella cache e condivisione dei dati tra i componenti</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/tools/validator/">Convalidatore del sistema Lightning Design per VS Code</a></td><td>Convalida del markup rispetto alle linee guida SLDS</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5">Modelli di pagina Lightning</a></td><td>Creazione di pagine Lightning per diversi fattori di forma</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_lookup_filters.htm&type=5">Filtri di ricerca</a></td><td>Filtrare i valori per le relazioni di ricerca, record principale-record dettaglio e gerarchia</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_currency.htm&type=5">Gestisci più valute</a></td><td>Utilizzare più valute nelle transazioni</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=livemessage_intro.htm&language=en_US&type=5">Messaggistica</a></td><td>Inviare messaggi SMS, Facebook Messenger o WhatsApp</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=s1_branded_apps.htm&language=en_US">Mobile Publisher</a></td><td>Creazione di versioni mobili delle app Lightning e dei siti Experience Cloud</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.mobile">Componenti pronti per l'uso</a></td><td>Creare componenti che funzionino bene nelle esperienze mobili</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.siteforce_languages_overview.htm&type=5">Siti multilingue</a></td><td>Creare versioni linguistiche diverse del sito</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5">Generatore di notifiche</a></td><td>Creare notifiche personalizzate per presentare informazioni</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.path_overview.htm&type=5">Percorso</a></td><td>Guidare gli utenti nei processi aziendali e festeggiare il successo</td><td class="check-col">X</td><td class="check-col">X </td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm">Cache piattaforma</a></td><td>Migliorare le prestazioni e l'affidabilità durante il caching dei dati</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_app_builder_mobile_guidance.htm&type=5">Anteprima delle pagine dell'app mobile nel Generatore di app Lightning</a></td><td>Visualizzare in anteprima le pagine di record e app su un dispositivo mobile</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/components/prompt/">Prompt</a></td><td>Avvisare gli utenti di problemi e aggiornamenti relativi al sistema</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=networks_recog_badges.htm&type=5&language=en_US">Badge di riconoscimento</a></td><td>Riconoscere e celebrare i successi degli utenti</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.workcom_overview.htm&type=5">Riconoscimento con WDC</a></td><td>Confermare le competenze e ringraziare</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customize_recordtype.htm&type=5&language=en_US">Tipi di record</a></td><td>Personalizzare i processi aziendali, i valori degli elenchi di selezione e i layout di pagina</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=networks_reputation_overview.htm&type=5&language=en_US">Panoramica della reputazione</a></td><td>Riconoscimento della partecipazione e condivisione Knowledge</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/apex/HTViewHelpDoc?id=sf.security_restriction_rule.htm&language=en_US">Regole di restrizione</a></td><td>Impedire agli utenti di accedere a record che possono contenere dati non necessari</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5">Componenti pagina standard</a></td><td>Informazioni sui componenti Salesforce Lightning standard</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=workbench_overview.htm&type=5&language=en_US">Traduzioni</a></td><td>Gestione delle traduzioni per gli utenti globali</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_about_field_validation.htm&type=5">Regole di convalida</a></td><td>Verificare che i dati soddisfino gli standard specificati prima di salvare</td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## Risorse rilevanti per il coinvolgimento

<table class="tools-table"><tbody><tr><th>Risorsa</th><th>Descrizione</th><th>Semplificato</th><th>Utile</th></tr>
<tr><td><a href="/docs/architect/it-it/decision-guides/guide/build-forms">Guida dell'architetto alla creazione di moduli</a></td><td>Valutare le considerazioni sulla progettazione dei moduli e selezionare lo strumento migliore</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_config_form_factors">Configurazione del componente per diversi fattori di forma</a></td><td>Configurare i componenti da visualizzare in desktop e telefoni</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customhelp_about.htm&type=5&language=en_US">Personalizzazione del contenuto della Guida</a></td><td>Personalizzare il contenuto della guida in base all'implementazione specifica </td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_defining_default_values.htm&type=5">Valori predefiniti dei campi</a></td><td>Definire valori di campo predefiniti, dinamici o statici</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/overview/">Linee guida di progettazione</a></td><td>Creare interfacce utente coerenti con le procedure consigliate</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/design-standards-template">Modello Design Standards (Standard di progettazione)</a></td><td>Creare standard di progettazione per l'organizzazione</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/ux-designer-certification-prep/refresh-your-design-testing-skills">Progettazione di competenze di test (Trailhead)</a></td><td>Pianificare i metodi per convalidare e testare un progetto</td><td class="check-col">X</td><td class="check-col">X </td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/in-app-feedback/overview/">Linee guida per i commenti in app</a></td><td>Rivedere le linee guida per raccogliere commenti dall'interno del sistema</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://github.com/salesforce-ux/design-system-android">Libreria statica Android Lightning Design System</a></td><td>Creare app Android native con l'aspetto delle pagine Lightning</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://github.com/salesforce-ux/design-system-ios">Libreria statica iOS Lightning Design System</a></td><td>Creare app iOS native con l'aspetto delle pagine Lightning</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/overview/">Linee guida di Messaggistica</a></td><td>Comunicare informazioni pertinenti e creare momenti di piacere</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/types/">Tipi di messaggistica</a></td><td>Informazioni sui diversi tipi di messaggistica in base all'interazione dell'utente</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/navigation/">Linee guida di navigazione</a></td><td>Aiutare gli utenti a spostarsi tra le pagine e a posizionarsi in un'app</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/testing-for-web-accessibility">Test dell'accessibilità del Web (Trailhead)</a></td><td>Utilizzare test automatici e manuali per garantire l'accessibilità</td><td class="check-col">X</td><td class="check-col">X </td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/user-engagement/overview/">Linee guida per il coinvolgimento degli utenti</a></td><td>Rivedere le linee guida per l'orientamento, l'adozione, l'assistenza e l'apprendimento</td><td class="check-col">X</td><td class="check-col">X</td></tr>
</table>

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.

<!-- document id=be3b66fc50104291a19ebefb6d5d233e0f7cfd9044e142f239f7d8f28147457e url=/architect/next/it-it/well-architected/guides/composable.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

Le soluzioni componibili si adattano rapidamente e con maggiore stabilità. Un sistema progettato per essere componibile è costruito in unità significative, o blocchi di costruzione, che possono funzionare con grazia l'uno con l'altro e possono essere facilmente scambiati dentro e fuori servizio. La creazione della componibilità in un sistema consente di introdurre nuove funzionalità o di eliminare l'indebitamento tecnico rifattorizzando o rimontando singole unità di un sistema. La componibilità consente cicli di consegna e rilasci più rapidi e prevedibili, poiché i team possono concentrarsi sulla creazione e la fornitura di funzioni significative tramite piccole quantità di modifiche.

I sistemi componibili consentono alle imprese di adeguarsi più rapidamente e con maggiore stabilità, sia che lo stimolo sia interno all'azienda o causato da fattori esterni. La componibilità consente ai sistemi di essere più [resilienti](/docs/architect/it-it/well-architected/guide/resilient) e può contribuire a rendere le soluzioni e gli schemi architettonici più [intenzionali](/docs/architect/it-it/well-architected/guide/intentional).

È possibile rendere le soluzioni Salesforce più componibili creando tre abitudini chiave: separazione delle preoccupazioni, interoperabilità e possibilità di inserire pacchetti. Di seguito è possibile vedere la relazione di queste abitudini in due modi: per una singola unità o in un sistema componibile e per più unità in un sistema componibile.

<b>Una singola unità componibile:</b>

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-capabilities.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem;width:50%;" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-capabilities.jpeg" alt="Questo è un diagramma che mostra come gli argomenti in componibile sono correlati attraverso tre schede nidificate. La scheda più interna è un&apos;unità funzionale, il livello successivo è l&apos;interoperabilità e il livello esterno è inseribile in pacchetti.">
</a>

<b>Un sistema componibile:</b>

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-multi-package-capabilities.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-multi-package-capabilities.jpeg" alt="Questo è un diagramma che mostra come gli argomenti in componibile sono correlati attraverso tre schede nidificate. La scheda più interna è un&apos;unità funzionale, il livello successivo è l&apos;interoperabilità e il livello esterno è inseribile in pacchetti.">
</a>

## Separazione delle preoccupazioni

Un concetto fondamentale nell'ingegneria del software e nell'architettura di sistema, la _separazione delle preoccupazioni_ comporta l'identificazione di varie preoccupazioni all'interno di un sistema più grande che può essere separato in unità modulari. Il raggiungimento di una forte separazione delle preoccupazioni all'interno di un sistema richiede la creazione di unità significative per la logica di applicazione e le funzioni in tutto il sistema. Le unità più piccole semplificano la consegna e la manutenzione delle app per i team che devono capire come e dove apportare modifiche, con interruzioni minime al sistema più grande. Le unità più piccole consentono anche di capire meglio come e dove concentrare il lavoro quando si affronta il [debito tecnico](/docs/architect/it-it/well-architected/guide/intentional#debito-tecnico) e contribuiscono alla [leggibilità](/docs/architect/it-it/well-architected/guide/intentional#leggibilità) complessiva del sistema.

È possibile creare una migliore separazione delle preoccupazioni nell'organizzazione Salesforce orientandosi verso la capacità aziendale e lo stato di gestione.

### Unità funzionali

Per i sistemi Salesforce, l'approccio migliore per la separazione delle preoccupazioni applica una prospettiva orientata al business per identificare e organizzare le unità modulari (o le funzionalità) all'interno del sistema. Questo è diverso da una visualizzazione focalizzata sull'ingegneria, che identifica le unità in base alla loro funzione tecnica. Una prospettiva orientata all'azienda indipendentemente dalle preoccupazioni richiede l'organizzazione del codice e delle personalizzazioni nel sistema in base al servizio che forniscono agli utenti aziendali e aziendali. Adottare questo approccio non significa ignorare il potenziale di funzioni tecniche ridondanti o duplicate in un sistema. Piuttosto, significa che i servizi tecnici sono chiaramente mappati a un principio organizzativo che in ultima analisi è trasparente per l'azienda.

L'orientamento alle funzionalità aziendali consente di garantire che i passaggi tra i team di analisi aziendale e di scoperta ai team di consegna siano il più semplici possibile. Se i generatori di app non hanno idea di dove le loro unità di lavoro vengono mappate nell'architettura componibile, significa che il panorama delle app non è componibile. Le mappature poco chiare tra lo stato finale richiesto dall'azienda e le unità modulari all'interno di un'organizzazione aumentano anche le possibilità che i team di sviluppo o i fornitori creino funzioni ridondanti nel sistema.

Considerare quanto segue per orientare le unità funzionali alla funzionalità aziendale:

- **Iniziare con i lavori da eseguire**. Concentrarsi sui processi da eseguire (JTBD) degli utenti e dell'azienda stessa. Pioniere di Tony Ulwick, l'approccio JTBD si concentra sulla comprensione del "lavoro", o vero scopo, che le persone stanno cercando di realizzare utilizzando un prodotto o servizio. È un livello di astrazione superiore rispetto alle operazioni correlate ai ruoli degli utenti o alle singole fasi di un processo aziendale. Ad esempio, operazioni come i controlli duplicati e le convalide degli indirizzi potrebbero rientrare in una funzione di ordine superiore di "stabilire una visualizzazione unica del cliente". Quando si ha un'idea chiara di queste funzionalità aziendali di livello superiore, è possibile iniziare a mapparvi parti del sistema.
- **Orientarsi alle funzionalità, non alle strutture di creazione di rapporti**. La gerarchia interna delle unità operative non è un proxy per le funzionalità o i processi significativi da eseguire. La gerarchia interna dell'azienda ha un impatto significativo sui processi e sulle strutture del team (per non parlare dei budget). Si tratta di considerazioni logistiche importanti. Ma le esigenze funzionali dell'azienda operano a un livello di astrazione superiore rispetto alla logistica. Se si sta creando un modulo per servire una struttura di rapporti anziché una funzione di ordine superiore, tenere presente che potrebbe essere necessario eseguire ulteriori operazioni per identificare in che modo il modulo è correlato alle funzionalità aziendali.
- **Sii iterativo**. Iniziare collaborando con l'azienda per identificare le funzionalità che potrebbero funzionare per un prodotto minimo vitale (MVP). Quando si identifica una funzionalità, iniziare a crearla come MVP. Durante la creazione, identificare i processi, i metadati e gli [eventi o messaggi](/docs/architect/it-it/well-architected/guide/composable#messaggistica-ed-eventi) centrali per l'unità funzionale che si sta creando. Identificare eventuali processi, metadati ed eventi o messaggi che sono dipendenze esterne. Man mano che si progettano unità più funzionali, implementare la [gestione API](/docs/architect/it-it/well-architected/guide/composable#gestione-api) e la [gestione delle dipendenze](/docs/architect/it-it/well-architected/guide/composable#gestione-delle-dipendenze) per creare unità che funzionano bene l'una con l'altra (anziché creare unità in silo).

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/composable#separazione-degli-schemi-di-preoccupazione-e-anti-schemi) riportato di seguito mostra l'orientamento corretto (e inadeguato) alla funzione aziendale all'interno di una soluzione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce che consentono di orientarsi meglio alle funzionalità aziendali, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/composable#strumenti-rilevanti-per-i-compositi) la composizione.

### Gestione statale

La gestione statale si concentra sulla circolazione delle informazioni in un sistema in vari punti nel tempo. Una gestione efficace dello stato consente alle applicazioni di gestire flussi complessi di dati o interazioni con un minimo di esiti non pianificati o indeterminati. Gestire lo stato in un'organizzazione Salesforce modulare significa creare percorsi chiari per i flussi di logica all'interno e tra le unità, nonché percorsi graziosi per i comportamenti di esecuzione non pianificati. La gestione dello stato consente di creare flussi coerenti di logica dalle unità di applicazione Salesforce modulari. Nella maggior parte dei casi, ciò richiede [l'interoperabilità](/docs/architect/it-it/well-architected/guide/composable#interoperabilità) per strutturare il flusso di informazioni tra le unità.

Difficoltà di gestione dello stato tra unità vagamente accoppiate spesso portano allo sviluppo di applicazioni monolitiche in Salesforce. È possibile vedere questo in grandi "monoflussi", che sono costruiti nel tentativo di orchestrare un processo complesso all'interno di un flusso singolare. Un altro esempio sono le classi Apex massicce, che orchestrano processi complessi tramite _spaghetti code_, o una lunga serie di metodi monouso. Questi tipi di architetture applicative rendono difficile il refactoring e il debug e aumentano i tempi di orientamento per i nuovi membri del team o fornitori. Riducono anche il valore delle applicazioni fornite all'azienda, poiché le funzionalità non sono riutilizzabili.

Considerare quanto segue per gestire lo stato in un'organizzazione Salesforce modulare:

- **Decidere quando utilizzare gli schemi stateful rispetto a quelli stateless**. Gli schemi stateful conservano le informazioni in tutto un percorso di esecuzione, mentre gli schemi stateless non le conservano. In un sistema vagamente accoppiato, gli schemi stateless consentono di rifattorizzare i componenti più rapidamente e con meno effetti collaterali. Tuttavia, gli schemi stateless non sono appropriati per tutti i casi d'uso. Se si creano componenti per le operazioni sui dati, gli schemi statici possono essere utili per l'integrità e la coerenza dei dati in tutti i sistemi. Utilizzare uno schema stateful se il componente soddisfa uno dei seguenti criteri:
  - La consapevolezza della posizione all'interno di un percorso di esecuzione più ampio è essenziale per il comportamento del componente
  - Il comportamento del componente deve cambiare in base ai risultati di un'azione a valle (ad esempio, deve modificare l'esecuzione in base ai messaggi di ritiro/errore/successo dei componenti a valle)
  - Il componente deve attendere le risposte da un sistema esterno o a valle per completare il lavoro
- **Creare categorie significative per informazioni dettagliate**. _Stato_ è un termine ambiguo che può essere applicato a una gamma così ampia e profonda di informazioni all'interno (e all'esterno) di un'organizzazione Salesforce che il termine da solo è quasi privo di significato. Un primo passo necessario per creare schemi stateful è quindi la creazione di categorie _significative_ per i più importanti percorsi di esecuzione stateful (o tipi di comportamenti stateful) all'interno del sistema. Alcune categorie da considerare:
  - Navigazione e moduli
  - Operazioni sul database
  - Operazioni batch e in blocco
  - Errori
- **Definire gli stati correlati ai dati in termini di [transazioni del database](/docs/architect/it-it/fundamentals/guide/architecture-basics#manipolazione-del-database)**. I comportamenti incorporati della piattaforma circoscriveranno la maggior parte delle considerazioni relative allo stato dei dati in Salesforce. Non tentare di gestire questo comportamento o di aggirarlo. Progettare per e con esso. Progettare soluzioni che riducono al minimo o eliminano la logica delle transazioni distribuite. (Per ulteriori dettagli, vedere [Gestione dei dati](/docs/architect/it-it/well-architected/guide/automated#gestione-dei-dati)).
- **Identificare gli stati che si verificano all'interno (e tra) le unità funzionali**. Quando si assemblano le unità funzionali in sistemi più grandi, tenere presente quando si mescolano il comportamento dei componenti stateless e stateful e impedire combinazioni che potrebbero creare loop o interruzioni infinite nell'elaborazione.
- **Definire i passaggi**. Considerare quali schemi di [messaggistica o eventi](/docs/architect/it-it/well-architected/guide/composable#messaggistica-ed-eventi) verranno utilizzati dai componenti per trasmettere i dati relativi allo stato a un'altra parte del sistema. Assicurarsi di acquisire consapevolezza e [gestione](/docs/architect/it-it/well-architected/guide/automated#gestione-dei-dati) delle transazioni nei componenti. Non includere alcuna logica di transazione distribuita nelle consegne.
- **Creare mappature tra i diagrammi e gli stati del processo**. I diagrammi dei processi descrivono in dettaglio le fasi che spostano le informazioni nel sistema in vari punti nel tempo. Un diagramma dello stato mostra le modifiche effettive nelle informazioni (lo stato). Utilizzare la parte piè di pagina dei metadati delle forme dei [diagrammi Salesforce](/docs/architect/it-it/reference-diagrams/guide/kit-of-parts) per acquisire lo stato mutevole delle informazioni in ogni fase del processo. Se si separano diagrammi di processo e diagrammi di stato, assicurarsi di collegarli. Questo concetto non deve essere confuso con l'acquisizione dello stato attuale e futuro dei processi o dei paesaggi del sistema durante la progettazione e l'implementazione, poiché non si tratta delle informazioni che passano attraverso il sistema.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/composable#separazione-degli-schemi-di-preoccupazione-e-anti-schemi) riportato di seguito mostra l'aspetto di una corretta (e scarsa) gestione dello stato all'interno di una soluzione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione dello stato, vedere [Tools Relevant to Composable](/docs/architect/it-it/well-architected/guide/composable#strumenti-rilevanti-per-i-compositi).

### Separazione degli schemi di preoccupazione e anti-schemi

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per la separazione delle preoccupazioni in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/adaptable-separation-of-concerns).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Unità funzionali</b></td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Le convenzioni di denominazione indicano come indicare un'unità funzionale
                <br> - Esiste un elenco di tutte le unità funzionali attualmente definite (e relative convenzioni di denominazione)
                <br> - Esistono standard per proporre aggiunte o modifiche delle unità funzionali</td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Gli standard di progettazione non esistono o non riguardano le unità funzionali e i casi d'uso
            </td>
        </tr>
        <tr>
            <td><b>Nella documentazione:</b>
                <br> - I diagrammi di paesaggio del sistema mostrano chiaramente le unità funzionali in un'organizzazione
                <br> - Tutta la documentazione e i diagrammi di implementazione mostrano chiaramente le unità funzionali per i componenti
                <br> - La documentazione per i singoli componenti include la mappatura delle unità funzionali per il componente
                <br> - Tutti i componenti all'interno di un'unità funzionale sono ricercabili e facili da trovare
            </td>
            <td><b>Nella documentazione:</b>
                <br> - La documentazione del componente non esiste
                <br> - La documentazione del componente descrive l'unità funzionale a cui appartiene un componente, ma è l'unico punto in cui appare la definizione di tale unità funzionale
                <br> - Non è possibile cercare una particolare unità funzionale e/o le ricerche non aiutano a identificare tutti i componenti all'interno di un'unità funzionale
            </td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
                <br> - È possibile identificare rapidamente l'allineamento delle unità funzionali per un dato elemento di metadati (ad esempio, un flusso, una classe Apex o una pagina Lightning)
                <br> - Le unità funzionali sono etichettate in termini business-friendly
            </td>
            <td><b>Nella propria organizzazione:</b>
                <br> - Non è possibile identificare l'allineamento delle unità funzionali per alcun metadati
                <br> - Le informazioni sulle unità funzionali sono incoerenti o imprecise
                <br> - Le informazioni sulle unità funzionali sono etichettate in termini ingegneristici che non hanno significato per gli utenti aziendali
            </td>
        </tr>
         <tr>
            <td rowspan="4"><b>Gestione statale</b></td>
            <td><b>Negli standard di progettazione:</b>
                <br> - I casi d'uso per i progetti stateful vs. stateless sono chiari
                <br> - Esistono schemi approvati per la comunicazione stateless
                <br> - Esistono schemi approvati per la comunicazione stateful
                <br> - Cancella categorie per stato esistono
            </td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Gli standard di progettazione non esistono o non riguardano schemi e casi d'uso di stato/apolide
            </td>
        </tr>
        <tr>
            <td><b>Nella documentazione:</b>
                <br> - Ogni componente che gestisce le comunicazioni stateful e/o stateless indica quale schema è stato implementato
                <br> - È possibile cercare e trovare tutti i componenti che hanno implementato un particolare schema stateful/stateless
                <br> - I diagrammi di processo e di interazione forniscono dettagli sulle categorie di stato e i trasferimenti
            </td>
            <td><b>Nella documentazione:</b>
                <br> - La documentazione del componente non esiste
                <br> - La documentazione del componente descrive lo schema stateful/stateless implementato, ma è l'unico punto in cui appare la definizione
                <br> - Non è possibile cercare uno schema particolare e/o le ricerche non aiutano a identificare tutti i componenti che utilizzano quello schema
            </td>
        </tr>
        <tr>
            <td><b>In Apex:</b><br> - Savepoint e comportamenti di ritiro sono utilizzati in tutte le operazioni sui dati</td>
            <td><b>In Apex:</b><br> - Savepoint e comportamenti di ritiro non vengono utilizzati</td>
        </tr>
        <tr>
            <td><b>Nel flusso:</b><br> - Percorsi di errore e viene utilizzato l'elemento Ritiro record</td>
            <td><b>Nel flusso:</b><br> - L'elemento Roll Back Record non viene utilizzato</td>
        </tr>
    </tbody>
</table>

## Interoperabilità

In un sistema progettato per l'interoperabilità, i componenti possono scambiare informazioni e operare insieme in modo efficace. L'interoperabilità è fondamentale per rendere un sistema modulare componibile anziché in silo. L'interoperabilità può essere difficile da ottenere in un sistema [accoppiato](/docs/architect/it-it/well-architected/guide/composable#accoppiamento-allentato). È necessario stabilire standard per metodi di integrazione coerenti che non compromettano l'indipendenza tra le unità e la [separazione delle preoccupazioni](/docs/architect/it-it/well-architected/guide/composable#separazione-delle-preoccupazioni) in tutto il sistema.

L'interoperabilità influisce anche sulla qualità delle esperienze utente. Gli utenti si aspettano che i dati creati in un'area (ad esempio le informazioni sugli ordini) siano utilizzabili in un'altra (ad esempio le campagne di marketing), mentre i generatori si aspettano che, se imparano a fare qualcosa (ad esempio creare un flusso o autenticarsi in un'API), troveranno le tecniche familiari quando passeranno al problema successivo. La mancata progettazione per l'interoperabilità determinerà architetture ridondanti, dati replicati, inefficienze dei processi e un aumento dei costi di sviluppo e assistenza.

È possibile creare interoperabilità nei sistemi modulari con messaggistica ed eventing e con la gestione API.

### Messaggistica ed eventi

Messaggi ed eventi sono due modi in cui è possibile abilitare i componenti in un sistema per inviare e ricevere informazioni. In termini di contenuto che possono trasportare, gli eventi e i messaggi sono simili. Una differenza fondamentale è il comportamento del mittente. Un componente che invia un _messaggio_ in genere invia i dati a una destinazione specifica e attende una risposta dal destinatario. Al contrario, un componente genera un _evento_ quando è accaduto qualcosa. Non esiste una destinazione specifica, né un'aspettativa di risposta. Queste differenze di comportamento supportano modelli di comunicazione diversi. I messaggi supportano schemi di comunicazione stateful e gli eventi supportano schemi di comunicazione stateless. (Per ulteriori informazioni su questa distinzione, vedere [Gestione statale](/docs/architect/it-it/well-architected/guide/composable#gestione-statale)).

È importante allineare i team sui protocolli e sui casi d'uso per la messaggistica e gli eventi. Standard poco chiari possono causare un mix di schemi in tutto il sistema, che porta a:

- Problemi di prestazioni e scalabilità in cui vengono applicati schemi errati a un caso d'uso specifico
- Elaborazione incoerente che rende il sistema instabile agli utenti finali
- Tempi di risoluzione dei problemi più lunghi e processi di manutenzione più complessi

Quando si progettano messaggi ed eventi per creare strutture più vagamente accoppiate all'interno dell'organizzazione Salesforce, tenere presente quanto segue:

- **Identificare i casi d'uso di sincronizzazione e asincrono**. L'evento consente comunicazioni vagamente accoppiate, apolidi e asincrone in un sistema. La messaggistica consente schemi di comunicazione più controllati, statici e sincroni. Quando si decide quando utilizzare i messaggi o gli eventi, è necessario decidere se la comunicazione deve essere sincrona (e potenzialmente bloccante) anziché asincrona e non bloccante.
- **Definire attentamente le** strutture dati. La struttura delle informazioni che i componenti passano tra loro è una parte importante per mantenere gestibile e coerente un sistema vagamente accoppiato. (Per ulteriori informazioni, vedere [Gestione API](/docs/architect/it-it/well-architected/guide/composable#gestione-api)). Una considerazione fondamentale quando si progetta un messaggio o un evento è la frequenza con cui può essere necessario modificare la struttura delle informazioni. Una volta definito e implementato un messaggio o una struttura di evento nel sistema, può essere difficile gestire gli aggiornamenti, soprattutto se l'evento o il messaggio viene già utilizzato per inviare informazioni a un sistema esterno.
- **Messaggi delle dimensioni** giuste. In generale, è consigliabile mantenere le dimensioni dei messaggi piccole. Tuttavia, esiste anche un bilanciamento tra _dimensioni_ e _volume_ dei messaggi. I sistemi possono elaborare più rapidamente piccole quantità di dati. L'atto di elaborazione comporta un sovraccarico aggiuntivo poiché i destinatari devono disimballare, interpretare e determinare cosa fare con le informazioni ricevute. Questi passaggi possono richiedere una quantità trascurabile di tempo, ma possono creare un carico sui sistemi su larga scala. Evitare le progettazioni che richiedono che i componenti del sistema elaborino molti piccoli messaggi in sequenza per completare un lavoro. Per dimensionare correttamente i messaggi, pensare alla progettazione per i componenti a valle di dati minimi che dovranno elaborare e agire correttamente sulle informazioni che sono state inviate, senza presumere che ogni componente a valle sarà in grado di richiedere o elaborare numerosi messaggi di follow-up.
- **Progettazione per scalabilità**. I componenti liberamente accoppiati possono semplificare la scalabilità dell'architettura. L'eliminazione delle dipendenze tra i componenti consente ai team di migliorare le prestazioni o la scalabilità di un singolo componente con effetti minimi sugli altri. Tuttavia, i componenti vagamente accoppiati introducono anche una complessità significativa nell'architettura su larga scala (soprattutto quando si tratta di [gestire lo stato](/docs/architect/it-it/well-architected/guide/composable#gestione-statale)). Identificare i processi che necessitano di una logica o di dipendenze più strette per motivi di esperienza utente o integrità dei dati validi e non tentare di introdurre schemi asincroni/basati sugli eventi in tali processi. Utilizzare invece schemi basati su sincronizzazione/messaggi e una corretta gestione degli errori.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/composable#schemi-di-interoperabilità-e-antischemi) riportato di seguito mostra l'aspetto corretto (e scadente) della messaggistica e degli eventi all'interno di una soluzione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti di messaggistica ed eventing di Salesforce, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/composable#strumenti-rilevanti-per-i-compositi) i componenti. Per ulteriori informazioni sulla scelta di uno schema di evento o di uno strumento per un determinato caso d'uso, vedere [Architect’s Guide to Event-Driven Architecture with Salesforce](/docs/architect/it-it/decision-guides/guide/event-driven#key-takeaways).

### Gestione API

La creazione di una gestione API (Application Programming Interface) corretta all'interno di una soluzione Salesforce consente ai singoli componenti del sistema di seguire schemi di comunicazione prevedibili. Salesforce fornisce API protette incorporate da utilizzare per la comunicazione con sistemi esterni a Salesforce. (Per ulteriori informazioni sulle API Salesforce Platform, vedere Nozioni di [base sull'architettura](/docs/architect/it-it/fundamentals/guide/architecture-basics#api-piattaforma)).

Una gestione efficace delle API all'interno delle soluzioni Salesforce è fondamentale per creare architetture realmente componibili. Consente ai componenti di un'organizzazione Salesforce di inviare e ricevere informazioni in modo efficiente. Consente inoltre ai generatori di soluzioni di seguire protocolli chiari per il modo in cui i componenti che creano comunicano con altri componenti del sistema e li aiuta a identificare precocemente le implementazioni inadeguate. Inoltre, consente ai costruttori di soluzioni di concentrarsi più strettamente sul componente specifico che stanno creando o eseguendo il refactoring, aumentando la produttività e la qualità.

La gestione API a livello aziendale è un argomento a sé stante e può essere realizzata al meglio con uno strumento di gestione API completo. (Per ulteriori informazioni sulla prospettiva MuleSoft su questo argomento, vedere [Che cos'è](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.).)

Considerare quanto segue per creare funzionalità di gestione API all'interno delle soluzioni Salesforce:

- **Pensare alle API come schemi o contratti _prevedibili_ per la comunicazione**. Il tipo di dati delle variabili di input o output, i nomi delle variabili, le informazioni che devono (o non devono) apparire in un determinato schema: queste sono le chiavi per una gestione efficace dell'API. Queste definizioni dovrebbero comparire negli standard di progettazione e i team dovrebbero essere in grado di scoprire come queste definizioni sono state implementate in particolari parti del sistema tramite la documentazione. Un modo per visualizzare le difficoltà di unione delle modifiche da un nuovo sviluppo in un ambiente di integrazione è quello di considerarle come una prova di dove le comunicazioni API sono state implementate in modo non corretto (o forse non è stata definita alcuna API).
- **Non limitare il pensiero sulle API esclusivamente al codice**. Ciò che definisce un'API in questo contesto è la coerenza delle strutture e delle variabili del messaggio all'interno del messaggio. A condizione che venga mantenuta tale coerenza, un'API può essere implementata nel codice e nelle personalizzazioni dichiarative, ad esempio nei flussi AutoLaunched modulari (o attivati da eventi piattaforma) o persino nei modelli di flusso. Basare le decisioni su ciò che definire nel codice e non nei flussi sull'implementazione dell'API, ma piuttosto sulla [disponibilità dei pacchetti](/docs/architect/it-it/well-architected/guide/composable#inserimento-in-pacchetti) e [sulla verificabilità](/docs/architect/it-it/well-architected/guide/resilient#gestione-del-ciclo-di-vita-delle-applicazioni).

- **Semplificare il ciclo di vita e il controllo delle versioni**. Come tutte le parti dello sviluppo delle applicazioni, le API hanno un ciclo di vita: definire, creare, testare, distribuire e mantenere (incluso il ritiro). Le API Salesforce Platform rilasciano diverse versioni in un anno di calendario, a causa del ciclo di rilascio rapido della piattaforma. (Ulteriori informazioni su questo comportamento sono disponibili in Salesforce [Architecture Basics](/docs/architect/it-it/fundamentals/guide/architecture-basics#api-piattaforma)). Ciò significa che le API piattaforma hanno un ciclo di vita abbastanza complesso, poiché è necessario mantenere e rendere disponibili diverse versioni di una determinata API per i clienti Salesforce. Questo livello di complessità è appropriato per i casi d'uso PaaS, ma molto probabilmente è una complessità inutile per le architetture delle soluzioni on-platform (vedere: [Anti-schemi di leggibilità](/docs/architect/it-it/well-architected/guide/intentional#modelli-di-leggibilità-e-anti-schemi)). Concentrarsi sulla definizione di uno scopo chiaro per un'API (ad esempio, la gestione degli errori) e di definizioni di base chiare. Cercare di avere una sola versione di ogni API.
- **Rendere le API individuabili, accessibili e gestibili**. [Documentare le API](/docs/architect/it-it/well-architected/guide/intentional#design-standards) in modo che i potenziali consumatori possano trovare facilmente le API disponibili per connettersi a loro. Le API devono funzionare senza problemi come parte di un panorama di [funzionalità](/docs/architect/it-it/well-architected/guide/composable#unità-funzionali).
- **Sii iterativo**. Concentrarsi sulla definizione e l'implementazione di una sola API interna alla volta. In questo modo, è possibile concentrarsi sull'iterazione rapida della definizione API, trovare il modulo giusto per _la_ versione supportata e stabilire le procedure consigliate in base all'esperienza di implementazione.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/composable#schemi-di-interoperabilità-e-antischemi) riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione API all'interno di una soluzione Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce per migliorare l'interoperabilità, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/composable#strumenti-rilevanti-per-i-compositi) la composizione.

### Schemi di interoperabilità e antischemi

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per l'interoperabilità in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/adaptable-interoperability).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Messaggistica ed eventi</b></td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Esistono standard chiari per quando utilizzare gli schemi sincroni (messaggistica) e asincroni (sera)
                <br> Esistono standard chiari per le strutture di eventi e messaggi
            </td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Gli standard di progettazione non esistono o mancano di standard chiari per la sincronizzazione rispetto agli schemi asincroni e di standard chiari per le strutture di messaggi o eventi
            </td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
                <br> - Gli eventi piattaforma utilizzati per la messaggistica di sistema interna sono chiaramente etichettati
                <br> - Gli strumenti del flusso Salesforce fanno riferimento a servizi di messaggistica o eventi a livello di sistema
                <br> - Modelli di messaggistica ed eventi coerenti vengono visualizzati nei flussi e nel codice
            </td>
            <td><b>Nella propria organizzazione:</b>
                <br> - Gli eventi piattaforma utilizzati per la messaggistica di sistema interna non sono chiaramente etichettati o non esistono
                <br> - Diverse strategie per gli schemi di messaggistica ed eventing vengono visualizzate nel flusso e nel codice
            </td>
        </tr>
        <tr>
            <td><b>In Apex o LWC:</b>
                <br> - Le definizioni degli eventi personalizzati sono limitate nell'ambito (nel codice non sono definiti eventi o messaggi a livello di sistema)
                <br> - I servizi di messaggistica o di evento a livello di sistema in Apex sono annotati in modo da renderli disponibili negli strumenti del flusso Salesforce
            </td>
            <td><b>In Apex o LWC:</b>
                <br> - Le strutture di messaggi e/o eventi a livello di sistema sono definite in Apex o JavaScript
                <br> - Le strutture di eventi o messaggi a livello di sistema definite in Apex non sono disponibili in strumenti come il flusso
            </td>
        </tr>
         <tr>
            <td rowspan="3"><b>Gestione API</b></td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Esistono protocolli chiari per la comunicazione tra componenti (ad esempio API)
                <br> - I protocolli/API sono delineati in gruppi logici che i costruttori possono cercare e trovare
                <br> I protocolli/API definiscono i tipi di dati delle variabili, i nomi delle variabili, gli elementi obbligatori o facoltativi e forniscono una descrizione chiara di quando utilizzare
            </td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Gli standard di progettazione non esistono o non definiscono API e casi d'uso
            </td>
        </tr>
        <tr>
            <td><b>Nella documentazione:</b>
                <br> - La documentazione di ogni componente elenca chiaramente quale API/protocollo di comunicazione è stato implementato
                <br> - È possibile cercare una particolare API o protocollo e identificare i componenti in cui viene implementato
            </td>
            <td><b>Nella documentazione:</b>
                <br> - La documentazione del componente non esiste
                <br> - La documentazione del componente descrive l'API implementata all'interno di un componente, ma questo è l'unico punto in cui appare la definizione API
                <br> - Non è possibile cercare una particolare API o protocollo e/o le ricerche non aiutano a identificare i componenti in cui è stata implementata un'API o un protocollo
            </td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
                <br> - I formati dei messaggi API e le variabili per la comunicazione interna sono definiti con tipi di metadati personalizzati
                <br> - I formati dei messaggi API e le variabili per la comunicazione interna sono definiti con gli eventi piattaforma
                <br> - Le personalizzazioni del codice e dichiarative fanno riferimento al tipo di metadati personalizzato appropriato (o evento piattaforma) per inviare o ricevere informazioni
            </td>
            <td><b>Nella propria organizzazione:</b>
                <br> - La comunicazione tra i componenti del sistema (codice e personalizzazioni dichiarative) è ad hoc
                <br> - Le API sono definite esclusivamente per la comunicazione tra Salesforce e i sistemi esterni
            </td>
        </tr>
    </tbody>
</table>

## Inserimento in pacchetti

La creazione della possibilità di inserire pacchetti in un'organizzazione Salesforce significa che le funzionalità dell'organizzazione provengono da unità che possono essere sviluppate e distribuite in modo indipendente e affidabile, come pacchetti. Idealmente, queste unità sono definite come un tipo di pacchetto [di seconda generazione](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm) (un pacchetto sbloccato o un pacchetto gestito per gli ISV). Nota: Poiché le soluzioni ben progettate utilizzano esclusivamente questi tipi di pacchetti, i pacchetti gestiti di prima generazione non sono trattati qui.

Una cosa è definire [separazioni delle preoccupazioni](/docs/architect/it-it/well-architected/guide/composable#separazione-delle-preoccupazioni) e creare unità funzionali in un'organizzazione Salesforce. Un'altra cosa è districarsi e gestire le dipendenze in modo abbastanza chiaro da poterli utilizzare correttamente come artefatti del pacchetto. Il raggiungimento di tale livello di stabilità e isolamento dei metadati richiede un livello significativo di maturità di DevOps (e dell'architettura). Accelera inoltre i tempi di sviluppo, migliora le esperienze del generatore di app e offre prevedibilità e controllo ai rilasci e alla gestione dei rilasci. Non tutte le organizzazioni saranno in grado di supportare l'infrastruttura necessaria per definire, gestire e sviluppare pacchetti efficaci. Tuttavia, il raggiungimento della possibilità di inserire pacchetti dovrebbe essere l'obiettivo finale per quasi tutte le organizzazioni Salesforce.

È possibile creare pacchetti nelle soluzioni Salesforce concentrandosi sull'accoppiamento flessibile e sulla gestione delle dipendenze.

### Accoppiamento allentato

In un sistema con accoppiamento sciolto, i singoli pezzi non sono strettamente legati tra loro. Molti dei vantaggi di un sistema componibile derivano dall'accoppiamento flessibile. Nei sistemi inseribili in pacchetti, ottenere un accoppiamento flessibile tra i pacchetti (e installare le organizzazioni) consentirà di avere pacchetti ben definiti e cicli di sviluppo più produttivi per i team che utilizzano i pacchetti.

In Salesforce Platform è possibile creare pacchetti [strettamente legati a](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm) una determinata organizzazione. Questa funzionalità è utile per definire le unità funzionali e sperimentare una corretta [separazione delle preoccupazioni](/docs/architect/it-it/well-architected/guide/composable#separazione-delle-preoccupazioni) nell'organizzazione, man mano che si procede nella maturità dei pacchetti. Se si sceglie questo approccio, tuttavia, si noteranno alcuni dei vantaggi dei metadati realmente inseribili in pacchetti, tra cui lo sviluppo basato sulla fonte, la possibilità di utilizzare il controllo delle versioni e la stabilità degli artefatti. Al contrario, probabilmente continuerai a sperimentare gli svantaggi di un sistema strettamente accoppiato, tra cui:

- Singoli punti di errore che causano interruzioni e problemi di prestazioni
- Implementazioni lente e imprevedibili
- Cicli di debug e risoluzione dei problemi difficili e complessi
- Problemi di [scala](/docs/architect/it-it/well-architected/guide/reliable#scalabilità) e [prestazioni](/docs/architect/it-it/well-architected/guide/reliable#prestazioni)

L'obiettivo finale di qualsiasi sistema Salesforce inseribile in pacchetti è costituito da pacchetti vagamente accoppiati.

Considerare quanto segue quando si esamina la separazione dei metadati Salesforce in pacchetti efficaci:

- **Quali personalizzazioni sono dati e quali metadati**. Quando si tratta di inseribilità in pacchetti, Salesforce Platform tratta i dati e i metadati in modo molto diverso. È importante capire quali funzioni dell'organizzazione sono [metadati o dati](/docs/architect/it-it/fundamentals/guide/architecture-basics#metadati-e-dati). Non è possibile includere dati in alcuna unità inserita in un pacchetto. Quando si decide da dove iniziare ad astrarre le funzionalità in un'unità inserita in un pacchetto, i team dovranno decidere se le personalizzazioni memorizzate come dati devono essere escluse completamente dal pacchetto o reinserite in un'implementazione basata sui metadati.
- **In che modo la creazione di pacchetti avrà effetto sui team**. Una realtà logistica del packaging Salesforce è che gran parte del lavoro di produzione e rilascio di una versione del pacchetto richiede competenza con le tecnologie Salesforce CLI e/o CI/CD. Ciò significa che le personalizzazioni a basso codice e a livello di programmazione richiederanno tempo e attenzione da parte di qualcuno in grado di lavorare con la tecnologia DevOps correlata ai pacchetti. A seconda di come il team gestisce la consegna delle funzioni, l'adozione dei pacchetti può causare rallentamenti o blocchi significativi ai diversi team di un'organizzazione. Sarà necessario identificare se i team saranno in grado di gestire la consegna delle funzioni tramite pacchetti ed elaborare un piano per risolvere eventuali lacune di competenze o di personale. Le soluzioni possono includere l'adozione di programmi abbinati o l'implementazione di processi CI/CD per gli ambienti di sviluppo.
- **Come il packaging cambierà le strategie ambientali**. In un ciclo di vita di sviluppo basato su pacchetto, il lavoro iniziale dovrebbe essere eseguito nelle [organizzazioni vuote](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org). Questi ambienti di sviluppo temporanei basati sulla fonte consentono cicli più rapidi e iterativi. Supportano inoltre controlli di accesso all'ambiente più granulari per i team di sviluppo e un maggiore isolamento dalla produzione. Maggiore è il numero di dipendenze dei pacchetti dai metadati o dai dati non inseriti in pacchetti che esistono solo in un ambiente Sandbox o di produzione, minore è la probabilità che i team siano in grado di utilizzare effettivamente le organizzazioni vuote. È possibile [abilitare il tracciamento sorgente nei Sandbox](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm) per tenere conto degli schemi di sviluppo basati sulla fonte negli ambienti delle organizzazioni non vuote, ma i team di sviluppo non trarranno vantaggio dalla velocità e dalla velocità iterativa delle organizzazioni vuote.
- **Come le versioni del pacchetto sono correlate ai rilasci**. Pianificare la frequenza e la fase di sviluppo del controllo delle versioni dei pacchetti. Le richieste di versione del pacchetto sono limitate (per organizzazione) su base continuativa di 24 ore. Come procedura consigliata in generale, eseguire la versione di un pacchetto solo quando si è certi che non sia necessario modificare alcun contenuto del pacchetto. L'ideale è eseguire il provisioning delle versioni del pacchetto al termine dei processi di controllo della qualità. Non consentire ai team di sviluppo di utilizzare l'esito positivo o negativo delle richieste di creazione di pacchetti come "test" della qualità dei confini dei pacchetti. Esistono modi per eseguire questa operazione senza tentare di eseguire la versione di un artefatto del pacchetto.
- **Quello che dovrebbe supportare l'end-state ideale**. La strategia di creazione pacchetti ideale consente rilasci Salesforce controllati e stabili che possono essere sviluppati e consegnati rapidamente. Definire troppi pacchetti nell'organizzazione può generare nuovi tipi di complessità e colli di bottiglia per i team di sviluppo. Un'organizzazione eccessivamente modulare può anche causare rilasci lenti e difficili. Iniziare creando e rilasciando alcune versioni di un singolo pacchetto significativo. Derivare i pacchetti di follow-on in modo incrementale. Smettere di introdurre pacchetti quando si dispone di una cadenza di rilascio adatta alla propria azienda. Eseguire il refactoring dei pacchetti nel tempo, se le esigenze aziendali cambiano o se la qualità del rilascio diminuisce. Lo stato finale ideale del pacchetto è soggettivo.

Indipendentemente da come si decide di definire i pacchetti, la versione di un pacchetto vagamente accoppiato verrà eseguita correttamente solo tramite un'efficace [gestione delle dipendenze](/docs/architect/it-it/well-architected/guide/composable#gestione-delle-dipendenze).

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/composable#pattern-di-inseribilità-in-pacchetti-e-anti-pattern) riportato di seguito mostra l'aspetto corretto (e scadente) dell'accoppiamento sciolto per gli imballaggi Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce che consentono di creare pacchetti più completi, vedere [Strumenti pertinenti per](/docs/architect/it-it/well-architected/guide/composable#strumenti-rilevanti-per-i-compositi) la composizione.

### Gestione delle dipendenze

Nel contesto di una soluzione Salesforce, per gestione delle dipendenze si intende l'identificazione e la strutturazione delle relazioni tra i metadati dei pacchetti e i metadati delle organizzazioni in cui verranno installati. La gestione delle dipendenze è una parte fondamentale dello sviluppo di artefatti di pacchetti stabili.

Le dipendenze possono essere in contrasto con gli sforzi per creare unità funzionali perfettamente separate e [accoppiate liberamente](/docs/architect/it-it/well-architected/guide/composable#accoppiamento-allentato). In uno stato ingegneristico ideale, un sistema vagamente accoppiato non ha dipendenze tra le unità. Nel mondo reale, tuttavia, eliminare tutte le dipendenze non è pratico.

Spesso, l'equilibrio tra rendere i sistemi [leggibili](/docs/architect/it-it/well-architected/guide/intentional#leggibilità) e utilizzare [unità funzionali](/docs/architect/it-it/well-architected/guide/composable#unità-funzionali) adatte alle aziende richiede un compromesso in termini di perfetto isolamento tra le unità di un sistema. Più pragmaticamente, i servizi di base forniti dalle [funzionalità standard](/docs/architect/it-it/well-architected/guide/intentional#funzionalità-standard-e-personalizzata) di Salesforce Platform creano dipendenze chiave positive per qualsiasi soluzione Salesforce. Molti vantaggi di scalabilità, prestazioni e sicurezza incorporati derivano dalla profondità con cui sono integrati nella piattaforma. Quando si progettano soluzioni Salesforce inseribili in pacchetti, è importante ricordare che le dipendenze dei pacchetti non sono intrinsecamente negative. Una cattiva gestione delle dipendenze _è_ negativa.

Un'efficace gestione delle dipendenze con i pacchetti Salesforce consente ai team di sviluppo e manutenzione di:

- Integrazione più rapida e con accesso limitato all'ambiente nei nuovi progetti
- Sviluppare e testare rapidamente le modifiche
- Comprendere in che modo le funzionalità complesse devono essere fornite in impegni più piccoli e specifici
- Controllare le cadenze dei rilasci e ridurre le finestre di manutenzione/disattivazione dei rilasci del sistema
- Ritirare in modo prevedibile le modifiche avverse in qualsiasi ambiente

Le tecniche per la gestione delle dipendenze con Salesforce sono abbastanza semplici:

- Utilizzare [messaggistica ed eventing](/docs/architect/it-it/well-architected/guide/composable#messaggistica-ed-eventi) per gestire agevoli passaggi di informazioni stateful o stateless tra i componenti.
- Utilizzare i tipi di metadati personalizzati per fornire informazioni dinamiche in fase di esecuzione e per supportare gli schemi di iniezione delle dipendenze.
- Fai usare agli sviluppatori Apex [classi astratte o virtuali](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm).

Alla fine, sarà necessario decidere gli schemi di progettazione consentiti nell'organizzazione durante lo sviluppo dichiarativo e programmatico. Le considerazioni più importanti (a livello architettonico) sono definire dove si desidera aggiungere più complessità ingegneristica per avere meno dipendenze e dove è necessario tollerare più dipendenze per semplificare i flussi di lavoro del generatore di app.

Quando si creano strategie di gestione delle dipendenze nei pacchetti, tenere presenti i due principi di organizzazione principali per le unità pacchetto: orizzontale e verticale.

- **Confini orizzontali**. Nei paradigmi orizzontali, le funzionalità che potrebbero essere necessarie a più di un pacchetto vengono astratte in un livello orizzontale. I livelli orizzontali diventano quindi l'origine delle funzionalità comuni e vi si accede tramite una dipendenza dichiarata. La riduzione al minimo delle funzionalità ridondanti tra i pacchetti è preferibile alla riduzione al minimo delle dipendenze.
- **Confini verticali**. I paradigmi verticali massimizzano l'isolamento e l'accoppiamento flessibile tra le parti del sistema. Le funzionalità condivise sono limitate e un lavoro simile potrebbe essere visualizzato tra le unità. Le dipendenze sono strettamente limitate, al fine di massimizzare l'isolamento tra le unità del pacchetto.

Tenere presente che non si tratta di una o più decisioni. È possibile combinare paradigmi verticali e orizzontali in base alle esigenze. Spesso, il modo più rapido per iniziare con un pacchetto è creare livelli di servizio orizzontali. Man mano che la scala e la complessità dell'adozione del pacchetto aumentano, l'astrazione di più unità verticali contribuirà a semplificare i processi di impostazione dell'ambiente complessi o l'orientamento degli sviluppatori.

Un sistema con due unità funzionali (A e B), ad esempio, può essere strutturato con dipendenze del pacchetto disposte in paradigmi ibridi verticali, orizzontali e verticali-orizzontali.

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-vertical-horizontal-slices.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-vertical-horizontal-slices.jpeg" alt="Questo diagramma mostra due pacchetti, A e B, creati per non avere dipendenze condivise (fetta verticale), creati per avere molti servizi comuni (orizzontale) e un mix di ciascuno (ibrido).">
</a>

Indipendentemente dal paradigma di organizzazione dei pacchetti scelto, è necessario tenere presenti alcuni valori assoluti:

- **Non duplicare i metadati tra i pacchetti**. I metadati necessari per più di un pacchetto devono essere astratti in uno o più pacchetti dichiarati come dipendenze.
- **Utilizzare le dipendenze incorporate dei metadati di Salesforce Platform**. Per i generatori di app, i servizi integrati offerti da Salesforce Platform offrono numerose funzionalità che possono essere configurate rapidamente. Molti di questi servizi hanno dipendenze incorporate che li rendono difficili da astrarre in unità funzionali di basso livello. Per un determinato tipo di metadati, è necessario capire dove rientra lo [spettro delle dipendenze incorporate](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail) e utilizzare questa comprensione per [definire le catene](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2) di dipendenze del pacchetto. Non iniziare l'adozione dei pacchetti tentando di forzare l'accoppiamento in una parte della funzionalità standard della piattaforma con numerose dipendenze incorporate. Aggiungerà complessità (non valore) man mano che si raggiungono le funzionalità di ordine superiore. È anche un altro modo per cadere in [anti-modelli](/docs/architect/it-it/well-architected/guide/intentional#modelli-di-manutenibilità-e-anti-schemi) [standard e personalizzati](/docs/architect/it-it/well-architected/guide/intentional#funzionalità-standard-e-personalizzata). Inserire i metadati nei pacchetti dal basso (meno dipendenze) verso l'alto ed eseguire l'iterazione nel tempo.
- **Attenzione alle catene di dipendenza**. Evitare di creare catene di dipendenze dei pacchetti che richiedono agli sviluppatori di suddividere le modifiche in molti pacchetti diversi contemporaneamente.
- **Pensare a cosa ha senso per il controllo sorgente**. Esistono due modi di base per gestire i pacchetti nel controllo sorgente. Il primo è un singolo _monorepo_ con pacchetti isolati all'interno di cartelle. Il secondo è costituito da più repository con pacchetti isolati nei propri repository. La gestione di ogni tipo di strategia di origine, a lungo termine, presenta delle complessità. In termini di onboarding degli sviluppatori, i confini verticali sono più efficienti in più paradigmi di repository. I confini orizzontali sono più comprensibili in un monorepo. Anche in questo caso, è possibile combinare le strategie man mano che l'architettura matura.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/composable#pattern-di-inseribilità-in-pacchetti-e-anti-pattern) riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione delle dipendenze con i pacchetti Salesforce. È possibile utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione delle dipendenze, vedere [Strumenti pertinenti per](/docs/architect/it-it/well-architected/guide/composable#strumenti-rilevanti-per-i-compositi) la composizione.

### Pattern di inseribilità in pacchetti e Anti-pattern

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri modelli per la possibilità di inserire pacchetti in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/adaptable-packageability).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="5"><b>Attacco sciolto</b></td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Le convenzioni di denominazione indicano come indicare le unità pacchetto
                <br> - E' possibile cercare e trovare un elenco di tutte le unità di pacchetto attualmente definite (e relative convenzioni di denominazione)
                <br> - Esistono standard per proporre aggiunte o modifiche di unità pacchetto
                <br> - (Facoltativo) Tutti i casi d'uso approvati per le impostazioni personalizzate sono chiaramente elencati (se presenti)
            </td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Gli standard di progettazione non esistono o non riguardano le unità pacchetto e i casi d'uso
            </td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
                <br> - I tipi di metadati personalizzati forniscono informazioni dinamiche in fase di esecuzione per il codice e le personalizzazioni dichiarative
                <br> - Non esistono impostazioni personalizzate o esistono poche impostazioni personalizzate e nessuna è correlata alle funzionalità del pacchetto
                <br> - Non esistono oggetti personalizzati per fornire informazioni dinamiche in fase di esecuzione per il codice o le personalizzazioni dichiarative
            </td>
            <td><b>Nella propria organizzazione:</b>
                <br> - Vengono utilizzate le impostazioni personalizzate
                <br> - Gli oggetti personalizzati esistono per fornire informazioni dinamiche in fase di esecuzione per il codice o le personalizzazioni dichiarative
                <br> I tipi di metadati personalizzati non vengono utilizzati (o non vengono utilizzati in modo coerente) per fornire informazioni dinamiche in fase di esecuzione per il codice e le personalizzazioni dichiarative
            </td>
        </tr>
        <tr>
            <td><b>In Apex:</b>
                <br> - I servizi comuni e il codice boilerplate sono definiti utilizzando classi Apex astratte o virtuali
                <br> - I metodi dipendenti dalle informazioni dinamiche in fase di esecuzione fanno riferimento ai tipi di metadati personalizzati appropriati
            </td>
            <td><b>In Apex:</b>
                <br> - I servizi comuni e il codice boilerplate non sono facilmente distinguibili dalle altre classi
                <br> - I riferimenti interni nelle classi e nei metodi sono difficili da seguire e non sono coerenti in tutta la codebase
                <br> - I metodi non utilizzano un approccio coerente per accedere alle informazioni dinamiche in fase di esecuzione o i metodi eseguono query sugli oggetti personalizzati per ottenere informazioni sul comportamento in fase di esecuzione o riferimenti al codice per le impostazioni personalizzate
            </td>
        </tr>
        <tr>
            <td><b>Negli ambienti di controllo sorgente e sviluppo:</b>
                <br> - i file package.xml vengono visualizzati solo nei manifesti dei progetti in fase iniziale o proof of concept
            </td>
            <td><b>Negli ambienti di controllo sorgente e sviluppo:</b>
                <br> - i file package.xml vengono utilizzati per controllare le distribuzioni dei metadati
            </td>
        </tr>
        <tr>
            <td><b>In pacchetti:</b>
                <br> - I pacchetti sbloccati dipendenti dall'organizzazione vengono utilizzati solo per gli esperimenti in fase iniziale o proof of concept
                <br> - Non sono definiti pacchetti non gestiti in produzione o Sandbox
            </td>
            <td><b>In pacchetti:</b>
                <br> - Tutti i pacchetti sono pacchetti sbloccati dipendenti dall'organizzazione
                <br> - I pacchetti non gestiti sono definiti in produzione o Sandbox
            </td>
        </tr>
         <tr>
            <td rowspan="4"><b>Gestione delle dipendenze</b></td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Esistono standard per dichiarare le dipendenze
                <br> - Esistono standard per l'introduzione o la modifica delle dipendenze
            </td>
            <td><b>Negli standard di progettazione:</b>
                <br> - Gli standard di progettazione non esistono o non riguardano come dichiarare le dipendenze
            </td>
        </tr>
        <tr>
            <td><b>Nel controllo sorgente:</b>
                <br> - Le versioni dei pacchetti sbloccati utilizzano l'aliasing (<code>LATEST</code>) per dichiarare le dipendenze nei manifesti <code>sfdx-project.json</code>
                <br> - Gli sviluppatori possono creare organizzazioni vuote e distribuire correttamente i metadati del pacchetto dal controllo sorgente
            </td>
            <td><b>Nel controllo sorgente:</b>
                <br> - Le versioni dei pacchetti sbloccati sono dichiarate esplicitamente (nessun aliasing <code>PIÙ RECENTE</code>) nei manifesti <code>sfdx-project.json</code>
                <br> - Gli sviluppatori non possono lavorare correttamente con le organizzazioni vuote utilizzando il controllo sorgente
            </td>
        </tr>
        <tr>
            <td><b>Nei pacchetti:</b>
                <br> - Nessun metadati viene duplicato tra i pacchetti
                <br> - Per lo sviluppo dei pacchetti, tutto il lavoro di sviluppo iniziale avviene nelle organizzazioni vuote
            </td>
            <td><b>Nei pacchetti:</b>
                <br> - Le dipendenze vengono aggirate duplicando i metadati in pacchetti diversi
                <br> - Lo sviluppo precoce dei pacchetti avviene nei Sandbox per sviluppatori o lo sviluppo precoce dei pacchetti non può avvenire nelle organizzazioni vuote
            </td>
        </tr>
        <tr>
            <td colspan="2">Vedere anche: <a href="/docs/architect/it-it/well-architected/guide/composable#accoppiamento-allentato">Attacco sciolto</a></td>
        </tr>
    </tbody>
</table>

## Strumenti rilevanti per i compositi

<table class="tools-table"><tbody><tr><th>Strumento</th><th>Descrizione</th><th>Separazione delle preoccupazioni</th><th>Interoperabilità</th><th>Inserimento in pacchetti</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_rest.htm">Servizi Web REST Apex</a></td><td>Esporre le classi e i metodi Apex ad applicazioni esterne tramite REST</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_web_services.htm#apex_web_services">Servizi Web Apex SOAP</a></td><td>Esporre le classi e i metodi Apex ad applicazioni esterne tramite SOAP</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><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>Pubblicare le modifiche nei record Salesforce</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.custommetadatatypes_overview.htm&language=en_US&r=https%3A%2F%2Fwww.google.com%2F&type=5">Tipi di metadati personalizzati</a></td><td>Definire funzionalità riutilizzabili, personalizzabili e inseribili in pacchetti</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_decorators">Decoratori</a></td><td>Esporre funzioni o proprietà pubblicamente come api</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_devhub.htm">Dev Hub</a></td><td>Gestire le organizzazioni vuote, i pacchetti di seconda generazione e le funzioni Einstein.</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/generic_streaming_intro.htm">Eventi generici (legacy)*</a></td><td>Inviare eventi personalizzati non legati alle modifiche dei dati Salesforce</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.data_ui_api">Servizio dati Lightning</a></td><td>Inserimento nella cache e condivisione dei dati tra i componenti</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_intro.htm">Metadata API</a></td><td>Distribuzione di personalizzazioni tra gli ambienti Salesforce</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_supported_mdapi_types.htm">Rapporto copertura metadati</a></td><td>Determinare la copertura dei metadati supportata in diversi canali </td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://docs.mulesoft.com/composer/ms_composer_overview">MuleSoft Composer</a></td><td>Creare l'automazione dei processi per i dati utilizzando clic anziché codice</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><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>Inviare messaggi agli endpoint esterni quando i valori dei campi vengono aggiornati</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><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>Inviare messaggi sicuri e scalabili contenenti dati sugli eventi quasi in tempo reale</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/blogs/2021/07/pub-sub-api-building-event-driven-integrations-just-got-even-easier">Pub/Sub API</a></td><td>Abbonamento agli eventi piattaforma, Acquisizione dati di modifica o Monitoraggio evento in tempo reale</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/pushtopic_events_intro.htm">Eventi PushTopic (legacy)*</a></td><td>Invia e ricevi notifiche di modifica corrispondenti a una query SOQL definita dall'utente</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/tools/sfdxcli">Salesforce CLI</a></td><td>Sviluppare e creare automazione quando si lavora con l'organizzazione Salesforce</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/it-it/reference-diagrams/guide/introduction">Grafici Salesforce</a></td><td>Creare diagrammi per mostrare le funzionalità aziendali e i dettagli tecnici</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-expanded">Estensioni Salesforce per Visual Studio Code (espanse)</a></td><td>Estensioni ufficiali di VS Code per lo sviluppo Salesforce</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs.htm">Organizzazioni vuote</a></td><td>Distribuzione del codice e dei metadati Salesforce a un'organizzazione usa e getta</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp.htm">Pacchetti gestiti di seconda generazione</a></td><td>Sviluppo e distribuzione di app per AppExchange</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_tooling.meta/api_tooling/intro_tasks.htm">API Tooling</a></td><td>Creare app o strumenti di sviluppo personalizzati per le applicazioni Lightning Platform</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm">Pacchetti sbloccati</a></td><td>Organizzare i metadati, inserire in un pacchetto un'app o estendere un'app AppExchange</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr>
<td colspan="5">*Salesforce continuerà a supportare PushTopic ed Eventi generici nell'ambito delle attuali funzionalità, ma non prevede di effettuare ulteriori investimenti in questa tecnologia.</td>
</tr>
</table>

## Risorse rilevanti per le composizioni

<table class="tools-table"><tbody><tr><th>Risorsa</th><th>Descrizione</th><th>Separazione delle preoccupazioni</th><th>Interoperabilità</th><th>Inserimento in pacchetti</th></tr>
<tr><td><a href="https://blogs.mulesoft.com/api-integration/strategy/a-primitive-look-at-digital-integration/">Uno sguardo primitivo all'integrazione digitale</a></td><td>Sviluppare un linguaggio comune per i concetti di connettività</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/p/cd4b7ebe926b">Applicazione della progettazione basata sul dominio con Salesforce</a></td><td>Orientare le soluzioni in base alle funzionalità aziendali</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_best_practices.htm">Procedure consigliate per i pacchetti di seconda generazione</a></td><td>Informazioni sugli schemi e le pratiche di creazione di pacchetti 2GP</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_dev.meta/sfdx_dev/packaging_packageable_components.htm">Componenti disponibili nei pacchetti gestiti</a></td><td>Informazioni sui componenti dei metadati del pacchetto gestito</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/design-standards-template">Modello Design Standards (Standard di progettazione)</a></td><td>Creare standard di progettazione per l'organizzazione</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/it-it/decision-guides/guide/event-driven">Guida alle decisioni sull'architettura basata sugli eventi</a></td><td>Confronto di schemi e strumenti di architettura basati sugli eventi</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/events_anti_patterns.htm">Eventi Anti-Patterns</a></td><td>Identificare gli anti-schemi da evitare quando si utilizzano gli eventi</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://blogs.mulesoft.com/dev-guides/design-message-driven-and-event-driven-apis/">Come progettare API basate sui messaggi e sugli eventi</a></td><td>Leggere le differenze in una guida per lo sviluppo di MuleSoft</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/en/content/learn/modules/jobs-to-be-done-framework-for-designers/learn-about-the-jobs-to-be-done-framework">Informazioni sul framework Processi da eseguire</a></td><td>Esplorazione di JTBD su Trailhead</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/managing-global-state.html">Gestione dello stato globale in B2C Commerce</a></td><td>Passare facilmente i dati tra i componenti per mantenere lo stato</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/overview/">Linee guida di Messaggistica</a></td><td>Comunicare informazioni pertinenti e creare momenti di piacere</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/types/">Tipi di messaggistica</a></td><td>Comprendere i diversi tipi di messaggistica in base alla natura dell'interazione dell'utente</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.api_meta.meta/api_meta/meta_types_list.htm">Tipi di metadati</a></td><td>Informazioni sui diversi tipi di metadati nell'organizzazione Salesforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.salesforce_app_enable_push_notifications.htm&type=5">Tipi di notifiche dell'app mobile</a></td><td>Informazioni sui tipi di notifiche per le app mobili Salesforce</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_visualforce_best_practices.meta/salesforce_visualforce_best_practices/pages_best_practices_perf_code_view_state.htm">Ottimizzazione dello stato visualizzazione</a></td><td>Mantenere lo stato in una pagina Visualforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm">Salesforce Developer Experience (DX)</a></td><td>Gestione e sviluppo di app in Lightning Platform</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm">Tipi di metadati non supportati</a></td><td>Identificare i componenti non disponibili nell'API dei metadati</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
</table>

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.

<!-- document id=5e322eb13b3d604e32c62c951837ae81f4f033f097f6a5468ea5106b01ca7af4 url=/architect/next/it-it/well-architected/guides/compliant.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

Dichiarazione di non responsabilità: Questo documento è distribuito esclusivamente a scopo informativo; non costituisce consulenza legale e non deve essere utilizzato come tale.

## Introduzione

Un sistema conforme è progettato in modo da rispettare le linee guida legali ed etiche applicabili e la sua osservanza è misurabile e controllabile. Ciò è dimostrato limitando l'accesso ai dati alle persone autorizzate per gli scopi previsti, rispettando le normative legali pertinenti e garantendo un accesso equo per tutti gli utenti autorizzati.

Le misure proattive sono essenziali per prevenire e rilevare le violazioni della conformità. Un approccio reattivo ai regolamenti e agli standard può erodere il Customer Trust, in particolare se i cambiamenti avvengono solo in risposta alle richieste o ai reclami dei clienti. Tali reclami possono danneggiare il marchio e la reputazione dell'organizzazione e causare perdite di reddito.

È possibile garantire la conformità delle soluzioni Salesforce concentrandosi su tre abitudini chiave: osservanza della legge, standard etici e accessibilità.

## Aderenza giuridica

Aderire ai mandati legali implica seguire le leggi regionali e le normative di settore. In qualità di architetto, una volta che il team legale dell'organizzazione o un auditor esterno ha determinato i requisiti di conformità specifici, è responsabilità dell'utente comprendere tali requisiti e identificare e segnalare in modo proattivo potenziali problemi di conformità nelle prime fasi del processo di progettazione per ridurre il rischio di multe e cause legali.

È possibile migliorare l'osservanza della legge nelle soluzioni Salesforce tramite la privacy dei dati e la localizzazione.

### Privacy dei dati

La privacy dei dati riguarda il modo in cui la soluzione raccoglie, archivia ed elabora le informazioni personali (PII), oltre ai regolamenti pertinenti e alla capacità di una persona di controllare l'accesso ai propri dati personali. L'osservanza di questi regolamenti può richiedere aggiornamenti del [modello di condivisione e visibilità](/docs/architect/it-it/well-architected/guide/secure#condivisione-e-visibilità), modifiche alle configurazioni dei metadati per limitare l'accesso, l'implementazione della crittografia a livello di campo, il monitoraggio di registri ed eventi, la creazione di automazioni per esportare o eliminare i dati di un cliente su richiesta e lo sviluppo di policy che disciplinano l'utilizzo dei dati nelle automazioni e nell'intelligenza artificiale.

Il mancato rispetto dei regolamenti sulla privacy dei dati può portare a multe e azioni legali sostanziali. Inoltre, l'esposizione dei dati degli stakeholder a causa di controlli insufficienti o di una violazione della sicurezza può causare perdite di reddito ed eroso il Customer Trust.

Considerare quanto segue quando si lavora per garantire il rispetto dei requisiti di privacy dei dati:

- **Consultare esperti normativi**. Collaborare con il proprio team legale o con un auditor esterno per valutare i regolamenti di conformità specifici del settore applicabili alla propria azienda. Ad esempio, le aziende sanitarie devono aderire all'HIPAA (Health Insurance Portability and Accountability Act).
- **Classificare i dati**. La classificazione dei dati aiuta i team di progetto a capire quando i vari elementi di dati dell'organizzazione possono o meno essere utilizzati. Consente inoltre all'azienda di [creare rapporti](https://help.salesforce.com/s/articleView?id=sf.data_classification_report.htm&type=5) sulla conformità delle policy di gestione dei dati. Classificare i dati nell'organizzazione specificando i regolamenti applicabili [a livello di](https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5) campo per individuare il titolare, il livello di riservatezza e se il campo è attualmente in uso.

Durante il processo di classificazione, è importante pensare a come potrebbero essere utilizzati tutti i campi del modello di dati e non solo quelli che a prima vista sembrano sensibili. In alcuni casi, i campi che sembrano insignificanti possono diventare sensibili se utilizzati nel contesto errato. Ad esempio, i codici postali negli Stati Uniti possono essere un proxy per la razza e quindi se utilizzati in modalità predittiva potrebbero involontariamente aggiungere distorsioni o causare danni. I nomi possono essere utilizzati per prevedere sesso, paese di origine, razza, religione e persino età, poiché i nomi popolari tendono a cambiare di generazione in generazione. Includere classificazioni di tutti i campi e una descrizione chiara di come le funzionalità di intelligenza artificiale associate li utilizzeranno nella documentazione.

Utilizzare strumenti come [Data Detect](https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5) per identificare i dati sensibili all'interno dell'organizzazione. Se i campi sono classificati come sensibili o se si sa quali campi sono sensibili, strumenti come Selezione contenuto Einstein identificheranno anche i campi che sono [strettamente correlati](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.mc_pb_manage_einstein_content_selection_attributes_and_bias.htm) e quindi possono essere proxy per quei campi sensibili.

- **Stabilire procedure consigliate per la governance dei dati**. Assicurarsi che tutta la documentazione pertinente sia completa, aggiornata e archiviata centralmente in modo che sia facilmente disponibile per tutti gli stakeholder. Ciò aggiungerà un livello di protezione per l'organizzazione contro la responsabilità legale, mantenendo al contempo Trust con i clienti e i partner. Ad esempio, un dizionario dei dati documenta le definizioni e le classificazioni a livello di oggetto e di campo per tutti gli elementi di dati che verranno memorizzati nel sistema, i documenti di progettazione contengono dettagli su eventuali automazioni create per conformarsi ai regolamenti e una matrice di protezione definisce i dati a cui gli utenti hanno accesso. In modo fondamentale, questa documentazione completa diventa la fonte autorevole per la generazione aumentata di recupero (RAG), radicando direttamente sistemi agentici come Agentforce in un contesto operativo verificato e conforme, evitando così output incoerenti o allucinati.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/compliant#modelli-di-osservanza-giuridica-e-anti-schemi) riportato di seguito mostra come si presenta una corretta (e scarsa) gestione della privacy dei dati all'interno di una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la privacy dei dati, vedere [Tools Relevant to Be Compliant](/docs/architect/it-it/well-architected/guide/compliant#strumenti-pertinenti-per-essere-conformi) (Strumenti pertinenti per essere conformi).

### Localizzazione

La localizzazione consiste nell'adattare un prodotto in modo che sia allineato a una lingua, una cultura e un'estetica locale specifiche. Ciò include anche l'adeguamento alle normative specifiche delle regioni, ad esempio le leggi sulla residenza dei dati, che possono variare in modo significativo da un paese all'altro e persino dai comuni. Di conseguenza, i sistemi potrebbero dover soddisfare più quadri normativi, a seconda di dove si trovano i clienti e di come l'azienda introduce i propri prodotti e servizi sul mercato.

Oltre alle variazioni delle leggi sulla privacy dei dati, molti paesi stanno anche emanando leggi sulla residenza dei dati. Come minimo, le leggi sulla residenza dei dati richiedono che tutti i dati relativi ai cittadini di un paese siano archiviati fisicamente entro i confini di quel paese. Alcune leggi si spingono oltre, richiedendo l'archiviazione locale di tutti i dati (inclusi i dati su prodotti e servizi) potenzialmente accessibili dai cittadini. In alcuni casi, i regolamenti richiedono che i dati dei cittadini siano conservati solo da altri cittadini di quel paese o regione.

Il mancato rispetto potrebbe portare a ingenti multe e cause legali. Ad esempio, le autorità dell'UE per la protezione dei dati possono infliggere ammende fino a 20 milioni di euro o al 4% del reddito globale, a seconda del valore più elevato. Negli Stati Uniti, l'ufficio del procuratore generale della California può richiedere sanzioni significative sia per violazioni intenzionali che non intenzionali.

Considerare quanto segue per gestire meglio i requisiti di localizzazione e residenza dei dati:

- **Consultare esperti normativi**. Collaborare con il proprio team legale o con un auditor esterno per valutare le leggi nelle regioni in cui opera l'azienda e determinare quali sono applicabili. Ad esempio, il Regolamento generale sulla protezione dei dati (GDPR) e la Legge AI dell'UE e il California Consumer Privacy Act (CCPA).
- **Memorizzare dati localmente**. Assicurarsi che i dati specifici di una regione rimangano in un'organizzazione separata. Utilizzare [Hyperforce](https://help.salesforce.com/s/articleView?id=000356459&type=1), il substrato del cloud pubblico di Salesforce per ospitare l'organizzazione in una regione specifica.
- **Evitare repliche dati**. Archiviazione dati locale significa che i dati sono memorizzati _a riposo_ nel paese; naturalmente, possono sorgere problemi di conformità quando i dati vengono trasferiti al di fuori del paese tramite interfacce standard. Ad esempio, la creazione e la gestione di record localmente ma la loro replica in un data warehouse in un altro paese per la creazione di rapporti violerà le leggi sulla residenza dei dati. Se si lavora per un'azienda globale con requisiti di reporting interregionale, aggregare prima i dati all'interno del paese in cui sono archiviati, rimuovere tutte le informazioni che potrebbero identificare i cittadini associati e quindi replicare solo le informazioni aggregate. Questo approccio può richiedere la comunicazione delle limitazioni dei rapporti agli stakeholder in modo che sappiano che, sebbene saranno disponibili dati più granulari a livello nazionale o regionale, saranno disponibili solo dati di riepilogo a livello globale.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/compliant#modelli-di-osservanza-giuridica-e-anti-schemi) riportato di seguito mostra l'aspetto corretto (e inadeguato) dei processi di localizzazione e residenza dei dati all'interno di una soluzione Salesforce. Utilizzare questi elementi per convalidare i progetti prima di creare o identificare le aree che devono essere rifattorizzate.

Per ulteriori informazioni sugli strumenti Salesforce per la localizzazione, vedere [Tools Relevant to Be Compliant](/docs/architect/it-it/well-architected/guide/compliant#strumenti-pertinenti-per-essere-conformi) (Strumenti pertinenti per essere conformi).

### Modelli di osservanza giuridica e anti-schemi

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri modelli per l'osservanza della legge in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-legal-adherence).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="2"><b>Privacy dei dati</b></td>
            <td><b>Nella documentazione:</b>
            <br> - Si dispone di un dizionario dei dati aggiornato contenente nomi, descrizioni e classificazioni a livello di campo
            <br> - Si dispone di una matrice di protezione aggiornata che identifica quali utenti hanno accesso a quali dati
            <br> - Si dispone di documentazione di progettazione aggiornata, inclusi standard e diagrammi per eventuali automazioni create per soddisfare i requisiti normativi</td>
            <td><b>Nella documentazione:</b>
            <br> - Un dizionario dei dati non esiste o non è stato aggiornato
            <br> - La documentazione di condivisione e visibilità non esiste o non è stata aggiornata
            <br> - Gli standard di progettazione, i diagrammi e la documentazione per le automazioni che soddisfano i requisiti normativi non esistono o non sono stati mantenuti aggiornati</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> Tutti gli oggetti e i campi che contengono informazioni sensibili o sono soggetti ai regolamenti sulla privacy dei dati hanno la categorizzazione di conformità, il titolare dei dati, il livello di riservatezza dei dati e l'utilizzo dei campi configurati</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Gli oggetti e i campi che contengono informazioni sensibili o sono soggetti ai regolamenti sulla privacy dei dati mancano della configurazione per la categorizzazione di conformità, il titolare dei dati, il livello di riservatezza dei dati o l'utilizzo dei campi</td>
        </tr>
        <tr>
            <td rowspan="1"><b>Localizzazione</b></td>
            <td><b>Nella documentazione:</b>
            <br> - L'organizzazione ha una strategia che definisce dove verranno archiviati e mantenuti i dati per soddisfare tutti i requisiti di residenza dei dati applicabili
            <br> - Si dispone di una strategia di integrazione che definisce scenari e processi accettabili per la replica dei dati oltre confine
            <br> - Si dispone di una strategia di analisi che definisce il livello di dettaglio che i rapporti e i cruscotti digitali possono contenere a livello regionale, nazionale e globale</td>
            <td><b>Nella documentazione:</b>
            <br> - Non si dispone di una strategia dell'organizzazione o la strategia dell'organizzazione non soddisfa i requisiti di localizzazione dei dati e residenza
            <br> - Non si dispone di una strategia di integrazione o la strategia di integrazione non soddisfa i requisiti di localizzazione dei dati e residenza
            <br> - Non si dispone di una strategia di analisi o la strategia di analisi non soddisfa i requisiti di localizzazione e residenza dei dati</td>
        </tr>
    </tbody>
</table>

## Standard etici

Nei contesti aziendali, gli standard etici sono le linee guida per il modo in cui aziende e individui si comportano da un punto di vista valoriale o morale. In Salesforce, i [nostri valori fondamentali](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values) guidano tutto ciò che facciamo come azienda e come dipendenti. Disponiamo inoltre di un team di [policy sull'uso](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/) che aiuta a garantire che i clienti utilizzino il nostro software in modo etico. La nostra [Acceptable Use Policy (](https://sfdc.co/AUP)AUP) e la [AI Acceptable Use Policy](http://sfdc.co/AI-Policy) (AI AUP) sono un'estensione dei nostri valori fondamentali e aiutano a guidare le nostre decisioni in caso di domande sull'utilizzo.

L'organizzazione può disporre di una serie aggiuntiva di policy che vanno oltre il semplice rispetto delle normative locali. Queste policy possono assumere varie forme, dall'adesione alle normative di altre regioni, al rifiuto di intrattenere rapporti commerciali con determinate organizzazioni o mercati, al monitoraggio delle interazioni dipendenti-clienti per prevenire discriminazioni o comportamenti distorti. Per rispettare queste policy, potrebbe essere necessario aggiornare gli standard di progettazione o la configurazione di sistema come si farebbe per [l'osservanza legale](/docs/architect/it-it/well-architected/guide/compliant#aderenza-giuridica).

Per favorire una maggiore osservanza degli standard etici nelle soluzioni Salesforce, allinearsi alle policy aziendali e valutare l'utilizzo dell'intelligenza artificiale.

### Policy aziendali

Le policy aziendali sono linee guida che definiscono come devono funzionare i vari aspetti dell'azienda (tra cui persone, processi e tecnologia). I clienti preferiscono fare affari con organizzazioni di loro Trust. La maggior parte delle policy aziendali sono progettate in modo da riflettere questo principio. Il Customer Trust si eroderà rapidamente se i sistemi creano esperienze utente non in linea con le policy dichiarate.

Politiche efficaci derivano naturalmente da [una cultura dell'etica](https://www.salesforce.com/blog/new-research-ethical-leadership-business/). Ogni dipendente, dall'ingegneria e progettazione alla scienza dei dati, al marketing e alle vendite, deve essere educato alla propria responsabilità per un uso etico. In tale cultura, i dipendenti vedono chiare strutture di incentivi per premiare il comportamento etico e chiare e coerenti conseguenze per il comportamento non etico.

Considerare quanto segue per assicurarsi che le policy dell'organizzazione si riflettano nei progetti:

- **Siate consapevoli delle conseguenze indesiderate**. In qualità di architetto, è tua responsabilità anticipare i potenziali impatti delle tue soluzioni e come verranno utilizzate. Non cadere nella trappola di considerare o testare solo percorsi felici. Applicare invece la propria esperienza nel testare i casi limite e valutare i compromessi per considerare a fondo le implicazioni etiche delle soluzioni. Pensare a tutti coloro che saranno interessati dal prodotto, soprattutto a coloro che sono sottorappresentati, emarginati o vulnerabili. Valutare la moltitudine di modi in cui qualcuno o qualcosa potrebbe interagire con la soluzione e creare conseguenze indesiderate. Utilizzare il [kit Build With Intention](http://sfdc.co/BuildwithIntention) (Crea con intenzione) per progettare pensando all'inclusione.
- **Integrare l'etica nella policy di utilizzo accettabile della propria azienda**. Collaborare con il proprio team legale o con una terza parte per includere l'etica nella policy di utilizzo accettabile per garantire che l'uso delle soluzioni sia in linea con i valori aziendali. La documentazione deve includere informazioni sui valori e le policy dell'organizzazione supportate dalle soluzioni, siano esse sviluppate con strumenti low-code o pro-code. Pubblicare la policy di utilizzo accettabile per dimostrare il proprio impegno a creare Trust con dipendenti e clienti.
- **Utilizzare linguaggio inclusivo**. Comprendere i diversi modi in cui le persone sperimentano la soluzione e [perfezionare il linguaggio](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/) nell'interfaccia utente, nel codice e nella documentazione per riflettere più accuratamente l'inclusività. Iniziare identificando e rimuovendo prima il linguaggio esclusivo e poi impegnarsi a capire i tipi di abitudini o pratiche che possono portare all'esclusione.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/compliant#modelli-e-anti-schemi-degli-standard-etici) riportato di seguito mostra l'aspetto di una corretta (e scarsa) osservanza delle policy aziendali all'interno di una soluzione Salesforce. Utilizzare questi elementi per convalidare i progetti prima di creare o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti di Salesforce per allineare i progetti alle policy aziendali, vedere [Strumenti pertinenti per essere conformi](/docs/architect/it-it/well-architected/guide/compliant#strumenti-pertinenti-per-essere-conformi).

### Intelligenza artificiale

L'intelligenza artificiale utilizza i sistemi computazionali per eseguire operazioni che normalmente richiedono l'intelligenza umana, come il ragionamento, la percezione e il processo decisionale. Le funzionalità di intelligenza artificiale di Salesforce Platform si estendono alle tecnologie predittive, generative e agentiche, offrendo una suite completa di strumenti per migliorare le esperienze dei clienti e le operazioni aziendali:

- L'**intelligenza artificiale predittiva** analizza i dati storici e prevede gli esiti futuri, ad esempio le tendenze di vendita o l'abbandono dei clienti. Einstein AI offre questi approfondimenti analizzando gli schemi nei dati per fornire consigli e prevedere i risultati aziendali.
- L'**intelligenza artificiale generativa** si concentra sulla creazione di nuovi contenuti sfruttando modelli di lingua di grandi dimensioni. Einstein GPT è un componente centrale che funziona con i dati CRM per generare contenuti personalizzati come email, risposte alle chat e comunicazioni con i clienti.
- **L'intelligenza artificiale** fa un ulteriore passo avanti consentendo agli agenti di ragionare e agire in autonomia per raggiungere un obiettivo specifico. Agentforce è la piattaforma per la creazione di questi agenti intelligenti, che possono automatizzare processi aziendali complessi come la risoluzione dei casi dei clienti o l'ottimizzazione delle campagne di marketing. Questi agenti possono interagire con i dati in tempo reale tramite Data 360 e sfruttare i flussi di lavoro e le API esistenti. Tutte queste funzionalità di intelligenza artificiale sono protette da Einstein Trust Layer, che garantisce un utilizzo etico.

La maggior parte degli algoritmi di base di Einstein AI non sono configurabili, ma per alcune funzioni i clienti potrebbero essere in grado di perfezionare i modelli utilizzando i propri dati come indicato nella documentazione. Inoltre, è possibile basare i modelli AI nel proprio CRM, negli articoli della Knowledge Base e in altri documenti tramite Retrieval Augmented Grounding (RAG) per rendere gli output ancora più precisi per l'organizzazione, i clienti e i casi d'uso. Tuttavia, se i dati sottostanti sono distorti o distorti, anche gli output potrebbero diventare distorti e imprecisi. Un esempio di distorsione è non includere membri di una determinata razza, sesso o etnia nell'elenco dei referenti anche se la base di clienti è varia e include membri di quel gruppo. Per ulteriori informazioni, fare riferimento al [modulo Creazione responsabile di](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence) AI Trailhead di Salesforce, [Understanding Trusted Agentic AI Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai), [AI Ethics Maturity Model](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf), Salesforce’s [Intelligenza artificiale affidabile](https://www.salesforceairesearch.com/trusted-ai), [Responsible Generative AI Guidelines](https://www.salesforce.com/news/stories/generative-ai-guidelines/) e [Responsible Agentic AI Guidelines](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/).

Non tenere conto dei regolamenti legali applicabili e degli standard etici della propria azienda può causare distorsioni all'interno dell'intelligenza artificiale, con conseguenti cause legali, perdita di reddito, problemi di customer Trust e danni all'immagine pubblica della società.

Ecco cosa considerare per un uso responsabile ed etico dell'intelligenza artificiale:

- **Esaminare le serie di dati e i documenti**. Assicurarsi che le serie di dati siano rappresentative di tutti gli effetti delle funzionalità di intelligenza artificiale. Ciò può richiedere una ricerca degli utenti per capire chi sono e confermare che i dati li rappresentino tutti in modo preciso per ridurre eventuali distorsioni potenziali. È inoltre fondamentale rivedere i dati CRM, gli articoli Knowledge e qualsiasi altra documentazione basata sui modelli per assicurarsi che siano aggiornati, precisi e completi. Basare i modelli su una grande quantità di dati non è utile e può causare allucinazioni se i dati sono vecchi, contraddittori o incompleti.
- **[Tieni un essere umano al timone](https://www.salesforce.com/news/stories/human-at-the-helm/)**. Non si desidera che gli esseri umani intervengano in ogni singola interazione di intelligenza artificiale, ma consentire ai dipendenti di concentrarsi sugli elementi di giudizio elevato che richiedono più attenzione. Testare i sistemi di intelligenza artificiale finché non si è certi che possano assumersi maggiori responsabilità e monitorare i risultati per assicurarsi che continuino a funzionare in modo preciso ed efficace. Assicurarsi inoltre che i sistemi di intelligenza artificiale o gli agenti ricevano istruzioni per l'inoltro a un livello umano per i casi d'uso ad alto rischio e quando il livello di confidenza dell'intelligenza artificiale è basso.
- **Dare priorità alla sicurezza degli output e degli esiti** del modello. Eseguire [valutazioni](https://www.salesforce.com/news/stories/developing-ethical-ai/) della distorsione, della spiegabilità e della solidità e del [red teaming etico](https://www.salesforce.com/blog/red-teaming-ai/). Assegnare priorità alla protezione della privacy tramite le risposte e le azioni degli agenti per qualsiasi informazione di identificazione personale (PII) presente nei dati utilizzati per l'addestramento e creare guardrail per evitare danni aggiuntivi. Se si rilevano risultati dannosi durante il test, aggiungere istruzioni ai prompt di sistema e ripetere il test. Può anche essere necessario migliorare la qualità o la rappresentatività dei dati utilizzati per la generazione aumentata di recupero (RAG).
- **Preparatevi ai regolamenti**. Oltre alle preoccupazioni etiche nei confronti dell'intelligenza artificiale, molti governi hanno approvato o stanno approvando leggi per regolamentare l'uso dell'intelligenza artificiale da parte delle organizzazioni che operano all'interno delle loro giurisdizioni. Questa normativa può includere l'obbligo di pubblicare schede modello che descrivono come è stata creata e funziona una soluzione AI. Prima di implementare una soluzione basata sull'intelligenza artificiale, tenere presente quale tipo di funzionalità correlata all'intelligenza artificiale è accettabile o meno nelle regioni in cui verranno utilizzati i sistemi e apportare le modifiche necessarie alla strategia. In alcune regioni potrebbe essere necessario disabilitare alcune funzioni per conformarsi alle normative locali; in tal caso, assicurarsi che i sistemi possano continuare a funzionare senza di esse. Molte giurisdizioni richiedono trasparenza anche quando i clienti o gli utenti finali interagiscono con i sistemi di intelligenza artificiale.
- **Monitorare i modelli AI della propria organizzazione**. Gli utenti interessati dovrebbero sapere quando è stata utilizzata un'intelligenza artificiale e avere la possibilità di segnalare facilmente i danni e richiedere un risarcimento. È importante tenere presente che i rapporti da soli potrebbero non essere sufficienti per determinare se la funzionalità AI sta causando danni agli utenti. Monitorare costantemente i modelli per verificare la fluttuazione dei dati, le variazioni dei punteggi di equità/bias, la precisione e la solidità. Assicurarsi di disporre di piani per [gestire gli avvisi qualità](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5) e rispondere rapidamente quando vengono rilevati impatti negativi.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/compliant#modelli-e-anti-schemi-degli-standard-etici) riportato di seguito mostra l'aspetto di una progettazione AI corretta (e scadente) all'interno di una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per implementare policy di intelligenza artificiale più etiche, vedere [Tools Relevant to Be Conliant](/docs/architect/it-it/well-architected/guide/compliant#strumenti-pertinenti-per-essere-conformi) (Strumenti pertinenti per essere conformi).

### Modelli e anti-schemi degli standard etici

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri modelli per gli standard etici in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-ethical-standards).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Polizze aziendali</b></td>
            <td><b>Negli standard di progettazione:</b>
            <br> - Gli standard includono indicazioni chiare per le aree interessate dalle policy aziendali</td>
            <td><b>Negli standard di progettazione:</b>
            <br> - Gli standard di progettazione non esistono o non forniscono indicazioni chiare sulle aree soggette alle policy aziendali</td>
        </tr>
        <tr>
            <td><b>Nella documentazione:</b>
            <br> - La documentazione per la configurazione e le personalizzazioni include riferimenti ai valori aziendali supportati</td>
            <td><b>Nella documentazione:</b>
            <br> - La documentazione per la configurazione e le personalizzazioni non fa riferimento ai valori o alle policy aziendali</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> Tutti gli oggetti e i campi soggetti alla conformità alle policy aziendali hanno la categorizzazione di conformità, il titolare dei dati, il livello di riservatezza dei dati e l'utilizzo dei campi configurati</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Gli oggetti e che sono soggetti alla conformità alle policy aziendali non sono configurati per la categorizzazione di conformità, il titolare dei dati, il livello di riservatezza dei dati o l'utilizzo dei campi</td>
        </tr>
        <tr>
            <td rowspan="2"><b>Intelligenza artificiale</b></td>
            <td><b>Negli standard di progettazione:</b>
            <br> Le policy e i casi d'uso approvati per le applicazioni AI sono chiari e facili da trovare
            <br> Assicurarsi che i dati e i documenti utilizzati per RAG siano rappresentativi, completi, accurati e aggiornati. Cercare distorsioni, contenuti tossici e altri contenuti dannosi che potrebbero essere presenti nelle serie di dati o nella documentazione
            <br> - Le risposte generative identificano sempre le fonti di dati utilizzate dai modelli AI
            <br> - Le serie di dati che possono/non possono essere utilizzate per la progettazione rapida sono state documentate
            <br> - I bot e le risposte AI generative sono chiaramente identificati per gli utenti
            <br> - Gli standard per quando e come utilizzare le dichiarazioni di non responsabilità per l'intelligenza artificiale generativa sono chiaramente definiti
            <br> - Esistono requisiti chiari per documentare i punti di coinvolgimento umano nella progettazione di soluzioni AI
            <br> - Esistono standard per documentare i percorsi di feedback diretti e indiretti nei progetti di soluzioni AI
            <br> - I punti in cui l'intelligenza artificiale deve essere identificata per un utente sono chiaramente definiti
            <br> - Mantenere un essere umano al timone, soprattutto nei casi d'uso regolamentati o ad alto rischio
            </td>
            <td><b>Negli standard di progettazione:</b>
            <br> - Gli standard di progettazione non esistono o non includono policy chiare e casi d'uso approvati per le applicazioni AI
            <br> - Le risposte generative non identificano le fonti di dati utilizzate dai modelli AI
            <br> - Le serie di dati utilizzate per la progettazione rapida non sono documentate
            <br> - I bot e le risposte AI generative non vengono identificati agli utenti
            <br> - Mancano le dichiarazioni di non responsabilità relative alle risposte generative
            <br> - Non esistono requisiti per documentare i punti di coinvolgimento umano nella progettazione di soluzioni AI
            <br> - Non esistono standard per documentare i percorsi di feedback diretti e indiretti per i progetti di soluzioni AI
            <br> - Gli standard di progettazione non indicano i punti in cui l'intelligenza artificiale deve essere identificata per gli utenti
            </td>
        </tr>
        <tr>
            <td><b>Nella documentazione:</b>
            <br> - La documentazione per la configurazione e le personalizzazioni che coinvolgono le funzionalità AI contiene una descrizione approfondita di tutta la logica dei processi ed è archiviata in una posizione centrale accessibile dai team legali o dagli auditor
            <br> - I modelli creati o portati in Salesforce sono chiaramente documentati, inclusi eventuali segmenti di dati applicabili
            <br> - La logica delle conversazioni e le conversazioni agentiche sono accuratamente documentate
            <br> - Sono in atto processi per monitorare i modelli AI dell'organizzazione per verificare la fluttuazione dei dati, i cambiamenti nei punteggi di equità e distorsione, la precisione e la solidità
            <br> Le descrizioni vengono mantenute per i dati di addestramento, valutazione e test utilizzati per tutti i processi AI
            <br> Le descrizioni vengono mantenute per qualsiasi pulizia dei dati correlata all'intelligenza artificiale insieme ai test di distorsione, ai risultati associati e ai punteggi di prestazioni/accuratezza (ad esempio, i punteggi F1)</td>
            <td><b>Nella documentazione:</b>
            <br> - La documentazione per la configurazione e le personalizzazioni che coinvolgono la funzionalità AI è assente, incompleta o archiviata in una posizione inaccessibile
            <br> - I modelli o i sistemi AI vengono implementati nell'organizzazione senza la documentazione dei relativi modelli
            <br> - Gli agenti vengono implementati nell'organizzazione senza la documentazione dei messaggi e del flusso di conversazione
            <br> - I processi di monitoraggio AI non esistono o non sono documentati
            <br> - Le informazioni sui dati di addestramento, valutazione e test utilizzati per tutti i processi AI non sono chiare o non sono disponibili
            <br> - Le informazioni sulla pulizia dei dati relativi all'intelligenza artificiale, i test di distorsione e i risultati non sono chiari o non sono disponibili</td>
        </tr>
    </tbody>
</table>

## Accessibilità

_L'accessibilità_ nella tecnologia si riferisce alla fruibilità di sistemi o soluzioni per persone con competenze diverse. Progettare sistemi che funzionino per tutti gli utenti, indipendentemente dalle loro capacità, è un obbligo legale in alcune sedi e settori. Oltre ai requisiti legali, la creazione di sistemi accessibili aiuta l'organizzazione a promuovere e aumentare il Trust con gli stakeholder. Per le applicazioni indirizzate ai clienti, ciò può persino aumentare il reddito poiché i clienti possono scegliere di utilizzare i sistemi anziché alternative meno accessibili.

Salesforce pubblica i [Rapporti conformità accessibilità](https://www.salesforce.com/company/legal/508_accessibility/), ovvero documenti standard del settore che descrivono in dettaglio in che modo il nostro software è conforme agli standard di accessibilità. La maggior parte dei controlli basati sull'interfaccia utente, inclusi i componenti Web Lightning e i modelli Experience Cloud, sono progettati per rispettare questi standard. Benché le nostre funzioni di accessibilità di base possano essere sufficienti per molte aziende, è importante rivedere i documenti ACR e le note di rilascio prima di iniziare qualsiasi progetto. Ciò consentirà di identificare e documentare eventuali requisiti di accessibilità aggiuntivi che vanno oltre i nostri standard, a seconda dell'approccio go-to-market del prodotto o servizio.

È possibile migliorare l'accessibilità dei sistemi concentrandosi su due aree chiave: l'immissione dei dati e la navigazione.

### Immissione dati

Le attività di immissione dati si verificano ogni volta che un utente deve inserire informazioni in un campo, modulo o in un'altra parte di un'interfaccia utente. Mentre le tastiere e i mouse sono i metodi di input più comuni, alcuni utenti possono fare affidamento su dispositivi vocali o simili. Inoltre, gli utenti possono comunicare in lingue diverse.

Le soluzioni non progettate per l'accessibilità possono escludere le persone con determinate disabilità dall'interazione con esse.

Durante la progettazione per l'accessibilità, tenere presente quanto segue:

- **La lingua preferita dagli utenti**. A seconda di dove opera la propria azienda, si può decidere di impostare un'unica lingua standard per i propri sistemi o di offrire funzionalità multilingue. Se il testo viene visualizzato in più lingue, gli standard di progettazione devono includere un elenco di etichette di campi e altri elementi dell'interfaccia utente (ad esempio notifiche e messaggi di errore) che richiedono la traduzione. Coinvolgere un madrelingua per verificare la precisione e il significato delle traduzioni. Utilizzare le [funzioni di traduzione](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5) di Salesforce per la traduzione dei metadati e dei dati in tempo reale e testare a fondo tutte le funzioni multilingue.
- **I tipi di dispositivi di input che verranno utilizzati**. Elencare gli strumenti che possono essere utilizzati per l'input dei dati oltre una tastiera e un mouse standard negli standard di progettazione. Includere i test di accessibilità nei piani di test e assicurarsi che tutti gli input vengano testati con più tipi di dispositivi di input.
- **La fruibilità dei moduli**. Assicurarsi che i moduli includano etichette visibili, forniscano messaggi di errore utili, guidino l'utente verso il completamento, lo informino dell'avanzamento e gli consentano di rivedere, confermare e modificare i propri input.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/compliant#modelli-di-accessibilità-e-anti-schemi) riportato di seguito mostra l'aspetto dell'immissione dei dati quando è correttamente (e scarsamente) progettata per l'accessibilità all'interno di una soluzione Salesforce. Utilizzare questi elementi per convalidare i progetti prima di creare o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per creare un'immissione dati più accessibile, vedere [Strumenti pertinenti per essere conformi](/docs/architect/it-it/well-architected/guide/compliant#strumenti-pertinenti-per-essere-conformi).

### Navigazione

La navigazione prevede che gli utenti spostino l'attivazione tra le schermate e tra i campi all'interno di una schermata. Gli utenti potrebbero dover navigare tra i vari elementi dell'interfaccia utente nel sistema in vari modi, inclusi clic e sequenze di tasti, affidandosi alla vista, all'udito e al tatto. Assicurarsi che gli standard di progettazione includano un elenco dei dispositivi di navigazione che si prevede di supportare. I team di implementazione devono fare riferimento a questo elenco durante i test per assicurarsi che tutte le possibilità di navigazione siano considerate.

Considerare le seguenti domande e le relative risposte durante la progettazione della navigazione accessibile:

- **Come si muoveranno gli utenti nella soluzione?** Elencare tutti i dispositivi che possono essere utilizzati per la navigazione oltre una tastiera e un mouse standard negli standard di progettazione.
- **La navigazione è coerente?** Stabilire standard di progettazione per i controlli di navigazione per garantire la coerenza in tutto il sistema. I percorsi di navigazione devono essere simili in tutto il sistema. La navigazione incoerente, ad esempio un pulsante blu "Avanti" in basso a destra in una schermata e un pulsante verde "Avanti" al centro di quella successiva, potrebbe essere un lieve fastidio per alcuni utenti ma potrebbe rendere l'applicazione inutilizzabile per le persone con disabilità.
- **I test tengono conto dell'accessibilità?** Includere i test di accessibilità nei piani di test e assicurarsi che tutti i flussi di navigazione siano testati con più tipi di dispositivi di input.
- **Il focus della tastiera è sempre visibile?** Visualizzare sempre visivamente lo stato attuale della tastiera per aiutare gli utenti che utilizzano una tastiera per navigare.
- **La navigazione si basa sul colore?** Evitare di utilizzare il solo colore per presentare informazioni o richiedere un'azione. Rispettare le [Linee guida Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/#visual-audio-contrast) per un uso corretto del colore per trasmettere significato e applicare il giusto livello di contrasto.
- **I tuoi progetti sono stati rivisti?** Eseguire revisioni periodiche per assicurarsi che l'interfaccia utente sia coerente e facile da comprendere.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/compliant#modelli-di-accessibilità-e-anti-schemi) riportato sotto mostra l'aspetto della navigazione quando è correttamente (e scarsamente) progettata per l'accessibilità all'interno di una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la creazione di una navigazione più accessibile, vedere [Strumenti pertinenti per essere conformi](/docs/architect/it-it/well-architected/guide/compliant#strumenti-pertinenti-per-essere-conformi).

### Modelli di accessibilità e anti-schemi

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per l'accessibilità in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-accessibility).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Inserimento dati</b></td>
            <td><b>Negli standard di progettazione:</b>
            <br> - Sono elencati tutti i dispositivi che possono essere utilizzati per l'input dei dati oltre una tastiera e un mouse standard
            <br> - Vengono elencati i valori di testo e le relative traduzioni in tutte le lingue supportate</td>
            <td><b>Negli standard di progettazione:</b>
            <br> - Solo alcuni, o nessuno, dei dispositivi che possono essere utilizzati per l'input dei dati oltre una tastiera e un mouse standard sono elencati
            <br> - Le lingue supportate sono elencate insieme agli elementi dell'interfaccia utente da tradurre
            </td>
        </tr>
        <tr>
            <td><b>Nei piani di test:</b>
            <br> - Le fasi di test includono l'utilizzo di più tipi di dispositivi di input per inserire i dati
            <br> - Le fasi di test includono l'immissione dei dati in più lingue</td>
            <td><b>Nei piani di test:</b>
            <br> - Il test di accessibilità non è incluso o il test per l'immissione di dati accessibili viene eseguito ad hoc</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le traduzioni per le lingue supportate sono memorizzate nell'Area di lavoro traduzione
            </td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le traduzioni sono memorizzate in etichette personalizzate
            </td>
        </tr>
        <tr>
            <td rowspan="2"><b>Navigazione</b></td>
            <td><b>Negli standard di progettazione:</b>
            <br> - Tutti i dispositivi utilizzabili per la navigazione (non solo tastiera e mouse standard) sono chiaramente elencati
            <br> - Gli standard UI/UX specificano il tipo e lo stile di tutti i controlli di navigazione
            <br> - I tipi di segnali visivi approvati per trasmettere significato o stato sono chiaramente elencati e il colore non è uno spunto principale</td>
            <td><b>Negli standard di progettazione:</b>
            <br> - Gli standard di progettazione non esistono o non tengono conto dei requisiti di accessibilità per i controlli di navigazione
            <br> - Gli standard UI/UX per la navigazione sono incoerenti
            <br> - I segnali visivi per il significato o lo stato si basano sul colore o non ci sono elenchi chiari di segnali visivi per i costruttori</td>
        </tr>
        <tr>
            <td><b>Nei piani di test:</b>
            <br> - Le fasi di test includono l'utilizzo di più tipi di dispositivi di input per navigare
            <br> - I piani di test includono l'utilizzo di test UI / UX per garantire percorsi di navigazione coerenti</td>
            <td><b>Nei piani di test:</b>
            <br> - I test di accessibilità non sono inclusi o i test per la navigazione accessibile sono eseguiti ad hoc</td>
        </tr>
    </tbody>
</table>

## Strumenti pertinenti per essere conformi

<table class="tools-table"><tbody><tr><th>Strumento</th><th>Descrizione</th><th>Aderenza giuridica</th><th>Standard etici</th><th>Accessibilità</th></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.copilot_analytics.htm&type=5">Agenteforce Analytics</a></td><td>Ottenere informazioni approfondite sulle prestazioni degli agenti</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.agent_testing_center.htm&type=5">Centro test Agentforce</a></td><td>Eseguire fino a 10 processi di test con un massimo di 1.000 casi di test per test, in modo da poter creare e valutare rapidamente più scenari.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_citations.htm&type=5">Citazioni</a></td><td>Le citazioni aiutano a identificare potenziali imprecisioni o allucinazioni nelle risposte generate, aumentando la fiducia nell'utilizzo degli strumenti di intelligenza artificiale.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.236.0.api_rest.meta/api_rest/resources_consent.htm">Consent API</a></td><td>Tenere traccia delle preferenze dei clienti per il consenso</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.consent_event_stream.htm&type=5">Stream evento consenso</a></td><td>Inviare notifiche per le modifiche al consenso o alle informazioni di contatto</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.consent_mgmt_fields.htm&type=5">Oggetti di gestione del consenso</a></td><td>Gestione della privacy e delle preferenze di consenso dei clienti</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_portability.htm&type=5">Accesso ai dati e portabilità</a></td><td>Esportazione dei dati relativi ai clienti su richiesta</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5">Classificazione dei dati</a></td><td>Registrare le informazioni di conformità e controllo delle chiavi per i campi oggetto</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.agent_instruction_adherence_monitor_dc.htm&type=5">Rapporti di Data 360</a></td><td>Monitoraggio dell'osservanza delle istruzioni dell'agente</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_deletion.htm&type=5">Eliminazione dei dati</a></td><td>Eliminare i dati per conformarsi alle normative legali</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.individuals_store_data_privacy.htm&type=5">Preferenze sulla privacy dei dati</a></td><td>Memorizzazione delle preferenze di privacy dei dati dei clienti</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_translation.htm&type=5">Traduzione dati</a></td><td>Tradurre i dati presentati agli utenti</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5">Rilevamento dati</a></td><td>Allineare le categorie e i livelli di riservatezza ai dati effettivi</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=data.c360_a_data_explorer.htm&type=5">Data 360 Explorer</a></td><td>Gestione delle autorizzazioni per progetti e oggetti per i data scientist</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai_prism.htm&type=5">Prisma dati Einstein</a></td><td>Una soluzione di base per le applicazioni AI generative in Salesforce, che migliora la precisione delle soluzioni AI che utilizzano le sue funzionalità di base</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/artificial-intelligence/trusted-ai/">Einstein Trust Layer</a></td><td>Una raccolta di funzioni, processi e policy progettati per salvaguardare la privacy dei dati, migliorare la precisione dell'intelligenza artificiale e promuovere un uso responsabile dell'intelligenza artificiale in tutto l'ecosistema Salesforce</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.copilot_setup_enhanced_event_logs.htm&type=5">Registri eventi ottimizzati</a></td><td>I registri eventi acquisiscono gli eventi e i messaggi degli utenti in una sessione agente per esaminare l'osservanza delle istruzioni, testare e risolvere i problemi dell'agente.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.collab_files_connect_parent.htm&type=5">Files Connect</a></td><td>Esplorazione, ricerca e condivisione di file esterni da Salesforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=000356459&type=1">Hyperforce</a></td><td>Rispettare i requisiti di memoria dati locale</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.workbench_metadata_translation.htm&type=5">Traduzione dei metadati</a></td><td>Tradurre le lingue per localizzare le applicazioni</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.236.0.api_rest.meta/api_rest/resources_portability.htm">API di portabilità</a></td><td>Compilare i dati dei clienti identificati nella policy di portabilità</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.preference_center_about.htm&type=5">Centro preferenze</a></td><td>Raccogliere le preferenze di comunicazione dei clienti</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.privacy_center.htm&type=5">Centro privacy</a></td><td>Soddisfare le richieste dei clienti e le leggi sulla privacy dei dati</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.restriction_of_processing.htm&type=5">Limitazione del trattamento dei dati</a></td><td>Limitazione dei metodi di trattamento dei dati personali</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.rtbf_policies.htm&type=5">Diritto all'oblio</a></td><td>Eliminare i dati di singoli clienti su richiesta</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.collab_files_overview.htm&type=5">Salesforce Files</a></td><td>Condividere e archiviare i file privatamente</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_center.htm&type=5">Centro di sicurezza</a></td><td>Visualizzazione delle impostazioni di sicurezza e privacy in più organizzazioni</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/security_pe_overview.htm">Shield Platform Encryption</a></td><td>Crittografia dei dati a riposo e in transito</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.workbench.htm&type=5">Area di lavoro traduzione</a></td><td>Gestione dei valori tradotti per i metadati e le etichette dei dati</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
</table>

## Risorse pertinenti per essere conformi

<table class="tools-table"><tbody><tr><th>Risorsa</th><th>Descrizione</th><th>Aderenza giuridica</th><th>Standard etici</th><th>Accessibilità</th></tr>
<tr><td><a href="https://medium.com/p/781b5fd2427">5 principi per una progettazione AI responsabile</a></td><td>Progettare le funzionalità di Intelligenza Artificiale (AI) in modo etico</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/accessibility-basics?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">Nozioni di base sull'accessibilità (Trailhead)</a></td><td>Scopri perché l'accessibilità è importante</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.salesforce.com/company/legal/508_accessibility/">Rapporti sulla conformità dell'accessibilità (ACR)</a></td><td>Informazioni su come Salesforce soddisfa gli standard di accessibilità</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/2e1ef8501/p/112ac5-accessibility">Panoramica dell'accessibilità</a></td><td>Informazioni sull'accessibilità in Salesforce Lightning</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf">Modello di maturità etica AI</a></td><td>Sviluppare una roadmap per rendere operativi i principi etici</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/blog/red-teaming-ai/">AI Red Teaming: Test per Trust</a></td><td>Scopri in che modo gli "hacker etici" di Salesforce sviluppano l'intelligenza artificiale responsabile attraverso il teaming rosso.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/blog/automated-framework-for-red-teaming-ai/">Automazione dell'avversario: Progettazione di un framework scalabile per Red Teaming AI</a></td><td>Di seguito viene descritto come Salesforce automatizza la generazione di prompt in contraddittorio e la convalida delle risposte. Fuzzai aiuta a proteggere le interazioni AI riducendo l'esposizione umana a contenuti dannosi.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.bots_service_best_practice.htm&type=5">Procedure consigliate per la progettazione delle conversazioni</a></td><td>Seguire le procedure consigliate durante la progettazione dei chatbot</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/best-practices-for-sustainable-design?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">Migliori pratiche per la progettazione sostenibile (Trailhead)</a></td><td>Integrare la sostenibilità nei progetti</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.consent_management.htm&type=5">Gestione del consenso</a></td><td>Monitoraggio e conformità alle richieste di consenso e rifiuto esplicito</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.aac_manage_data_policies.htm&type=5">Polizze sui dati per Einstein</a></td><td>Controllare l'utilizzo dei dati nelle funzionalità Einstein</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/design-standards-template">Modello Design Standards (Standard di progettazione)</a></td><td>Creare standard di progettazione per l'organizzazione</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.salesforce.com/blog/red-teaming-ai/">Le pratiche di hacking etico si dimostrano efficaci nella creazione di prodotti di Intelligenza artificiale affidabili</a></td><td>Di seguito viene descritto come Salesforce utilizza le <a href="https://www.salesforce.com/blog/red-teaming-ai/">pratiche Red Teaming</a> per migliorare la sicurezza dei prodotti AI testando l'eventuale presenza di uso dannoso, attacchi intenzionali all'integrità, uso improprio involontario e identificando i problemi di intelligenza artificiale responsabili.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/content/dam/web/en_us/www/documents/research/salesforce-research-ethical-leadership-and-business.pdf">Leadership etica e business</a></td><td>Approfondimenti su tecnologia, uguaglianza ed etica</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/">Politica di utilizzo etico</a></td><td>Esplorare la policy di Salesforce sull'uso etico dei prodotti e servizi</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/ethics-by-design?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">Etica per progettazione (Trailhead)</a></td><td>Integrare la progettazione etica nello sviluppo tecnologico</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values">Esplorazione della cultura e dei valori di Salesforce (Trailhead)</a></td><td>Esplorazione dei valori centrali di Salesforce</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/mobile_a11y.html">Seguire le linee guida per la progettazione mobile accessibile</a></td><td>Seguire le procedure consigliate per rendere accessibili i progetti</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/en/content/learn/trails/get-started-with-web-accessibility">Iniziare con l'accessibilità del Web (Trailhead)</a></td><td>Informazioni di base su come rendere accessibili siti Web e app</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.salesforce.com/blog/how-salesforce-builds-reproducible-red-teaming-infrastructure/">Come Salesforce crea un'infrastruttura di Red Teaming riproducibile</a></td><td>Quattro componenti che si consigliano quando si progetta, si implementa e si eseguono i test di un avversario</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-ux/how-to-run-a-consequence-scanning-workshop-4b14792ea987">Come eseguire un workshop di scansione delle conseguenze</a></td><td>Considerare tutti i possibili risultati durante l'innovazione</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_protection_and_privacy.htm&type=5">Attuazione della protezione dei dati e della privacy</a></td><td>Valutare i requisiti di protezione dei dati e privacy</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/inclusive-design">Progettazione inclusiva (Trailhead)</a></td><td>Promuovere l'innovazione con principi di progettazione inclusivi</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/kpi-spreadsheet-template">Modello di foglio di calcolo KPI</a></td><td>Impostazione degli indicatori di prestazione chiave (KPI) per l'organizzazione</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/company/legal/">Informazioni legali</a></td><td>Esplorazione del centro Informazioni legali di Salesforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/blogs/2021/09/learn-moar-in-winter-22-with-lwc-cookie-consent-module">Modulo di consenso sui cookie LWC</a></td><td>Controllo dell'accesso ai cookie degli utenti nei siti Experience Cloud</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/privacy/overview/">Panoramica sulla privacy</a></td><td>Informazioni sulla privacy dei dati per regione e settore</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai/promote-responsible-and-ethical-agents">Promuovere agenti responsabili ed etici</a></td><td>Di seguito viene descritto come implementare strategie etiche di teaming e test e sviluppare principi e standard guida per l'organizzazione.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/">Linee guida AI per agenti responsabili</a></td><td></td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence">Creazione responsabile del modulo Trailhead AI</a></td><td>Di seguito viene descritto come rimuovere la distorsione dai dati e dagli algoritmi per creare sistemi di intelligenza artificiale etici nella propria azienda.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforceairesearch.com/trusted-ai">Linee guida AI generativa responsabile</a></td><td>Ci siamo basati sui nostri <a href="https://www.salesforceairesearch.com/trusted-ai">principi di Intelligenza artificiale affidabile</a> con una nuova serie di linee guida incentrate sullo sviluppo responsabile e l'implementazione dell'intelligenza artificiale generativa.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://compliance.salesforce.com/">Certificazioni di conformità Salesforce</a></td><td>Esaminare le certificazioni e le attestazioni di conformità di Saleforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/sustainable-design?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">Progettazione sostenibile (Trailhead)</a></td><td>Rafforzare il rapporto tra imprese e società</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/testing-for-web-accessibility">Test dell'accessibilità del Web (Trailhead)</a></td><td>Utilizzare test automatici e manuali per garantire l'accessibilità</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai">AI agente affidabile</a></td><td>Di seguito viene descritto come Agentforce utilizza le protezioni e i principi di intelligenza artificiale responsabile per creare un'intelligenza artificiale etica.</td><td class="check-col"></td><td class="check-col">x</td><td class="check-col"></td></tr>
</table>

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.

<!-- document id=4137a64a8dcc70753258c809f760bde219d1fd8eab3c4d611495afb4606a329b url=/architect/next/it-it/well-architected/guides/contributors.md -->

## Introduzione

Salesforce Well-Architected rappresenta le indicazioni e le procedure consigliate di un esperto di Salesforce e dell'intero ecosistema. Grazie a tutti coloro che hanno contribuito con risorse e Knowledge a well-architected.

I documenti di Well-Architected vengono aggiornati due volte l'anno. Annunceremo come contribuire a Well-Architected durante la nostra prossima finestra di manutenzione.

È possibile inviare commenti su Well-Architected in qualsiasi momento [qui](https://sfdc.co/bxNtvh).

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.

<!---
## October 2025 Release

> Thank you to all our contributors who helped with the revision of the whitepaper.

<table border="0">
    <tr>
        <td>
        A A<br />
        A B<br />
        A C<br />
        A D<br />
        A E<br />
        A F<br />
        </td>
        <td>
        A A<br />
        A B<br />
        A C<br />
        A D<br />
        A E<br />
        A F<br />
        </td>
        <td>
        A A<br />
        A B<br />
        A C<br />
        A D<br />
        A E<br />
        A F<br />
        </td>
        <td>
        A A<br />
        A B<br />
        A C<br />
        A D<br />
        A E<br />
        A F<br />
        </td>
    </tr>
</table>
--->
<!---
## July 2024 Release

> Thank you to our contributors who helped with our initial release of patterns & anti-patterns for Data 360 and Einstien.

<table border="0">
    <tr>
        <td>
        Ahmed Keshk<br />
        Andres Perez<br />
        Arturo Alvarado<br />
        Arvind Raman<br />
        Bret Brizzee<br />
        CJ Buskey<br />
        </td>
        <td>
        Gina Nichols<br />
        Jim Stukas<br />
        John Kucera<br />
        Jordan Seeley<br />
        Justin Piehowski<br />
        Marc Braga<br />
        </td>
        <td>
        Marissa Chesney<br />
        Matt Dykeman<br />
        Michael DePuy<br />
        Moustafa Ishak Kamal Moustafa<br />
        Muralidhar Krishnaprasad<br />
        Patrick Hermiller<br />
        </td>
        <td>
        Scott Robbins<br />
        Shoby Abdi<br />
        Stella Hang<br />
        Susannah Plaisted<br />
        Tom Leddy<br />
        Zayne Turner<br />
        </td>
    </tr>
</table>
--->

<!-- document id=4ae68d61a9c75888c7619ff1e8efc433cb42ec43c6f83ad88023b3d66f341434 url=/architect/next/it-it/well-architected/guides/easy-overview.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

# Introduzione

Una soluzione Salesforce **Facile** offre valore velocemente. Una soluzione ben progettata per essere **facile** è intenzionale, automatizzata e coinvolgente.

Le soluzioni **intenzionali** offrono valore aziendale immediatamente e nel tempo.<br>
Le soluzioni **automatiche** consentono all'azienda di eseguire il lavoro più rapidamente e su larga scala.<br>
Soluzioni **coinvolgenti** soddisfano gli utenti e favoriscono l'adozione.<br>

Creare architetture **facili** può rappresentare sfide complesse per un architetto. Data la flessibilità di Salesforce Platform e la varietà di [strumenti di automazione](/docs/architect/it-it/well-architected/guide/automated#strumenti-rilevanti-per-lautomazione) disponibili, i dettagli dell'implementazione possono variare notevolmente tra le singole organizzazioni Salesforce. Architetture **facili** possono richiedere analisi di compromesso e conversazioni più intelligenti (e difficili) con gli stakeholder. La progettazione di una soluzione può essere resiliente e affidabile per un programmatore, ma non semplice da possedere o gestire per un amministratore di organizzazione. Una soluzione del genere non sarebbe ben progettata per essere **facile**.

Per arrivare a una soluzione **facile**, è necessario comprendere le priorità aziendali in modo profondo e preciso. È necessario conoscere gli utenti, comprese le loro preferenze, le loro esigenze e la realtà quotidiana del loro lavoro. È inoltre necessario conoscere le competenze (e le lacune di competenza) dei team di consegna e manutenzione. Sarà necessario ripetere diverse opzioni di tooling e schemi di progettazione per arrivare a una soluzione che sia intenzionale per ottenere valore per l'azienda e sia gestibile per i team di consegna e manutenzione, automatizza il lavoro più velocemente e su larga scala e coinvolge davvero gli utenti.

Le sezioni che seguono offrono indicazioni più approfondite per le considerazioni principali di un'architettura **Easy** Solution.

## Panoramica semplice

<table>
<tbody>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/intentional">Intenzionale</a></th>
        </tr>
        <tr>
        <td colspan="3">Le soluzioni intenzionali offrono valore aziendale immediatamente e nel tempo. Le architetture intenzionali sono pianificate e fornite in modo strategico, possono essere mantenute in modo efficace e sono facili da leggere e comprendere per gli esseri umani.</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/intentional#strategia">Strategia</a></th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/intentional#manutenibilità">Gestibilità</a></th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/intentional#leggibilità">Leggibilità</a></th>
        </tr>
        <tr>
            <td>Assegnazione di priorità <br>Roadmapping <br>Governance</td>
            <td>Standard vs Personalizzato <br>Debito tecnico</td>
            <td>Design Standards <br>Documentazione</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/automated">Automatizzato</a></th>
        </tr>
        <tr>
        <td colspan="3">Le soluzioni automatiche consentono all'azienda di eseguire il lavoro più rapidamente e su larga scala. Una sana automazione riduce il tempo dedicato a operazioni manuali ripetitive o all'immissione di dati complessi.</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/automated#efficienza">Efficienza</a></th>
            <th scope="colgroup" colspan="2"><a href="/docs/architect/it-it/well-architected/guide/automated#integrità-dei-dati">Integrità dei dati</a></th>
        </tr>
        <tr>
            <td>Progettazione dei processi <br>Logica operativa<br>KPIs</td>
            <td colspan="2">Gestione dei dati <br>Gestione degli errori</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/engaging">Coinvolgimento</a></th>
        </tr>
        <tr>
        <td colspan="3">Soluzioni coinvolgenti soddisfano gli utenti e favoriscono l'adozione. Progettare per il coinvolgimento significa creare esperienze utente intuitive e utili.</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/it-it/well-architected/guide/engaging#semplificato">Semplificato</a></th>
            <th scope="colgroup" colspan="2"><a href="/docs/architect/it-it/well-architected/guide/engaging#utile">Utile</a></th>
        </tr>
        <tr>
            <td>Complessità dell'applicazione <br>Moduli <br>Fattore di forma</td>
            <td colspan="2">Notifiche e Messaggistica <br>Guida in app<br>Riconoscimenti e premi</td>
        </tr>
        </tbody>
</table>

<!-- document id=d0d4882421d1a3ff439b4868351089e16f4f591a7fa72a46fc5ede95baeb49b8 url=/architect/next/it-it/well-architected/guides/intentional.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

Le soluzioni intenzionali offrono valore aziendale immediatamente e nel tempo. Le architetture intenzionali sono pianificate e fornite in modo strategico, possono essere mantenute in modo efficace e sono facili da leggere e comprendere per gli esseri umani.

Le funzioni e le correzioni sono definite in base alla priorità e fornite in modo trasparente sia per le aziende che per gli stakeholder tecnologici. Le scelte ingegneristiche creano implementazioni facili da utilizzare per i team di consegna e manutenzione, senza funzioni aggiuntive o complicazioni. Le architetture intenzionali sono più facili da possedere, gestire ed evolvere con l'azienda perché seguono schemi di implementazione chiari e coerenti. I generatori possono interpretare e implementare progetti per nuove funzioni e i team di manutenzione possono comprendere la documentazione di ciò che è stato implementato.

È possibile creare sistemi più intenzionali concentrandosi su tre aree chiave: strategia, manutenibilità e leggibilità.

## Strategia

Strategia in architettura significa che i sistemi vengono pianificati e consegnati in modo ponderato. Ciò significa che i team di consegna e manutenzione hanno una visione chiara del lavoro da svolgere oggi e in futuro e tutti sono allineati sul "perché" del lavoro da svolgere. Ciò significa che le richieste urgenti possono essere gestite in modo efficace ed efficiente e che gli stakeholder possono comprendere chiaramente l'impatto e i compromessi delle richieste.

È possibile definire una strategia più chiara nell'architettura concentrandosi sulla definizione delle priorità, sulla mappatura stradale e sulla governance.

### Assegnazione di priorità

Assegnare priorità significa pianificare l'ordine e l'ambito del lavoro che verrà consegnato. L'assegnazione delle priorità implica la comprensione del reale impatto dei risultati sul business, la valutazione di tali impatti rispetto ad altre richieste di lavoro e la roadmap complessiva per il prodotto o il programma.

Un modo per valutare l'impatto di una determinata voce su cui lavorare è esaminare il costo o il vantaggio effettivo per l'azienda. Dopo aver identificato i [KPI](/docs/architect/it-it/well-architected/guide/automated#kpis) per l'automazione, è possibile utilizzare un [foglio di lavoro](/docs/architect/it-it/resources/guide/kpi-spreadsheet-template) per valutare il costo o il vantaggio complessivo dell'implementazione. Questi calcoli possono aiutare a ottenere l'allineamento e il consenso degli stakeholder sulle automazioni da creare e in quale ordine. Possono anche aiutare a identificare le automazioni da posticipare o evitare. Per ulteriori informazioni sull'identificazione del lavoro efficace, vedere [Progettazione dei processi](/docs/architect/it-it/well-architected/guide/automated#progettazione-dei-processi).

Stabilire un framework di definizione delle priorità per la consegna aiuterà anche l'utente e i suoi team di manutenzione a gestire le aspettative degli utenti e a rimanere in linea con la roadmap.

Alcune considerazioni che è possibile utilizzare per definire le priorità sono:

- Impatto aziendale (costo/beneficio) del deliverable
- Quantità di nuovo lavoro richiesto per il deliverable
- Quantità di lavoro necessaria per mantenere il deliverable

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/intentional#strategia-e-anti-schemi) riportato di seguito mostra l'aspetto della corretta (e scarsa) definizione delle priorità quando si tratta di lavorare in Salesforce. È possibile utilizzarli per convalidare i piani di implementazione o identificare i punti in cui è necessario identificare meglio le priorità prima di procedere alla creazione.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce per informazioni sull'assegnazione delle priorità, vedere [Strumenti pertinenti all'intenzionale](/docs/architect/it-it/well-architected/guide/intentional#strumenti-pertinenti-allintenzionale).

### Roadmapping

Una roadmap è una visualizzazione prioritaria, convalidata e ben definita delle operazioni da eseguire. Tabelle di marcia efficaci offrono un quadro chiaro dell'impatto sul business e dell'impatto tecnologico del lavoro futuro. Coinvolgere gli stakeholder aziendali e tecnici è una parte fondamentale della roadmapping. Le tabelle di marcia consentono di ricevere commenti e contributi sull'approccio e sui risultati prima dell'inizio del lavoro. In definitiva, le roadmap allineano ogni stakeholder sul "perché" del lavoro futuro.

Se il team utilizza un backlog, è importante capire che la roadmap non è un riepilogo o un elenco degli elementi in backlog. La relazione è opposta: Le voci sono destinate a entrare nell'arretrato solo se possono essere collegate in modo chiaro e credibile a un risultato nella roadmap. Roadmap di alta qualità, create con il coinvolgimento degli stakeholder, offrono ai team di consegna e manutenzione una visione chiara di ciò su cui concentrarsi e di come assegnare la priorità alle richieste, semplificando la risoluzione delle richieste in conflitto e la gestione delle aspettative degli stakeholder.

Una mappatura stradale scarsa o inesistente porta a:

- Mancanza di chiarezza su quando saranno disponibili nuove funzioni e funzionalità
- Priorità in conflitto tra gli stakeholder
- Una disconnessione tra le soluzioni fornite e la visione organizzativa complessiva
- Difficoltà a capire quali lavori sono in corso
- Carichi di lavoro irregolari tra i team
- Mancanza di visibilità sulle relazioni e le dipendenze tra le voci su cui lavorare
- Implementazioni in stallo a causa di dipendenze mal gestite

Spesso gli stakeholder necessitano di informazioni in linea con i loro ruoli per prendere decisioni. La creazione di roadmap efficaci richiede una chiara comprensione del pubblico e del tipo di informazioni di cui ha bisogno. Le roadmap sono classificate in due stili per supportare i pubblici aziendali e tecnici. Ogni stile contiene due livelli di dettaglio per supportare diversi tipi di informazioni.

Le roadmap aziendali aiutano gli stakeholder a pianificare il cambiamento organizzativo, a sfruttare le opportunità di crescita e a rimanere allineati agli obiettivi aziendali. Le roadmap aziendali offrono anche un modo per garantire che la spesa IT sia allineata alla visione aziendale generale.

- Creare una roadmap delle funzionalità aziendali per mostrare agli stakeholder dirigenti le funzionalità che verranno abilitate. Questo tipo di roadmap contiene dettagli generali sulle funzionalità stesse e sul modo in cui si allineano agli obiettivi aziendali, ad esempio l'aumento dell'efficienza operativa o il lancio di una nuova linea di prodotti.
- Creare una roadmap delle funzioni aziendali per visualizzare in dettaglio una funzionalità specifica e le relative caratteristiche e funzionalità quando è necessario aiutare gli stakeholder aziendali nella pianificazione delle risorse, nel budget e nella gestione del cambiamento.

Le roadmap tecnologiche aiutano gli stakeholder tecnici nella pianificazione del budget e dell'allocazione delle risorse. Aiutano anche i team di implementazione a capire dove si inseriscono i loro progetti come parte di un quadro generale più ampio e a identificare eventuali dipendenze tra team.

- Creare una roadmap del sistema tecnologico per mostrare i sistemi specifici che verranno implementati, insieme alle eventuali dipendenze a livello di sistema. Questo tipo di roadmap mostra le informazioni generali sul sistema e l'allineamento tra i sistemi e le funzionalità aziendali.
- Creare una roadmap dei componenti tecnologici per visualizzare i dettagli dei componenti specifici di un sistema che verranno distribuiti per facilitare la pianificazione delle risorse e i requisiti di abilitazione. Questo tipo di roadmap mostra le informazioni a livello di componente e i requisiti di implementazione (ad esempio, sviluppo dichiarativo, pro-code e così via).

Assicurarsi che le roadmap contengano tempistiche realistiche. Un errore comune è includere solo la quantità di tempo necessaria per implementare un sistema senza considerare anche la quantità di tempo necessaria per completare le attività correlate. Ciò può causare un'allocazione eccessiva dei membri del team di implementazione e ritardi più lunghi del previsto. Quando si crea una roadmap, tenere presente il tempo necessario per completare quanto segue:

- Documentazione di tutte le funzionalità nuove e aggiornate
- Manutenzione delle funzionalità esistenti necessarie per supportare le nuove funzionalità
- Aggiornamenti ai sistemi correlati necessari per supportare le integrazioni
- Supporto elevato da parte dei team di progetto subito dopo l'implementazione
- Test, formazione e gestione del cambiamento

Roadmap aziendali e tecnologiche ben allineate comunicano una visione olistica di quando le funzionalità saranno rese disponibili e di quale tecnologia è alla loro base. L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/intentional#strategia-e-anti-schemi) riportato di seguito mostra le roadmap corrette (e scadenti) per un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare la strategia di mappatura stradale.

Per ulteriori informazioni sugli strumenti Salesforce che possono essere utili per la mappatura stradale, vedere [Strumenti pertinenti all'intenzionale](/docs/architect/it-it/well-architected/guide/intentional#strumenti-pertinenti-allintenzionale).

### Governance

La governance è la struttura utilizzata per gestire le priorità, il processo decisionale e la gestione del cambiamento con gli stakeholder. La governance chiarisce come vengono prese e comunicate le decisioni. Fornisce modalità coerenti per i feedback e le richieste di partecipazione al processo decisionale e consente a tutte le parti interessate di comprendere lo stato del lavoro di manutenzione e sviluppo. La governance consente di rilasciare i processi di gestione in modo chiaro e coerente e aiuta tutti i membri del team a comprendere i propri ruoli e responsabilità.

Senza una governance adeguata, i team sperimenteranno una varietà di problemi, tra cui:

- Le richieste di sovrapposizione di caratteristiche e funzionalità arrivano ad hoc
- I team di implementazione danno priorità agli sforzi o alle richieste più "semplici" da parte di stakeholder più influenti, senza tenere in debita considerazione il valore aziendale, i compromessi o gli obiettivi organizzativi complessivi
- Mancanza di processi di approvazione e revisione coerenti
- Cadenza e qualità dei rilasci incoerenti
- Alte percentuali di difetti, sovrascritture, conflitti e lavoro ridondante negli sforzi di sviluppo

Forse il segnale più chiaro che un sistema non ha una governance efficace sono i rilasci lenti e complessi. È importante riconoscere che le dimensioni di un sistema di governance non sono una misura della sua efficacia. Infatti, sistemi elaborati per la governance (come quelli presenti in molte grandi aziende) possono limitare la velocità e la frequenza dei rilasci.

Una buona governance consiste nel rendere difficile per le personalizzazioni non corrette superare le prime fasi di sviluppo e ottenere personalizzazioni valide in produzione in modo prevedibile e coerente.

Troppo spesso gli sforzi di governance sono reazionari. Vengono avviati o raddoppiati quando un problema, ad esempio un debito tecnico eccessivo, inizia a diventare un problema aziendale. In molti casi, la sfortunata risposta è che l'azienda "blocca" gli sforzi di sviluppo e i rilasci, invece di creare [standard di progettazione](/docs/architect/it-it/resources/guide/design-standards-template) efficaci e di automazione degli edifici per applicare tali standard nelle catene di strumenti per sviluppatori e nei sistemi di controllo sorgente.

Quando si crea il framework per il sistema di governance Salesforce, includere i seguenti elementi e considerare le seguenti domande chiave a cui rispondere:

- **Richieste di lavoro.** Come possono gli utenti richiedere funzionalità o caratteristiche? Come vengono segnalati i bug?
- **Priorità e pianificazione del lavoro.** Chi decide quali richieste di lavoro contano? In che modo il lavoro viene circoscritto, assegnato alle priorità e accettato o approvato?
- **Ambienti e pianificazione dei rilasci.** Qual è la pipeline ambientale per sviluppo, test e rilascio? Chi fa cosa per eseguire il provisioning, aggiornare e concedere l'accesso? Chi gestisce le distribuzioni e la convalida? Come e quando vengono rilasciate le modifiche? Come si gestiscono le distribuzioni o gli ambienti durante un ciclo di rilascio di Salesforce? (Per ulteriori informazioni, vedere [Gestione del ciclo](/docs/architect/it-it/well-architected/guide/resilient#gestione-del-ciclo-di-vita-delle-applicazioni) di vita delle applicazioni).
- **Titolarità del servizio e supporto alla produzione.** Chi sostiene cosa? Chi gestisce i problemi di produzione "hot-fix"? Come vengono testati e rilasciati questi elementi? Chi è responsabile degli standard di sicurezza complessivi dell'organizzazione?

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/intentional#strategia-e-anti-schemi) riportato sotto mostra l'aspetto di una governance corretta (e scarsa) per un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare la strategia di governance.

Per ulteriori informazioni sugli strumenti Salesforce disponibili per la governance, vedere [Strumenti pertinenti all'intenzionale](/docs/architect/it-it/well-architected/guide/intentional#strumenti-pertinenti-allintenzionale).

### Strategia e anti-schemi

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per la strategia in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/easy-strategy).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="2"><b>Priorità</b></td>
            <td><b>Nella documentazione:</b>
            <br> - Tutte le nuove voci su cui lavorare hanno chiare metriche di valore aziendale (ad esempio, aumenti del reddito, risparmi sui costi derivanti dalle ottimizzazioni dei processi e così via)
            <br> - Le roadmap mostrano il lavoro con priorità in base al valore aziendale</td>
            <td><b>Nella documentazione:</b>
            <br> - Il valore aziendale associato al lavoro è poco chiaro o inesistente
            <br> - Le roadmap non esistono</td>
        </tr>
        <tr>
            <td><b>All'interno dell'azienda:</b>
            <br> - I costi di implementazione e manutenzione sono stati identificati per tutte le voci su cui lavorare
            <br> - Le richieste di funzioni hanno la priorità in base all'impatto sul business, alla quantità di nuovo lavoro richiesto per la consegna e alla quantità di lavoro richiesto per la manutenzione</td>
            <td><b>All'interno dell'azienda:</b>
            <br> - I costi associati all'implementazione e alla manutenzione delle funzioni non sono chiari
            <br> - Le richieste vengono consegnate su base ad hoc o first-in/first-out</td>
        </tr>
        <tr>
            <td rowspan="2"><b>Roadmapping</b></td>
            <td><b>Roadmap:</b>
            <br> - Comunicare informazioni personalizzate per il pubblico (aziendale o tecnico)
            <br> - Comunicare le informazioni al corretto livello di dettaglio
            <br> - Mostra date di inizio e fine
            <br> - Mostra prerequisiti e dipendenze</td>
            <td><b>Tabelle di marcia (se esistenti):</b>
            <br> - Sono utilizzati come materiali di avvio del progetto e non artefatti per la consegna
            <br> - Non aiutare ad allineare stakeholder e team di consegna
            <br> - Mescolare i livelli di dettaglio (ad esempio, includendo sistemi e componenti all'interno della stessa roadmap)
            <br> - Contenere informazioni non personalizzate per il pubblico (ad esempio, capacità aziendali e sistemi all'interno della stessa roadmap)</td>
        </tr>
        <tr>
            <td><b>All'interno della tua azienda:</b>
            <br> - Gli stakeholder comprendono il "perché" delle voci su cui lavorare
            <br> - I team di consegna sanno come valutare le voci arretrate rispetto alle priorità a lungo termine
            <br> - I team sanno chi sta facendo cosa e come gestire le dipendenze
            <br> - Il lavoro è intenzionale, anche quando le priorità devono cambiare rapidamente</td>
            <td><b>All'interno della tua azienda:</b>
            <br> - Il lavoro viene estratto da qualsiasi cosa sia in arretrato e non c'è un "perché" chiaro
            <br> - I team hanno difficoltà a coordinare il lavoro interdipendente e spesso replicano il lavoro senza rendersene conto
            <br> - Il lavoro è spesso reattivo
            <br> - Gli stakeholder spesso si sentono frustrati e confusi su ciò che viene fatto e sono usure quando verranno fornite nuove funzionalità</td>
        </tr>
        <tr>
            <td><b>Governance</b></td>
            <td><b>All'interno della tua azienda:</b>
            <br> - Gli utenti possono facilmente segnalare bug e richiedere funzioni
            <br> - Il processo di assegnazione delle priorità alle voci su cui lavorare è documentato e trasparente per tutti gli stakeholder
            <br> - La strategia ambientale è chiaramente documentata e gli ambienti di sviluppo corrispondono alla documentazione
            <br> - La pianificazione del rilascio è prevedibile e trasparente per tutti i membri del team di consegna
            <br> - I membri del team sanno chi è responsabile di cosa durante il ciclo di vita dell'app
            <br> - I rilasci sono chiari per gli utenti e i team di consegna / manutenzione
            <br> - I processi di supporto alla produzione sono chiari e le correzioni rapide hanno un percorso chiaro per la produzione
            <br> - Team e progetti utilizzano solo modelli AI approvati per uso aziendale</td>
            <td><b>All'interno della tua azienda:</b>
            <br> - Le segnalazioni di bug e le richieste di funzioni sono ad hoc
            <br> - Le voci su cui lavorare non hanno una chiara priorità
            <br> - Gli ambienti sono forniti ad hoc e potrebbero non essere aggiornati in modo prevedibile; gli sviluppatori spesso non dispongono degli ambienti e dell'accesso necessari
            <br> - I rilasci sono imprevedibili per i team di consegna e gli utenti
            <br> - I team non sanno chi è responsabile di cosa
            <br> - Hot-fix sono affrontati ad hoc
            <br> - Il tuo backlog è diventato una “banca delle idee” stantia e stagnante
            <br> - Gli organi di governance fungono da help desk per la risoluzione dei problemi delle richieste di assistenza
            <br> - La documentazione non è facilmente accessibile
            <br> - I team selezionano modelli AI ad hoc</td>
        </tr>
    </tbody>
</table>

## Manutenibilità

La manutenibilità significa che un sistema può essere mantenuto in uno stato sano, con l'introduzione di nuove funzioni e l'indebitamento tecnico che esce dal sistema su base regolare e prevedibile. I sistemi di manutenzione consentono ai team di offrire valore all'azienda con velocità e qualità prevedibili. La manutenibilità di un sistema dipende da diversi fattori, tra cui la leggibilità, l'accoppiamento e l'accuratezza della strategia di test.

Soprattutto, la manutenibilità di un sistema dipende dalla semplicità del suo design. Questa sezione descrive come creare soluzioni più semplici e aumentare la manutenibilità.

È possibile creare soluzioni più facili da gestire concentrandosi su due elementi chiave: l'utilizzo delle funzionalità standard rispetto a quelle personalizzate e la gestione del debito tecnico.

### Funzionalità standard e personalizzata

Salesforce offre una gamma di soluzioni predefinite (Sales Cloud, Service Cloud e molte soluzioni Salesforce per il settore) e la flessibilità di creare soluzioni personalizzate. I servizi di base che supportano le soluzioni cloud di Salesforce sono disponibili anche per tutte le soluzioni personalizzate create in Salesforce Customer 360 Platform. Utilizzare i servizi e le soluzioni predefinite di Salesforce come base affidabile per il maggior numero possibile di soluzioni.

L'utilizzo dei servizi piattaforma predefiniti presenta due vantaggi distinti. Innanzitutto, le app beneficiano naturalmente delle ultime innovazioni di Salesforce con ogni rilascio. In secondo luogo, i team di sviluppo possono concentrarsi sull'espansione e l'approfondimento delle funzionalità aziendali offerte dalle soluzioni Salesforce anziché gestire operazioni di sollevamento gravose di base dell'architettura.

Scegliere correttamente quando utilizzare le funzionalità standard e quando creare funzionalità personalizzate non è difficile da un punto di vista architettonico. Le chiavi sono:

- **Personalizzare la piattaforma significa modificare ed estendere, non copiare**. Durante la progettazione o la valutazione dell'architettura, è necessario chiedere: Esiste già in qualche punto della piattaforma Salesforce? Se la risposta è "_Sì, ma... \[inserire le modifiche desiderate da un stakeholder aziendale...]"_, utilizzare la funzione predefinita nella piattaforma. Il lavoro di architettura da eseguire consiste nell'identificare i modi più utili per configurare la funzione Salesforce predefinita in modo da soddisfare le aspettative aziendali.
- **Nessuna personalizzazione è banale**. Nel tempo, ogni modifica ha delle conseguenze. Se è necessario implementare una soluzione personalizzata, è possibile ridurre l'inevitabile [debito tecnico](/docs/architect/it-it/well-architected/guide/intentional#debito-tecnico) che il sistema accumulerà scegliendo di utilizzare una tecnologia low-code ogni volta che sia possibile e creando [unità componibili](/docs/architect/it-it/well-architected/guide/composable) nelle implementazioni.
- Si **consideri lo spettro build-buy**. [Salesforce AppExchange](https://appexchange.salesforce.com/) è un marketplace di app e soluzioni per estendere Salesforce. Le app AppExchange possono offrire funzionalità senza il sovraccarico necessario per creare e gestire una soluzione personalizzata. Durante la valutazione delle soluzioni AppExchange, tenere presente quanto segue:
  - Identificare le caratteristiche e le lacune della soluzione. L'ideale è trovare un'app che soddisfi tutti i requisiti aziendali. In realtà, potresti non trovare una misura perfetta. Durante la valutazione delle soluzioni, mappare le funzionalità della soluzione potenziale a un elenco prioritario di requisiti aziendali. Questo vi aiuterà a trovare la soluzione più adatta alle vostre esigenze più critiche.
  - Utilizzare i Sandbox e le versioni di prova gratuite. Utilizzare periodi di prova gratuiti per valutare le app negli ambienti Sandbox e identificare la soluzione migliore. Determinare se le app richiederanno modifiche alla configurazione in conflitto con la configurazione esistente.
  - Considerare i costi a breve e a lungo termine. Valutare i risparmi di manutenzione a lungo termine rispetto ai costi ricorrenti delle app basate su abbonamento. Evitare gli scenari in cui è necessario pagare costi ricorrenti per molte funzionalità che gli stakeholder aziendali non utilizzeranno mai.
- **Utilizzare i modelli di dati predefiniti di Salesforce.** Salesforce fornisce modelli di dati predefiniti per Sales, Service e una varietà di verticali di settore. L'utilizzo dei modelli di dati forniti da Salesforce garantisce che le funzionalità del sistema vengano definite una sola volta (eliminando ridondanza e silos), stabilisce un'unica fonte di dati in tutto il sistema, semplifica la comprensione dei dati delle applicazioni con gli analytics, semplifica l'utilizzo dei servizi di intelligenza artificiale predefiniti di Salesforce, riduce i costi di manutenzione (riducendo le personalizzazioni che è necessario supportare) e riduce l'indebitamento tecnico.

E' cosi' semplice. Come si può vedere negli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/intentional#modelli-di-manutenibilità-e-anti-schemi) riportati di seguito, gli antischemi si riducono a replicare le funzioni standard in una soluzione personalizzata o a utilizzare tecnologie più complesse per fornire personalizzazioni.

In pratica, si può verificare uno scenario in cui un anti-schema di funzionalità personalizzata viene considerato dagli stakeholder aziendali come la migliore o l'unica strada percorribile. In questi casi, è essenziale spiegare agli stakeholder i compromessi coinvolti nella scelta di questo percorso e quindi documentare in modo approfondito la decisione, la sua logica e la sua attuazione. Questo è anche un settore in cui fornire tempestivamente il valore chiave e adattarsi nel tempo può aiutare gli stakeholder a capire meglio come procedere.

Per ulteriori informazioni sugli strumenti Salesforce che possono aiutare a migliorare la manutenibilità, vedere [Strumenti pertinenti all'intenzionale](/docs/architect/it-it/well-architected/guide/intentional#strumenti-pertinenti-allintenzionale).

### Debito tecnico

Il debito tecnico è una parte naturale di qualsiasi sistema. I sound design di ieri possono diventare anti-schemi quando la tecnologia o le esigenze aziendali cambiano. È possibile che qualcosa creato per colmare una lacuna nelle funzionalità di Salesforce Platform diventi improvvisamente ridondante con un nuovo rilascio di Salesforce o il lancio di un prodotto. Forse una tecnologia più performante o flessibile sostituisce una tecnologia già implementata. Il debito tecnico può essere creato in molti modi.

Un vantaggio chiave della creazione di applicazioni con Salesforce Customer 360 Platform è la [compatibilità retroattiva integrata nella piattaforma](/docs/architect/it-it/fundamentals/guide/architecture-basics#api-piattaforma). Ciò significa che le nuove innovazioni della piattaforma possono modificare lo schema da utilizzare per le soluzioni in futuro, ma la funzione quotidiana delle soluzioni create sulle tecnologie Salesforce precedenti continuerà a funzionare. Con il tempo, qualsiasi soluzione basata su tecnologie più datate inizierà a comportare rischi o colli di bottiglia per l'aggiunta di nuove funzioni alle app e ridurrà lo stato generale della soluzione.

Pianificare ed eseguire lavori regolari per risolvere il debito tecnico è essenziale per mantenere progetti sani e semplici in una soluzione Salesforce. Non pianificare, controllare e correggere il debito tecnico è un modo sicuro per creare un sistema mal progettato.

Un modo per ridurre al minimo l'indebitamento tecnico è evitare di introdurlo il più possibile, evitando le scelte rapide e preferendo le [funzionalità standard alle funzionalità personalizzate](/docs/architect/it-it/well-architected/guide/intentional#funzionalità-standard-e-personalizzata). Le scelte rapide, come i valori codificati, possono essere tentate di risparmiare tempo, ma nel lungo termine creano un debito che deve essere ripagato.

Le chiavi per affrontare il debito tecnico da una prospettiva architettonica includono:

- Identificare il [costo o i](/docs/architect/it-it/resources/guide/kpi-spreadsheet-template) vantaggi effettivi dell'azione rispetto all'inazione
- [Roadmapping](/docs/architect/it-it/well-architected/guide/intentional#roadmapping) corretto
- Costruire [soluzioni componibili](/docs/architect/it-it/well-architected/guide/composable)

La difficoltà può essere quella di allineare gli stakeholder all'azione. Alcuni stakeholder possono percepire la manutenzione in corso come una soluzione agli “errori di ieri” o come un’eliminazione delle funzionalità che vogliono supportare con il budget.

Mostrare l'impatto reale dell'azione e dell'inazione sul business, insieme a risultati e tempistiche chiaramente definiti, può aiutare gli stakeholder a capire il valore e la priorità relativa della gestione del debito tecnico. Fare costantemente il lavoro per collegare il debito tecnico agli impatti sul business non solo aiuterà gli stakeholder a capire meglio il lavoro da fare. Ti aiuterà anche a essere sicuro di identificare e risolvere il debito tecnico in modi che vadano davvero a vantaggio degli utenti.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/intentional#modelli-di-manutenibilità-e-anti-schemi) riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione del debito tecnico per un'organizzazione Salesforce.

Per ulteriori informazioni sugli strumenti Salesforce che possono aiutare l'utente in caso di indebitamento tecnico, vedere [Strumenti pertinenti all'intenzionale](/docs/architect/it-it/well-architected/guide/intentional#strumenti-pertinenti-allintenzionale).

### Modelli di manutenibilità e anti-schemi

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per la manutenibilità in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/easy-maintainability).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="5"><b>Standard vs. Personalizzato</b></td>
            <td><b>Negli standard di progettazione:</b>
            <br> - C'è un chiaro principio guida per evitare inutili personalizzazioni
            <br> - Il principio guida per le soluzioni utilizza la seguente priorità: 1. Utilizzare i servizi piattaforma integrati, 2. Considerare le app AppExchange prima di creare una soluzione personalizzata, 3. Utilizzare personalizzazioni low-code prima di scrivere codice</td>
            <td><b>Negli standard di progettazione:</b>
            <br> - Gli standard di progettazione non esistono o non hanno una chiara logica per evitare personalizzazioni e codice non necessari</td>
        </tr>
        <tr>
            <td><b>Nella documentazione:</b>
            <br> - I record decisione mostrano il calcolo dei costi a breve e lungo termine quando si sceglie di creare o acquistare soluzioni</td>
            <td><b>Nella documentazione:</b>
            <br> - I record decisione non considerano i costi sia a breve che a lungo termine quando si sceglie di creare o acquistare soluzioni</td>
        </tr>
        <tr>
            <td><b>Nei modelli di dati:</b>
            <br> - Nessun oggetto ha nomi o funzionalità che duplicano oggetti standard
            <br> - Gli oggetti standard non vengono utilizzati per scopi che esulano dall'ambito previsto</td>
            <td><b>Nei modelli di dati:</b>
            <br> - Gli oggetti duplicano i nomi e/o le funzionalità degli oggetti standard
            <br> - Gli oggetti standard vengono utilizzati per scopi ben al di fuori dell'ambito previsto</td>
        </tr>
        <tr>
            <td><b>In LWC, Aura o Visualforce:</b>
            <br> - Non esiste codice per ignorare i meccanismi di visualizzazione pagina standard</td>
            <td><b>In LWC, Aura o Visualforce:</b>
            <br> - Il codice esiste per ignorare i meccanismi di visualizzazione pagina standard, spesso sotto forma di app a pagina singola</td>
        </tr>
        <tr>
            <td><b>In LWC, Aura o Apex:</b>
            <br> Nessun tentativo di codice di ignorare o aggirare l'ordine di esecuzione della piattaforma</td>
            <td><b>In LWC, Aura o Apex:</b>
            <br> - Il codice tenta di ignorare o aggirare l'ordine di esecuzione della piattaforma</td>
        </tr>
        <tr>
            <td rowspan="3"><b>Debito tecnico</b></td>
            <td><b>Nella roadmap:</b>
            <br> - È previsto un lavoro per affrontare il debito tecnologico
            <br> - Le consegne e le date di inizio/fine sono chiare</td>
            <td><b>Nella roadmap:</b>
            <br> - Non è previsto alcun lavoro per risolvere il debito tecnologico
            <br> - Le consegne sono vaghe; le date di inizio/fine non sono chiare</td>
        </tr>
        <tr>
            <td><b>Nei record decisione:</b>
            <br> - I KPI per la correzione del debito pre-/post-tech sono chiaramente documentati
            <br> Le discussioni di compromesso per l'azione e l'inazione si concentrano sui costi o sui vantaggi aziendali</td>
            <td><b>Nei record decisione:</b>
            <br> - La correzione del debito tecnologico non ha KPI misurabili
            <br> Il debito tecnologico è considerato in termini tecnici o IT, senza rilevanza per il business</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Nessuna tecnologia legacy o non supportata è attiva, inclusi:
            <br> -- Tutti gli utenti lavorano in Lightning Experience
            <br> -- nessun o pochissimo uso di <code>@future</code> in Apex (viene usato Queueable)
            <br> -- Tutto Apex di terze parti appartiene ai pacchetti AppExchange
            <br> -- nessuna regola di flusso di lavoro attiva (viene utilizzato il flusso)
            <br> -- nessun processo Process Builder attivo (viene utilizzato il flusso)
            <br> -- Eventi PushTopic (viene utilizzata l'acquisizione dati di modifica)
            <br> -- Eventi generici (vengono utilizzati gli eventi piattaforma)
            <br> -- Versioni API precedenti alla 30.0
            <br> -- Le connessioni organizzazione Salesforce utilizzano l'adattatore tra organizzazioni per Salesforce Connect</td>
            <td><b>Nella propria organizzazione:</b>
            <br> La tecnologia non supportata o legacy è attiva, inclusi:
            <br> -- Utenti che lavorano in Salesforce Classic
            <br> -- uso <code>di @future</code> in Apex
            <br> -- Apex di terze parti da fonti non AppExchange
            <br> -- Regole di flusso di lavoro
            <br> -- Processi di Process Builder
            <br> -- PushTopic Events
            <br> -- Eventi generici
            <br> -- Versioni API precedenti alla 30.0
            <br> -- Connessioni da Salesforce a Salesforce</td>
        </tr>
    </tbody>
</table>

## Leggibilità

Alla base, il concetto di _leggibilità_ consiste nel creare coerenza che consenta alle persone di capire facilmente come funzionano le cose. La creazione di sistemi leggibili allinea i team di consegna e manutenzione e aiuta le persone che non hanno familiarità con il sistema a capire rapidamente come si inseriscono i pezzi. Ciò significa che il team può essere meno dipendente da singole persone con Knowledge istituzionali o storiche per integrare efficacemente i fornitori o i nuovi membri del team. Ciò significa che le persone esperte di un team possono concentrarsi sulla qualità e sui compromessi delle scelte che vengono effettuate, poiché la configurazione e il codice del sistema sono facili da leggere e comprendere. La leggibilità può velocizzare i processi di governance e di controllo della qualità e aiutare i team a identificare meglio quando potrebbero creare personalizzazioni ridondanti. Può anche aumentare le possibilità di avere un sistema che si comporta in modo riutilizzabile e testabile.

È possibile migliorare la leggibilità tramite standard di progettazione e documentazione efficaci.

### Design Standards

Gli [standard di progettazione](/docs/architect/it-it/resources/guide/design-standards-template) forniscono indicazioni per mantenere coerenti tutte le personalizzazioni, anche nelle prime fasi di sviluppo. Gli standard di progettazione funzionano come guardrail, mantenendo allineati tutti i team di consegna e i team di manutenzione che lavorano sul sistema su come approcciare e implementare le personalizzazioni. La definizione di standard di progettazione consente di aumentare la produttività dei team di consegna e manutenzione, semplifica le revisioni del codice e dell'architettura e fornisce una base per una migliore [documentazione](/docs/architect/it-it/well-architected/guide/intentional#documentazione).

Senza standard di progettazione, i team hanno maggiori probabilità di lavorare in silos. Senza la coerenza offerta dagli standard di progettazione, le aziende si troveranno alle prese con:

- Venditori e team di sviluppo che utilizzano schemi e approcci ad hoc nelle soluzioni, potenzialmente introducendo schemi anti-schema e riducendo la riutilizzabilità (vedere [Separazione delle preoccupazioni](/docs/architect/it-it/well-architected/guide/composable#separazione-delle-preoccupazioni)).
- Maggiore tempo per risolvere i problemi di produzione e team di assistenza necessari per inserire nuovi membri del team e aiutarli a comprendere una serie di schemi e approcci diversi.
- Scarsa collaborazione tra i team, ridondanze nel lavoro tra i team, tempo perso per risolvere i conflitti e bug rilevati durante i test di integrazione.
- Aumento della frustrazione e tassi di turnover più elevati.

Un vantaggio chiave degli standard di progettazione deriva dalle conversazioni e dalle decisioni che gli stakeholder devono prendere per crearli. Nello specifico, il processo offre ai lead aziendali e tecnologici l'opportunità di allinearsi su come si presenta la progettazione ottimale per la propria azienda.

Includere i seguenti elementi negli [standard di progettazione](/docs/architect/it-it/resources/guide/design-standards-template)

- **Convenzioni di denominazione per i metadati Salesforce**. Definire un insieme di convenzioni per il nome di ogni personalizzazione di un sistema. Le convenzioni di denominazione corrette non si limitano a imporre la coerenza tra i nomi di oggetti, campi, codice, flussi e altri elementi del sistema. Convenzioni di denominazione valide aiutano anche i team di sviluppo a utilizzare nomi che trasmettono informazioni sullo scopo e la funzionalità di ciò che stanno creando. Di conseguenza, gli altri stakeholder possono comprendere meglio una determinata personalizzazione, semplicemente visualizzandone il nome.
- **Modelli di progettazione approvati e relativi casi d'uso**. Creare una libreria di [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/patterns), insieme alle informazioni chiave su quando (e quando non) utilizzare ogni schema. La libreria può includere schemi di trigger Apex richiesti o schemi di orchestrazione dei flussi basati sulla [componibilità](/docs/architect/it-it/well-architected/guide/composable) desiderata nel sistema.
- **Ambiente di sviluppo e guida**. Mantenere un elenco chiaro degli strumenti che i team di sviluppo devono utilizzare per il proprio lavoro. Ciò potrebbe includere catene di strumenti e lingue approvate per chiunque scriva codice o funzioni dichiarative approvate (o non approvate) per lo sviluppo di codice basso. Gli standard possono includere un elenco di sistemi di controllo sorgente per la personalizzazione e la documentazione e le fasi di check-in/check-out obbligatori. Possono anche includere un elenco di ambienti da utilizzare per diversi tipi di lavoro di sviluppo.

Oltre a definire questi standard, sarà necessario decidere come e dove mantenerli e archiviarli. Se i team di tutta l'azienda non riescono a trovare gli standard di progettazione (o non ne sono nemmeno consapevoli), non saranno efficaci. L'ideale è che gli standard di progettazione siano integrati nello stesso sistema della documentazione (per ulteriori informazioni, vedere la sezione successiva).

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/intentional#modelli-di-leggibilità-e-anti-schemi) riportato di seguito mostra l'aspetto degli standard di progettazione corretti (e scadenti) per un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare gli standard di progettazione.

Per ulteriori informazioni sugli strumenti Salesforce che possono aiutare a definire gli standard di progettazione, vedere [Strumenti pertinenti all'intenzionale](/docs/architect/it-it/well-architected/guide/intentional#strumenti-pertinenti-allintenzionale).

### Documentazione

La documentazione spiega cosa, come e perché del sistema. Senza una documentazione significativa e coerente, i team perdono molto tempo a cercare di capire il sistema così com'è (e potenzialmente fraintendere le funzioni e le personalizzazioni).

La creazione di una buona documentazione richiede tempo. Benché la maggior parte dei team sia d'accordo sul fatto che la documentazione sia importante per i progetti di grandi dimensioni, può essere un passo allettante da saltare quando si apportano modifiche rapide come aggiornamenti di configurazione o piccole modifiche a un'automazione. Non documentare le modifiche apportate al sistema è sempre un anti-schema. Ignorare la documentazione può far risparmiare un po' di tempo in anticipo, ma la quantità di tempo necessaria per risolvere i problemi di un'organizzazione non adeguatamente documentata annulla ampiamente tali risparmi di tempo. Includere sempre tempo sufficiente per creare la documentazione in tutte le stime, indipendentemente dal livello di impegno richiesto per gli aggiornamenti che si prevede di eseguire.

La mancanza di una documentazione chiara può causare una serie di problemi, tra cui:

- Cicli di sviluppo spesi per rielaborare implementazioni esistenti
- Discussioni ripetitive che rivedono o sconcertano le decisioni precedenti
- Onboarding più lungo per i nuovi membri del team o fornitori
- Eccessiva dipendenza da individui con Knowledge istituzionali o storiche
- Architetture ridondanti per supportare le stesse funzionalità o funzionalità simili in tutta l'azienda
- Difficoltà a comunicare lo scopo e il valore della soluzione ai principali stakeholder

Per le soluzioni Salesforce, conservare la documentazione per:

- **Panoramica delle soluzioni**. I [diagrammi](/docs/architect/it-it/reference-diagrams/guide/introduction) consentono all'utente e ai suoi stakeholder di visualizzare le soluzioni a vari livelli di dettaglio. Il framework del diagramma di Salesforce consente di creare diagrammi che mostrano le funzionalità aziendali delle soluzioni e i dettagli tecnici dell'implementazione.
- **Record decisioni**. Tenere un registro delle opzioni considerate, dei compromessi, della decisione finale e del ragionamento in una posizione centrale a cui tutti i membri del team possono accedere per riferimento futuro.
- **Codice**. Il formato stesso del codice è un elemento chiave della documentazione e questo può (e deve) allinearsi agli [standard di progettazione](/docs/architect/it-it/well-architected/guide/intentional#design-standards). Si desidera anche avere un registro delle informazioni chiave e aggiornarlo con ogni modifica di un frammento di codice. Per tutte le classi, i trigger e i componenti, documentare quanto segue:
  - Chi ha creato il codice
  - Quando è stato scritto il codice
  - Cosa dovrebbe fare il codice
  - Dipendenze chiave
  - Tutte le modifiche
- **Personalizzazione dichiarativa**. Per ogni tipo di personalizzazione che può essere apportata ai metadati nell'organizzazione, Salesforce fornisce [attributi incorporati](/docs/architect/it-it/fundamentals/guide/platform-multitenant-architecture#sviluppo-di-applicazioni-basate-su-browser-senza-codice-e-low-code) che consentono ai team di fornire informazioni utili sullo scopo e l'intento dei metadati. Nell'ambito degli standard di progettazione, includere le modalità di utilizzo di queste funzioni incorporate da parte dei team e la denominazione delle personalizzazioni dichiarative. Mantenere anche un registro delle informazioni chiave identico a quello utilizzato per il codice.

Sviluppare una serie di standard di documentazione per garantire che tutti i membri attuali e futuri del team siano in grado di interpretare i documenti allo stesso modo (gli [standard di progettazione](/docs/architect/it-it/resources/guide/design-standards-template) possono essere utili in questo caso). È anche importante considerare in che modo gli utenti potranno cercare nella documentazione per trovare sezioni o termini pertinenti. Man mano che il sistema invecchia e diventa più complesso, crescerà anche la documentazione. L'utilità delle informazioni nella documentazione sarà direttamente correlata alla frequenza, alla rapidità e alla facilità con cui gli utenti possono cercare e trovare gli elementi pertinenti.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/intentional#modelli-di-leggibilità-e-anti-schemi) riportato di seguito mostra l'aspetto della documentazione corretta (e scarsa) per un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare la strategia di documentazione.

Per ulteriori informazioni sugli strumenti Salesforce per la documentazione, vedere [Strumenti pertinenti all'intenzionale](/docs/architect/it-it/well-architected/guide/intentional#strumenti-pertinenti-allintenzionale).

### Modelli di leggibilità e anti-schemi

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri modelli per la leggibilità in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/easy-readability).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="2"><b>Standard di progettazione</b></td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Il codice e le personalizzazioni dichiarative hanno nomi coerenti e leggibili
            <br> - I modelli di dati hanno nomi coerenti e uniformi per oggetti e campi
            <br> - I controlli mostrano che i campi sono compilati in modo coerente e vi si fa riferimento nei rapporti, ecc.</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Il codice e le personalizzazioni dichiarative non hanno nomi coerenti
            <br> - I modelli di dati hanno nomi incoerenti e molti oggetti e campi sembrano essere ridondanti
            <br> - I controlli mostrano molti campi inutilizzati o vari livelli di utilizzo e non esiste un collegamento coerente ai rapporti, ecc.</td>
        </tr>
        <tr>
            <td><b>All'interno della tua azienda:</b>
            <br> - I team sanno quali strumenti utilizzare (e non utilizzare) per completare il lavoro
            <br> - I modelli di progettazione approvati sono facili da trovare e identificare in base al caso d'uso
            <br> - I modelli AI approvati sono chiaramente identificati e includono uno scopo previsto</td>
            <td><b>All'interno della tua azienda:</b>
            <br> - I team utilizzano molti strumenti diversi per eseguire lavori simili
            <br> - Non ci sono modelli di progettazione approvati
            <br> - Richiede molto tempo per i fornitori o i nuovi dipendenti per l'inserimento
            <br> - I modelli AI approvati non sono chiaramente identificati e il loro scopo previsto non è chiaro</td>
        </tr>
        <tr>
            <td rowspan="2"><b>Documentazione</b></td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Il codice e le personalizzazioni dichiarative hanno descrizioni chiare</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Il codice e le personalizzazioni dichiarative non hanno descrizioni, hanno descrizioni difficili da capire o hanno descrizioni che non sembrano corrispondere a ciò che la personalizzazione sta effettivamente facendo</td>
        </tr>
        <tr>
            <td><b>All'interno della tua azienda:</b>
            <br> - Esistono diagrammi per le funzionalità aziendali e dettagli tecnici di implementazione per tutte le soluzioni
            <br> - Key chi/quando/quali registri di informazioni esistono per il codice e le personalizzazioni dichiarative
            <br> - Le persone possono cercare e trovare la documentazione pertinente</td>
            <td><b>All'interno della tua azienda:</b>
            <br> - Il cosa/come/perché delle soluzioni è difficile da trovare e potrebbe non essere disponibile per la maggior parte dei team
            <br> - Le persone faticano a capire le soluzioni e il sistema con cui stanno lavorando
            <br> - Richiede molto tempo per i fornitori o i nuovi dipendenti per l'inserimento</td>
        </tr>
    </tbody>
</table>

## Strumenti pertinenti all'intenzionale

<table class="tools-table"><tbody><tr><th>Strumento</th><th>Descrizione</th><th>Strategia</th><th>Manutenibilità</th><th>Leggibilità</th></tr>
<tr><td><a href="https://github.com/SalesforceFoundation/ApexDoc">ApexDoc</a></td><td>Apex documento con pagine HTML statiche</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_picklist_delete_inactive_values.htm&language=en_US&type=5&_ga=2.216886358.1142927923.1683068265-1808100124.1682614163">Eliminazione in blocco di valori di elenchi di selezione inattivi</a></td><td>Eliminare i valori inattivi inutilizzati dagli elenchi di selezione</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/tools/validator/">Convalidatore del sistema Lightning Design</a></td><td>Convalida il markup e scopri come migliorare il codice</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_mgmt_migrate_to_flow_tool.htm&type=5&release=242&_ga=2.180751207.1142927923.1683068265-1808100124.1682614163">Migrazione al flusso</a></td><td>Conversione delle regole di flusso di lavoro e dei processi di Process Builder in flussi</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3u00000MRsKnEAL">Strumento di gestione dei progetti di Salesforce Labs</a></td><td>Gestione dei progetti nell'organizzazione Salesforce</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-expanded">Estensioni Salesforce per Visual Studio Code (espanse)</a></td><td>Analisi efficiente del codice Salesforce con le estensioni Visual Studio Code</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://sfdc.co/OrgCheck">Controllo organizzazione</a></td><td>Analisi rapida dell'organizzazione e del relativo debito tecnico</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://github.com/forcedotcom/code-analyzer">Analizzatore di codice Salesforce</a></td><td>Scansionare il codice tramite IDE, CLI o CI/CD per assicurarsi che rispetti le procedure consigliate</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://architect.salesforce.com/roadmaps/roadmap-explorer">Explorer roadmap Salesforce</a></td><td>Esplorazione delle innovazioni dei prodotti Salesforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5">Percorso di controllo impostazioni</a></td><td>Monitoraggio delle modifiche alle impostazioni e della cronologia di controllo</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## Risorse pertinenti all'intenzionale

<table class="tools-table"><tbody><tr><th>Risorsa</th><th>Descrizione</th><th>Strategia</th><th>Manutenibilità</th><th>Leggibilità</th></tr>
<tr><td><a href="https://www.salesforce.com/blog/documentation-strategies-to-improve-your-salesforce-org/">5 strategie di documentazione per migliorare l'organizzazione Salesforce</a></td><td>Miglioramento della documentazione sull'implementazione di Salesforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/choose-naming-conventions-sc">Scegliere le convenzioni di denominazione (Trailhead)</a></td><td>Informazioni sull'applicazione delle convenzioni di denominazione</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/defining-identifying-and-measuring-technical-debt-5f783e2b381d">Definizione, identificazione e misurazione del debito tecnico</a></td><td>Definire, identificare e misurare il debito tecnico</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/design-standards-template">Modello Design Standards (Standard di progettazione)</a></td><td>Creare standard di progettazione per l'organizzazione</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/diagrams">Suggerimenti introduttivi sui diagrammi Salesforce</a></td><td>Informazioni su come creare il diagramma giusto per il proprio caso d'uso</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/get-started-with-coding-conventions-sc">Iniziare con le convenzioni di codifica (Trailhead)</a></td><td>Definire e seguire le convenzioni di codifica</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/trailblazer-community/download/file/0693A000006PskRQAS">Come affrontare il debito tecnico (Trailhead)</a></td><td>Gestione del debito tecnico nell'organizzazione Salesforce</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/improve-your-apex-code-sc">Migliorare il proprio Apex Code (Trailhead)</a></td><td>Applicare i principi di base dello sviluppo basato su test</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">Allineamento dell'organizzazione (Trailhead)</a></td><td>Informazioni sul processo V2MOM per l'allineamento</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/prioritizing-and-planning-a-way-out-of-technical-debt-6f18fbb2b007">Dare priorità e pianificare una via d'uscita dal debito tecnico</a></td><td>Creare un piano per ridurre e rimuovere il debito tecnico</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://salesforce.quip.com/MW5cAPVwat8k#JCIACA8Q963">Modello Convenzioni di denominazione Salesforce</a></td><td>Suggerimenti introduttivi sulle convenzioni di denominazione</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td>Debito <a href="https://admin.salesforce.com/blog/2021/tech-debt-what-it-is-and-why-you-should-care">tecnico: Che cos'è e perché dovrebbe interessarti? </a></td><td>Comprendere l'impatto del debito tecnico nell'organizzazione</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/using-the-business-model-canvas-in-enterprise-architecture-5c136803a99d">Utilizzo dell'area di disegno del modello di business nell'architettura aziendale</a></td><td>Creare, fornire e visualizzare valore in un modello di business</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
</table>

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.

<!-- document id=4d72b63db9d67c243a8331c035288ed0bdfa09716d98becba9abee0acae4588a url=/architect/next/it-it/well-architected/guides/overview.md -->

## Introduzione

<image style="width:100%;padding-top:1rem;padding-bottom:1rem;" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/framework2023-7.png" alt="Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable">

Salesforce Well-Architected Framework mostra l'aspetto della salute e dove trascorrere il proprio tempo a mappare e progettare soluzioni con Salesforce Customer 360 Platform. Condivide indicazioni prescrittive ed esempi di schemi e anti-schemi da cercare nel panorama, in base alla Knowledge dei team di prodotto e degli esperti di implementazione di Salesforce e del nostro ecosistema. Salesforce Well-Architected è organizzato per aiutare l'utente a creare soluzioni affidabili, facili e adattabili.

Soluzioni **affidabili** proteggono gli stakeholder. <br>
Le soluzioni **semplici** offrono valore velocemente. <br>
Le soluzioni **adattabili** evolvono con l'azienda. <br>

Salesforce Well-Architected è stato progettato per aiutare l'utente a sviluppare le idee architettoniche necessarie per creare soluzioni efficaci in Customer 360 Platform.

Una sfida unica per gli architetti che creano soluzioni con Salesforce è la flessibilità fondamentale della piattaforma. Una soluzione potrebbe estendere una soluzione predefinita offerta da Salesforce (ad esempio Sales Cloud, Service Cloud, diversi verticali di Industries Cloud). Un'altra soluzione potrebbe essere un'applicazione completamente personalizzata. Quello che si può fare con Salesforce è ampio e approfondito e le scelte tecnologiche specifiche più adatte alla propria implementazione dipenderanno dalle esigenze aziendali. Può essere estremamente difficile sapere che cosa creerà le migliori possibilità di salute a lungo termine per ogni possibile soluzione Salesforce.

Salesforce Well-Architected offre approfondimenti e indicazioni da parte di architetti esperti in base alle esigenze. È possibile utilizzare le opinioni e i consigli per convalidare (o sfidare) il proprio pensiero e ottenere informazioni su aree di considerazione o tecnologie che potrebbero essere nuove per l'utente.

Può anche essere difficile capire se esistono benchmark architettonici comuni a tutte le soluzioni sane, data l'ampia varietà tra le varie implementazioni. In Salesforce, tutto ciò che facciamo come azienda e come persone è guidato dai nostri valori fondamentali. Crediamo che questo possa valere anche per l'architettura. Ecco perché Salesforce Well-Architected è basato su un nucleo di componenti affidabili, facili e adattabili. Quando si valutano dettagli architettonici complessi e compromessi, è possibile tornare a queste funzionalità principali e utilizzarle come punti di riferimento per guidare il processo decisionale.

Di seguito sono riportati i dettagli sui singoli argomenti da esplorare nel framework Affidabile, facile e adattabile.

## Disposizione degli argomenti

Vengono utilizzati due livelli per organizzare le informazioni in Salesforce Well-Architected. Il livello massimo è quello che dovrebbero essere le soluzioni ben progettate: Affidabile, facile e adattabile. Il secondo livello approfondisce le considerazioni, gli schemi da creare (o gli schemi anti-pattern da evitare) e le indicazioni prescrittive relative ad aspetti specifici delle soluzioni affidabili, facili e adattabili. Allineare i progetti alle indicazioni fornite in questo framework dovrebbe migliorare la qualità e la durata delle applicazioni Salesforce Customer 360.

💡 Vuoi iniziare velocemente con schemi e anti-schemi? Visitare l'[Explorer schemi e antischegge](/docs/architect/it-it/well-architected-tools/guide/patterns).

Di seguito è riportata una panoramica della disposizione degli argomenti:

<table style="border-color:white;">
    <colgroup>
       <col span="1" style="width: 33%;">
       <col span="1" style="width: 34%;">
       <col span="1" style="width: 33%;">
    </colgroup>
    <tbody>
            <tr>
                <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/trusted-overview">Fiduciato</a></th>
            </tr>
            <tr>
                <td colspan="3"> Una soluzione affidabile protegge l'azienda e gli stakeholder.</td>
            </tr>
            <tr>
                <th><a href="/docs/architect/it-it/well-architected/guide/secure">Sicuro</a></th>
                <th><a href="/docs/architect/it-it/well-architected/guide/compliant">Conforme</a></th>
                <th><a href="/docs/architect/it-it/well-architected/guide/reliable">Affidabile</a></th>
            </tr>
            <tr>
                <td>Sicurezza organizzativa<br>Sicurezza della sessione<br>Sicurezza dei dati</td>
                <td>Aderenza giuridica<br>Standard etici<br>Accessibilità</td>
                <td>Disponibilità<br>Prestazioni<br>Scalabilità</td>
            </tr>
            <tr>
                <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/easy-overview">Facile</a></th>
            </tr>
            <tr>
            <td colspan="3">Una soluzione semplice offre rapidamente valore aziendale.</td>
            </tr>
            <tr>
                <th><a href="/docs/architect/it-it/well-architected/guide/intentional">Intenzionale</a></th>
                <th><a href="/docs/architect/it-it/well-architected/guide/automated">Automatizzato</a></th>
                <th><a href="/docs/architect/it-it/well-architected/guide/engaging">Coinvolgimento</a></th>
            </tr>
            <tr>
                <td>Strategia<br>Manutenibilità<br>Leggibilità</td>
                <td>Efficienza<br>Integrità dei dati</td>
                <td>Semplificato<br>Utile</td>
            </tr>
            <tr>
                <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/it-it/well-architected/guide/adaptable-overview">Adattabile</a></th>
            <tr>
                <td colspan="3">Una soluzione adattabile si evolve con l'azienda.</td>
            </tr>
            <tr>
                <th colspan="2"><a href="/docs/architect/it-it/well-architected/guide/resilient">Resiliente</a></th>
                <th><a href="/docs/architect/it-it/well-architected/guide/composable">Componibile</a></th>
            </tr>
            <tr>
                <td colspan="2">Gestione del ciclo di vita delle applicazioni<br>Risposta incidente<br>Pianificazione della continuità</td>
                <td>Separazione delle preoccupazioni<br>Interoperabilità<br>Inserimento in pacchetti</td>
            </tr>
    </tbody>
 </table>

<!-- document id=16ab1dcfcb88070f7d560285c69643656d52a1d0ff2b9361ac292dc7af425159 url=/architect/next/it-it/well-architected/guides/resilient.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

Le soluzioni resilienti mantengono un'alta qualità del servizio anche in caso di errori. Se le prestazioni peggiorano o il servizio viene interrotto, la soluzione viene ripristinata in modo rapido ed efficace.

La resilienza di una soluzione si basa su due qualità chiave:

- **Durezza**: Quando si verificano problemi, la soluzione li resiste e li sopporta.
- **Elasticità**: Una volta risolti i problemi, la soluzione torna allo stato o alla forma ideale.

Per progettare la soluzione per la resilienza, è necessario progettare sia per la resistenza che per l'elasticità, garantendo sia la durata che il rapido recupero a fronte di cambiamenti pianificati e non pianificati.

Nei contesti tecnologici, considerare un sistema o una soluzione come un insieme di componenti interdipendenti che si coordinano per raggiungere obiettivi condivisi. Ogni componente potrebbe non funzionare. Problemi all'interno di questi componenti, dal codice e dai difetti di configurazione ai problemi di rete e hardware, possono causare comportamenti imprevisti e indesiderati. Un sistema dimostra un comportamento resiliente quando uno o più componenti si guastano, ma l'intero sistema continua a funzionare o torna rapidamente a uno stato stabile.

Per migliorare la resilienza delle soluzioni Salesforce, si consiglia di concentrarsi su tre abitudini chiave.

- [**Application Lifecycle Management (ALM)**](/docs/architect/it-it/well-architected/guide/resilient#gestione-del-ciclo-di-vita-delle-applicazioni): come i team gestiscono il software durante tutto il suo ciclo di vita, dall'ideazione al ritiro
- [**Risposta agli incidenti**](/docs/architect/it-it/well-architected/guide/resilient#risposta-incidente): come i team identificano, risolvono e prevengono i problemi che influiscono sulla disponibilità o la sicurezza di un sistema
- [**Pianificazione della continuità**](/docs/architect/it-it/well-architected/guide/resilient#pianificazione-della-continuità): come i team pianificano che le persone e i sistemi continuino a funzionare quando eventi non pianificati causano problemi

## Gestione del ciclo di vita delle applicazioni

La gestione del ciclo di vita delle applicazioni (ALM, Application Lifecycle Management) è una pratica per la gestione olistica del software in tutto il suo ciclo di vita, dalla creazione al ritiro. ALM è una pietra angolare della resilienza del sistema e comprende persone, processi, strumenti e discipline relativi al ciclo di vita dell'applicazione. Queste discipline includono DevOps e metodologie di consegna, osservabilità, strategie di test, governance e CI/CD.

Quando un'azienda pratica un ALM efficace, i suoi team reagiscono rapidamente ai cambiamenti e le sue applicazioni stanno al passo con l'evoluzione dei requisiti aziendali senza compromettere la stabilità o la qualità.

D'altra parte, senza un'ALM sana, i team faticano in ogni fase del ciclo di vita dell'applicazione.

I sintomi di ALM scarsa includono:

- Cicli di sviluppo lenti e soggetti a errori
- Implementazioni intensive e difficili
- Problemi o bug di elevata gravità rilevati in ambienti di produzione e post-QA
- Agenti AI che hanno allucinazioni o comportamenti incoerenti
- Ritiri frequenti o distribuzioni di hotfix necessari per stabilizzare i rilasci

Poiché ALM riguarda quasi ogni aspetto di una soluzione, stabilire procedure ALM chiare ed efficaci per la soluzione è una parte fondamentale del lavoro architettonico.

Creare procedure ALM migliori concentrandosi su tre aree chiave.

- [**Gestione dei rilasci**](/docs/architect/it-it/well-architected/guide/resilient#gestione-dei-rilasci): pianificazione, sequenza, controllo e migrazione delle modifiche in ambienti diversi
- [**Strategia ambientale**](/docs/architect/it-it/well-architected/guide/resilient#strategia-ambientale): una strategia per l'utilizzo e la gestione delle applicazioni negli ambienti di destinazione durante lo sviluppo e i test
- [**Strategia di segnalazione**](/docs/architect/it-it/well-architected/guide/resilient#strategia-di-segnalazione): definizione dei segnali critici e della strumentazione dell'applicazione utilizzata per rilevare e risolvere i guasti all'interno del sistema prima che si verifichi il degrado
- [**Strategia di test**](/docs/architect/it-it/well-architected/guide/resilient#strategia-di-test): i principi e gli standard che guidano la pianificazione e l'esecuzione dei test per valutare il successo delle applicazioni durante i processi ALM

### Gestione dei rilasci

La gestione dei rilasci prevede la pianificazione, la sequenza, il controllo e la migrazione delle modifiche in uno o più ambienti. Un singolo rilascio è un gruppo di modifiche pianificate che un team sposta contemporaneamente in un ambiente di destinazione.

Il rilascio di una modifica a un sistema comporta dei rischi. Se il sistema è in uno stato stabile prima della modifica, passa a un nuovo stato, dove è anche più vulnerabile ai rischi derivanti da modifiche future. Se modifiche future attivano uno stato incontrollato e instabile nel sistema, possono causare un incidente critico. In un'architettura di soluzioni, progettare rilasci resilienti non è solo [testare efficacemente singole modifiche](/docs/architect/it-it/well-architected/guide/resilient#strategia-di-test). Include anche la pianificazione di come introdurre modifiche ai sistemi e ai relativi utenti in modo sicuro.

Il lavoro svolto dai team dipende da informazioni sul rilascio prevedibili e accurate. Nei processi di gestione e abilitazione del cambiamento, indicare chiaramente quali modifiche possono essere apportate al sistema. Nei processi di gestione e abilitazione dei rilasci, specificare come e con quale frequenza vengono rilasciate le modifiche al sistema.

Anche gli stakeholder aziendali si preoccupano delle informazioni sui rilasci, soprattutto se sono correlate a funzioni o correzioni di bug che richiedono. Per creare Trust nella soluzione e dimostrare valore agli stakeholder, stabilire pianificazioni di rilascio coerenti e chiare e artefatti di rilascio della spedizione stabili.

Per stabilire una gestione dei rilasci efficace per Salesforce:

- **Allinearsi strettamente alla governance dell'architettura e dello sviluppo**. Assicurarsi che i rilasci siano pianificati con largo anticipo per allinearsi a tutti i forum e i controlli di governance pertinenti. Prima di iniziare lo sviluppo, fare in modo che tutti i casi d'uso Agentforce con priorità vengano rivisti e approvati dal Consiglio AI. Utilizzare gli elenchi di controllo e la documentazione della distribuzione per tenere traccia degli elementi della distribuzione, ad esempio i nomi API degli agenti Agentforce, rispetto alle attività di governance.
- **Non utilizzare [processi di sviluppo](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)**. Questo paradigma riflette le tecnologie più datate e limitate per lo sviluppo e il rilascio. Con Salesforce CLI, i team possono ora adottare funzionalità di sviluppo e rilascio basate sui sorgenti.
- **Scegliere il meccanismo di rilascio più stabile possibile**. Questo approccio realizza due cose. Innanzitutto, riduce al minimo la durata delle finestre di rilascio e delle interruzioni del servizio. In secondo luogo, consente comportamenti di rilascio altamente controllati e prevedibili. Più stabile è il meccanismo di rilascio, meno è probabile che i rilasci introducano modifiche che richiedono aggiornamenti rapidi o ritiri. In caso di problemi imprevisti, i meccanismi di rilascio stabili consentono anche al personale di assistenza o agli amministratori di sistema di eseguire i rollback in modo più semplice.

I meccanismi di rilascio migliori per il team sono le opzioni più stabili per cui il team ha le competenze richieste. Di seguito sono elencati i meccanismi di rilascio consigliati, elencati in ordine di stabilità. Poiché sono tutti compatibili tra loro, utilizzarne diversi in tandem, se è meglio per la propria azienda.

- [**Pacchetti sbloccati**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm): i pacchetti sbloccati sono l'artefatto rilascio più stabile. La distribuzione delle modifiche tramite l'installazione di un pacchetto è il modo più rapido e prevedibile per introdurre le modifiche. I pacchetti utilizzano il controllo delle versioni, che consente una gestione efficace delle modifiche e un rollback preciso e intuitivo per l'amministratore di sistema. Inoltre, i pacchetti richiedono una gestione avanzata dei metadati, che può aiutare a identificare precocemente le dipendenze gestite in modo errato. Creano anche pipeline di sviluppo e artefatti controllabili. Vedere [Pacchetto](/docs/architect/it-it/well-architected/guide/composable#inserimento-in-pacchetti).
- [**DevOps Center**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5): DevOps Center consente ai team di consegna con competenze a basso codice o pro-codice di utilizzare il controllo sorgente, lavorare in collaborazione sulle modifiche e definire percorsi di rilascio comuni. DevOps Center si integra con il controllo sorgente e consente il controllo "point-and-click" delle modifiche e delle distribuzioni.
- **Sviluppo e distribuzione dei metadati basati sulla fonte utilizzando [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli)**: se non è possibile utilizzare i pacchetti, utilizzare Salesforce CLI per lo sviluppo e la distribuzione dei metadati basati sulla fonte. Non distribuire i metadati utilizzando il formato package.xml precedente, che segue una struttura diversa rispetto al [formato di origine](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm) consigliato. Il formato di origine si è evoluto per supportare lo sviluppo di pacchetti, flussi di lavoro di organizzazioni vuote e un tracciamento delle modifiche più dettagliato nei Sandbox. Il formato è più leggibile, consente un maggiore disaccoppiamento dei tipi di metadati complessi e delle dipendenze e offre un controllo molto maggiore sui manifesti di distribuzione.
- **Date un nome**. Assegnare ai rilasci identificatori chiari per aiutare i team e gli stakeholder a rimanere allineati. In Salesforce, il nome di ogni rilascio principale inizia con "Primavera", "Estate" o "Inverno", seguito dall'anno del rilascio (ad esempio, "Estate '25"). Se non si dispone già di una convenzione di denominazione per definire e organizzare i rilasci nella propria azienda, crearne una e utilizzarla. L'uso di nomi di rilascio chiari semplifica l'organizzazione in ogni fase della pianificazione, dello sviluppo e della consegna, in tutti i sistemi dei team. Utilizzare i nomi dei rilasci nella [roadmap](/docs/architect/it-it/well-architected/guide/intentional#roadmapping) per comunicare chiaramente agli stakeholder quali modifiche sono in arrivo e quando. Utilizzare i nomi dei rilasci nella documentazione, nei registri di modifica, nelle descrizioni del lavoro, nei commenti al codice e nei rami del controllo sorgente per poter tracciare e controllare facilmente gli elementi di sviluppo.
- **All'interno di un manifesto di rilascio, gestire correttamente le dipendenze**. I metadati Salesforce hanno dipendenze incorporate. Un motivo comune per cui le distribuzioni Salesforce non riescono è che le dipendenze non vengono gestite correttamente. La scelta di un meccanismo di rilascio stabile, come descritto in precedenza, può aiutare a esporre le dipendenze gestite in modo errato nelle prime fasi del ciclo di sviluppo. Uno dei motivi principali per cui i pacchetti sbloccati sono il veicolo di rilascio più stabile è la loro forte gestione dei metadati, necessaria per lo sviluppo e la creazione dei pacchetti. Se l'utente o i suoi team di gestione dei rilasci non comprendono le dipendenze incorporate tra i tipi di metadati Salesforce, non sarà in grado di individuare in modo proattivo le combinazioni problematiche nei manifesti di distribuzione e rilascio. Vedere [Gestione delle dipendenze](/docs/architect/it-it/well-architected/guide/composable#gestione-delle-dipendenze).

Gli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/resilient#pattern-alm-e-anti-pattern) mostrano l'aspetto corretto e inadeguato della gestione dei rilasci per un'organizzazione Salesforce. Utilizzare gli schemi per convalidare i progetti prima della creazione o per identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione dei rilasci, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Strategia ambientale

Salesforce offre una varietà di [ambienti](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5) utilizzabili durante i cicli di sviluppo e test delle applicazioni. Una strategia ambientale efficace per Salesforce richiede la comprensione dell'utilizzo degli ambienti e di una buona gestione. In ALM, l'utilità di un ambiente di sviluppo o test dipende dalla fedeltà e dall'isolamento dalla produzione.

Una buona strategia ambientale offre diversi vantaggi.

- Maggiore fedeltà alla produzione
- Configurazioni e arresti dell'ambiente più rapidi
- Maggiore agilità nello sviluppo e nei test
- Maggiore sicurezza in tutta la pipeline
- Meno rumore e conflitti durante le fasi di consegna
- Team di sviluppo più soddisfatti

I team spesso faticano a realizzare questi vantaggi. Le sfide per sfruttare al meglio gli ambienti di sviluppo e la strategia possono provenire da diverse fonti. Una fonte probabile è il tipo di modello di sviluppo seguito dai team.

Nel vecchio approccio di sviluppo basato sull'organizzazione, ogni ambiente doveva svolgere diverse funzioni. Oltre a essere la sede in cui il team svolge i suoi vari tipi di lavoro, doveva essere l'origine degli artefatti rilascio (ovvero i metadati che si desiderava distribuire in un rilascio). Poiché gli ambienti non erano facili da configurare o abbattere, erano spesso sovraffollati e pieni di conflitti di metadati tra i team e non contribuivano in modo significativo alla velocità o alla flessibilità di ALM in generale.

L'utilizzo di un modello di sviluppo basato su sorgente modifica in modo sostanziale la relazione degli ambienti con i rilasci e gli artefatti rilascio. In questo modello, il controllo sorgente è l'origine dei metadati che si desidera rilasciare. Gli ambienti sono solo luoghi in cui i team svolgono il proprio lavoro.

Tuttavia, seguire il modello di sviluppo basato sul sorgente non garantisce da solo una buona strategia ambientale. Anche con il controllo sorgente, i team possono ancora avere difficoltà a impostare le condizioni per testare le integrazioni con i sistemi esterni; configurazioni che dipendono da metadati che non sono nel controllo sorgente, ad esempio pacchetti gestiti o personalizzazioni che dipendono dai [dati](/docs/architect/it-it/fundamentals/guide/architecture-basics#metadati-e-dati)) e così via. In alcune circostanze, le sfide di un modello basato su origine sono simili alle sfide tipiche di un modello basato su organizzazione.

Per sviluppare una strategia ambientale efficace:

- **Adottare un modello di sviluppo e rilascio basato sulla fonte**. Smettere di utilizzare i modelli [di sviluppo basati](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models) sull'organizzazione. Vedere [Gestione dei rilasci](/docs/architect/it-it/well-architected/guide/resilient#gestione-dei-rilasci).) È necessario separare gli ambienti da ciò che viene distribuito per creare una strategia per un ambiente sano e rilasci più sani.
- **Comprendere i tipi di lavoro supportati da ogni ambiente**. I tipi di ambiente supportati da Salesforce hanno funzionalità e limiti diversi. Quando si progetta la strategia ambientale, considerare ciò che gli ambienti possono e non possono fare. Assicurarsi che i team svolgano il proprio lavoro in un ambiente dotato delle funzionalità necessarie. Per indicazioni, vedere questa panoramica degli ambienti di sviluppo Salesforce e delle relative funzionalità.

<table>
<thead>
<tr>
<th></th>
<th>Organizzazione vuota</th>
<th>Developer Sandbox (Sandbox per sviluppatori)</th>
<th>Developer Pro Sandbox</th>
<th>Partial Copy Sandbox</th>
<th>Sandbox Completo</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Supporta la <a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_create_shape.htm">forma dell'organizzazione</a></strong></td>
<td>Sì</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td><strong>Supporta <a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm">il tracciamento sorgente</a></strong></td>
<td>Sì</td>
<td>Sì</td>
<td>Sì</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>Durata <strong>vita</strong></td>
<td>1-30 giorni</td>
<td>Controllo manuale</td>
<td>Controllo manuale</td>
<td>Controllo manuale</td>
<td>Controllo manuale</td>
</tr>
<tr>
<td><strong>Intervallo di aggiornamento</strong></td>
<td>Non disponibile</td>
<td>1 giorno</td>
<td>1 giorno</td>
<td>5 giorni</td>
<td>29 giorni</td>
</tr>
<tr>
<td><strong>Supporto anteprima rilascio</strong></td>
<td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_version_selection.htm">Controllato dallo sviluppatore</a></td>
<td>Basato sull'istanza Sandbox</td>
<td>Basato sull'istanza Sandbox</td>
<td>Basato sull'istanza Sandbox</td>
<td>Basato sull'istanza Sandbox</td>
</tr>
<tr>
<td><strong>Ora provisioning</strong></td>
<td>> 5 minuti</td>
<td>Ore o giorni</td>
<td>Ore o giorni</td>
<td>Ore o giorni</td>
<td>Ore o giorni</td>
</tr>
<tr>
<td><strong>Metadati determinati da</strong></td>
<td>Controllo sorgente</td>
<td>Produzione</td>
<td>Produzione</td>
<td>Produzione</td>
<td>Produzione</td>
</tr>
<tr>
<td><strong>Dati determinati da</strong></td>
<td>Caricamento manuale dei dati</td>
<td>Caricamento manuale dei dati</td>
<td>Caricamento manuale dei dati</td>
<td>Modello Sandbox</td>
<td>Produzione</td>
</tr>
<tr>
<td><strong>Limite di dati</strong></td>
<td>200 MB</td>
<td>200 MB</td>
<td>1 GB</td>
<td>5 GB</td>
<td>Come nella produzione</td>
</tr>
</tbody>
</table>

Fare riferimento a questa tabella per informazioni sulle funzioni e gli ambienti da utilizzare per diverse operazioni di sviluppo comuni.

<table style="overflow-x:scroll;">
<thead>
<tr>
<th>Operazione</th>
<th>Forma organizzazione</th>
<th>Tracciamento sorgente</th>
<th>Aggiornamenti frequenti</th>
<th>Supporto per l'anteprima rilascio</th>
<th>Tutti i metadati della produzione</th>
<th>Metadati parziali dalla produzione</th>
<th>Serie di dati di grandi dimensioni dalla produzione</th>
<th>Serie di dati parziali dalla produzione</th>
<th>Ambienti compatibili</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Prototipazione</strong></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"></td>
<td align="center">X</td>
<td>Organizzazioni vuote, Developer e Developer Pro Sandbox</td>
</tr>
<tr>
<td><strong>Indagini sulle nuove funzioni o sviluppo di Proof-of-Concept</strong></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"></td>
<td align="center">X</td>
<td>Organizzazioni vuote, Developer e Developer Pro Sandbox</td>
</tr>
<tr>
<td><strong>Test di accettazione utente</strong></td>
<td align="center"></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"></td>
<td align="center">X</td>
<td>Sandbox Developer, Developer Pro e Copia parziale</td>
</tr>
<tr>
<td><strong>Test di prestazioni e scalabilità</strong></td>
<td align="center"></td>
<td align="center"></td>
<td align="center"></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"></td>
<td align="center">X</td>
<td align="center"></td>
<td>Sandbox Completo</td>
</tr>
<tr>
<td><strong>Formazione utente</strong></td>
<td align="center"></td>
<td align="center"></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X*</td>
<td align="center">X</td>
<td>Developer Pro, Copia parziale e * Full Sandbox</td>
</tr>
<tr>
<td colspan="10">*Se necessario per completare un tipo specifico di lavoro, altrimenti utilizzare un ambiente che richiede meno risorse</td>
</tr>
</tbody>
</table>

Inoltre, tenere presente che per gli agenti Agentforce che utilizzano funzioni come la libreria di dati Einstein, gli articoli Knowledge e i dati non strutturati, i test completi sono limitati a meno che non si disponga di un Sandbox Data 360. È necessario anche un Sandbox Data 360 per garantire condizioni di test accurate.

- **Disaccoppiare gli ambienti dagli artefatti rilascio.** Non utilizzare lo [sviluppo basato sull'](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)organizzazione. Considerare gli ambienti come luoghi in cui il lavoro si svolge per un periodo di tempo fisso. Considerare lo stato dei metadati in un ambiente come separato dagli elementi di rilascio. Se una porzione di codice o configurazione viene "capita" in un ambiente, deve essere assegnata al controllo sorgente, rendendola un artefatto rilascio.
  - Gli ambienti sono effimeri. Creare processi in modo da poterli creare e distruggere il più rapidamente possibile.
  - Gli artefatti resistono. Appartengono al controllo sorgente.
- **Disaccoppiare gli ambienti dai percorsi di rilascio**. È comune vedere percorsi di rilascio obbligatori che richiedono la distribuzione delle modifiche in ambienti specifici. Spesso questo approccio viene implementato per stabilire un proxy per convalidare la maturità dell'applicazione o la stabilità del rilascio. I team possono utilizzarlo anche per cercare di ridurre al minimo il numero di ambienti in cui devono configurare un'infrastruttura di test complessa. Nei paradigmi basati sulla fonte, si dispone di una maggiore flessibilità nel modo e nella posizione in cui è possibile convalidare e testare le modifiche.
  - Le fasi di rilascio si applicano agli artefatti rilascio, non agli ambienti. Non creare un ambiente solo per "raccogliere" tutte le modifiche in una determinata fase di rilascio. A questo serve il controllo sorgente, in particolare la ramificazione. Utilizzare le strategie di ramificazione nel controllo sorgente per organizzare le modifiche da distribuire a quali ambienti. A seconda del lavoro da eseguire, potrebbe essere necessario distribuire tutti i metadati di un rilascio a un ambiente. La ramificazione consente di eseguire questa operazione. Con alcune eccezioni, ogni ambiente di sviluppo deve essere aggiornato o distrutto non appena viene completato il lavoro pertinente. Assicurarsi di sincronizzare tutte le modifiche ai metadati che avvengono all'interno di un ambiente specifico e che si desidera mantenere nel controllo sorgente.
  - Gli ambienti sono utili tanto quanto la loro fedeltà alla produzione. Ottimizzare i flussi di lavoro o l'automazione di impostazione dell'ambiente in modo da poter demolire o aggiornare gli ambienti il più rapidamente possibile. Considerare qualsiasi configurazione che impedisce di eseguire aggiornamenti di ambiente più rapidi e frequenti come un rischio critico per la resilienza complessiva dei processi ALM. Se sono presenti interventi di riparazione correlati, aggiungerli ai piani e assegnargli la priorità. Esplorare come adottare [unità modulari](/docs/architect/it-it/well-architected/guide/composable) più vagamente accoppiate nel sistema. Consentono ai team di eseguire più tipi di sviluppo nelle organizzazioni vuote e liberano le allocazioni Sandbox per altri lavori. Non dimenticare le funzionalità offerte dalle organizzazioni vuote per testare funzioni che non sono presenti in produzione, sia perché non sono state acquistate licenze per le organizzazioni o non sono state abilitate.
  - Negli ambienti a cui possono accedere gli utenti aziendali o finali, consentire a tali utenti di concentrarsi su ciò che è importante per loro. Non avere ambienti generici e indifferenziati in cui molti gruppi diversi di utenti finali o stakeholder aziendali tentano di svolgere attività correlate all'ALM. Invitare e attivare stakeholder specifici in ambienti specifici per svolgere un lavoro specifico. Valutare attentamente qualsiasi processo che mette gli utenti finali o gli stakeholder aziendali in un ambiente con più dati di quelli supportati da un Sandbox Copia parziale. Assicurarsi che il volume di dati sia necessario per il lavoro da eseguire. Pianificare i test di accettazione utente e i cicli di sviluppo iniziali in modo che si verifichino il più vicino possibile. Ottimizzare tutte le fasi di test per consentire cicli di feedback e iterazioni più rapidi e anticipati per i team di sviluppo e gli utenti finali. Vedere [Strategia di test](/docs/architect/it-it/well-architected/guide/resilient#strategia-di-test).
- **Creare percorsi di rilascio diversi per diversi tipi di modifiche.** Non tutte le modifiche richiedono che gli stessi tipi di lavoro ALM vengano completati nello stesso ordine. Fare in modo che gli utenti finali eseguano test di accettazione per modifiche minori ai componenti di backend di un sistema probabilmente non è un buon uso del loro tempo. Tuttavia, l'accettazione da parte degli utenti e i test su larga scala possono essere estremamente utili durante lo sviluppo iniziale di un'applicazione mobile. Identificare i percorsi di rilascio per le diverse categorie di modifiche, ad esempio rischio alto, rischio medio e rischio basso.

  - **Rischio elevato:** Le modifiche hanno effetto su clienti, partner o tutti gli utenti interni. Le modifiche influiscono sulla sicurezza o sull'integrazione. Le modifiche aggiungono nuove funzionalità complesse.
  - **Rischio medio:** Le modifiche hanno un impatto superiore a una soglia definita di utenti interni. Le modifiche influiscono sui modelli di dati, sull'automazione che esegue le operazioni sui dati o sull'integrazione.
  - **Rischio basso:** Ha un impatto diretto inferiore a una soglia definita di utenti interni. Non include modifiche alla sicurezza, ai modelli di dati o alle automazioni che comportano operazioni sui dati o integrazione.

- **Non consentire l'esistenza di ambienti sovraffollati**. Una mancanza di disciplina nell'assegnazione delle priorità, nella definizione degli ambiti e nella sequenza del lavoro porta inevitabilmente a ambienti di sviluppo sovraccarichi, con volumi di lavoro eccessivi, troppi, troppo diversi. Gli ambienti sovraffollati creano elevati livelli di stress, ambiguità e conflitti tra i team di sviluppo. Inoltre, creano rumore all'interno delle opportunità di sviluppo in corso di realizzazione e ostacolano le attività di controllo della qualità. Oltre a questi impatti negativi, gli ambienti di sviluppo sovraffollati rappresentano gravi minacce per la manutenzione e la sicurezza dell'ambiente. Considerare il sovraffollamento come sintomo di potenziali problemi nei processi ALM. Esaminare eventuali problemi di causa principale e risolverli. Se si continua a riscontrare sovraffollamento, è possibile [acquistare ulteriori Sandbox](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5).

L'elenco degli [schemi e antischemi per ALM](/docs/architect/it-it/well-architected/guide/resilient#pattern-alm-e-anti-pattern) mostra l'aspetto di una gestione dell'ambiente corretta e inadeguata in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione dell'ambiente, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Strategia di segnalazione

Una strategia di segnalazione definisce i segnali critici e la strumentazione dell'applicazione necessari per rilevare, diagnosticare e risolvere i guasti prima che si verifichino nel degrado a livello di sistema. Una strumentazione efficace trasforma le applicazioni da vittime passive di errori in partecipanti attivi alla propria resilienza, in grado di rilevare i problemi, adattare il loro comportamento e coordinare il degrado grazioso quando necessario.

Quando le applicazioni implementano una strumentazione completa, acquisiscono la capacità di autoregolarsi sotto stress, comunicare il proprio stato di salute agli operatori e partecipare a sforzi di ripristino coordinati. Queste funzionalità consentono ai sistemi di mantenere la qualità del servizio anche quando i singoli componenti subiscono difficoltà. D'altra parte, senza una strumentazione adeguata, le applicazioni diventano scatole nere che falliscono silenziosamente fino a quando non compaiono sintomi catastrofici. I team reagiscono ai problemi solo dopo che gli utenti li hanno segnalati e la risoluzione dei problemi diventa un esercizio di archeologia anziché di osservazione.

- **Rilevamento di errori nell'applicazione**. Le applicazioni devono dotarsi di strumenti per rilevare e rispondere agli schemi di guasto comuni che emergono sotto carico pesante. Considerare la saturazione dell'area di attesa. Quando le aree di attesa dei messaggi si riempiono più velocemente di quanto possano essere elaborate, le applicazioni non strumentate continuano ad accettare il lavoro fino a esaurimento della memoria o fino a quando non si verificano cascate di timeout. Applicazioni adeguatamente strumentate monitorano la profondità dell'area di attesa, le percentuali di rifiuto e la latenza di elaborazione, attivando risposte difensive quando vengono superate le soglie.
- **Gestire efficacemente i segnali esterni all'applicazione**: La gestione dei segnali dal sistema operativo rappresenta un altro punto critico della strumentazione. Le applicazioni devono registrare gli handler per i segnali di terminazione (SIGTERM, SIGINT) per abilitare l'arresto graduale. Durante l'arresto, le applicazioni dotate di strumenti appropriati interrompono l'accettazione di nuovo lavoro, consentono il completamento delle richieste in volo, svuotano gli buffer, chiudono le connessioni in modo pulito e annullano la registrazione dal rilevamento del servizio. Questo arresto orchestrato impedisce la perdita di dati e consente ai bilanciatori del carico di reindirizzare il traffico senza interruzioni.
- **Strumento per scenari di errore complessi:** Al di là di questi schemi di base, le applicazioni devono adottare modalità di errore più sottili. L'identificazione dei guasti grigi, in cui i componenti appaiono sani per alcuni osservatori mentre per altri non funzionano, richiede la correlazione dei segnali interni ed esterni. Un'applicazione può utilizzare lo strumento del pool di connessioni al database per segnalare controlli dello stato riusciti, monitorando contemporaneamente le percentuali di completamento delle transazioni che rivelano un deterioramento strisciante. Strategie di strumentazione efficaci sovrappongono più punti di osservazione.

  - Le **metriche aziendali** tengono traccia degli indicatori di successo specifici dell'applicazione, ad esempio le percentuali di completamento degli ordini o la qualità dei risultati della ricerca.
  - Le **metriche di sistema** monitorano l'utilizzo delle risorse, le distribuzioni della latenza e le percentuali di errore.
  - **Le sonde sintetiche** eseguono continuamente percorsi critici per rilevare la degradazione prima che gli utenti la incontrino.
  - Il **tracciamento distribuito** offre visibilità a livello di richiesta oltre i limiti del servizio.

Questi segnali vengono esposti attraverso interfacce standardizzate che consentono sia ai sistemi automatizzati che agli operatori umani di valutare lo stato dell'applicazione. La strumentazione stessa diventa parte della strategia di resilienza dell'applicazione, consentendo agli interruttori di scattare in base alle percentuali di errore, ai scalatori automatici di rispondere alle profondità dell'area di attesa e agli [operatori di prendere decisioni informate durante gli incidenti](/docs/architect/it-it/well-architected/guide/resilient#risposta-incidente).

Gli [schemi e anti-schemi per ALM](/docs/architect/it-it/well-architected/guide/resilient#pattern-alm-e-anti-pattern) mostrano l'aspetto di una strategia di segnalazione corretta e scadente in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per una strategia di segnalazione, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Strategia di test

Una strategia di test è una serie di principi e standard guida per la pianificazione e l'esecuzione di test che misurano il successo e l'insuccesso delle applicazioni durante i processi ALM. Una strategia di test tiene informati e allineati tutti gli stakeholder coinvolti nel test sulla priorità, lo scopo e l'ambito di un determinato test. Aiuta anche i team di progetto a creare piani di test efficaci e ponderati.

In genere, gli sviluppatori o gli esperti di controllo della qualità e test sono coinvolti nella creazione e nell'esecuzione di test specifici. Una strategia di test consente di assicurarsi che queste persone sappiano quali tipi di test devono essere condotti per un determinato progetto e in quale sequenza condurli. Una strategia di test consente anche di assicurarsi che i team dispongano di ciò di cui hanno bisogno per creare test, piani di test e artefatti adeguati (ad esempio, serie di dati di test, dispositivi e simulatori di traffico o rete).

Una strategia di test efficace crea un quadro chiaro di come, quando, dove e perché eseguire diversi tipi di test, inclusi test di unità, test dell'interfaccia utente e test di regressione, in varie combinazioni e condizioni per scoprire come si comporterà il sistema ed eventuali modifiche in volo. Una strategia di test efficace produce test che mostrano la conformità di un sistema a requisiti non funzionali, come scalabilità, affidabilità e fruibilità, che possono essere difficili da misurare con un unico tipo di test.

Per creare strategie di test efficaci per Salesforce:

- **Testare in modo iterativo, frequente e con mezzi automatizzati il più possibile**. Progettare e implementare l'automazione dei test che consente ai team di eseguire una varietà di tipi di test su una varietà di carichi di lavoro. È possibile orchestrare varie serie di test in modo che avvengano automaticamente quando le modifiche entrano nel controllo sorgente. Questo approccio consente ai team di identificare e gestire in modo proattivo le regressioni in anticipo. Se possibile, utilizzare l'integrazione continua/erogazione continua (CI/CD) per questo sforzo. In caso contrario, stabilire piani di test chiari che consentano ai team di eseguire sequenze di test in anticipo e spesso, in modalità self-service. Per i test degli agenti Agentforce, affidarsi al Centro test per eseguire test batch rigorosi degli agenti AI con vari input per assicurarsi che funzionino correttamente in scenari diversi.
- **Riconoscere che non tutte le modifiche richiedono ogni tipo di test**. Così come una pipeline di rilascio efficace consente percorsi per applicazioni ad alto, medio e basso rischio, così una strategia di test efficace. Descrivere chiaramente per i team come selezionare e seguire un regime di test appropriato per le applicazioni con vari tipi di rischio, casi d'uso o complessità. Vedere [Strategia ambientale](/docs/architect/it-it/well-architected/guide/resilient#strategia-ambientale).
- **Definire quali test possono essere condotti in diversi tipi di ambiente**. La fedeltà alla produzione è un componente chiave di test accurati, ma significa cose diverse per i diversi tipi di test. Ad esempio, il test di regressione richiede fedeltà alla produzione in termini di metadati e, in una certa misura, di dati. Assicurarsi di definire il tipo di fedeltà alla produzione richiesta per un determinato insieme di test e di classificare chiaramente i tipi di ambienti che possono supportare le condizioni appropriate per i diversi test. Per una panoramica dei tipi di lavoro allineati a ogni tipo di ambiente, vedere [Strategia ambientale](/docs/architect/it-it/well-architected/guide/resilient#strategia-ambientale).
- **Utilizzare test di resistenza, stress, prestazioni e scalabilità per misurare continuamente la maturità delle applicazioni**. Questi test mostrano in che modo un'applicazione è pronta per il rilascio rispetto alle esigenze a livello di produzione. Per le nuove funzionalità principali, eseguire questi test a diversi intervalli nel ciclo di sviluppo dell'applicazione. Considerare questi test come parte di una singola fase o fase di sviluppo anziché come parte di operazioni in corso è anti-schema. È molto utile che i team ricevano feedback sulle prestazioni dell'app in anticipo e spesso, il che li aiuta a capire meglio quanto l'app sia vicina o lontana dalla preparazione a livello di produzione. La capacità di identificare e risolvere meglio i problemi prima che le modifiche entrino in produzione vale la pena di aggiungere la complessità di eseguire spesso test più sofisticati.
  - **Sapere quali test sono importanti**. Probabilmente si avrà una quantità fissa di tempo per condurre i test di scala o delle prestazioni, rendendo poco pratico testare ogni aspetto del sistema. Non tutte le funzioni vengono utilizzate allo stesso modo e non tutti i colli di bottiglia su larga scala avranno un impatto uguale sul business. Assicurarsi che i test di scala siano concentrati sulle parti del sistema più utilizzate e apprezzate. Definire e comprendere le opportunità più importanti per verificare e migliorare la scalabilità e le prestazioni nell'organizzazione.
  - **Conoscere l'aspetto "abbastanza buono".** La definizione dei criteri di successo per i test di scala e delle prestazioni è fondamentale. Assicurarsi che l'utente e i suoi team di sviluppo utilizzino i criteri di successo come benchmark di test. Assicurarsi inoltre che soddisfino i requisiti funzionali definiti dai team di sviluppo. In genere, questi criteri includono il supporto di un numero specifico di utenti simultanei con tempi di risposta inferiori a un valore concordato e gli [obiettivi del livello](/docs/architect/it-it/well-architected/guide/resilient#tempo-di-recupero) di servizio. Definire i criteri di destinazione chiave e quindi progettare test di scala e delle prestazioni che garantiscano che i criteri siano soddisfatti.
  - **Assicurarsi di disporre di ambienti adeguati.** I test di scala e delle prestazioni richiedono una particolare fedeltà alla produzione. Le serie di dati, i dati demografici delle richieste, le percentuali di richieste e le caratteristiche del carico di lavoro negli ambienti non di produzione devono corrispondere il più possibile a ciò che si vede in produzione. Per i test su scala, è necessario utilizzare un Sandbox Completo. Se l'organizzazione non dispone di un Sandbox Completo per i test di scala, non è possibile eseguire test di scala adeguati.
- **Assicurarsi che i carichi di lavoro di prova aiutino a misurare i requisiti non funzionali**. Ricordati di considerare:
  - **Dati di test**: ogni tipo di test deve essere eseguito con dati isolati dalla produzione. Nei test di unità Apex, implementare [schemi di fabbrica](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm) per garantire che il codice generi i propri dati di test, isolati dai dati ambientali. È anche possibile creare e gestire serie di dati di test in vari formati per testare i comportamenti di caricamento dei dati, compilare gli ambienti di sviluppo con dati per i test basati sull'interfaccia utente e fornire assistenza per i test di integrazione. Tutti i dati di test, siano essi gestiti come serie di dati esternalizzata o creati su richiesta dal codice data-factory, devono essere cancellati dai dati sensibili e identificativi. Dovrebbe includere dati corrotti, incompleti e in formato non corretto per supportare comportamenti negativi e di test di unità limite.
  - **Servizi fittizi e stub**: per i test di integrazione, è possibile utilizzare i servizi fittizi e stub per simulare le risposte API. Apex supporta un'[API Stub](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm) per creare framework fittizi da utilizzare nei test Apex. Scherzi per creare framework fittizi che possono essere utilizzati nei test Apex. I falsi e gli stub possono aiutare a convalidare i comportamenti di gestione dei dati di un sistema, con una minore dipendenza da fabbriche di dati complesse o serie di dati di test esterni. I falsi e gli stub sono a volte più appropriati da utilizzare nei test in cui il traffico o i volumi di dati simili alla produzione non sono rilevanti.
  - **Dispositivi e tecnologie** per l'assistenza: una parte fondamentale della creazione di applicazioni [coinvolgenti](/docs/architect/it-it/well-architected/guide/engaging) e [accessibili](/docs/architect/it-it/well-architected/guide/compliant#accessibilità) è garantire che soddisfino le aspettative degli utenti in una varietà di dispositivi e con diversi tipi di tecnologie per l'assistenza. Un test di fruibilità significativo può richiedere più investimenti e diversi tipi di esperienza per essere eseguito in modo efficace, ma è una parte essenziale per sapere quanto saranno ben progettate le applicazioni rivolte agli utenti quando verranno rilasciate.
  - **Simulatori**: quando è necessario replicare volumi simili a quelli di produzione di richieste utente, traffico API o variazioni della velocità di rete, potrebbero essere necessari strumenti che simulano queste condizioni. Non tutti i test richiedono questo livello di investimento. Questi strumenti sono spesso più utili nei test di scalabilità e prestazioni.
  - **AI e test** degli agenti - Un obiettivo principale dei test è ridurre le allucinazioni AI, che sono risposte convincenti fabbricate e non corrette. Assicurarsi che i casi d'uso AI vengano testati per evidenziare i problemi comuni causati da una comprensione incompleta del cliente, dati mancanti, campi con metadati incompleti e dati non aggiornati. Utilizzare il Centro test per facilitare la creazione dei dati di test necessari per tali test.

### Pattern ALM e anti-pattern

La tabella seguente mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la riparazione.

✨ Scopri altri modelli per ALM in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/adaptable-application-lifecycle-management).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
        <td rowspan="2"><b>Gestione dei rilasci</b></td>
        <td><strong>In produzione:</strong>
        <br> - I metadati mostrano l'uso di meccanismi di rilascio stabili, ad esempio:
        <br> -- Metadati organizzati in pacchetti sbloccati
        <br> -- DevOps Center attivo e installato
        <br> -- Distribuzioni tramite l'API dei metadati utilizzando il formato di origine
        <br> - I registri di distribuzione non mostrano distribuzioni non riuscite nella cronologia disponibile.
        <br> - La cronologia di distribuzione mostra cadenze di rilascio chiare e cluster di distribuzione abbastanza uniformi all'interno delle finestre di rilascio.</td>
        <td><strong>In produzione:</strong>
        <br> - I metadati indicano l'uso di meccanismi di rilascio basati sull'organizzazione, ad esempio:
        <br> -- Utilizzo attivo delle serie di modifiche
        <br> -- Le distribuzioni tramite l'API dei metadati utilizzano il formato package.xml
        <br> - I registri di distribuzione mostrano le istanze ripetute di distribuzioni non riuscite nella cronologia disponibile.
        <br> - Le distribuzioni non hanno una cadenza distinguibile o mostrano cluster non regolari di distribuzioni, che sono segni di correzioni rapide e ritiri ad hoc).
        <br> - DevOps Center non è abilitato e installato.</td></tr>
        <tr><td><strong>Nella roadmap e nella documentazione:</strong>
        <br> - I nomi dei rilasci sono chiari.
        <br> - Le funzioni sono chiaramente legate a un rilascio denominato specifico.
        <br> - I nomi dei rilasci sono ricercabili e individuabili.
        <br> - I team possono trovare e seguire linee guida chiare per l'assegnazione di tag a artefatti, elementi di sviluppo e altri lavori con i nomi di rilascio corretti.
        <br> - È possibile ottenere una visualizzazione chiara di un manifesto di rilascio in base al nome di un rilascio.
        <br> - Le soglie di qualità per le app AI generative sono definite per le diverse fasi di sviluppo.</td>
        <td><strong>Nella roadmap e nella documentazione:</strong>
        <br> - I nomi dei rilasci non sono inclusi.
        <br> - Le funzioni non sono chiaramente collegate a un rilascio specifico.
        <br> - I nomi dei rilasci vengono utilizzati ad hoc o non esistono.
        <br> I team si riferiscono ad artefatti, elementi di sviluppo e altri lavori in modi diversi.
        <br> - Non è possibile ottenere una visualizzazione chiara di un manifesto di rilascio utilizzando un nome di rilascio.
        <br> - Le soglie di qualità per le app di intelligenza artificiale generative non sono definite o, in caso affermativo, non sono definite per fasi di sviluppo diverse.</td></tr>
        <tr><td><strong>Strategia ambientale</strong></td>
        <td><strong>Nelle organizzazioni:</strong>
            <br> - Viene adottato un modello di sviluppo e rilascio basato sulla fonte.
            <br> - Il tracciamento sorgente è abilitato per i Sandbox Developer e Developer Pro.
            <br> - I metadati in un determinato ambiente sono indipendenti dagli artefatti rilascio.
            <br> - Gli ambienti non corrispondono direttamente a un percorso di rilascio.
            <br> - I percorsi di rilascio di una modifica dipendono dal tipo di modifica (rischio alto, rischio medio o rischio basso).
            <br> Gli ambienti sovraffollati non esistono.
            <br> - Le modifiche di configurazione rischiose non vengono mai apportate direttamente in produzione.
            <br> - Nessun rilascio si verifica durante l'orario di ufficio di punta.
            <br> I Sandbox Data 360 vengono utilizzati per testare correttamente i casi d'uso degli agenti che richiedono libreria di dati Einstein, articoli Knowledge e dati non strutturati </td>
            <td><strong>Nelle organizzazioni:</strong>
                <br> - Viene adottato un modello di sviluppo e rilascio basato sull'organizzazione.
                <br> - Il tracciamento sorgente non è abilitato per i Sandbox Developer e Developer Pro.
                <br> - I metadati in un determinato ambiente sono un artefatto rilascio.
                <br> - Gli ambienti corrispondono direttamente a un percorso di rilascio.
                <br> - Il percorso di rilascio per ogni modifica è lo stesso, indipendentemente dal tipo di modifica.
                <br> - Esistono ambienti sovraffollati. - Le modifiche di configurazione rischiose vengono apportate direttamente in produzione.
                <br> - I rilasci avvengono durante l'orario di ufficio di punta.
                <br> - Gli agenti Agentforce che richiedono Libreria di dati Einstein, articoli Knowledge e dati non strutturati non vengono testati utilizzando i Sandbox Data 360</td></tr>
        <tr><td><strong>Strategia di segnalazione</strong></td>
            <td><strong>Nelle organizzazioni:</strong>
                <br> - I team collaborano alla definizione e standardizzazione delle API e degli SLO di controllo dello stato.
                <br> La revisione periodica e il perfezionamento delle strategie di segnalazione fanno parte delle revisioni post-mortem e della preparazione operativa.
                <br><strong>In produzione:</strong>
                <br> - I controlli dello stato vengono implementati per tutte le applicazioni.
                <br> - Le applicazioni forniscono segnali espliciti sulla loro salute, ad esempio il carico e le capacità.
                <br> - Le applicazioni sono progettate per degradarsi con grazia quando le dipendenze sono malsane.
                <br> - Lo spargimento di carico viene utilizzato per evitare errori a cascata.
                <br><strong>Nella progettazione:</strong>
                <br> I meccanismi di contropressione e di sversamento del carico evitano che i servizi vengano sovraccaricati dal traffico.
                <br> Si presume che le dipendenze alla fine falliscano. Gli handler dei segnali sono creati per migliorare gli errori.</td>
            <td><strong>Nelle organizzazioni:</strong>
                <br> - I team operano in silos, creando meccanismi di segnalazione della salute incoerenti e incompatibili.
                <br> - Le strategie di segnalazione sono un ripensamento, affrontato solo quando si verifica un incidente.
                <br><strong>In produzione:</strong>
                <br> - I componenti si guastano silenziosamente senza segnalare il loro stato di salute.
                <br> - Le applicazioni ritentano le richieste a servizi non sani a tempo indeterminato.
                <br> - Tutte le richieste vengono trattate con la stessa priorità, indipendentemente dalla loro importanza.
                <br> - Per identificare i problemi, gli operatori si affidano esclusivamente a misure reattive, come reclami degli utenti o errori critici del sistema.
                <br><strong>Nella progettazione:</strong>
                <br> - Si presume che tutte le dipendenze saranno sempre disponibili e che le partizioni di rete, i picchi di latenza o altri problemi comuni non vengano considerati.
                <br> - Le applicazioni accettano tutte le richieste in entrata, anche quando sono sovraccaricate, causando un aumento della latenza e una maggiore probabilità di errore</td>
        </tr>
        <tr><td rowspan="4"><strong>Strategia di test</strong></td>
            <td><strong>Nel tuo business:</strong>
                <br> - I test di usabilità utilizzano una varietà di dispositivi e tecnologie per l'assistenza.
                <br> I simulatori vengono utilizzati per replicare condizioni simili a quelle di produzione per testare la scalabilità e le prestazioni.
                <br> - I test vengono eseguiti automaticamente quando le modifiche entrano nel controllo sorgente.
                <br> I test di resistenza, stress, prestazioni e scalabilità vengono eseguiti a diversi intervalli nel ciclo di sviluppo dell'applicazione e considerati operazioni in corso.
                <br> - Includere i test di scala come parte del processo di controllo della qualità quando si dispone di app su scala B2C, grandi volumi di utenti o grandi volumi di dati.
                <br> - I test di scala sono focalizzati sugli aspetti ad alta priorità del sistema.
                <br> - I test di scala hanno criteri ben definiti.
                <br> - Si eseguono test di scala in un Sandbox Completo.
                <br> - L'ingegneria del prompt include una revisione della qualità da parte di un essere umano.
                <br> - Centro test Agentforce viene utilizzato per test efficaci degli agenti.</td>
            <td><strong>Nel tuo business:</strong>
                <br> - I test di fruibilità non vengono condotti o, in caso affermativo, vengono condotti su un insieme limitato di dispositivi.
                <br> I volumi di richieste utente, il traffico API e le variazioni della velocità di rete simili a quelli di produzione non vengono testati.
                <br> L'automazione dei test non è attiva.
                <br> - I test di resistenza, stress, prestazioni, scala sono considerati una fase o fase di sviluppo.
                <br> - Non si eseguono test di scala nell'ambito del processo di controllo della qualità e si dispone di app su scala B2C, grandi volumi di utenti o grandi volumi di dati.
                <br> I test della scala non hanno priorità.
                <br> - I test di scala non hanno criteri ben definiti.
                <br> - Si eseguono test di scala in una Copia parziale o Developer Sandbox.
                <br> - L'ingegneria del prompt non include una revisione della qualità da parte di un essere umano.
                <br> - Gli agenti Agentforce non vengono testati o, in caso affermativo, testati solo ad hoc utilizzando il Generatore di agenti.</td></tr>
        <tr><td><strong>Nella propria organizzazione:</strong>
                <br> - Tutti i dati di test vengono cancellati dai dati sensibili e identificativi.</td>
            <td><strong>Nella propria organizzazione:</strong>
                <br> - I dati di test sono identici ai dati di produzione.</td></tr>
        <tr><td><strong>In Apex:</strong>
            <br> - Gli schemi di fabbrica dei dati vengono utilizzati per i test di unità
            <br> - Falsi e stub vengono utilizzati per simulare le risposte API.</td>
            <td><strong>In Apex:</strong>
                <br> - I test di unità si basano sui dati dell'organizzazione.
                <br> Non si usano i mozziconi.</td></tr>
        <tr><td><strong>Negli standard di progettazione e nella documentazione:</strong>
            <br> - Gli ambienti sono classificati in base ai tipi di test che possono supportare.
            <br> - I regimi di test appropriati sono specificati in base al rischio, al caso d'uso o alla complessità.</td>
            <td><strong>Negli standard di progettazione e nella documentazione:</strong>
                <br> - I tipi di test supportati da ogni ambiente non sono chiari.
                <br> - I regimi di test non sono classificati in base al rischio, al caso d'uso o alla complessità.</td>
        </tr>
    </tbody>
</table>

## Risposta incidente

Nell'ingegneria della sicurezza e dell'affidabilità dei siti (SRE), la risposta agli incidenti si concentra sul modo in cui i team identificano e risolvono gli eventi che influiscono sulla disponibilità o la sicurezza complessive di un sistema, nonché sul modo in cui i team lavorano per affrontare le cause principali e prevenire problemi futuri. La risposta agli incidenti include i processi, gli strumenti e i comportamenti organizzativi necessari per risolvere i problemi in tempo reale e dopo che si è verificato un problema.

Un architetto potrebbe non essere la persona che monitora quotidianamente le attività della soluzione una volta che viene resa disponibile. Parte dell'architettura per la resilienza consiste nella progettazione di funzionalità di ripristino che consentono ai team di assistenza di eseguire diagnosi di primo livello, stabilizzare i sistemi e affidare efficacemente l'analisi e la mitigazione delle cause principali ai team di sviluppo o manutenzione. I team che supportano direttamente gli utenti quotidianamente potrebbero non avere una profonda conoscenza o esperienza dell'architettura del sistema. È essenziale che questi team dispongano degli strumenti e dei processi necessari per monitorare le operazioni quotidiane, accedere alle informazioni del sistema quando diagnosticano un potenziale incidente e svolgere un ruolo di primo soccorso efficace per qualsiasi problema che influisce sulla disponibilità.

È possibile migliorare la risposta dei team agli incidenti nelle soluzioni Salesforce concentrandosi sul [tempo di recupero](/docs/architect/it-it/well-architected/guide/resilient#tempo-di-recupero), sulla [capacità di triage](/docs/architect/it-it/well-architected/guide/resilient#capacità-di-triage) e sul [monitoraggio e avviso](/docs/architect/it-it/well-architected/guide/resilient#monitoraggio-e-avviso).

### Tempo di recupero

Quando si verifica un incidente, la prima priorità deve essere il ripristino di uno stato operativo stabile. Spesso le aziende pensano che l'unico modo per riprendersi da un incidente sia "risolvere il problema". Questo presupposto è corretto in quanto un'analisi accurata delle cause principali e la risoluzione dei problemi critici in un sistema sono il modo in cui si risolvono. Tuttavia, “risolvere il problema” durante le prime fasi della risposta alla crisi non è l’approccio più pratico. A seconda della gravità di un incidente, ogni secondo di incidente e il relativo impatto potrebbero causare una perdita di reddito o di reputazione per l'azienda.

Spesso, il tentativo di diagnosticare e risolvere i problemi alla radice ritarda gli sforzi per ripristinare il funzionamento di un sistema. Logisticamente, l'adozione di un approccio che chiede ai soccorritori di affrontare le cause profonde mette a dura prova gli esperti in materia (PMI) e il personale di assistenza dell'azienda. Lavorare per trovare e correggere le cause profonde _durante_ un incidente richiede che le PMI siano disponibili per ogni incidente, il che può impedire al personale di assistenza in prima linea rivolto ai clienti di intraprendere azioni. Può anche causare il rilascio di modifiche da parte dei team che, a loro volta, creano ulteriori incidenti. In definitiva, un approccio di questo tipo aumenta i costi, consuma larghezza di banda tra i team e genera comportamenti in tempi di crisi che possono erodere il Customer Trust e la reputazione del marchio.

Il giusto paradigma di gestione degli incidenti consiste nel dare priorità e concentrarsi sul ripristino come primo passo. Dopo che un sistema è stato ripristinato alla stabilità, è possibile eseguire autopsie, indagini sugli incidenti, riparazione delle cause principali e attività simili. Questo ordine di operazioni consente al personale di risposta agli incidenti di eseguire il triage, la diagnosi e l'esecuzione delle tattiche di ripristino, avvisando le PMI pertinenti di fornire assistenza solo se necessario. Consente inoltre alle PMI di identificare e correggere le cause profonde di un incidente con meno pressione da un ticchettio.

Per adottare una mentalità basata sul ripristino per la risposta agli incidenti:

- **Stabilire e raggiungere gli obiettivi del livello di servizio SLO**. Gli SLO sono standard sviluppati con le parti interessate per requisiti non funzionali (NFR) specifici di un sistema, ad esempio prestazioni o tempo di attività. Questi obiettivi vengono misurati da indicatori del livello di servizio (SLI) in un periodo di tempo. Senza gli SLO, gran parte del lavoro sulla risposta agli incidenti e la risoluzione dei problemi complessi può sembrare disorganizzato e reattivo, ad esempio richiedere un'azione rapida per "arrestare questo errore specifico, per questa manciata di utenti che lo hanno segnalato". Questo ciclo è spesso ciò che spinge i team a spingere l'analisi delle cause principali più vicino alla risposta agli incidenti, perché sembra che aiuterà a fermare i comportamenti reattivi. Stabilire SLO e SLI è un modo più efficace per iniziare. Per stabilire gli SLO, tenere presenti le seguenti domande.
  - **Quali sono i valori NFR del sistema per i prossimi 1–3 anni?** Ad esempio, l'NFR può includere i tempi di risposta, le percentuali di richieste di picco e gli utenti simultanei che il sistema deve essere in grado di supportare.
  - **Cosa si desidera che i clienti e i loro utenti possano sperimentare?** Basare gli SLO sulla risposta a questa domanda, che potrebbe essere "Gli utenti possono eseguire rapidamente i rapporti in Salesforce".
  - **Cosa si può misurare e per quale periodo di tempo misurarlo?** Basare gli SLI sulla risposta a questa domanda. Uno SLI corrispondente all'esempio precedente potrebbe essere "l'_x_% dei rapporti viene caricato in media entro \_n_o secondi, misurato in un periodo di 30 giorni".
- **Definire e standardizzare le tattiche di ripristino.** I ritiri di modifiche e le implementazioni di soluzioni possono aiutare a ripristinare il funzionamento di un sistema e a ridurre al minimo l'impatto di un incidente. Tattiche e protocolli di ripristino dei documenti che possono essere eseguiti dai membri appropriati dei team di assistenza o operativi. Le tattiche di ripristino variano a seconda del tipo di incidente. La tabella seguente mostra un framework generale che mappa i tipi di incidenti alle tattiche di ripristino. Per ulteriori informazioni sull'identificazione dei punti di errore e la definizione delle strategie di mitigazione, vedere [Disponibilità](/docs/architect/it-it/well-architected/guide/reliable#disponibilità).

<table>
    <tbody>
    <tr>
        <th align="center">Tipo di incidente</th>
        <th align="center">Trigger apparente</th>
        <th align="center">Tattiche di recupero</th>
    </tr>
    <tr><th rowspan="2"><strong>Arresto del sistema</strong></td>
    <td>Accessi danneggiati o problemi di accesso agli account</td>
    <td>Una policy di ripristino account</td></tr>
    <tr><td>Indisponibilità del servizio</td>
        <td>Attivazione di un servizio di backup ridondante; soluzioni manuali</td></tr>
    <tr><th rowspan="2"><strong>Bug di produzione</strong></td>
    <td>Una modifica recente</td>
    <td>Ritiro o ritiro della distribuzione della versione precedente</td></tr>
    <tr><td>Un bug emergente e inspiegabile</td>
        <td>Soluzioni manuali, disabilitazione di funzioni non essenziali, inoltro alle PMI</td></tr>
    </tbody>
</table>

- **Definire criteri di uscita** chiari. Utilizzare gli SLO per determinare quando il sistema è fuori dallo stato di incidente o impatto.
- **Definire i processi per le revisioni post-incidente e la riparazione delle cause principali.** Rivedere gli incidenti dopo il ripristino del servizio. Durante le revisioni, adottare un approccio _post mortem senza_ colpe. Collaborare con le parti interessate per stabilire fatti chiari su _ciò_ che si è verificato e _su come_ si è verificato, anziché tentare di assegnare colpe o colpe ai singoli. Utilizzare formati di revisione diversi per esaminare come affrontare i problemi a lungo termine.
  - Un _riesame post-azione si_ concentra sulla risposta all'incidente. È utile per valutare se sono in atto i processi e le tattiche di risposta appropriati.
  - Un'_analisi della causa_ principale si concentra sulla causa principale dell'incidente. Può aiutare a identificare eventuali bug o problemi nella progettazione e nell'implementazione del sistema che hanno portato all'incidente.
- **Praticare periodicamente i protocolli di ripristino concordati.** Esercitarsi sui protocolli di ripristino per assicurarsi che tutti sappiano come gestire gli incidenti in modo corretto. Utilizzare i Sandbox e gli ambienti di test per offrire ai team luoghi in cui esercitarsi nella simulazione e nel ripristino degli incidenti. Esercitarsi anche nelle revisioni post-incidente. Facendo tutto questo, il ripristino diventa parte della cultura ingegneristica e di assistenza.

Gli [schemi e anti-schemi per la](/docs/architect/it-it/well-architected/guide/resilient#schemi-di-risposta-agli-incidenti-e-schemi-anti-incidente) risposta agli incidenti mostrano l'aspetto dell'architettura per assegnare la priorità al ripristino in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per aiutare il recupero, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Capacità di triage

Nel contesto della tecnologia, il triaging prevede l'assegnazione di categorie e livelli di gravità ai problemi e alle richieste di assistenza. Non importa quanto sia ben pianificata la soluzione, si presenteranno problemi e richieste di assistenza agli utenti. Questi problemi possono derivare da una mancanza di formazione sufficiente o di gestione del cambiamento, lacune nell'interfaccia utente/interfaccia utente, comportamenti imprevisti degli utenti finali e problemi urgenti del sistema non rilevati dal [monitoraggio o dagli avvisi](/docs/architect/it-it/well-architected/guide/resilient#monitoraggio-e-avviso).

I team di assistenza e operativi devono essere in grado di analizzare le richieste di assistenza degli utenti in modo efficiente e diagnosticarle rapidamente. Risolvere i problemi per escludere le preoccupazioni meno gravi e individuare rapidamente gli incidenti di sistema critici è una competenza chiave per questi team. Una scarsa ottimizzazione rallenta tutti i livelli di assistenza agli utenti, prolunga gli incidenti critici e aumenta il rischio di ulteriori interruzioni per i clienti e per l'azienda.

Anche se l'utente potrebbe non essere coinvolto nelle attività e nell'assistenza quotidiane, in qualità di architetto è sua responsabilità assicurarsi che i team di assistenza e operativi possano risolvere efficacemente i problemi in qualsiasi soluzione creata sulla piattaforma Salesforce.

Per consentire ai team di gestire efficacemente i problemi all'interno delle soluzioni Salesforce:

- **Assicurarsi che i team di assistenza abbiano accesso a informazioni utili**.
  - **Documentare il sistema e gli schemi di progettazione**. Garantire la [leggibilità](/docs/architect/it-it/well-architected/guide/intentional#leggibilità) e la coerenza della soluzione è una parte fondamentale per consentire al personale di assistenza di comprendere il sistema di cui è responsabile. Nella documentazione, considerare come i team troveranno informazioni su come assegnare la priorità a problemi o incidenti con diverse parti del sistema. Assicurarsi inoltre che i team possano ottenere rapidamente informazioni tecniche sulle tattiche di recupero in base all'area di impatto. Fornire le guide per la risoluzione dei problemi più comuni di Agentforce, ad esempio Classificazione argomenti e Selezione azioni, che possono aiutare i team a risolvere rapidamente i problemi relativi alle autorizzazioni o alla configurazione.
  - **Progettare pensando al debug**. I team di assistenza e gli amministratori dell'organizzazione dovranno abilitare il debug e la diagnostica per individuare correttamente i problemi degli utenti in vari ambienti. Esempi di schemi _facili da utilizzare_ per i bug sono quelli che incorporano messaggi di registrazione e di errore personalizzati nei percorsi di esecuzione in tutto il sistema. Abilitare i team di assistenza sugli approcci di debug più comuni di Agentforce con strumenti come i registri eventi e la visualizzazione ragionamento di Agent Builder.
  - **Identificare PMI e stakeholder** degli incidenti. Creare un elenco delle PMI o degli stakeholder pertinenti che dovrebbero essere disponibili a sostenere la ripresa da un incidente e che dovrebbero essere coinvolti durante l'analisi post-incidente.
  - **Tratta con attenzione** le consegne. Assicurare la qualità di ogni passaggio di soluzione ai team di assistenza o operativi nell'ambito dell'implementazione. Fornire formazione al personale di assistenza per esaminare l'architettura di sistema pertinente e le esercitazioni di risposta agli incidenti fittizi. Pensare ai trasferimenti successivi all'incidente, incluso il modo in cui i team devono documentare le informazioni che non vengono acquisite dai registri o dalle note caso, nonché al modo in cui i soccorritori degli incidenti possono contribuire alle indagini sulle cause principali o eseguire test di accettazione degli utenti per eventuali rimedi.
- **Se si viene consultati, tenere tutti concentrati sul recupero come la preoccupazione principale**.
  - **Rispondere rapidamente.** Rispondere rapidamente alle richieste di assistenza degli utenti, alle notifiche di monitoraggio e agli avvisi ricevuti.
  - **Consentire di distinguere i sintomi dai problemi.** Verificare se esiste un incidente di sistema effettivo che deve essere risolto. Provare a identificare i componenti con i problemi effettivi. Assicurarsi che vengano seguite le [tattiche di ripristino](/docs/architect/it-it/well-architected/guide/resilient#tempo-di-recupero) concordate per far uscire rapidamente il sistema dallo stato di incidente.
- Per gli agenti Agentforce che supportano casi d'uso critici, assicurarsi che siano disponibili soluzioni valide e pertinenti e che possano essere attivate con breve preavviso come misura di ridondanza. Alcuni esempi sono il passaggio alla gestione manuale o il reindirizzamento alla documentazione pertinente per la revisione manuale.

Gli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/resilient#schemi-di-risposta-agli-incidenti-e-schemi-anti-incidente) mostrano l'aspetto dell'architettura per un triaging efficace in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per il triaging, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Monitoraggio e avviso

_Monitoraggio_ e _avviso_ sono termini ampiamente utilizzati nella progettazione dell'affidabilità del sito. Nel contesto della resilienza del sistema, il monitoraggio valuta costantemente lo stato attuale di un sistema e l'avviso automatizza le notifiche alle parti interessate in merito a potenziali preoccupazioni sullo stato del sistema. Monitoraggio e avvisi efficaci sono una parte fondamentale per separare la scala e la crescita del sistema dalla scala e dalla crescita del personale di assistenza.

Salesforce offre una varietà di funzionalità incorporate per monitorare i comportamenti nel sistema. Salesforce offre anche il [monitoraggio evento reale](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm) come componente aggiuntivo o come parte di [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). In qualsiasi soluzione Salesforce, le strutture progettate per il monitoraggio e l'avviso offrono:

- Funzionalità per la risposta automatica agli incidenti
- Informazioni pertinenti agli utenti giusti, al momento giusto
- Informazioni chiare per visualizzazioni storiche e analisi delle tendenze

Per progettare un monitoraggio e un avviso efficaci all'interno delle soluzioni Salesforce:

- **Impostare l'automazione** come priorità. Sebbene informare gli utenti delle modifiche critiche dello stato sia una parte cruciale per mantenere i sistemi stabili e operativi, in un'architettura ideale, il sistema corregge automaticamente i problemi quando possibile e invia avvisi solo per problemi urgenti e non risolvibili. Anche senza funzionalità di autocorrezione, l'automazione può rendere più utili gli avvisi e i rapporti.
  - **Iniziare con ciò che Salesforce offre già**. Salesforce Platform fornisce registri e API pertinenti per monitorare le operazioni della soluzione in base ai limiti del governor. Inoltre, la piattaforma invia avvisi per violazioni dei limiti governor e problemi simili. Utilizzare questi registri e avvisi come base per esplorare modi per automatizzare in modo più completo l'autoripristino del sistema, la segnalazione degli incidenti e gli avvisi. Ad esempio, è possibile implementare un'automazione che monitora il registro e quindi esegue un'azione di ripristino quando viene registrato un particolare tipo di evento.
  - **Classificare le modifiche allo stato del sistema in modi prevedibili**. Creare categorie specifiche e significative per gli stati chiave su cui si desidera monitorare e generare rapporti. Allineare queste categorie alle categorie definite per gestire lo stato nei [componenti dell'applicazione](/docs/architect/it-it/well-architected/guide/composable#gestione-statale). Adottare una mentalità [orientata all'API](/docs/architect/it-it/well-architected/guide/composable#gestione-api) per gestire le informazioni sulle modifiche di stato. Formati dei messaggi e categorie di stato coerenti semplificano l'automazione, la generazione di rapporti e gli avvisi.
  - **Allineare la logica di automazione alle altre parti del sistema**. Se è stata creata una corretta [gestione degli errori](/docs/architect/it-it/well-architected/guide/automated#gestione-degli-errori) di automazione, è possibile estendere tali schemi al modo in cui si classificano le modifiche di stato e si risponde con l'automazione. Per le modifiche dello stato considerate recuperabili, è possibile automatizzare i comportamenti di tentativo. Per le modifiche dello stato considerate critiche o fatali, automatizzare gli avvisi agli utenti.
- **Evitare di creare rumore**. Quando gli utenti ricevono troppi avvisi, soprattutto quelli che non richiedono alcuna azione, tendono a disabilitare o ignorare tutti gli avvisi. Questo scenario compromette qualsiasi sforzo per creare avvisi [utili](/docs/architect/it-it/well-architected/guide/engaging#utile). Per comprendere meglio chi riceve gli avvisi, che cosa li attiva e quando vengono attivati, valutare la possibilità di eseguire queste operazioni.
  - **Creare mappe stakeholder**. Per assicurarsi che il sistema fornisca gli avvisi giusti agli stakeholder giusti al momento giusto, identificare e classificare innanzitutto i gruppi di stakeholder.
  - **Instradare i messaggi in base ai privilegi utente**. Inviare avvisi solo ai destinatari che hanno la capacità e l'autorità per rispondere. Gli utenti aziendali potrebbero trarre vantaggio dagli avvisi sui problemi che possono risolvere correggendo i problemi nei record a cui hanno accesso. Se un problema richiede una risposta tecnica più coinvolta, gli avvisi devono essere indirizzati al personale di assistenza.
  - **Chiarire la risposta prevista**. Inviare avvisi solo in scenari che richiedono l'intervento umano. Strutturare i messaggi per indicare chiaramente l'azione che ci si aspetta dal destinatario. Se si invia un avviso a uno stakeholder per la visibilità e non è richiesta alcuna azione da parte dello stesso, specificarlo chiaramente nella versione del messaggio che riceve.
  - **Rendere tempestivi e pertinenti** gli avvisi. Gli avvisi inviati in risposta a errori che si sono verificati e che devono ancora essere risolti) non sono utili quanto gli avvisi relativi a un potenziale errore. Idealmente, il personale di assistenza viene avvisato non appena si verificano condizioni problematiche nel sistema, offrendo l'opportunità di [risolvere](/docs/architect/it-it/well-architected/guide/resilient#capacità-di-triage) i problemi prima che possano avere impatti negativi sulle operazioni aziendali.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/resilient#schemi-di-risposta-agli-incidenti-e-schemi-anti-incidente) mostra l'aspetto dell'architettura per un monitoraggio e un avviso efficaci in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per il monitoraggio e l'avviso, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Schemi di risposta agli incidenti e schemi anti-incidente

Questa tabella mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la riparazione.

✨ Scopri altri schemi per la risposta agli incidenti in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/adaptable-incident-response).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr><td rowspan="4"><b>Tempo di recupero</b></td>
            <td><strong>Nel tuo business:</strong>
                <br> - I protocolli di recupero vengono praticati a intervalli regolari.
                <br> - I team sanno di quali servizi in produzione sono titolari e responsabili.
                <br> - I team comprendono gli strumenti pertinenti per supportare la diagnosi dei problemi.</td>
            <td><strong>Nel tuo business:</strong>
                <br> I protocolli di ripristino non esistono o non vengono praticati a intervalli regolari.
                <br> - Quali team sono titolari e responsabili dei diversi servizi in produzione non è chiaro.
                <br> - I team non hanno linee guida o standard sugli strumenti per supportare la diagnosi dei problemi.</td>
        </tr>
        <tr><td><strong>Nella documentazione:</strong>
            <br> - Le tattiche di ripristino sono definite e classificate per tipo di incidente e trigger.
            <br> - I criteri di uscita per le risposte agli incidenti sono inclusi negli SLO e sono chiari.
            <br> - I criteri di attivazione e la logica di assegnazione per le autorizzazioni elevate durante gli incidenti sono chiari.
            <br> - Gli insiemi di autorizzazioni e le autorizzazioni per la risposta agli incidenti sono chiaramente elencati.
            <br> - Esiste una guida alla risoluzione dei problemi per aiutare a identificare e diagnosticare i problemi comuni.</td>
            <td><strong>Nella documentazione:</strong>
                <br> - La risposta agli incidenti viene eseguita ad hoc.
                <br> - I criteri di uscita per le risposte agli incidenti non esistono.
                <br> - Le autorizzazioni elevate non vengono assegnate o, se lo sono, vengono assegnate ad hoc.
                <br> - Gli insiemi di autorizzazioni e le autorizzazioni per la risposta agli incidenti non sono elencati.</td>
        </tr>
        <tr><td><strong>Nella propria organizzazione:</strong>
            <br> - Gli insiemi di autorizzazioni basati su sessioni per la risposta agli incidenti esistono e possono essere assegnati al personale di assistenza durante il ripristino.
            <br> - Itinerario di controllo impostazioni mostra che i tester di ripristino designati hanno eseguito l'accesso all'ambiente di test all'ora concordata e hanno seguito gli script dei test di ripristino.</td>
            <td><strong>Nella propria organizzazione:</strong>
                <br> - Gli insiemi di autorizzazioni basati su sessioni non esistono per la risposta agli incidenti oppure, in caso affermativo, il personale di assistenza non è autorizzato a utilizzarli.
                <br> - Itinerario di controllo impostazioni mostra che i tester di ripristino designati non hanno eseguito l'accesso all'ambiente di test o non hanno seguito gli script dei test di ripristino</td></tr>
        <tr><td><strong>Nei piani di test:</strong>
            <br> - Gli script di test per i test di ripristino esistono e sono ripetibili.
            <br> - Gli ambienti per le simulazioni degli incidenti sono chiaramente elencati.</td>
            <td><strong>Nei piani di test:</strong>
                <br> - Gli script di test per i test di ripristino non esistono.
                <br> - Gli ambienti per le simulazioni degli incidenti non sono stabiliti.</td>
        </tr>
        <tr><td rowspan="3"><b>Capacità di triage</b></td>
            <td><strong>Nel tuo business:</strong>
                <br> - le PMI o le parti interessate che devono essere avvisate per supportare questioni complesse vengono identificate prima che si verifichi un incidente.
                <br> - Il passaggio di consegne tra i team di consegna e di assistenza fa parte dell'implementazione.
                <br> - Se consultati, gli architetti Salesforce rispondono rapidamente e aiutano il team a rimanere concentrato sul ripristino.</td>
            <td><strong>Nel tuo business:</strong>
                <br> - Le PMI o gli stakeholder che devono essere avvisati non vengono identificati finché non si verifica un incidente.
                <br> - Il passaggio di consegne tra i team di consegna e i team di assistenza non fa parte del processo di rilascio.
                <br> Gli architetti Salesforce considerano la risposta agli incidenti al di fuori del loro ambito di lavoro.</td></tr>
        <tr><td><strong>Nella documentazione:</strong>
            <br> - Gli schemi di sistema e di progettazione utilizzati in una determinata soluzione sono individuabili e leggibili dal personale di assistenza.</td>
            <td><strong>Nella documentazione:</strong>
                <br> - Gli schemi di sistema e di progettazione utilizzati in una determinata soluzione non sono facilmente disponibili per il personale di assistenza.</td>
        </tr>
        <tr><td><strong>Nella propria organizzazione:</strong>
            <br> - La registrazione e i messaggi di errore personalizzati sono incorporati nei percorsi di esecuzione in tutto il sistema.</td>
            <td><strong>Nell'organizzazione:</strong> - La registrazione e i messaggi di errore personalizzati non vengono utilizzati.</td></tr>
        <tr><td rowspan="2"><b>Monitoraggio e avvisi</b></td>
            <td><strong>Nella propria organizzazione:</strong>
                <br> - Gli avvisi vengono utilizzati solo per informare gli utenti di scenari che richiedono l'intervento umano; altri errori vengono registrati e segnalati.
                <br>  - Gli avvisi vengono inviati agli utenti che sono in grado di rispondere.
                <br> Ove possibile, gli avvisi vengono consegnati prima di un potenziale errore.</td>
            <td><strong>Nella propria organizzazione:</strong>
                <br> - Gli avvisi vengono inviati quando si verifica qualsiasi tipo di errore, indipendentemente dal fatto che siano necessarie azioni di follow-on.
                <br> - Gli avvisi sui problemi che richiedono soluzioni tecniche vengono consegnati agli utenti aziendali.
                <br> - Gli avvisi vengono consegnati solo in risposta a errori che si sono già verificati.</td></tr>
        <tr>
            <td><strong>Nella documentazione:</strong>
                <br> - I criteri di immissione per la sintonizzazione degli avvisi vengono definiti in base alle metriche di feedback AI generative dirette e indirette.</td>
            <td><strong>Nella documentazione:</strong>
                <br> - Non sono definiti criteri per l'attivazione degli avvisi di sintonizzazione rapida per le app di intelligenza artificiale generative.</td></tr>
    </tbody>
</table>

## Pianificazione della continuità

Una chiave per la resilienza del business è la pianificazione della continuità, che si concentra su come consentire alle persone e ai sistemi di funzionare attraverso i problemi causati da un evento non pianificato. I piani di continuità operativa (BCP) hanno una visione orientata alle persone di come far avanzare i processi attraverso la crisi. Gli aspetti tecnici della pianificazione della continuità sono contenuti nelle parti di ripristino di emergenza di un BCP. Vedere [Continuità tecnologica](/docs/architect/it-it/well-architected/guide/resilient#continuità-tecnologica).

Senza piani di continuità adeguati, l'organizzazione potrebbe ora sapere come agire, e quindi non agire affatto, durante una crisi o un guasto del sistema. Una pianificazione della continuità inefficace può avere un impatto catastrofico su clienti, stakeholder e aziende. A seguito di un evento avverso, ogni momento trascorso senza mantenere o ripristinare processi critici rischia danni finanziari, danni alla reputazione, sicurezza dei dipendenti e persino conformità alle normative.

È possibile migliorare la pianificazione della continuità nei sistemi concentrando gli sforzi in tre aree: [definizione della continuità aziendale](/docs/architect/it-it/well-architected/guide/resilient#continuità-operativa), [pianificazione della continuità](/docs/architect/it-it/well-architected/guide/resilient#continuità-tecnologica) e [creazione di backup e ripristino](/docs/architect/it-it/well-architected/guide/resilient#creazione-di-funzionalità-di-backup-e-ripristino).

### Continuità operativa

È possibile che la società disponga già di un BCP. In caso affermativo, assicurarsi che Salesforce sia incluso. Se la propria azienda non dispone di un BCP, collaborare con gli stakeholder per crearne uno che copra le organizzazioni Salesforce.

Salesforce è spesso considerato una fonte di dati veritieri per i dati dei clienti e i processi aziendali essenziali in molte divisioni aziendali. Di conseguenza, il ruolo svolto da Salesforce in un BCP può essere diverso da quello svolto da altri sistemi. È probabile che Salesforce sarà coinvolto in molte aree con priorità alta per il ripristino.

Per creare una pianificazione della continuità operativa pertinente per i sistemi Salesforce:

- **Chiarire le priorità per il ripristino**. Come per l'approccio generale per la [risposta agli incidenti](/docs/architect/it-it/well-architected/guide/resilient#risposta-incidente), la ripresa deve essere la prima priorità per i sistemi nei momenti di crisi. Molti servizi business critical vengono eseguiti in e con Salesforce. È necessario aiutare gli stakeholder a identificare la priorità corretta per il ripristino di varie funzioni e funzionalità aziendali. Un quadro generale potrebbe essere:
  - Stabilizzare l'infrastruttura aziendale essenziale.
  - Stabilizzare l'assistenza clienti.
  - Stabilizzare i servizi per dipendenti e partner.
- **Tenere conto del proprio ecosistema nei BCP**. Salesforce non è l'unico sistema nel panorama. Assicurarsi di identificare eventuali lacune nel BCP relative ai sistemi che si integrano con Salesforce, alle soluzioni installate dai fornitori AppExchange e a qualsiasi altro sistema che si connette a dati o processi in Salesforce. Se la capacità di fornire dipende dai fornitori, chiedere a questi ultimi informazioni sui loro piani di continuità. Valutare le loro capacità e pianificare come mantenere disponibili i sistemi.
- **Integrare le preoccupazioni BCP nella strategia di test**. Creare piani di test per il BCP ed eseguirli. È particolarmente importante testare le aree del BCP relative ai processi o alle persone, che spesso vengono trascurate. Incorporare gli elementi pertinenti del BCP nella [strategia di test](/docs/architect/it-it/well-architected/guide/resilient#strategia-di-test) ALM generale. Creare e seguire una pianificazione di manutenzione per rivedere i test e assicurarsi che il piano rimanga aggiornato.

Gli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/resilient#schemi-di-pianificazione-della-continuità-e-antischemi) mostrano l'aspetto di una pianificazione della continuità corretta e inadeguata in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la definizione della continuità operativa, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Continuità tecnologica

L'obiettivo della continuità tecnologica è assicurarsi che i problemi con i componenti di un sistema non impediscano all'azienda di gestire le operazioni essenziali. Salesforce dà priorità al mantenimento dei servizi ai massimi livelli di disponibilità e alla fornitura di informazioni trasparenti su eventuali problemi. È possibile visualizzare informazioni in tempo reale sulle prestazioni e i problemi del sistema Salesforce su [Trust.salesforce.com](https://trust.salesforce.com/). In qualità di architetto basato su Salesforce, le soluzioni sfruttano l'affidabilità, la sicurezza e le prestazioni del sito offerte da Salesforce in tutta la piattaforma.

Tuttavia, la continuità complessiva delle soluzioni Salesforce va oltre i servizi integrati offerti da Salesforce. Da un punto di vista architetturale, la pianificazione della continuità tecnologica di Salesforce deve iniziare ponendo e rispondendo a domande su come Salesforce si inserisce nel panorama aziendale più ampio. Quali tipi di sistemi si integrano con Salesforce? In che modo i sistemi esterni dipendono dai processi o dalle informazioni in Salesforce? Nelle organizzazioni Salesforce, quali processi o funzionalità si basano sulle soluzioni AppExchange? Gli utenti accedono a Salesforce tramite servizi di identità di terze parti o SSO?

Per migliorare la continuità tecnologica nei sistemi Salesforce:

- **Valutare l'infrastruttura.** La strategia di risoluzione più comune per le interruzioni o i problemi tecnologici è la creazione di servizi o sistemi ridondanti a cui è possibile ricorrere durante un incidente. Salesforce dispone di un'architettura intenzionalmente ridondante, ovvero gestisce copie dei sistemi e dei servizi dei clienti in sedi fisiche diverse. Utilizziamo diverse tecniche di ripristino di emergenza, tra cui il passaggio da un sito all'altro, che ci consente di indirizzare il traffico degli utenti da un data center all'altro se necessario. Per identificare dove potrebbe essere necessario creare una ridondanza intenzionale, porsi le seguenti domande.
  - Che cosa accade durante un'interruzione del servizio per il servizio \[X]? Possiamo passare da quel servizio a un altro?
  - Quanto tempo ci vuole per recuperare \[X]? Qual è l'impatto sui nostri clienti? Qual è l'impatto sui nostri partner? Qual è l'impatto sui team interni?
  - E i [backup](/docs/architect/it-it/well-architected/guide/resilient#creazione-di-funzionalità-di-backup-e-ripristino) e la loro frequenza? I backup potrebbero fornire i dati necessari per supportare l'azienda?
  - Abbiamo dipendenze dai fornitori? Quali sono i loro piani BCP?
- **Fornire supporto operativo.** Il supporto operativo consiste nel ripristinare l'operatività dei team il più velocemente possibile. Riflettere su come il sistema può gestire aumenti significativi dei requisiti di capacità e della domanda dovuti a cambiamenti imprevisti, inclusi cambiamenti a livello di settore, regionale o globale. Assicurarsi che il proprio BCP tenga conto delle risorse aggiuntive o delle procedure break-glass di cui Site Reliability Engineering (SRE) o i team di assistenza potrebbero avere bisogno per rispondere efficacemente agli incidenti. Le domande da porre sul supporto operativo includono:
  - In caso di guasto, i nostri team tecnici avrebbero gli strumenti necessari per continuare a lavorare? Abbiamo simulato un guasto per convalidare i piani o identificare lacune?
  - Se un disastro si verifica in un'area specifica, abbiamo piani di copertura per quell'area?
  - I nostri clienti sono globali? Operano 24 ore su 24, 7 giorni su 7?
  - Disponiamo di [monitoraggio e avvisi](/docs/architect/it-it/well-architected/guide/resilient#monitoraggio-e-avviso) adeguati per informare le persone appropriate in caso di errori?
- **Automatizzare e testare le tattiche di recupero.** Dopo aver risolto un problema, identificare dove si è verificato e come è stato risolto. Se possibile, in base alla riparazione, automatizzare le tattiche di ripristino e correggere eventuali problemi del processo. Molte aziende pianificano simulazioni di incidenti per un sottoinsieme di servizi per testare la resilienza del sistema. Un esempio potrebbe essere la simulazione di un account amministratore di sistema bloccato o compromesso o la simulazione di un guasto o un problema con un provider AppExchange. Vedere [Risposta agli incidenti](/docs/architect/it-it/well-architected/guide/resilient#risposta-incidente).)Le domande su come i test e l'automazione possono aiutare a ripristinare più rapidamente i servizi includono:
  - Con che frequenza vengono pianificate ed eseguite le simulazioni degli incidenti?
  - Sappiamo quanto tempo ci vuole per riportare i servizi a uno stato stabile?
  - Sono in atto processi di consegna stabili?
  - Sappiamo dove automatizzare il failover e il ripristino?

Considerare tutti gli elementi che escono dalle recensioni post-incidente come gli altri elementi di sviluppo. Aggiungerli ai sistemi di pianificazione in modo da poterli assegnare alle priorità e utilizzarli.

Gli [schemi e antischemi per la](/docs/architect/it-it/well-architected/guide/resilient#schemi-di-pianificazione-della-continuità-e-antischemi) pianificazione della continuità mostrano l'aspetto corretto e inadeguato della pianificazione della continuità tecnologica in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la pianificazione della continuità tecnologica, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Creazione di funzionalità di backup e ripristino

Il ripristino delle copie di backup dei dati o dei metadati può contribuire a riportare l'organizzazione all'ultimo stato stabile noto. Può anche fornire un sistema di failover durante un guasto catastrofico del sistema o un'interruzione del servizio. Il backup regolare dei dati e dei metadati e l'archiviazione delle copie di backup crittografate in un luogo sicuro aggiungono un ulteriore livello di resilienza all'architettura.

Senza strategie di backup e ripristino, non è possibile ripristinare versioni pulite dei dati di produzione e dei metadati quando vengono danneggiati in modo dannoso, quando i difetti si fanno inavvertitamente strada nella produzione o quando un errore durante un carico di dati elevato danneggia i dati di produzione. Uno qualsiasi di questi scenari può causare la corruzione o addirittura la perdita definitiva dei dati di produzione critici per l'azienda. L'impostazione della tecnologia di backup e ripristino offre una serie di vantaggi oltre alla pianificazione della continuità, tra cui l'assistenza nelle strategie per mitigare grandi volumi di dati e l'adesione alle policy di conservazione relative alla conformità.

Per garantire la continuità con le strategie di backup e ripristino nelle soluzioni Salesforce:

- **Inizia.** Il primo passo per avere una buona strategia di backup e ripristino è innanzitutto avere una strategia. Anche un'operazione semplice come l'esecuzione di backup notturni di tutti i dati e metadati dell'organizzazione può evitare che l'azienda perda informazioni o funzionalità critiche durante un disastro.
- **Limitare l'accesso ai backup.** Gli amministratori di sistema sono gli unici utenti che dovrebbero avere accesso alle copie di backup dei dati. Questa limitazione di accesso impedisce a un utente aziendale di visualizzare i record in una copia di backup che non sarebbe autorizzato a visualizzare nell'organizzazione.
- **Testare regolarmente il processo di ripristino.** Indipendentemente dalla strategia di backup e ripristino implementata, [testare](/docs/architect/it-it/well-architected/guide/resilient#strategia-di-test) regolarmente il processo di ripristino in un Sandbox Copia completa o parziale per assicurarsi che funzioni correttamente quando necessario.
- **Allineare la strategia di backup e ripristino alla strategia di archiviazione dei dati.** Determinare cosa deve accadere nei backup o negli archivi quando i record vengono archiviati o eliminati dal sistema. Vedere [Volume di dati](/docs/architect/it-it/well-architected/guide/reliable#volume-di-dati)).

Può essere necessaria una strategia di backup più dettagliata se i volumi di dati sono così elevati che un backup completo non ha il tempo di essere completato prima che inizi l'esecuzione del backup successivo. Può anche essere necessaria una strategia di backup più dettagliata se i dati dell'organizzazione cambiano così spesso che gli aggiornamenti sono mission critical per l'organizzazione.

Per rendere la strategia di backup più dettagliata:

- **Amministrare i backup a oggetti specifici**. Questa strategia prevede il backup dei record di oggetti diversi a intervalli di tempo diversi. Tenere presente che è necessario eseguire il backup degli oggetti secondari con gli stessi intervalli dei relativi oggetti controllanti per mantenere la coerenza dei dati.
- **Backup parziali** **della casella temporale**. Questa strategia prevede la distinzione tra backup completi (di tutti i dati e metadati) e backup parziali (solo dei metadati e dei record aggiunti o modificati dopo l'ultimo backup).

**\* Non smettere mai di eseguire backup completi**. È importante notare che non è mai opportuno eliminare completamente i backup completi, anche se i volumi di dati causano tempi di esecuzione lunghi. Per volumi di dati elevati, pianificare backup completi regolari ma poco frequenti (ad esempio, backup settimanali). Pianificare anche backup parziali o specifici degli oggetti più frequenti (ad esempio backup notturni o backup ogni X ore). Questo approccio offre la flessibilità di ricostruire la serie di dati più completa e precisa da utilizzare nei processi di ripristino.\*

Gli [schemi e antischemi per la](/docs/architect/it-it/well-architected/guide/resilient#schemi-di-pianificazione-della-continuità-e-antischemi) pianificazione della continuità mostrano come si presentano le funzionalità di backup e ripristino appropriate e scadenti in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare i punti del sistema che devono essere sottoposti a refactoring.

### Backup e ripristino di Salesforce

Salesforce Backup and Recover, una soluzione Salesforce integrata che include Own Recover from the Own acquisition, protegge i dati importanti da perdite o danneggiamenti. La nostra soluzione altamente sicura, facile da configurare e sempre disponibile garantisce la continuità operativa e la resilienza dei dati e semplifica la conformità.

Utilizzare Salesforce Backup and Recover per prevenire la perdita di dati, ripristinare rapidamente i dati da incidenti e semplificare la strategia di gestione dei dati complessiva. È possibile creare policy di backup per i dati di valore elevato e regolamentati e ripristinarli in pochi clic.

#### Distribuzione di backup automatici

I backup automatici giornalieri proteggono tutti i dati cruciali dell'organizzazione, inclusi metadati, Sandbox, dati dei pacchetti gestiti, file allegati e altro ancora. Eseguire i backup con la frequenza necessaria per raggiungere gli obiettivi del punto di ripristino (RPO) e salvaguardare le distribuzioni. I backup sono sempre accessibili e archiviati in modo sicuro e conforme. La protezione continua dei dati è disponibile anche per i dati più sensibili o transazionali, consentendo un ripristino più rapido delle informazioni critiche in rapida evoluzione.

#### Monitoraggio proattivo dei dati

Rileva attività insolite dei dati, perdita di dati e danneggiamento con avvisi proattivi inviati direttamente al tuo indirizzo email. Ricevere avvisi in tempo reale per identificare i valori anomali statistici o per creare regole che informano dell'attività insolita dei dati, consentendo di rilevare gli incidenti più rapidamente che mai.

#### Ripristino preciso e rapido

Salesforce Backup and Recover accelera il ripristino offrendo una visibilità granulare delle modifiche, consentendo l'identificazione e il ripristino rapidi dei dati interessati. Strumenti come i grafici visivi evidenziano le modifiche indesiderate, mentre le funzioni di ripristino facili da usare ripristinano con precisione oggetti, campi e record interessati.

#### Estensione dell'uso dei backup

I nostri strumenti consentono di utilizzare i backup per analisi, controlli e conformità, offrendo dati storici ricercabili, funzionalità di ricerca aperte per la visibilità dei dati passati e funzionalità di esportazione per analisi o magazzini esterni. In questo modo i backup vengono riutilizzati senza bisogno di API Salesforce aggiuntive.

#### Gestione dei dati di backup unificata

Backup and Recover offre un'unica console per consolidare tutti i backup, la gestione, le operazioni e la conformità. Questa console consente di accedere, gestire, personalizzare e monitorare i backup per tutte le organizzazioni di produzione e i Sandbox. Con questo strumento è anche possibile eseguire le richieste degli interessati per garantire la conformità dei dati di backup e avere il controllo completo sulla personalizzazione delle pianificazioni di backup, della frequenza e dei criteri di conservazione.

#### Casi d'uso chiave per il backup e il ripristino di Salesforce

- **Mitigare l'impatto degli incidenti sui dati**. Salesforce Backup and Recover aiuta a mitigare gli incidenti nei dati, ad esempio attacchi informatici o attività interne o esterne dannose, consentendo agli utenti di ripristinare lo stato precedente all'incidente. La funzionalità di esportazione di Backup and Recover garantisce l'accesso continuo ai dati critici degli utenti e la loro fruibilità.
- **Impedire perdite permanenti**. L'errore umano rimane la causa principale della perdita di dati. Backup and& Recover offre una soluzione precisa e rapida a questi errori.
- **Soddisfare più facilmente la conformità dei dati e i requisiti legali**. Salesforce Backup and Recover supporta il modello di responsabilità condivisa, abilitando la funzionalità self-service per gli errori in blocco o la rettifica dei dati nei dati di backup.

Per ulteriori informazioni sugli strumenti Salesforce per il backup e il ripristino, vedere [Salesforce Tools for Resiliency](/docs/architect/it-it/well-architected/guide/resilient#strumenti-salesforce-per-laffidabilità).

### Schemi di pianificazione della continuità e antischemi

Questa tabella mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la riparazione.

✨ Scopri altri schemi per la pianificazione della continuità in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/adaptable-continuity-planning).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr><td rowspan="3"><b>Continuità operativa</b></td>
        <td><strong>Nel tuo business:</strong>
            <br> - Viene adottata una mentalità "recovery first" con l'obiettivo di ridurre al più presto l'impatto delle funzioni e delle funzionalità aziendali con la massima priorità.
             <br> - C'è una pianificazione di manutenzione per la revisione dei piani di test BCP.</td>
        <td><strong>Nel tuo business:</strong>
             <br> - Una mentalità "correggi il problema" è l'unico approccio alla gestione degli incidenti.
             <br> - I piani di test BCP non vengono aggiornati a intervalli regolari.</td></tr>
    <tr><td><strong>Nella documentazione:</strong>
         <br> - Esiste un BCP contenente le fasi per continuare a elaborare o triage i dati se Salesforce non è disponibile, un elenco di eventi che attivano l'uso del BCP e fasi e intervalli per i test BCP.
         <br> - Il BCP include sistemi e dipendenze a monte e a valle.</td>
        <td><strong>Nella documentazione:</strong>
             <br> - Un BCP non esiste, non è completo o include solo Salesforce.</td>
    </tr>
    <tr><td><strong>Nei piani di test:</strong>
         <br> - Vengono considerate le aree del BCP relative ai processi e alle persone.</td>
        <td><strong>Nei piani di test:</strong>
             <br> - Le aree del BCP correlate ai processi e alle persone non vengono considerate.</td></tr>
    <tr><td rowspan="2"><b>Continuità tecnologica</b></td>
        <td><strong>Nel tuo business:</strong>
            <br> - Hai valutato se è necessario creare sistemi di ridondanza intenzionale o failover
            <br> - Le tattiche di ripristino degli incidenti vengono automatizzate ogni volta che è possibile.</td>
        <td><strong>Nel tuo business:</strong>
            <br> - Non è stata valutata la necessità di una ridondanza intenzionale o di sistemi di fail over
            <br> - Le tattiche di ripristino degli incidenti sono tutte manuali.</td>
    </tr>
    <tr><td><strong>Nella documentazione:</strong>
        <br> - Il BCP tiene conto delle risorse aggiuntive o delle procedure break-glass di cui i team potrebbero avere bisogno per rispondere efficacemente agli incidenti.</td>
        <td><strong>Nella documentazione:</strong>
            <br> - Il BCP non include le esigenze di assistenza operativa.</td>
    </tr>
    <tr><td rowspan="2"><b>Backup e ripristino</b></td>
        <td><strong>Nella documentazione:</strong>
            <br> - Esiste una strategia di backup e ripristino sia per i dati che per i metadati.</td>
        <td><strong>Nella documentazione:</strong>
            <br> - Una strategia di backup e ripristino non esiste o, in caso affermativo, è incompleta e si applica solo ai dati o solo ai metadati, non a entrambi.</td></tr>
    <tr><td><strong>Presso la vostra azienda:</strong>
        <br> - I backup sono memorizzati in una posizione sicura a cui possono accedere solo gli utenti autorizzati.
        <br> - I piani di test e i registri di test mostrano che i ripristini dei dati vengono testati in un Sandbox Copia completa o parziale almeno due volte l'anno.</td>
        <td><strong>Presso la vostra azienda:</strong>
            <br> I backup non sono leggibili.
            <br> I backup sono archiviati in posizioni a cui possono accedere utenti aziendali non autorizzati.
            <br> - Non esiste un processo di ripristino dei dati o il processo di ripristino dei dati non è testato.</td>
    </tr>
    </tbody>
</table>

## Strumenti Salesforce per l'affidabilità

<table class="tools-table"><tbody><tr><th>Strumento</th><th>Descrizione</th><th>Gestione del ciclo di vita delle applicazioni</th><th>Risposta incidente</th><th>Pianificazione della continuità</th></tr>

<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.apex_hammer_execution_status.htm&type=5">Test martello Apex</a></td>
<td>Informazioni sui test Salesforce Apex nei rilasci correnti e nuovi.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm">API Apex Stub</a></td>
<td>Creare un framework fittizio per semplificare i test.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.backup_restore.htm&type=5">Backup e ripristino</a></td>
<td>Generare automaticamente backup per evitare la perdita di dati.</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.custom_index.htm&type=5">Big Object</a></td>
<td>Archiviare e gestire grandi volumi di dati sulla piattaforma.</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=tracking_field_history.htm&type=5&language=en_US">Tracciamento cronologia campi</a></td>
<td>Monitorare e visualizzare la cronologia dei campi.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=adoption_security_metrics.htm&type=5&language=en_US">Ottieni approfondimenti sull'adozione e la sicurezza per la tua organizzazioneApri il link in una nuova finestra</a></td>
<td>Monitorare l'adozione e l'utilizzo di Lightning Experience nell'organizzazione.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=monitoring_async_api_jobs_overview.htm&type=5&language=en_US">Gestisci processi di caricamento dati in blocco</a></td>
<td>Creare, aggiornare o eliminare grandi volumi di record con l'API in blocco.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=event_monitoring_monitor_events_with_event_manager.htm&type=5&language=en_US">Gestisci eventi di Monitoraggio evento in tempo reale</a></td>
<td>Gestire le impostazioni di streaming e archiviazione del monitoraggio evento.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=admin_monitorresources.htm&type=5&language=en_US">Risorse di dati e archiviazione</a></td>
<td>Visualizzare i limiti di memoria e l'utilizzo dell'organizzazione Salesforce.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=code_monitoring_debug_logs.htm&type=5&language=en_US">Monitoraggio dei registri debug</a></td>
<td>Monitorare i registri e impostare i flag per attivare la registrazione.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=event_monitoring_faq.htm&type=5&language=en_US">Monitoraggio dell'attività di accesso con Login Forensics</a></td>
<td>Identificare il comportamento che può indicare una frode dell'identità.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=admin_monitorsetup.htm&type=5&language=en_US">Monitoraggio delle modifiche alle impostazioni con Itinerario di controllo impostazioni</a></td>
<td>Tenere traccia delle modifiche apportate di recente dagli amministratori.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=monitoring_training_history.htm&type=5&language=en_US">Monitoraggio della cronologia di addestramento</a></td>
<td>Visualizzare i corsi di formazione Salesforce seguiti dagli utenti.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=monitoring_background_jobs.htm&type=5&language=en_US">Monitoraggio dei processi in background</a></td>
<td>Monitorare i processi in background nell'organizzazione.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=data_monitoring_jobs.htm&type=5&language=en_US">Monitoraggio dei processi pianificati</a></td>
<td>Visualizzare istantanee del rapporto, processi Apex pianificati e aggiornamenti dei cruscotti digitali.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.technical_requirements_performance_assistant.htm&type=5">Test scala</a></td>
<td>Testare le prestazioni del sistema e interpretare i risultati.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://www.salesforce.com/services/professional-services/proactive-monitoring/">Proactive Monitoring</a></td>
<td>Ridurre al minimo le interruzioni utilizzando i servizi di monitoraggio Salesforce.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.data_mask_overview.htm&type=5">Salesforce Data Mask</a></td>
<td>Mascherare automaticamente i dati in un Sandbox.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=dev_force_com_system_overview_page.htm&type=5&language=en_US">Pagina Panoramica del sistema</a></td>
<td>Visualizzare i dati e i limiti di utilizzo per l'organizzazione.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Usa force:Lightning:lint</a></td>
<td>Analizzare e convalidare il codice tramite Salesforce CLI.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
</table>

## Risorse rilevanti per la resilienza

<table class="tools-table"><tbody><tr><th>Risorsa</th><th>Descrizione</th><th>Gestione del ciclo di vita delle applicazioni</th><th>Risposta incidente</th><th>Pianificazione della continuità</th></tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/7-anti-patterns-in-performance-and-scale-testing-ba4eeda00516?source=friends_link&sk=5268a41719e7d01ba7f89f003064918f">7 Anti-schemi nei test di prestazioni e scala</a></td>
<td>Evitare gli schemi anti-pattern comuni nei test delle prestazioni e della scala.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://developer.salesforce.com/blogs/2022/05/analyze-performance-scale-hotspots-in-complex-salesforce-apps">Analisi degli hotspot di prestazioni e scalabilità nelle app Salesforce complesse</a></td>
<td>Di seguito viene descritto un approccio per risolvere i problemi di prestazioni e scalabilità nell'organizzazione.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://trailhead.salesforce.com/en/content/learn/modules/cybersecurity-threat-prevention-and-response/build-a-disaster-recovery-plan">Creazione di un piano di ripristino di emergenza (Trailhead)</a></td>
<td>Creare un piano di ripristino di emergenza.</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/business-continuity-is-more-than-backup-and-restore-bebe9fb9b93d">La continuità operativa non è solo backup e ripristino</a></td>
<td>Ottenere una visione completa di BCP.</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="/docs/architect/it-it/resources/guide/design-standards-template">Modello Design Standards (Standard di progettazione)</a></td>
<td>Creare standard di progettazione per la propria organizzazione.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/diagnostics-and-monitoring-tools-for-salesforce-part-1-bfa059f9a63e?source=search_post---------3----------------------------">Strumenti di diagnostica e monitoraggio in Salesforce</a></td>
<td>Informazioni su come migliorare la qualità e le prestazioni delle implementazioni.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/guiding-principles-for-bcps-6871d29ee947">Principi guida per la pianificazione della continuità operativa</a></td>
<td>Esaminare i principi di base alla base del BCP effettivo.</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/how-to-scale-test-on-salesforce-bf933d5948b9">Come eseguire il Test di scalabilità in Salesforce</a></td>
<td>Di seguito sono descritte le cinque fasi del ciclo di vita del test su scala.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://developer.salesforce.com/blogs/2020/09/introduction-to-performance-testing">Introduzione ai test delle prestazioni</a></td>
<td>Di seguito viene descritto come sviluppare un metodo di test delle prestazioni.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5">Monitoraggio dell'organizzazione</a></td>
<td>Informazioni sulle opzioni di monitoraggio self-service.</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="/docs/architect/it-it/resources/guide/test-strategy-template">Test del modello di strategia</a></td>
<td>Creare e personalizzare piani di test di scala e delle prestazioni.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="/docs/architect/it-it/resources/guide/test-strategy-template">Test del modello di strategia</a></td>
<td>Assicurarsi che la strategia di test sia completa.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://trailhead.salesforce.com/en/content/learn/modules/sfdx_dev_model/sfdx_dev_model_sdd">Informazioni sullo sviluppo basato sulla fonte (Trailhead)</a></td>
<td>Informazioni sullo sviluppo dei pacchetti e sulle organizzazioni vuote.</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>

</table>

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.

<!-- document id=ba2ef10c30507bc2d567b8b2fd4aca1360887b9fd7675401553610c3ef4ba5aa url=/architect/next/it-it/well-architected/guides/secure.md -->

> Leggi [qui](/docs/architect/it-it/well-architected/guide/contributors) le nostre pianificazioni degli aggiornamenti.

## Introduzione

Un sistema sicuro protegge gli stakeholder e i dati di un'organizzazione. Le architetture protette verificano l'identità degli utenti, limitano l'accesso ai dati solo alle informazioni necessarie e impediscono la compromissione dei dati.

Salesforce assegna priorità al Customer Trust e alla sicurezza dei dati. Salesforce Platform garantisce privacy e sicurezza. Le informazioni in tempo reale sulle prestazioni del sistema e sulla sicurezza sono disponibili presso [Salesforce Trust](https://trust.salesforce.com/).

La protezione dei dati dell'organizzazione e dei clienti è alla base della creazione di soluzioni Salesforce sicure. L'architetto Salesforce è responsabile della protezione dei dati dell'organizzazione e dei clienti utilizzando le funzioni di protezione incorporate di Salesforce. Considerare la distribuzione geografica, il settore, le procedure operative aziendali e i tipi di dati dei clienti quando si prendono queste decisioni.

È possibile rendere le soluzioni più sicure concentrandosi su tre aree: sicurezza organizzativa, sicurezza delle sessioni e sicurezza dei dati.

## Sicurezza organizzativa

La protezione dell'organizzazione protegge i sistemi dall'accesso non autorizzato assicurando che solo gli utenti convalidati e autorizzati possano accedere a un sistema e solo alle funzioni e ai dati necessari.

I segnali che indicano problemi di sicurezza organizzativa includono:

- Processi ad hoc per attivare o disattivare gli utenti
- Passaggi non chiari per aggiornare l'autorizzazione per le modifiche dei ruoli utente o di sistema
- Affidamento alle Knowledge istituzionali delle persone per le assegnazioni corrette della sicurezza degli utenti
- Mancato allineamento ai framework di sicurezza o alle procedure consigliate del settore
- Assenza di un framework di governance dei dati strutturato e di policy a supporto

È possibile creare controlli di sicurezza organizzativi migliori per le organizzazioni Salesforce concentrandosi sull'autenticazione e l'autorizzazione.

### Autenticazione

L'autenticazione è fondamentale per la sicurezza e la gestione degli accessi, verificando l'identità degli utenti che tentano di accedere al sistema. Questo vale sia per gli utenti umani (dipendenti, clienti) che per gli utenti automatizzati (sistemi esterni, integrazioni), con ogni tipo di utente che richiede schemi di autenticazione specifici. Per garantire un accesso sicuro in tutti i punti di ingresso Salesforce dell'organizzazione, è necessario impostare vari metodi di autenticazione.

Per creare flussi di autenticazione protetti in Salesforce:

- **Creare utenti Salesforce in base alle persone, non ai profili**. Le funzionalità di controllo incorporate di Salesforce sono più efficaci quando ogni account utente corrisponde a una singola persona che accede alla piattaforma. L'uso di account utente condivisi compromette l'efficacia di questi controlli, introduce ulteriori vulnerabilità di sicurezza, aumenta il potenziale impatto delle violazioni degli account e complica la capacità di creare schemi di autorizzazione efficaci. Sono inclusi gli account utente per gli utenti integrazione.
- **Scenari di accesso** protetti basati sull'interfaccia utente. La maggior parte degli utenti richiede un tipo di accesso basato sull'interfaccia utente (spesso chiamato accesso) per un'organizzazione Salesforce. Salesforce offre diversi livelli di protezione per questi scenari di accesso, tra cui:
  - **Polizze sulle password.** I criminali informatici spesso prendono di mira nomi utente e password per ottenere l'accesso non autorizzato alle applicazioni. Benché la configurazione [dei criteri relativi](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5) alle password sia un passaggio fondamentale per proteggere l'accesso, è importante notare che questo da solo non è sufficiente, poiché Salesforce consente la sostituzione di questi criteri per utente.
  - **Autenticazione a più fattori (MFA)**. Salesforce [richiede la MFA](https://help.salesforce.com/s/articleView?id=000352937&type=1) per tutti gli accessi utente basati sull'interfaccia utente. La MFA fornisce una difesa essenziale contro le fughe di credenziali e gli attacchi brute-force richiedendo agli utenti di fornire un'ulteriore forma di identificazione, o fattore, dopo aver immesso correttamente il nome utente e la password. Questo fattore aggiuntivo assume in genere una forma fisica, ad esempio un dispositivo mobile, una chiave di protezione o un indicatore biometrico.
  - **Single-sign on (SSO)**. Negli scenari SSO, gli utenti utilizzano un solo insieme di credenziali nelle applicazioni di un'organizzazione. L'accesso ai sistemi viene fornito e gestito da una posizione centrale, il che migliora la sicurezza. Salesforce può agire come fornitore di servizi o provider di identità negli [scenari SSO](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5). Assicurarsi di consentire ad alcuni o a tutti gli amministratori di accedere direttamente a Salesforce in modo che possano risolvere eventuali guasti o problemi nell'implementazione di SSO.
  - **Fasi post-accesso.** Per alcuni casi d'uso, potrebbe essere necessario eseguire ulteriori operazioni prima di accedere al sistema. È possibile implementare flussi di accesso personalizzati per guidare gli utenti in queste fasi aggiuntive del processo. Gli esempi includono:
    - Accettazione di termini e condizioni
    - Uso degli [scenari di individuazione degli accessi e di accesso senza password](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5)
    - Limitazione del numero di sessioni Salesforce simultanee per utente per ridurre la probabilità di attacchi basati su sessioni (vedere [Sicurezza delle sessioni](/docs/architect/it-it/well-architected/guide/secure#sicurezza-della-sessione)).
    - Connessione ai servizi di geofencing
- **Scenari di accesso** sicuri basati su API. Qualsiasi utente può richiedere l'accesso basato su API per un'organizzazione Salesforce. Salesforce offre diversi livelli di protezione per gli scenari basati su API, tra cui:
  - **Controllo accessi API**. Senza il [controllo accesso API](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5), chiunque disponga di un insieme di credenziali valido può utilizzare qualsiasi app per connettersi all'organizzazione, anche se l'applicazione connessa non è distribuita nell'organizzazione. I controlli di accesso ai dati continueranno a essere applicati, ma gli utenti potrebbero accedere alle informazioni in modi non controllati. Ad esempio, un'app può essere utilizzata per scaricare grandi volumi di dati o persino per caricare informazioni danneggiate senza l'approvazione di un amministratore di sistema.
  - **Autorizzazioni API Only**. È possibile configurare le autorizzazioni utente Solo API in Salesforce. Assegnarlo come parte di un insieme di autorizzazioni a qualsiasi profilo utente automatico o [di integrazione](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm) per bloccare completamente l'accesso basato sull'interfaccia utente.
  - **Certificati e chiavi**. [Certificati e chiavi](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5) consentono a Salesforce di confermare che le richieste provengono da aziende o aziende autorizzate. Se si desidera utilizzare [SSO con Salesforce](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5), sarà necessario configurare certificati e chiavi.
  - **Applicazioni connesse**. La configurazione delle [applicazioni connesse](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5) in Salesforce consente di controllare l'accesso a Salesforce da parte di sistemi esterni, inclusi i protocolli di autenticazione, l'ambito di autorizzazione e il comportamento della sessione richiesti in un'unica definizione.
  - **Credenziali denominate**. Le [credenziali denominate](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5) consentono di controllare i punti di accesso esterni e i protocolli di autenticazione in un'unica definizione in Salesforce. Utilizzarli per definire e gestire in modo sicuro l'autenticazione per le chiamate da Apex, servizi esterni e fonti di dati Salesforce Connect.
- **Autenticazione Agentforce Agent Users**. Gli agenti Agentforce, basati su Salesforce, utilizzano oggetti utente-agente con autorizzazioni gestibili esattamente come quelle degli utenti reali. Quando si imposta un agente, allineare attentamente l'accesso al ruolo svolto dall'agente, limitando l'accesso ai dati solo a ciò che è necessario per servire gli utenti finali. Altrettanto importante, gli agenti possono essere configurati con azioni sia pubbliche che private. Per le azioni private, convalidare e autenticare gli utenti finali mappandoli al contesto dell'agente. Ciò consente all'agente di impersonare e operare all'interno dei controlli di accesso dell'utente finale, mantenendo sicurezza e Trust.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/secure#schemi-di-sicurezza-organizzativi-e-anti-schemi) riportato di seguito mostra l'aspetto dell'architettura di autenticazione corretta (e scadente) in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di autenticazione disponibili in Salesforce, vedere [Strumenti pertinenti per](/docs/architect/it-it/well-architected/guide/secure#strumenti-rilevanti-per-la-sicurezza) la sicurezza.

### Autorizzazione

L'autorizzazione definisce le caratteristiche, le funzionalità e i dati a cui un utente può accedere, nonché le azioni che può eseguire con tali risorse dopo l'[autenticazione](/docs/architect/it-it/well-architected/guide/secure#autenticazione). I controlli di autorizzazione non sono destinati solo agli utenti umani, ma devono anche essere personalizzati per gli utenti Agentforce Agent, in particolare per gli agenti che forniscono servizi agli utenti finali non autenticati.

Anche se limitare gli utenti che possono eseguire l'autenticazione nell'organizzazione è un primo passo fondamentale, è altrettanto essenziale associare un'autenticazione forte a un'autorizzazione efficace. Senza controlli di autorizzazione adeguati, gli utenti potrebbero potenzialmente creare, modificare ed eliminare record o accedere alle funzionalità del sistema in modi dannosi per l'azienda e gli stakeholder. Un controllo delle autorizzazioni inadeguato può anche rendere i sistemi più difficili da utilizzare. Controllando ciò che gli utenti possono fare all'interno del sistema, si alimentano livelli più elevati di Trust, salvaguardando sia il sistema che gli utenti.

Per creare schemi di autorizzazione sicuri per Salesforce:

- **Seguire il principio dei minimi privilegi**. Applicare il principio dei privilegi minimi assegnando agli utenti solo le autorizzazioni necessarie per le loro operazioni. Per seguire questo principio, progettare insiemi di autorizzazioni granulari e modulari. Ciò consente sofisticati controlli degli accessi tramite gruppi di insiemi di autorizzazioni, consentendo una gestione precisa delle autorizzazioni, inclusa la possibilità di [silenziare](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5), [impostare date di scadenza](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238) e altro ancora. Allineare le [unità funzionali dei](/docs/architect/it-it/well-architected/guide/composable#unità-funzionali) sistemi alle funzionalità aziendali per definire autorizzazioni granulari e gruppi di insiemi di autorizzazioni efficaci. Ricordare che le autorizzazioni si applicano all'accesso ai _metadati_ in Salesforce. Per informazioni dettagliate sulla configurazione dell'accesso _ai dati_ PoLP per Salesforce, vedere [Condivisione e visibilità](/docs/architect/it-it/well-architected/guide/secure#condivisione-e-visibilità).
- **Pensare all'accesso degli utenti in termini di profili, non di singoli**. Pensando all'autorizzazione (o alla sicurezza in generale) in termini di singoli utenti non si imposta il sistema per scalare ed evolvere. Progettare e gestire invece profili che rappresentano gruppi di utenti. Le soluzioni Salesforce sicure utilizzano le persone per l'autenticazione e i profili per l'autorizzazione. Definendo configurazioni di sicurezza per profili distinti, si ottiene un controllo granulare sull'accesso e i privilegi nel modello di sicurezza, riducendo al minimo la necessità di refactoring nel lungo periodo. Includere i profili di sicurezza definiti negli [standard di progettazione](/docs/architect/it-it/well-architected/guide/intentional#leggibilità).
- **Controllare l'accesso degli utenti ai metadati utilizzando gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni**. Gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni determinano a quali metadati gli utenti possono accedere e cosa possono fare con tali metadati. Per ulteriori informazioni sui metadati Salesforce, vedere [Metadati e dati](/docs/architect/it-it/fundamentals/guide/architecture-basics#metadati-e-dati). Configurare le assegnazioni delle app, le attivazioni delle licenze funzioni, l'accesso ai pacchetti gestiti, le autorizzazioni di sistema, l'accesso [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) e l'accesso a livello di campo tramite gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni. Includere questo accesso negli [standard di progettazione](/docs/architect/it-it/well-architected/guide/intentional#leggibilità).
- **Utilizzare le impostazioni predefinite dell'organizzazione (OWD) e la condivisione per controllare l'accesso ai dati per gli utenti**. [Dati e metadati](/docs/architect/it-it/fundamentals/guide/architecture-basics#metadati-e-dati) sono entità distinte in Salesforce, che richiedono controlli di accesso separati per ciascuna entità. Utilizzare OWD e strumenti di condivisione integrati per configurare l'accesso ai dati Salesforce (singoli record, file e documenti). Per ulteriori dettagli, vedere [Sicurezza dei dati](/docs/architect/it-it/well-architected/guide/secure#sicurezza-dei-dati).
- **Utilizzare gli ambiti OAuth per controllare l'accesso per le applicazioni connesse**. Quando si configura un'applicazione connessa, si definisce l'[ambito](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) o le autorizzazioni di accesso degli utenti dell'applicazione alle risorse Salesforce. Per ulteriori informazioni sulla gestione dei token OAuth, vedere [Gestione delle sessioni](/docs/architect/it-it/well-architected/guide/secure#gestione-sessioni).
- **Creare un utente Salesforce per ogni integrazione**. Per rispettare il principio dei privilegi minimi, creare un [utente integrazione](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm) Salesforce univoco per ogni integrazione. Ciò consente di assegnare un accesso specifico ai dati, migliorando il controllo sulle operazioni, garantendo la tracciabilità delle transazioni e riducendo al minimo l'impatto di potenziali violazioni della sicurezza.
- **Implementare account univoci con PoLP per tutti gli utenti Agente**. Ogni utente Agentforce Agent deve essere univoco e non riutilizzato in più agenti. Le autorizzazioni per questi account devono rispettare rigorosamente il principio dei privilegi minimi. Tenere presente che le azioni eseguite da un utente agente possono operare in un contesto di sicurezza elevata all'interno di Salesforce o contro sistemi esterni che non rispettano i controlli di accesso di Salesforce. Ciò potrebbe portare ad azioni che accedono o rivelano informazioni sensibili agli utenti.
- **Ridurre al minimo l'uso dei profili e migrare eventuali controlli di accesso dai profili**. I profili consentono di limitare l'accesso agli [intervalli IP di](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5) accesso, agli [orari di accesso](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) e alle funzioni specifiche dell'interfaccia utente Salesforce Classic legacy (in particolare i tipi di record predefiniti e le assegnazioni dei layout di pagina). Tutte le altre funzionalità attualmente presenti nei profili devono essere migrate a funzionalità equivalenti negli [insiemi di autorizzazioni e](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm) nei gruppi di insiemi di autorizzazioni. Le funzionalità dei profili collegate alle funzioni dell'interfaccia utente di Salesforce Classic devono essere oggetto di correzione.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/secure#schemi-di-sicurezza-organizzativi-e-anti-schemi) riportato di seguito mostra l'aspetto delle procedure di autorizzazione appropriate (e scadenti) in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di autorizzazione disponibili in Salesforce, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/secure#strumenti-rilevanti-per-la-sicurezza) la sicurezza.

### Schemi di sicurezza organizzativi e anti-schemi

Questa tabella mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la correzione.

✨ Scopri altri schemi per la sicurezza organizzativa in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-organizational-security).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Autenticazione</b></td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - I profili di sicurezza approvati sono chiaramente definiti ed elencati
            <br> - La mappatura tra i profili di sicurezza e gli schemi di autenticazione consentiti (interfaccia utente, API) esiste in una matrice di sicurezza</td>
            <td><b>Se esistono standard di progettazione e documentazione, essi:</b>
            <br> - Non includere profili di sicurezza
            <br> - Non includere una matrice di sicurezza con mappature chiare per i profili di sicurezza e gli schemi di autenticazione consentiti</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le configurazioni di accesso sono allineate al <a href="https://security.salesforce.com/mfa-requirement-check">Controllo MFA Salesforce</a>
            <br> - La relazione tra utenti ed entità che accedono a Salesforce è 1:1 (nessun utente condiviso)
            <br> - <a href="https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_api_access_control_about.htm">Controllo accesso API</a> impedisce agli utenti di eseguire l'autenticazione tramite un'applicazione connessa non autorizzata
            <br> - Se SSO è abilitato, gli utenti amministratori approvati hanno accesso diretto</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le configurazioni di accesso non sono allineate al <a href="https://security.salesforce.com/mfa-requirement-check">Controllo MFA Salesforce</a>
            <br> - La relazione tra utenti ed entità che accedono a Salesforce non è 1:1 (ci sono account utente condivisi)
            <br> - Se gli utenti accedono a Salesforce da dietro un firewall, il firewall utilizza indirizzi IP codificati per proteggere le comunicazioni da/verso Salesforce
            <br> - <a href="https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_api_access_control_about.htm">Controllo accessi API</a> non abilitato
            <br> - Se SSO è abilitato, nessun utente amministratore approvato ha accesso diretto</td>
        </tr>
        <tr>
            <td><b>In LWC, Apex, Aura:</b>
            <br> - I metodi che eseguono l'autenticazione utilizzano le credenziali denominate per gestire i flussi nome utente/password
            <br> - Nessun nome utente o password viene visualizzato nel codice in formati leggibili (nessun valore codificato o stringhe)
            <br> - Se esistono flussi di accesso personalizzati, tutto il codice personalizzato correlato utilizza metodi <code>SessionManagement</code> appropriati</td>
            <td><b>In LWC, Apex, Aura:</b>
            <br> - L'autenticazione viene gestita ad hoc
            <br> - Nomi utente e password vengono visualizzati nel codice</td>
        </tr>
        <tr>
            <td rowspan="4"><b>Autorizzazione</b></td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - Ogni utente e sistema con accesso a Salesforce mappa a uno o più profili in una matrice di sicurezza
            <br> - La matrice di protezione elenca chiaramente le autorizzazioni per i metadati e i profili utente assegnati
            <br> - I casi d'uso per la concessione di privilegi elevati sono chiaramente elencati, tra cui:
            <br> -- Autorizzazioni Modifica tutti i dati
            <br> -- Autorizzazioni Visualizza tutti i dati </td>
            <td><b>Se esistono standard di progettazione e documentazione, essi:</b>
            <br> - Non includere una matrice di sicurezza
            <br> - Non elencare chiaramente le autorizzazioni
            <br> - Non elencare chiaramente i casi d'uso per la concessione di privilegi elevati</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni vengono utilizzati per controllare l'accesso ai metadati
            <br> - Gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni sono allineati alle funzionalità aziendali
            <br> - Le autorizzazioni assegnate agli utenti seguono le definizioni della matrice di sicurezza
            <br> - I profili vengono utilizzati in modo minimo e solo per controllare gli intervalli IP di accesso e gli orari di accesso
            <br> - Per ogni integrazione viene configurato un utente integrazione solo API univoco</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - I gruppi di insiemi di autorizzazioni non sono configurati per consentire l'accesso in base alle funzionalità aziendali
            <br> - Gli insiemi di autorizzazioni sono configurati ad hoc
            <br> - Gli insiemi di autorizzazioni sono ridondanti o sono fortemente duplicati; è difficile comprendere una chiara logica funzionale e le differenze tra gli insiemi
            <br> - Le autorizzazioni assegnate agli utenti non seguono le definizioni della matrice di protezione
            <br> - I profili contengono controlli di accesso per i metadati
            <br> - Gli utenti solo API non sono configurati o sono condivisi in più di un'integrazione</td>
        </tr>
        <tr>
            <td><b>In Apex:</b>
            <br> - Le operazioni di database eseguono controlli appropriati dell'accesso a livello di campo e di oggetto, tra cui:
            <br> -- Le istruzioni DML e Database DML dichiarano la <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_enforce_usermode.htm">modalità utente o sistema</a> per le operazioni sui dati E/O
            <br> -- Le istruzioni DML e Database DML utilizzano i metodi <code>stripInaccessible</code> prima delle operazioni sui dati
            <br> -- Le istruzioni SOQL e SOSL utilizzano le parole chiave <code> WITH USER_MODE</code> e <code>WITH SYSTEM_MODE</code> AND/OR
            <br> -- i metodi <code>stripInaccessible</code> vengono utilizzati per filtrare i risultati delle query e delle sottoquery
            <br> -- i metodi sObject describe result (ad esempio <code>isAccessible</code>, <code>isCreateable</code>, <code>isUpdateable</code> e/o <code>isDeletable</code>) sono usati con parsimonia</td>
            <td><b>In Apex:</b>
            <br> - DML, metodi Classe di database, SOQL e SOSL eseguiti in modalità di sistema predefinita
            <br> - Le operazioni del database non eseguono controlli di accesso appropriati, tra cui:
            <br> -- I metodi DML o Classe di database utilizzano esclusivamente controlli <code>isAccessible</code>, <code>isCreateable</code>, <code>isUpdateable</code> e/o <code>isDeletable</code> per l'accesso sObject e a livello di campo
            <br> -- Le query SOQL utilizzano esclusivamente parole chiave <code> WITH SECURITY_ENFORCED</code> per le restrizioni di accesso</td>
        </tr>
        <tr>
            <td><b>Nei flussi</b> <a href="https://developer.salesforce.com/docs/atlas.en-us.secure_coding_guide.meta/secure_coding_guide/secure_coding_considerations_flow_design.htm">(considerazioni sulla sicurezza per la progettazione dei flussi)</a><b>:</b>
            <br> - I flussi utilizzano il contesto di esecuzione più restrittivo possibile, idealmente Modalità utente
            <br> - L'accesso ai dati sensibili o con privilegi di sicurezza viene eseguito dai sottoflussi per ridurre al minimo il contesto di esecuzione
            <br> - Limita la logica eseguita nei flussi attivati da record
            <br> - Gli input del flusso vengono convalidati per garantire che vengano passati come input solo i payload consentiti</td>
            <td><b>Nei flussi:</b>
            <br> - I flussi vengono eseguiti in modalità di sistema o in modalità di sistema senza condivisione, indipendentemente dalle azioni eseguite dal flusso
            <br> - Tutta la logica del flusso viene eseguita all'interno di un unico flusso di grandi dimensioni
            <br> - Gli input del flusso non vengono convalidati e vengono passati ai consumatori senza verifica</td>
        </tr>
    </tbody>
</table>

## Sicurezza della sessione

Una sessione è la serie di richieste e risposte associate a un utente in un periodo di tempo. Una sessione viene avviata quando un utente esegue correttamente l'autenticazione in Salesforce. La [sicurezza della sessione](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm) è la procedura di configurazione del sistema per impedire l'accesso non autorizzato e le violazioni dei dati ostacolando le interferenze o gli attacchi hijack della sessione.

Tutte le attività degli utenti nel sistema avvengono nel contesto di una sessione, quindi è fondamentale tenere conto di come vengono avviate le sessioni, di cosa può avvenire durante una sessione, dei dispositivi che gli utenti utilizzeranno (e dovrebbero) e di come rilevare e rispondere ai comportamenti sospetti o anomali della sessione.

È possibile creare la sicurezza delle sessioni in Salesforce concentrandosi su tre chiavi: gestione delle sessioni, accesso ai dispositivi e rilevamento e risposta alle minacce.

### Gestione sessioni

Le sessioni vengono avviate quando un utente esegue correttamente l'autenticazione e ottiene l'accesso a Salesforce. Queste sessioni consentono alla piattaforma di associare richieste e risposte specifiche a quel determinato utente.

Il protocollo HTTPS facilita la comunicazione tra un client front-end e Salesforce Platform. I client possono includere browser, applicazioni mobili, applicazioni locali e così via. HTTPS è un protocollo stateless, ovvero ogni comunicazione è discreta e non correlata a comunicazioni precedenti o future.

Questo approccio stateless accelera le comunicazioni di rete ed elimina gli errori causati dall'interruzione dei link tra i pacchetti. Tuttavia, le app Web necessitano ancora di un modo per tenere traccia dell'identità di ogni utente e di altre informazioni correlate in più interazioni di richiesta e risposta. Salesforce, come la maggior parte delle applicazioni Web, esegue questa operazione utilizzando sessioni e [token](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5).

- Le **sessioni** consentono a Salesforce di associare richieste e risposte agli utenti. Dopo che un utente è stato autenticato, la piattaforma invia di nuovo un ID sessione all'app client, che include questo ID con tutte le richieste dell'utente (ad esempio navigazione, ricerca e invio di dati).
- I **token** consentono agli utenti e alle applicazioni connesse di verificare la propria identità una sola volta e di utilizzare un token di accesso univoco da quel momento in poi. I token hanno una durata limitata e forniscono l'accesso solo a risorse specifiche (vedere [Autorizzazione](/docs/architect/it-it/well-architected/guide/secure#autorizzazione) per ulteriori informazioni sulla configurazione dei livelli di accesso). I token consentono l'accesso alle risorse autorizzate senza richiedere agli utenti di eseguire l'accesso.

Se le sessioni e i token non sono protetti correttamente, i malintenzionati possono potenzialmente interferire con loro e impersonare gli utenti o eseguire codice dannoso nel sistema.

Per creare una gestione sicura delle sessioni per Salesforce:

- **Informazioni su come Salesforce classifica i tipi di sessione**. Identificare e mappare i [tipi di sessione](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5) approvati ai profili utente di sicurezza e registrarli nella documentazione.
- **Controllare come possono avere origine le sessioni e dove può andare il traffico della sessione**. Dopo aver identificato i tipi di sessioni che i vari profili utente possono avviare, configurare i controlli per bloccare le sessioni originate da fonti o contesti non approvati. Salesforce offre diversi modi per controllare le origini delle sessioni e il traffico, tra cui:
  - **Protezione sessione incorporata**. Salesforce abilita automaticamente le protezioni a livello di organizzazione per le attività dannose basate su sessioni, tra cui cross-site scripting, contraffazione di richieste tra siti, [sniffing di contenuti](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing), [clickjacking](https://owasp.org/www-community/attacks/Clickjacking) e altro ancora. Queste protezioni non devono mai essere disabilitate; alcune non possono essere disabilitate.
  - **Domini e intervalli IP**. Per impostazione predefinita, in tutte le organizzazioni Salesforce è abilitato [Dominio personale](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5), il che crea un sottodominio specifico dell'azienda per l'accesso a Salesforce. È possibile personalizzare o modificare il nome associato a un'organizzazione tramite Dominio personale. Inoltre, Salesforce supporta [configurazioni di dominio](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5) aggiuntive per i siti Experience Cloud e altre pagine di applicazioni. Nota: Se gli utenti devono accedere a Salesforce da un firewall aziendale, aggiungere i [domini richiesti](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5) agli elenchi consentiti del firewall. È possibile impostare [intervalli IP di](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm) accesso e [intervalli IP affidabili](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm) per controllare l'accesso in entrata e le richieste di sessione a Salesforce.
  - **Orari di accesso**. Se alcuni profili utente hanno impostato orari di lavoro, è possibile limitare la loro possibilità di accedere a Salesforce al di fuori degli [orari di accesso](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) definiti.
- **Controllare le attività che richiedono una maggiore protezione a livello di sessione**. Per impostazione predefinita, le sessioni possono avere due tipi di [livelli di sicurezza](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5): standard e high assurance. Utilizzare questi livelli di sicurezza per controllare in che modo gli utenti possono e non possono svolgere attività come accedere a rapporti e cruscotti digitali o gestire le configurazioni di sicurezza in un'organizzazione Salesforce. Le policy di protezione a livello di sessione possono richiedere agli utenti di stabilire [sessioni High Assurance](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5) per eseguire operazioni o impedire agli utenti di eseguire operazioni sensibili.
- **Controllare le attività che richiedono autorizzazioni aggiuntive basate su sessioni**. Salesforce supporta le attivazioni delle [autorizzazioni basate su sessioni](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5) per consentire temporaneamente agli utenti un'autorizzazione o un accesso elevati alle autorizzazioni durante una determinata sessione. Le autorizzazioni basate su sessioni si possono attivare e disattivare tramite le API Flusso o Salesforce.
- **Gestire le sessioni utente inattive durante i timeout**. La fine delle sessioni inattive è una parte fondamentale della gestione della sicurezza delle sessioni. Ciò consente di proteggere il sistema quando, ad esempio, un utente lascia aperta una sessione Salesforce in una scheda del browser ma sta lavorando attivamente in un'altra applicazione, oppure quando il dispositivo mobile di un utente è connesso a Salesforce ma non è sorvegliato. Salesforce ha un timeout di inattività sessione predefinito di due ore. È possibile aumentare o ridurre i livelli di timeout di inattività della sessione, ma l'aumento dei timeout deve essere eseguito solo con una giustificazione convincente e ben documentata.
- **Gestire le sessioni dell'applicazione connessa tramite la configurazione del token.** Quando si configura un'applicazione connessa, si definisce anche l'ambito, o il livello di autorizzazione, che verrà concesso agli utenti che accedono a Salesforce tramite l'applicazione connessa. Questo ambito viene applicato a livello di sessione tramite i [token OAuth](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US), che vengono emessi dopo che un utente di un'applicazione connessa esegue correttamente l'autenticazione. È possibile controllare la durata di un token tramite le [politiche di aggiornamento](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US). Se necessario, gli amministratori dell'organizzazione possono revocare manualmente i token per utente e per organizzazione.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/secure#schemi-di-sicurezza-della-sessione-e-anti-schemi) riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione delle sessioni in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di gestione delle sessioni disponibili in Salesforce, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/secure#strumenti-rilevanti-per-la-sicurezza) la sicurezza.

### Accesso dispositivo

Nel contesto attuale, un _dispositivo_ è qualsiasi apparecchiatura elettronica che un individuo utilizzerà per accedere a Salesforce, ad esempio una workstation desktop, un laptop, un tablet o un telefono cellulare.

I dispositivi portatili offrono agli utenti la flessibilità di accedere a Salesforce da qualsiasi posizione. Tuttavia, questa comodità potenzialmente introduce ulteriori vettori di attacco per gli attori malintenzionati. Questi vettori di minacce vanno da semplici tattiche, come la navigazione a spalla in un luogo pubblico per rubare le credenziali, a metodi più sofisticati come l'installazione di malware su un dispositivo o la creazione di una rete Wi-Fi pubblica fasulla per intercettare le trasmissioni di dati. Per questo motivo, proteggere i dispositivi, in particolare i dispositivi portatili, è essenziale per la sicurezza generale del sistema.

Per proteggere l'accesso ai dispositivi per Salesforce:

- **Utilizzare le soluzioni dell'app mobile fornite da Salesforce**. Chiedere agli utenti dei dispositivi mobili che devono accedere a Salesforce di utilizzare le [app Salesforce](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5) ufficiali. Se le esigenze aziendali richiedono una soluzione mobile personalizzata, è necessario utilizzare [Salesforce Mobile SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm), che fornisce metodi per l'autenticazione e l'autorizzazione sicure.
- **Progettare l'utilizzo dei dispositivi mobili nella gestione delle sessioni**. I livelli di sicurezza delle sessioni, i timeout delle sessioni e altri controlli del contesto della sessione devono tenere conto di qualsiasi accesso previsto da parte degli utenti sui dispositivi mobili. Considerare quali dispositivi devono e non devono essere autorizzati ad accedere a Salesforce e quali tipi di utenti devono avere accesso alle sessioni mobili. Includere gli standard di accesso mobile nella documentazione del profilo di sicurezza. Per ulteriori informazioni su questo argomento, vedere [Gestione delle sessioni](/docs/architect/it-it/well-architected/guide/secure#gestione-sessioni).
- **Integrazione della protezione a livello di dispositivo con la tecnologia MDM (Mobile Device Management).** Le app Salesforce per iOS e Android sono [compatibili con molte suite MDM](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5). È possibile configurare ulteriori controlli di accesso per l'app Salesforce sui dispositivi degli utenti tramite la soluzione MDM preferita.
- **Integrare la protezione a livello di app con la tecnologia MAM (Mobile Application Management)**. La tecnologia MAM supporta i controlli a livello di app sui dispositivi mobili. Salesforce offre un [componente aggiuntivo MAM](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5) a pagamento per le app mobili Salesforce.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/secure#schemi-di-sicurezza-della-sessione-e-anti-schemi) riportato di seguito mostra l'aspetto di una corretta (e scarsa) gestione dei dispositivi in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di gestione dei dispositivi disponibili in Salesforce, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/secure#strumenti-rilevanti-per-la-sicurezza) la sicurezza.

### Rilevamento e risposta alle minacce

Il rilevamento delle minacce è il processo di identificazione degli schemi di comportamento nel sistema che possono indicare attività dannose. Ciò può includere volumi di dati scaricati superiori alla media o la modifica da parte di un utente di campi contenenti dati sensibili su più record in un periodo di tempo inferiore alla media. Le risposte alle minacce possono includere la scadenza automatica delle sessioni, avvisi e altre notifiche.

L'obiettivo del rilevamento delle minacce è identificare e rispondere ai potenziali problemi il più rapidamente possibile. L'esecuzione di azioni basate sul rilevamento delle minacce in tempo reale può arrestare i comportamenti dannosi. Salesforce offre il [monitoraggio evento in tempo reale](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5) come componente aggiuntivo o come parte di [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). Utilizzare una di queste soluzioni se si dispone di applicazioni estremamente sensibili o se sono necessarie solide funzionalità di rilevamento delle minacce e risposta in tempo reale.

Per creare una strategia efficace di rilevamento e risposta alle minacce per le soluzioni Salesforce:

- **Utilizzare funzionalità di controllo** incorporate. Salesforce offre una varietà di [strumenti integrati](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5) per monitorare e controllare le modifiche apportate all'organizzazione. Ad esempio, l'[itinerario di controllo](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5) consente di visualizzare la cronologia di controllo delle azioni amministrative. Salesforce tiene traccia delle modifiche a livello di campo per un periodo di tempo limitato per impostazione predefinita, ma è possibile attivare il [Tracciamento cronologia campi](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5) per visualizzare le modifiche dei campi per un massimo di 18 mesi nell'interfaccia utente e fino a 24 mesi tramite l'API. Inoltre, è possibile attivare l'[itinerario di controllo](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5) per conservare una cronologia di controllo per le modifiche a livello di campo a tempo indeterminato (fino a quando non si eliminano manualmente i dati).
- **Stabilire revisioni periodiche**. Il controllo è fondamentale per identificare le modifiche anomale che il rilevamento delle minacce in tempo reale potrebbe non rilevare. Si supponga uno scenario in cui un utente con accesso legittimo elimina costantemente un numero limitato di record al giorno per un periodo prolungato. Poiché questo utente dispone di credenziali di accesso valide, dell'autorizzazione appropriata per eliminare i record e non elimina un volume elevato di record contemporaneamente, è improbabile che l'attività venga rilevata come una minaccia in tempo reale. Tuttavia, un team di audit che esamina i rapporti sulle attività degli utenti identificherebbe chiaramente questa tendenza all'eliminazione eccessiva dei record da parte di un singolo utente nel tempo, rendendo più semplice la gestione. Nell'ambito delle [politiche di governance](/docs/architect/it-it/well-architected/guide/intentional#governance), stabilire intervalli regolari per il controllo della cronologia accessi, dell'attività delle sessioni utente e dell'utilizzo delle applicazioni connesse.
- **Sviluppare una strategia di risposta alle minacce e includerla nelle policy di sicurezza.** Creare una strategia di risposta alle minacce che copra:
  - Definizioni dei tipi di risposta alle minacce (ad esempio, avvisi e automazioni) ed eventuali [gruppi di](/docs/architect/it-it/well-architected/guide/resilient#risposta-incidente) stakeholder. Per ulteriori informazioni sulla progettazione di messaggi o avvisi, vedere [Errori e notifiche](/docs/architect/it-it/well-architected/guide/engaging#notifiche-e-messaggi).
  - Categorie specifiche per le modifiche in tempo reale o le attività che potrebbero essere considerate minacce e il tipo di risposta associato per ciascuna
  - Elenco chiaro di tutte le risposte alle minacce automatiche (ad esempio revoca dei token, chiusura delle sessioni, disattivazione degli account utente o blocco dell'accesso alle risorse) e dei trigger di automazione

Monitoraggio evento fornisce i dati necessari per applicare questo principio abilitando il rilevamento e la risposta alle minacce in tempo reale. La sicurezza delle transazioni applica le azioni della società basate sulle policy e i tipi di evento supportano il monitoraggio dell'accesso di utenti e applicazioni nel tempo.

Il servizio di rilevamento delle minacce nativo di Salesforce utilizza modelli statistici e di machine learning per identificare comportamenti sospetti. Questo servizio genera eventi specifici che proteggono dagli attacchi informatici e dall'accesso ai dati sospetto.

La sicurezza delle transazioni migliora ulteriormente la sicurezza poiché offre un framework che intercetta gli eventi chiave che si verificano nell'organizzazione e applica le azioni della società basate sulle policy. Questo trasforma Monitoraggio evento da strumento di registrazione a componente importante di una difesa della sicurezza automatica.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/secure#schemi-di-sicurezza-della-sessione-e-anti-schemi) riportato di seguito mostra l'aspetto corretto (e scarso) del rilevamento e della risposta alle minacce in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di rilevamento delle minacce, di avviso e di automazione della risposta disponibili in Salesforce, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/secure#strumenti-rilevanti-per-la-sicurezza) la sicurezza.

### Schemi di sicurezza della sessione e anti-schemi

Questa tabella mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la correzione.

✨ Scopri altri schemi per la sicurezza delle sessioni in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-session-security).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Gestione sessioni</b></td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - I profili di sicurezza elencano chiaramente i tipi di sessione approvati e le impostazioni di timeout/durata per ogni profilo
            <br> - Gli orari di accesso sono stati specificati (o identificati come non necessari)
            <br> - Le operazioni che richiedono protezione o autorizzazioni a livello di sessione elevato sono chiare e individuabili
            <br> - L'ambito dell'applicazione connessa e le policy di gestione dei token sono chiare e individuabili</td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - I profili di sicurezza non esistono o mancano di informazioni sui tipi di sessione e sulle impostazioni di timeout/durata
            <br> - Le policy di sicurezza non contengono informazioni sugli ambiti delle applicazioni connesse o sulla gestione dei token</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - I controlli delle sessioni mostrano che gli utenti accedono a Salesforce solo tramite i tipi di sessione previsti
            <br> - Esiste un insieme di autorizzazioni chiaro e attivo per l'accesso "Utente solo API" (con l'insieme di autorizzazioni "Solo API" su TRUE) e tutti gli utenti integrazione e automatici vengono assegnati
            <br> - Se gli utenti accedono a Salesforce da dietro un firewall, il firewall utilizza un elenco consentiti di domini obbligatori anziché indirizzi IP per proteggere le comunicazioni da/verso Salesforce
            <br> - Gli intervalli di timeout della sessione inattivi non superano il valore predefinito (2 ore)
            <br> - Sono abilitate tutte le seguenti impostazioni:
            <br> -- Protezione dal clickjack per le pagine di impostazione
            <br> -- Protezione dal clickjack per le pagine Salesforce non impostate
            <br> -- Protezione dal Cross-Site Request Forgery (CSRF)
            <br> -- Protezione dal cross-site scripting (XSS)
            <br> -- Abilitare la protezione dallo sniffing dei contenuti
            <br> -- Protezione URL referrer
            <br> Avvisa gli utenti prima che vengano reindirizzati all'esterno di Salesforce</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Non esiste un controllo regolare delle sessioni
            <br> - Non ci sono definizioni dei tipi di sessione che gli utenti devono avere
            <br> - Le autorizzazioni "Solo API" non sono chiare o mancano dagli utenti integrazione e automatici
            <br> - Se gli utenti accedono a Salesforce da dietro un firewall, il firewall utilizza indirizzi IP codificati per proteggere le comunicazioni da/verso Salesforce
            <br> - Gli intervalli di timeout della sessione inattivi superano il valore predefinito (2 ore)
            <br> - Una delle seguenti impostazioni è disabilitata:
            <br> -- Protezione dal clickjack per le pagine di impostazione
            <br> -- Protezione dal clickjack per le pagine Salesforce non impostate
            <br> -- Protezione dal Cross-Site Request Forgery (CSRF)
            <br> -- Protezione dal cross-site scripting (XSS)
            <br> -- Abilitare la protezione dallo sniffing dei contenuti
            <br> -- Protezione URL referrer
            <br> Avvisa gli utenti prima che vengano reindirizzati all'esterno di Salesforce</td>
        </tr>
        <tr>
            <td><b>In LWC, Apex, Aura:</b>
            <br> - Se esistono flussi di accesso personalizzati, tutto il codice personalizzato correlato utilizza metodi <code>SessionManagement</code> appropriati per assegnare la protezione a livello di sessione</td>
            <td><b>In LWC, Apex, Aura:</b>
            <br> - Se esistono flussi di accesso personalizzati, non esiste una logica per assegnare la protezione a livello di sessione</td>
        </tr>
        <tr>
            <td rowspan="2"><b>Accesso dispositivo</b></td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - Le policy sui dispositivi sono chiare e individuabili
            <br> - I profili di sicurezza sono chiaramente mappati agli utilizzi e alle policy appropriati dei dispositivi</td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> Le policy di sicurezza non esistono o non contengono informazioni sull'accesso ai dispositivi</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - La configurazione dell'applicazione connessa mobile Salesforce richiede lo sblocco di PIN/codice di accesso dopo l'inattività
            <br> - Se le esigenze aziendali richiedono un controllo rigoroso degli utenti che possono accedere a Salesforce Mobile, il controllo dell'accesso API è abilitato e gli insiemi di autorizzazioni vengono assegnati a tutti gli utenti delle app mobili Salesforce</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - L'applicazione connessa mobile Salesforce non è configurata per richiedere lo sblocco di PIN/codice di accesso per l'inattività
            <br> – Le esigenze aziendali richiedono un rigoroso controllo degli utenti che possono accedere a Salesforce Mobile, ma il controllo dell'accesso API non è abilitato o non vengono utilizzati insiemi di autorizzazioni per controllare l'accesso alle app mobili Salesforce</td>
        </tr>
        <tr>
            <td rowspan="3"><b>Rilevamento e risposta alle minacce</b></td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - Le policy di sicurezza contengono un elenco di eventi che dovrebbero attivare una risposta insieme al tipo di risposta appropriato
            <br> - I livelli di controllo sono stati specificati per tutti gli oggetti del modello di dati<br> - I passaggi per rivedere i registri disponibili in Salesforce sono documentati
            <br> - Tutte le risposte automatiche sono documentate chiaramente</td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - Le policy di sicurezza non esistono o non includono informazioni sul rilevamento e l'avviso delle minacce
            <br> - La documentazione per le risposte automatiche non esiste o non è chiara</td>
        </tr>
        <tr>
            <td><b>All'interno dell'azienda:</b>
            <br> - I dati di controllo sono disponibili nei rapporti che gli stakeholder aziendali possono comprendere e consultare
            <br> - Esami periodici della cronologia e dei rapporti di controllo</td>
            <td><b>All'interno dell'azienda:</b>
            <br> - I dati di controllo sono disponibili solo tramite file di registro che richiedono competenze in materia per l'accesso e l'interpretazione
            <br> - Non esistono processi per esaminare le informazioni di controllo</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Sono attive automazioni per rispondere alle minacce disattivando gli account utente o bloccando l'accesso alle risorse in tempo reale se viene rilevato un utilizzo anomalo
            <br> - Notifiche e avvisi sono configurati per informare gli utenti appropriati in caso di attività anomala
            <br> - Il tracciamento della cronologia dei campi è abilitato per tutti i campi contenenti dati privati o sensibili</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Non sono presenti automazioni per rispondere alle minacce
            <br> - Le notifiche e gli avvisi non sono configurati per informare gli utenti appropriati in caso di attività anomala, oppure esistono alcune notifiche e avvisi correlati all'attività anomala, ma sono ad hoc
            <br> - Il tracciamento della cronologia dei campi non è abilitato in modo coerente per i campi contenenti dati privati o sensibili</td>
        </tr>
    </tbody>
</table>

## Sicurezza dei dati

La sicurezza dei dati è la procedura di protezione dei dati da accesso non autorizzato, corruzione o eliminazione involontaria. La sicurezza dei dati consiste nella protezione dei dati sia in transito che a riposo.

Una forte sicurezza dei dati riduce al minimo i rischi e i potenziali danni derivanti dall'accesso non autorizzato al sistema. Una sicurezza dei dati inadeguata rende i sistemi vulnerabili alle violazioni dei dati, che possono avere un impatto grave sui clienti e sulla società. Pertanto, proteggere i dati è fondamentale per creare architetture sicure.

Il miglioramento della sicurezza dei dati inizia con una chiara comprensione di ciò che sono considerati dati in Salesforce, insieme alla loro classificazione. I singoli record, file e documenti archiviati in un'organizzazione Salesforce sono i relativi dati. Per ulteriori informazioni sulla distinzione tra metadati e dati, vedere [Nozioni di base](/docs/architect/it-it/fundamentals/guide/architecture-basics#metadati-e-dati) sull'architettura Salesforce.

È possibile rafforzare la sicurezza dei dati nelle soluzioni Salesforce concentrandosi sulla condivisione e la visibilità nonché sull'uso della crittografia.

> Nota: Quando si progetta per la sicurezza dei dati, assicurarsi di tenere conto della [privacy dei dati](/docs/architect/it-it/well-architected/guide/compliant#privacy-dei-dati), nonché dell'[archiviazione e della](/docs/architect/it-it/well-architected/guide/resilient#pianificazione-della-continuità) rimozione, poiché entrambi questi concetti influiscono sulla sicurezza dei dati complessiva delle soluzioni.

### Classificazione dei dati

Identificare e classificare tutti i dati memorizzati nella piattaforma Salesforce in base alla loro riservatezza (ad esempio, pubblica, interna, riservata, limitata). Definire una **politica di classificazione** chiara che descriva come gestire e proteggere ogni tipo di dati. Implementare controlli di sicurezza appropriati, ad esempio protezione a livello di campo, crittografia e mascheramento dei dati, per applicare la policy e proteggere i dati sensibili da accessi o esposizioni non autorizzate. Esaminare e controllare regolarmente queste classificazioni e questi controlli per assicurarsi che rimangano in linea con i requisiti aziendali e di conformità.

### Condivisione e visibilità

La condivisione e la visibilità includono la configurazione del sistema per controllare il modo in cui gli utenti accedono ai dati all'interno di Salesforce. È importante notare che la condivisione e la visibilità controllano i singoli record a cui un utente può accedere, ma queste impostazioni da sole non controllano in ultima analisi cosa può fare un utente con un determinato record o quali campi specifici all'interno di quel record sono visibili. Le autorizzazioni per eseguire operazioni sui dati (ad esempio [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm)) vengono assegnate agli utenti tramite controlli di accesso ai metadati, che possono essere configurati per un utente a livello di singolo oggetto e campo. Per ulteriori informazioni, vedere [Autorizzazione](/docs/architect/it-it/well-architected/guide/secure#autorizzazione).

Le azioni Agentforce possono esporre i dati sia agli utenti autenticati che a quelli anonimi che in genere non dispongono di accesso diretto. Durante la creazione degli agenti Agentforce, considerare attentamente e documentare tutte le azioni assegnate all'agente. Per ogni azione è necessario comprendere:

- A quali dati possono accedere le azioni.
- Contesto di sicurezza in cui vengono eseguite le azioni.
- Indica se le azioni dispongono del recupero Knowledge o di altre funzionalità che possono incorporare dati sensibili o limitati nella sessione dell'agente.

Per configurare condivisione e visibilità efficaci in Salesforce:

- **Progettare l'accesso in base a funzioni lavorative significative**. Creare una matrice di protezione che mappa i [profili utente](/docs/architect/it-it/well-architected/guide/secure#autenticazione) alle funzioni aziendali che devono svolgere. Utilizzare questo [modello](/docs/architect/it-it/resources/guide/security-policy-template) come base per progettare la condivisione e la visibilità. Per ulteriori informazioni sull'identificazione di funzioni aziendali significative, vedere [Unità funzionali](/docs/architect/it-it/well-architected/guide/composable#unità-funzionali).
- **Scegliere il percorso più semplice per applicare il principio dei minimi privilegi**. Quando si applica il [principio dei minimi privilegi](/docs/architect/it-it/well-architected/guide/secure#autorizzazione) nella progettazione di schemi di condivisione e visibilità, farlo nel modo più semplice. Evitare restrizioni dei dati e schemi di condivisione eccessivamente ingegnerizzati, che possono causare problemi a valle per la manutenibilità, la scalabilità e l'adattabilità del sistema. Sfruttare invece la [condivisione dati flessibile](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf) per configurare regole precise per l'accesso degli utenti a livello di dati.
- **Impostare le impostazioni predefinite _interne_ dell'organizzazione su Sola lettura pubblica, a meno che l'azienda non tratti dati sensibili, quindi utilizzare Privato**. Gli OWD controllano il livello di privilegi "minimi" che gli utenti avranno a livello di dati. Non è possibile limitare l'accesso al di sotto del livello di OWD. Benché gli OWD privati possano sembrare ideali in ogni caso d'uso, gli utenti di tutta l'azienda spesso possono finire per replicare inavvertitamente un OWD più permissivo attraverso schemi di condivisione complessi. Inoltre, gli OWD privati possono causare la creazione di dati duplicati da parte degli utenti. Il completamento dei calcoli di condivisione (e dei ricalcoli) può richiedere una notevole quantità di tempo a seconda del volume di dati e della distorsione controllante-controllato o della proprietà. È importante notare che le OWD non controllano le autorizzazioni CRUD e la visibilità a livello di campo. Scegliere un OWD di Privato solo quando è giustificato dalle esigenze aziendali: il più delle volte, tali giustificazioni saranno correlate alla [conformità](/docs/architect/it-it/well-architected/guide/compliant).
- **Impostare le impostazioni predefinite _esterne_ dell'organizzazione su Privato, a meno che non si disponga di un valido motivo aziendale per consentire un accesso più ampio.** [Gli OWD esterni](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5) si applicano agli utenti che accedono ai dati Salesforce da siti Experience Cloud, portali e così via. Ciò consente di configurare basi di riferimento OWD separate per gli utenti interni ed esterni, per consentire diversi tipi di privilegi "minimi". Impostare sempre OWD per gli utenti esterni su Privato: le eccezioni per un livello più aperto devono essere chiaramente giustificate dalle esigenze aziendali.

L'elenco degli [schemi e antischemi](/docs/architect/it-it/well-architected/guide/secure#schemi-di-sicurezza-dei-dati-e-schemi-anti-schemi) riportato di seguito mostra l'aspetto corretto (e scarso) della condivisione e della visibilità in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di condivisione e visibilità di Salesforce, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/secure#strumenti-rilevanti-per-la-sicurezza) la sicurezza.

### Uso della crittografia

La crittografia converte i dati leggibili in un formato codificato indecifrabile. I dati crittografati possono essere decrittografati o riportati al formato originale tramite una chiave. Di conseguenza, la crittografia è uno dei metodi più efficaci per proteggere i dati sia a riposo che in transito, assicurando che anche se parti non autorizzate accedono ai dati, saranno illeggibili.

Per progettare un uso corretto della crittografia nelle soluzioni Salesforce:

- **Crittografia sempre adeguata dei dati in transito**. Salesforce [impiega Transport Layer Security (TLS)](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5) per tutte le sessioni che si svolgono in un [browser supportato da Salesforce](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5) e richiede che le chiamate in uscita che utilizzano HTTPS soddisfino standard di sicurezza specifici. Le API piattaforma utilizzano anche HTTPS per impostazione predefinita. Inoltre, i dati inviati tra un sito Experience Cloud Salesforce o un portale e la relativa organizzazione Salesforce vengono crittografati in transito [per impostazione predefinita](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5). Se si utilizzano i [servizi email integrati](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5) di Salesforce, esistono livelli predefiniti per la sicurezza degli strati di trasporto (TLS) utilizzata da Salesforce per [inviare e tentare](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5) la consegna. È necessario, come minimo, assicurarsi che le impostazioni dell'organizzazione non siano inferiori a quelle predefinite, a meno che non si disponga di una chiara giustificazione aziendale. In base alla classificazione e alla riservatezza dei dati, valutare la possibilità di utilizzare una connessione di rete privata a Salesforce tramite AWS Direct Connect o Salesforce Private Connect. Ciò garantisce che i dati non attraversino Internet pubblico, ma fluiscano in modo sicuro su una connessione di rete privata sia per l'accesso degli utenti che per le integrazioni.
- **Se l'azienda lo richiede, crittografare i dati a riposo**. Salesforce offre diversi modi per crittografare i dati a riposo.
  - **Hyperforce**. I dati vengono crittografati a riposo nelle organizzazioni che utilizzano [Hyperforce](/docs/architect/it-it/fundamentals/guide/platform-multitenant-architecture#hyperforce). La crittografia è gestita per l'organizzazione da Salesforce. Non è possibile creare (o distruggere) le proprie chiavi di crittografia.
  - **Salesforce Shield**. [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) consente di crittografare i dati a riposo in un'organizzazione Salesforce a livelli aggiuntivi, inclusi i livelli applicazione e database. Con Shield si dispone di funzionalità di gestione complete per le chiavi di crittografia del tenant, incluse le potenti opzioni "Bring Your Own Key" (BYOK). È anche possibile crittografare dati non strutturati (inclusi file, allegati, indici di ricerca ed eventi). Le istanze basate su Hyperforce offrono l'opzione di utilizzare un gestore chiavi esterno, che consente di utilizzare il proprio KMS AWS. Con questa funzionalità si mantiene il controllo completo sulle chiavi di crittografia all'interno del KMS utilizzate per crittografare e decrittografare i dati archiviati in Salesforce, rafforzando la sicurezza e allineandosi ai requisiti di conformità dell'organizzazione.

L'elenco di [schemi e antischemi](/docs/architect/it-it/well-architected/guide/secure#schemi-di-sicurezza-dei-dati-e-schemi-anti-schemi) riportato di seguito mostra l'aspetto di un uso corretto (e errato) della crittografia in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di crittografia disponibili in Salesforce, vedere [Strumenti rilevanti per](/docs/architect/it-it/well-architected/guide/secure#strumenti-rilevanti-per-la-sicurezza) la sicurezza.

### Schemi di sicurezza dei dati e schemi anti-schemi

Questa tabella mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la correzione.

✨ Scopri altri schemi per la sicurezza dei dati in [Pattern & Anti-Pattern Explorer](/docs/architect/it-it/well-architected-tools/guide/trusted-data-security).

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">Schemi</th>
            <th scope="colgroup">Anti-schemi</th>
        </tr>
        <tr>
            <td rowspan="3"><b>Condivisione e visibilità</b></td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - Una matrice di sicurezza delinea i dati a cui ogni profilo utente è autorizzato ad accedere
            <br> - Vengono utilizzati diversi standard di accesso ai dati per gli utenti esterni e gli utenti interni, se applicabile
            </td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - Gli standard di progettazione e la documentazione non esistono o non contengono una matrice di sicurezza
            <br> - Se esiste una matrice di protezione, non delinea l'accesso ai dati per i profili utente
            </td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le impostazioni predefinite dell'organizzazione (OWD) per gli utenti interni sono Lettura pubblica, o le impostazioni OWD per gli utenti interni sono Privato, a causa dei requisiti di conformità
            <br> - OWD per gli utenti esterni è Privato
            <br> - L'intelligenza artificiale generativa funziona solo in modalità utente, oppure gli utilizzi selezionati per l'accesso al sistema hanno una chiara giustificazione aziendale</td></td>
            <td><b>Nella propria organizzazione:</b>
            <br> - OWD per gli utenti interni è impostato su Privato senza giustificazione aziendale o OWD per gli utenti interni è impostato su Lettura/Scrittura pubblica
            <br> - Gli OWD per gli utenti esterni sono impostati su qualsiasi cosa diversa da Privato senza giustificazione aziendale
            <br> - L'intelligenza artificiale generativa funziona in modalità di sistema senza giustificazione aziendale</td>
        </tr>
        <tr>
            <td><b>In Apex:</b>
            <br> - Tutto il codice che accede ai dati (SOQL/SOSL) o esegue operazioni sui dati (metodi DML/Classe di database) utilizza <code>con la condivisione</code> di parole chiave</td>
            <td><b>In Apex:</b>
            <br> - <code>con la condivisione</code> le parole chiave vengono utilizzate in modo incoerente</td>
        </tr>
        <tr>
        <tr>
            <td rowspan="3"><b>Utilizzo della crittografia</b></td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - I casi d'uso per la crittografia dei dati in transito e (se necessario) a riposo sono chiari e individuabili
            <br> - I protocolli di crittografia approvati sono chiaramente elencati
            <br> - La documentazione del codice indica chiaramente dove viene utilizzata la crittografia e quali protocolli vengono utilizzati</td>
            <td><b>Negli standard di progettazione e nella documentazione:</b>
            <br> - I protocolli di crittografia approvati non sono chiari o non sono elencati
            <br> - Il codice non è documentato o la documentazione non è chiara su dove e come viene utilizzata la crittografia nel codice</td>
        </tr>
        <tr>
            <td><b>Nella propria organizzazione:</b>
            <br> - Se vengono identificati rischi per la sicurezza che richiedono una maggiore protezione dei dati a riposo, Hyperforce o Salesforce Shield forniscono la crittografia a riposo</td>
            <td><b>Nella propria organizzazione:</b>
            <br> - Le esigenze aziendali richiedono una maggiore protezione dei dati a riposo, ma non vengono utilizzati né Hyperforce né Salesforce Shield</td>
        </tr>
        <tr>
            <td><b>In Apex:</b>
            <br> Se le esigenze aziendali richiedono una maggiore protezione dei dati in transito, tutto il codice coinvolto nell'integrazione esegue la logica utilizzando <a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_classes_restful_crypto.htm">metodi Crypto Class</a> per crittografare i dati prima della trasmissione o decrittografare i dati al ricevimento</td>
            <td><b>In Apex:</b>
            <br> - Le esigenze aziendali richiedono una maggiore protezione dei dati in transito, ma il codice coinvolto nell'integrazione esegue la logica senza crittografare i dati prima della trasmissione o al ricevimento, oppure i metodi di classe crittografica vengono utilizzati ad hoc</td>
        </tr>
    </tbody>
</table>

## Strumenti rilevanti per la sicurezza

<table class="tools-table"><tbody><tr><th>Strumento</th><th>Descrizione</th><th>Sicurezza organizzativa</th><th>Sicurezza della sessione</th><th>Sicurezza dei dati</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_classes_restful_crypto.htm">Classe crittografica Apex</a></td><td>Crittografia e decrittografia dei dati in Apex</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_api_access_control_about.htm&type=5&language=en_US">Controllo accesso API</a></td><td>Gestire l'accesso alle API Salesforce e alle applicazioni connesse</td><td class="check-col">X </td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_apianomalyevent.htm">Evento anomalia API</a></td><td>Monitoraggio delle anomalie nel modo in cui gli utenti effettuano le chiamate API</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=browser_security.htm&type=5&language=en_US">Impostazioni di sicurezza del browser</a></td><td>Proteggere i dati sensibili e monitorare i certificati SSL</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_certificate_based_auth.htm&type=5&language=en_US">Autenticazione basata su certificato</a></td><td>Autenticazione di persone con certificati digitali univoci</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5">Certificati e chiavi</a></td><td>Verifica delle richieste a siti Web esterni da Salesforce</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://github.com/forcedotcom/code-analyzer">Scanner di codice</a></td><td>Scansione di Apex Code per individuare vulnerabilità di sicurezza</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=connected_app_overview.htm&type=5&language=en_US">App connesse</a></td><td>Integrazione tramite API e protocolli standard</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_credentialstuffingevent.htm">Evento di credential stuffing</a></td><td>Tenere traccia dei tentativi di accesso che utilizzano credenziali utente rubate</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.configuring_remoteproxy.htm&type=5">Sito affidabile con policy per la sicurezza dei contenuti</a></td><td>Impedire attacchi di code injection (ad esempio cross-site scripting)</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_login_flow.htm&type=5">Flussi di accesso personalizzati</a></td><td>Controllare i processi aziendali di accesso per gli utenti</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=identity_about_customers_partners.htm&type=5&language=en_US">Identità cliente</a></td><td>Controllo degli accessi e della verifica a siti Web e app</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_mask_overview.htm&type=5">Data Mask</a></td><td>Maschera automaticamente i dati sensibili nei Sandbox</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.code_debug_log.htm&type=5">Registri debug</a></td><td>Tenere traccia degli eventi che si verificano nell'organizzazione</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=admin_delegate.htm&type=5&language=en_US">Amministrazione delegata</a></td><td>Assegnare privilegi di amministratore limitati agli utenti non amministratori</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_overview_identity_verification.htm&type=5">Attivazione dispositivo</a></td><td>Verificare gli accessi da browser, dispositivi o intervalli IP non affidabili</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.enhanced_transaction_security_policy_types.htm&type=5">Sicurezza delle transazioni ottimizzata</a></td><td>Intercettare gli eventi, monitorare e controllare l'attività degli utenti</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.modifying_field_access_settings.htm&type=5">Accesso ai campi</a></td><td>Controllare l'accesso ai dati a livello di campo</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5">Traccia di controllo</a></td><td>Definire una policy per conservare i dati della cronologia dei campi archiviati</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5">Tracciamento cronologia campi</a></td><td>Tracciamento e visualizzazione della cronologia dei campi</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_frontdoorjsp.htm&type=5&language=en_US">Frontdoor.jsp</a></td><td>Consenti l'accesso con un ID sessione e un URL server esistenti</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.heroku.com/connect">Heroku Connect</a></td><td>Sincronizzazione bidirezionale tra Heroku e Salesforce</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.heroku.com/shield">Heroku Shield</a></td><td>Creazione di app conformi a HIPAA o PCI</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_auth_require_ha_session.htm&type=5&language=en_US">Sicurezza sessione High Assurance</a></td><td>Richiedono ulteriore sicurezza per le operazioni sensibili</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.identityconnect_about.htm&type=5">Identity Connect</a></td><td>Mappare i record utente agli account Active Directory</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_verification_history.htm&type=5">Cronologia verifica dell'identità</a></td><td>Controllare i tentativi di verifica dell'identità degli utenti</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm">Licenza utente integrazione</a></td><td>Concedere l'accesso ai dati e alle funzioni solo tramite API.</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_ll_overview.htm&type=5">Lightning Login</a></td><td>Impedire password deboli o dimenticate e account bloccati</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.identity_login_access.htm&type=5">Accesso</a></td><td>Consentire agli utenti dell'assistenza di accedere come un altro utente</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.event_monitoring_faq.htm&type=5">Login Forensics</a></td><td>Identificare il comportamento che può indicare una frode dell'identità</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=users_login_history.htm&type=5&language=en_US">Cronologia accessi</a></td><td>Monitoraggio dei tentativi di accesso dell'organizzazione e del sito Experience Cloud</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_device_management.htm&type=5&language=en_US">Tracciamento dispositivo mobile</a></td><td>Monitoraggio e monitoraggio dell'accesso dei dispositivi mobili all'organizzazione</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm">SDK mobile</a></td><td>Connessione a Salesforce Platform tramite app mobili indipendenti</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_security_monitor_user_permissions.htm&type=5&release=238">Monitoraggio delle autorizzazioni utente (Shield)</a></td><td>Modifiche dell'insieme di autorizzazioni e del gruppo di insiemi di autorizzazioni</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_overview_2fa.htm&type=5">Autenticazione a più fattori</a></td><td>Richiedi due o più metodi di verifica per l'accesso</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_keys_uploading_mutual_auth_cert_api.htm&type=5">Autenticazione reciproca</a></td><td>Imponi autenticazione reciproca SSL o TLS</td><td class="check-col"></td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5">Dominio personale</a></td><td>Configurazione di pagine di accesso e policy, SSO e accessi sociali</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.named_credentials_about.htm&type=5">Credibili denominate</a></td><td>Specificare gli URL endpoint e i parametri di autenticazione</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.remoteaccess_authenticate.htm&type=5">Autorizzazione OAuth</a></td><td>Autorizzazione dell'accesso alle applicazioni client tramite scambio di token </td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=admin_password.htm&type=5&language=en_US">Polizze sulle password</a></td><td>Impostazione della cronologia, della lunghezza e della complessità delle password</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238">Spedizioni assegnazione insiemi di autorizzazioni</a></td><td>Impostare le scadenze per le assegnazioni di insiemi di autorizzazioni e gruppi di insiemi di autorizzazioni</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_security_monitor_user_permissions.htm&type=5&release=238">Evento insieme di autorizzazioni</a></td><td>Monitoraggio delle modifiche apportate agli insiemi di autorizzazioni e ai gruppi di insiemi di autorizzazioni</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=perm_set_groups.htm&type=5&language=en_US">Gruppi di insiemi di autorizzazioni</a></td><td>Insiemi di autorizzazioni bundle per supportare requisiti di accesso complessi</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=perm_sets_overview.htm&type=5&language=en_US">Insiemi di autorizzazioni</a></td><td>Controllare come gli utenti accedono a metadati, funzioni e app</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.private_connect_overview.htm&type=5">Connessione privata</a></td><td>Integrazioni sicure tra Salesforce e Amazon Web Services</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_userprofiles.htm&type=5">Profili</a></td><td>Controllo degli intervalli IP di accesso e degli orari di accesso</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5">Monitoraggio evento in tempo reale</a></td><td>Monitoraggio e rilevamento di eventi standard in Salesforce </td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=configuring_remoteproxy.htm&type=5&language=en_US">Impostazioni sito remoto</a></td><td>Registrazione di siti esterni per chiamate Apex o JavaScript</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_reportanomalyevent.htm">Segnala evento anomalia</a></td><td>Monitoraggio delle anomalie nel modo in cui gli utenti eseguono o esportano i rapporti</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule.htm&type=5">Regole di restrizione</a></td><td>Impedire agli utenti di accedere a record non necessari</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://github.com/forcedotcom/code-analyzer">Analizzatore di codice Salesforce</a></td><td>Scansionare il codice tramite IDE, CLI o CI/CD per assicurarsi che rispetti le procedure consigliate</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_scoping_rule.htm&type=5">Regole di definizione</a></td><td>Controllare i record predefiniti che possono essere visualizzati dagli utenti</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_center.htm&type=5">Centro di sicurezza</a></td><td>Visualizzare le impostazioni di sicurezza in tutte le organizzazioni e configurare gli avvisi per i cambiamenti di postura</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_health_check.htm&type=5">Controllo dello stato di sicurezza</a></td><td>Identificare le vulnerabilità nelle impostazioni di sicurezza</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_sessionhijackingevent.htm">Evento hijack della sessione</a></td><td>Identificare l'accesso non autorizzato tramite identificatori di sessione rubati</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.236.0.apexref.meta/apexref/apex_class_Auth_SessionManagement.htm">Classe di gestione delle sessioni</a></td><td>Personalizzare le impostazioni di sicurezza per una sessione attiva</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=admin_sessions.htm&type=5&language=en_US">Impostazioni di sicurezza della sessione</a></td><td>Configurare le sessioni per proteggersi da attacchi dannosi</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5">Percorso di controllo impostazioni</a></td><td>Tenere traccia delle modifiche apportate di recente dagli amministratori</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.managing_the_sharing_model.htm&type=5">Impostazioni di condivisione</a></td><td>Controllare l'accesso ai dati a livello di record</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_pe_overview.htm&type=5">Shield Platform Encryption</a></td><td>Crittografia dei dati sensibili a riposo e in transito</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5">Single Sign-On</a></td><td>Fornire l'accesso a più applicazioni tramite un unico accesso</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.identity_scim_overview.htm&type=5">Sistema per la gestione dell'identità tra domini (SCIM)</a></td><td>Gestione delle identità tra i sistemi tramite le API REST</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.real_time_em_threat_detection.htm&type=5">Rilevamento delle minacce</a></td><td>Utilizzare le statistiche e il machine learning per rilevare le minacce</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_networkaccess.htm&type=5&language=en_US">Intervalli IP affidabili</a></td><td>Definire indirizzi IP che non richiedono ulteriori verifiche</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FYkDDUA1&tab=e">Rapporto accesso utente</a></td><td>Ottenere una visualizzazione unificata dell'accesso a oggetti, record e autorizzazioni degli utenti</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
</table>

## Risorse rilevanti per la sicurezza

<table class="tools-table"><tbody><tr><th>Risorsa</th><th>Descrizione</th><th>Sicurezza organizzativa</th><th>Sicurezza della sessione</th><th>Sicurezza dei dati</th></tr>
<tr><td><a href="https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf">Guida alla condivisione dell'architettura</a></td><td>Ulteriori informazioni sugli strumenti di accesso, i modelli di condivisione e i casi d'uso</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/design-standards-template">Modello Design Standards (Standard di progettazione)</a></td><td>Creare standard di progettazione per l'organizzazione</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/how-to-build-a-user-security-model-12db130b3182">Come creare un modello di sicurezza utente</a></td><td>Ottenere una migliore comprensione dei modelli di sicurezza degli utenti</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/how-to-implement-the-principle-of-least-privilege-in-salesforce-59d3dbab9908?source=friends_link&sk=b7650c7fca8ad47bdd876399bbb0c635">Come implementare il principio dei privilegi minimi in Salesforce</a></td><td>Informazioni sull'applicazione dei controlli di accesso ai dati PoLP in Salesforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_user_session_info.htm&type=5&language=en_US">Monitoraggio delle sessioni utente</a></td><td>Esaminare le sessioni attive e terminare le sessioni sospette</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://security.salesforce.com/mfa">Autenticazione a più fattori</a></td><td>Accesso alle risorse ufficiali per la MFA da Salesforce</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/permission-set-groups/mute-permissions-in-permission-set-groups">Gruppi di insiemi di autorizzazioni (Trailhead)</a></td><td>Pratica con i gruppi di insiemi di autorizzazioni</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.234.0.api_rest.meta/api_rest/intro_rest_architecture.htm">Architettura API REST</a></td><td>Termini e concetti dell'API REST</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_concepts_security.htm">Sicurezza e API SOAP</a></td><td>Termini e concetti dell'API SOAP</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/security-best-practices-for-api-access-and-internal-system-users-a6199d0cda09">Procedure consigliate per la sicurezza per gli utenti API e del sistema interno</a></td><td>Accesso sicuro a Salesforce da parte degli utenti API e protezione degli utenti del sistema interno</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://resources.docs.salesforce.com/238/latest/en-us/sfdc/pdf/salesforce_security_impl_guide.pdf">Guida all'implementazione della sicurezza</a></td><td>Panoramica completa sulla sicurezza di Salesforce</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/it-it/resources/guide/security-policy-template">Modello di policy di sicurezza</a></td><td>Impostazione delle policy di sicurezza per l'organizzazione</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_session_types.htm&type=5&language=en_US">Tipi di sessione</a></td><td>Identificare i tipi di sessioni utilizzate per accedere all'organizzazione</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/threat-modeling-fundamentals">Nozioni di base sulla modellazione delle minacce (Trailhead)</a></td><td>Informazioni sulle minacce alla sicurezza e su come prevenirle.</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## Dicci cosa ne pensi

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro [sondaggio](https://sfdc.co/bxNtvh) per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.