Questo testo è stato tradotto utilizzando il sistema di traduzione automatica di Salesforce. Partecipa al nostro sondaggio per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.
Note
Il modello di condivisione Salesforce è un elemento essenziale per la capacità dell'organizzazione di fornire un accesso sicuro ai dati delle applicazioni. Pertanto, è fondamentale progettare correttamente il modello di condivisione per soddisfare i requisiti di accesso ai dati attuali e futuri. In questo documento esamineremo i componenti di accessibilità dei dati, i casi d'uso dei modelli di condivisione e le soluzioni di condivisione dei clienti reali e forniremo alcune linee guida per la risoluzione dei problemi.
Questo documento è destinato agli amministratori di sistema avanzati e agli architetti. Per comprendere i concetti, è necessario avere una Knowledge di funzionamento del modello di condivisione e protezione Salesforce. I prerequisiti di questa guida sono:
Questa guida si concentra sulle funzioni principali utilizzate per controllare l'accesso a livello di record agli oggetti standard e personalizzati. Gli argomenti non trattati in questa guida includono:
La protezione a livello di record consente di concedere agli utenti l'accesso ad alcuni record di oggetti, ma non ad altri. Come per la maggior parte delle applicazioni, l'accesso ai dati inizia con un utente. L'applicazione deve sapere chi è l'utente prima di concedere l'accesso. Per Salesforce esistono diversi tipi di utenti e, a volte, il livello di accesso è diverso in base al tipo. Anziché esaminare ogni attributo di ogni tipo di licenza, ci concentreremo qui sugli attributi interessanti che hanno un impatto significativo sull'accesso ai dati. La proprietà dei record e l'accesso completo sono sinonimi e intercambiabili e offrono all'utente il massimo livello di accesso a un record.
Utenti a volume elevato
Gli utenti a volume elevato (inclusi gli utenti con i tipi di licenza Customer Community, High Volume Customer Portal e Authenticated Website) non utilizzano il modello di condivisione, perché i loro tipi di licenza non supportano i ruoli. Queste licenze hanno un proprio modello di condivisione che funziona in base alla corrispondenza della chiave esterna tra l'utente (titolare della licenza) e i dati nelle ricerche di account e referenti. Gli amministratori possono creare insiemi di condivisione o gruppi di condivisione per concedere agli utenti a volume elevato l'accesso ai record.
Licenze Chatter Free e Chatter External
Le licenze Chatter Free e Chatter External non seguono il modello di condivisione standard. Queste licenze non hanno accesso ai record CRM (oggetti standard o personalizzati) e alla funzionalità Contenuto e non supportano i ruoli, pertanto non è possibile condividere.
Per il resto di questo documento, si presuppone che un tipo di utente Salesforce utilizzi un modello di condivisione completo. Per ulteriori informazioni su ogni tipo di licenza disponibile, vedere Licenze utente.
Profili e insiemi di autorizzazioni
I profili e gli insiemi di autorizzazioni offrono una protezione a livello di oggetto determinando quali tipi di dati vengono visualizzati dagli utenti e se possono modificare, creare o eliminare i record. Per ogni oggetto, le autorizzazioni "Visualizza tutto" e "Modifica tutto" ignorano le regole e le impostazioni di condivisione, consentendo agli amministratori di concedere rapidamente l'accesso ai record associati a un determinato oggetto in tutta l'organizzazione. Queste autorizzazioni sono spesso alternative preferibili alle autorizzazioni amministrative "Visualizza tutti i dati" e "Modifica tutti i dati", che consentono agli utenti di visualizzare o modificare tutte le app e i dati.
I profili e gli insiemi di autorizzazioni controllano anche la protezione a livello di campo, che determina i campi all'interno di ogni oggetto a cui gli utenti possono accedere. Ad esempio, un oggetto può avere 20 campi, ma la protezione a livello di campo può essere impostata per impedire agli utenti di visualizzare cinque dei 20 campi.
Si consiglia vivamente di utilizzare gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni anziché i profili per gestire le autorizzazioni oggetto degli utenti. Poiché è possibile riutilizzare componenti base di insiemi di autorizzazioni più piccoli, è possibile evitare di creare decine o persino centinaia di profili per ogni utente e funzione lavorativa.
Titolarità dei record e aree di attesa
Ogni record deve essere di proprietà di un singolo utente o di un'area di attesa. Il titolare ha accesso al record in base alle impostazioni oggetto del profilo del titolare. Ad esempio, se il profilo del titolare dispone dell'autorizzazione Crea e Lettura per un oggetto ma non dell'autorizzazione Modifica o Elimina, il titolare può creare un record per l'oggetto e visualizzare il nuovo record. Tuttavia, il titolare non potrà modificare o eliminare il record. Gli utenti di livello superiore in una gerarchia (ruolo o territorio) ereditano lo stesso accesso ai dati dei loro subordinati per gli oggetti standard. Se il subordinato dispone dell'accesso in sola lettura, lo saranno anche gli utenti che occupano una posizione superiore nella gerarchia dei ruoli. Questo accesso si applica ai record di proprietà degli utenti e ai record condivisi con loro.
Le aree di attesa consentono di assegnare priorità, distribuire e assegnare record ai team che condividono i carichi di lavoro. I membri dell'area di attesa e gli utenti di livello superiore nella gerarchia dei ruoli possono accedere alle aree di attesa dalle visualizzazioni elenco e diventare titolari dei record di un'area di attesa.
Se un singolo utente è titolare di più di 10.000 record, è consigliabile:
Il record utente del titolare non deve avere un ruolo nella gerarchia dei ruoli.
Se il record utente del titolare deve contenere un ruolo, posizionare il ruolo in cima alla gerarchia nel proprio ramo della gerarchia dei ruoli.
Per ulteriori informazioni, vedere Salesforce Well-Architected - Affidabile.
Impostazioni predefinite organizzazione
Le impostazioni di condivisione dell'organizzazione specificano il livello predefinito di accesso degli utenti ai record degli altri utenti. Le impostazioni di condivisione dell'organizzazione consentono di bloccare i dati al livello più restrittivo. Utilizzare gli altri strumenti di protezione e condivisione a livello di record per concedere l'accesso in modo selettivo ad altri utenti. Ad esempio, gli utenti dispongono delle autorizzazioni a livello di oggetto per leggere e modificare le opportunità e l'impostazione di condivisione a livello di organizzazione è Sola lettura. Per impostazione predefinita, questi utenti possono leggere tutti i record opportunità, ma non possono modificarli a meno che non siano titolari del record o dispongano di altre autorizzazioni.
Le impostazioni predefinite dell'organizzazione possono essere modificate da un'impostazione all'altra (Privato a Controllato da società controllante, quindi di nuovo a Privato). Tuttavia, queste modifiche richiedono un ricalcolo della condivisione e, a seconda del volume, potrebbero causare lunghi tempi di elaborazione.
Solo per gli oggetti personalizzati, è possibile configurare l'impostazione Concedi accesso tramite le gerarchie. Se l'opzione è deselezionata (è selezionata l'impostazione predefinita), agli utenti di livello superiore nella gerarchia dei ruoli viene impedito di ereditare l'accesso. Questa impostazione si trova nelle impostazioni predefinite dell'organizzazione.
Gerarchia dei ruoli
Una gerarchia dei ruoli rappresenta un livello di accesso ai dati necessario per un utente o un gruppo di utenti. La gerarchia dei ruoli garantisce che i responsabili abbiano sempre accesso agli stessi dati dei dipendenti, indipendentemente dalle impostazioni predefinite dell'organizzazione. Le gerarchie dei ruoli non devono necessariamente corrispondere esattamente all'organigramma. Ogni ruolo nella gerarchia dovrebbe invece rappresentare un livello di accesso ai dati necessario per un utente o un gruppo di utenti.
Nelle organizzazioni Salesforce create nel rilascio Spring '21 o successivi, è possibile creare fino a 5.000 ruoli. Nelle organizzazioni create prima del rilascio Spring '21, è possibile creare fino a 500 ruoli e contattare l'Assistenza clienti Salesforce per aumentare questo limite. È consigliabile mantenere il numero di ruoli interni a 25.000 e il numero di ruoli esterni a 100.000.
È consigliabile mantenere la gerarchia dei ruoli a non più di 10 livelli di rami nella gerarchia.
Quando il ruolo di un utente cambia, tutte le regole di condivisione pertinenti vengono valutate per correggere l'accesso in base alle esigenze. I pari all'interno dello stesso ruolo non garantiscono loro l'accesso reciproco ai dati.
La modellazione della gerarchia dei ruoli inizia dalla comprensione della struttura dell'organizzazione. Questo di solito si basa sulla comprensione dell'ambito di un responsabile, iniziando dall'alto. Il CEO supervisiona l'intera società. Il CEO di solito ha dei riporti diretti che possono essere segmentati per unità operativa (Vendite o Assistenza) o area geografica (EMEA, APAC). Quella persona ha quindi rapporti diretti che potrebbero essere ulteriormente segmentati e così via. Benché questo sembri molto simile a un organigramma delle risorse umane, quando si modella l'accesso ai dati, concentrarsi sull'accessibilità dei dati con una considerazione alla generazione di rapporti sulle risorse umane.
Le sovrapposizioni sono sempre la parte difficile della gerarchia. Se si trovano nella loro filiale, dovranno disporre di regole di condivisione, team o gestione dei territori per ottenere l'accesso necessario. Se vengono inseriti nella gerarchia, potrebbero esserci implicazioni in termini di rapporti.
È importante dedicare tempo alla configurazione della gerarchia dei ruoli perché è uno degli aspetti fondamentali del modello di condivisione.
| Casi d'uso della gerarchia dei ruoli |
|---|
| Accesso alla gestione: la possibilità per i responsabili di vedere e fare tutto ciò che i loro subordinati possono vedere e fare. |
| Rapporti gestionali: la possibilità di riportare i rapporti in modo gerarchico in modo che chiunque nella gerarchia veda più dati di quelli subordinati. |
| Segregazione tra le filiali dell'organizzazione: le diverse unità operative non hanno bisogno di visualizzare i dati l'una dell'altra; avere una gerarchia in cui è possibile definire filiali separate consente di separare la visibilità all'interno delle unità operative, continuando a estendere la visibilità ai livelli esecutivi superiori a tali unità. |
| Segregazione all'interno di un ruolo: in molte organizzazioni/applicazioni, le persone che svolgono tutte lo stesso ruolo non devono necessariamente vedere i dati degli altri. La presenza di ruoli gerarchici consente di definire un nodo “foglia” in cui tutti i dati sono essenzialmente privati e di riportare i dati a un ruolo controllante che li può visualizzare tutti. |
Gruppi pubblici
Un gruppo pubblico è un insieme di singoli utenti, ruoli, territori e così via, che hanno tutti una funzione in comune. I gruppi pubblici possono essere costituiti da:
I gruppi possono essere nidificati (Gruppo A nidificato nel Gruppo B), ma non nidificare più di cinque livelli. La nidificazione ha un impatto sulla manutenzione e sulle prestazioni dei gruppi a causa del calcolo dell'appartenenza ai gruppi. È consigliabile mantenere il numero totale di gruppi pubblici per un'organizzazione a 100.000.
| Casi d'uso di gruppi pubblici |
|---|
| Quando è necessario concedere l'accesso a un gruppo arbitrario di persone, creare un gruppo pubblico per raccoglierle e quindi utilizzare altri strumenti di condivisione per concedere al gruppo l'accesso necessario. La sola appartenenza ai gruppi non fornisce l'accesso ai dati. |
| I gruppi possono anche essere nidificati l'uno all'interno dell'altro, consentendo quindi a un gruppo nidificato di ottenere lo stesso accesso del gruppo in cui è contenuto. Ciò consente la creazione di gerarchie più piccole e ad hoc che non interagiscono necessariamente con le gerarchie dei ruoli o dei territori. Se il Gruppo A è membro del Gruppo B, i membri del Gruppo A avranno accesso ai dati condivisi con il Gruppo B allo stesso livello di accesso dei membri del Gruppo B. |
| I gruppi hanno anche la possibilità di proteggere i dati condivisi nel gruppo dall'essere resi accessibili alle persone nella gerarchia dei ruoli al di sopra dei membri del gruppo. Questo (e l'accesso dei titolari dei record e della loro gerarchia di gestione) consente la creazione di gruppi in cui è possibile condividere informazioni molto riservate: i dati saranno accessibili SOLO ai membri del gruppo e a nessun altro membro dell'organizzazione. A questo scopo, utilizzare l'impostazione Concedi accesso tramite le gerarchie. |
Regole di condivisione basate sul titolare
Le regole di condivisione basate sul titolare consentono eccezioni alle impostazioni predefinite dell'organizzazione e alla gerarchia dei ruoli che consentono ad altri utenti di accedere ai record di cui non sono titolari. Le regole di condivisione basate sul titolare si basano solo sul titolare del record.
Le regole di condivisione basate sul titolare del referente non si applicano ai referenti privati o ai referenti che non sono associati a un account.
Il limite totale di regole di condivisione per oggetto è 300.
| Casi d'uso delle regole di condivisione basate sul titolare |
|---|
| Gestione a matrice basata sui ruoli o situazioni di sovrapposizione: una persona in Service deve essere in grado di visualizzare alcuni dati di Sales, ma vive in rami diversi della gerarchia, quindi è possibile creare una regola che condivide i dati tra ruoli in rami diversi. |
| Fornire l'accesso ai dati a colleghi che ricoprono lo stesso ruolo o territorio. |
| Fornire l'accesso ai dati ad altri gruppi di utenti (gruppi pubblici, portale, ruoli, territori). I membri dei raggruppamenti titolari dei record possono essere condivisi con i membri di altri raggruppamenti. |
Regole di condivisione basate su criteri
Le regole di condivisione basate su criteri forniscono l'accesso ai record in base ai valori dei campi (criteri) del record. Se i criteri sono soddisfatti (uno o più valori di campo), viene creato un record condivisione per la regola. La proprietà dei record non è una considerazione.
Il limite di regole di condivisione basate su criteri e utenti guest per oggetto è 50.
| Caso d'uso delle regole di condivisione basate su criteri |
|---|
| Fornire l'accesso ai dati a utenti o gruppi in base al valore di un campo del record. |
Regole di condivisione utenti guest
Una regola di condivisione utente guest è un tipo speciale di regola di condivisione basata su criteri utilizzata per concedere l'accesso ai record agli utenti guest non autenticati. Il limite di regole di condivisione basate su criteri e utenti guest per oggetto è 50.
Avvertenza: Il tipo di regola di condivisione utente guest concede l'accesso agli utenti guest senza credenziali di accesso. Creando una regola di condivisione per gli utenti guest si consente a chiunque l'accesso immediato e illimitato a tutti i record che soddisfano i criteri della regola di condivisione. Per proteggere i dati Salesforce e consentire agli utenti guest di accedere a ciò di cui hanno bisogno, considerare tutti i casi d'uso e le implicazioni della creazione di questo tipo di regola di condivisione. Implementare i controlli di sicurezza che si ritengono appropriati per la riservatezza dei dati. Salesforce non è responsabile dell'esposizione dei dati a utenti non autenticati in base a questa modifica delle impostazioni predefinite.
| Caso d'uso regola di condivisione utenti guest |
|---|
| Fornire l'accesso ai dati agli utenti guest non autenticati. |
Condivisione manuale
A volte è impossibile definire un gruppo coerente di utenti che necessitano dell'accesso a un determinato insieme di record. I titolari dei record o altri utenti con privilegi adeguati, ad esempio gli amministratori di sistema, possono utilizzare la condivisione manuale per concedere le autorizzazioni di lettura e modifica agli utenti che non hanno accesso in altro modo. La condivisione manuale non è automatizzata come le impostazioni di condivisione dell'organizzazione, le gerarchie dei ruoli o le regole di condivisione. Offre tuttavia ai titolari dei record la flessibilità di condividere i record con gli utenti che devono visualizzarli.
La condivisione manuale viene rimossa quando cambia il titolare del record o quando l'accesso in condivisione concesso non concede un accesso aggiuntivo oltre il livello di accesso predefinito di condivisione dell'oggetto a livello di organizzazione. Questo vale anche per le condivisioni manuali create a livello di programmazione.
I record condivisione manuale sono definiti come record condivisione con la causale riga impostata su condivisione manuale.
Tutti i record di condivisione (oggetti standard e personalizzati) con una causa riga impostata su condivisione manuale possono essere modificati ed eliminati dal pulsante Condividi nel layout di pagina dell'oggetto, anche se il record di condivisione è stato creato a livello di programmazione.
| Caso d'uso di condivisione manuale |
|---|
| Fornire all'utente la possibilità di concedere l'accesso (sola lettura o lettura/scrittura) al record corrente ad altri utenti, gruppi o ruoli. |
Team
Un team è un gruppo di utenti che lavorano insieme su un account, un'opportunità di vendita o un caso. I titolari dei record possono creare un team per ogni record di cui sono titolari. Il titolare del record aggiunge i membri del team e specifica il livello di accesso di ogni membro del team al record. Alcuni membri del team possono avere accesso in sola lettura, mentre altri hanno accesso in lettura/scrittura.
Solo i titolari, le persone di grado superiore nella gerarchia e gli amministratori possono aggiungere membri del team e fornire un accesso più ampio al membro. Un membro del team con accesso in lettura/scrittura può aggiungere un altro membro che ha già accesso al record a cui è associato il team. Il membro del team non può fornire un accesso aggiuntivo.
La creazione di un membro del team nell'app crea due record: un record team e un record condivisione associato. Se si creano membri del team a livello di programmazione, è necessario gestire sia il record team che il record condivisione associato. È presente un solo team per record (Account, Opportunità o Caso). Se sono necessari più team, a seconda delle esigenze specifiche, valutare la gestione dei territori o la condivisione a livello di programmazione
| Casi d'uso del team |
|---|
| Fornire all'utente la possibilità di concedere l'accesso (sola lettura o lettura/scrittura) a un singolo gruppo di utenti (il team). |
| Se i team sono gestiti esternamente, ad esempio tramite una commissione esterna o un sistema di gestione dei territori, è possibile utilizzare l'integrazione per gestire il team account. Esistono casi in cui la gestione dei territori in un sistema esterno può allinearsi a una soluzione di team in Salesforce. |
| Il team account può gestire più titolari di un account. |
| Un singolo gruppo di utenti (team) richiede l'accesso in sola lettura o lettura/scrittura a un record opportunità. (Team opportunità) |
Gerarchia dei territori
Quando si utilizza Gestione territorio di livello aziendale, si imposta una gerarchia dei territori che mostra la struttura dei territori di un modello e funge da punto di interazione principale. Se Gestione territorio di livello aziendale è abilitata, è necessario gestire sia la gerarchia dei ruoli che la gerarchia dei territori. Per ulteriori informazioni, vedere Gestione dei territori aziendali nella Guida di Salesforce.
Condivisione gestita Apex
La condivisione gestita Apex (detta anche condivisione a livello di programmazione) consente di utilizzare il codice per creare impostazioni di condivisione sofisticate e dinamiche quando un requisito di accesso ai dati non può essere soddisfatto con altri mezzi.
Se si crea un record condivisione a livello di programmazione e viene utilizzata la causa della riga pronta all'uso (condivisione manuale), è possibile mantenere questo record condivisione con il pulsante Condividi nell'app. Il record condivisione è soggetto a tutte le regole con la causa della riga di condivisione manuale, ad esempio l'eliminazione al trasferimento del titolare.
È anche possibile creare i propri motivi di condivisione Apex per gli oggetti personalizzati per tenere traccia del motivo di un record con un utente o un gruppo di utenti e semplificare il codice necessario per eseguire aggiornamenti ed eliminazioni dei record di condivisione.
Per ulteriori informazioni, consultare Condivisione di un record con Apex prima di valutare l'uso della condivisione a livello di programmazione.
| Casi d'uso di condivisione gestiti Apex |
|---|
| Nessun altro metodo di condivisione (dichiarativo) soddisfa le esigenze di accesso ai dati. |
| Esiste già un sistema di verifica esterno per le assegnazioni dell'accesso utente che continuerà a favorire l'accesso e a integrarlo con Salesforce. |
| Scarse prestazioni utilizzando componenti di condivisione nativi. (In genere si applica a volumi di dati molto elevati) |
| Funzionalità del team sugli oggetti personalizzati. |
Regole di restrizione
Nella configurazione di accesso ai dati, può essere opportuno impedire agli utenti di visualizzare record che possono contenere dati sensibili o semplicemente non essenziali per il loro lavoro. È possibile utilizzare le regole di restrizione per consentire agli utenti di accedere solo ai record che soddisfano i criteri specificati. Quando si applica una regola di restrizione a un utente, i record a cui l'utente ha accesso tramite le impostazioni predefinite dell'organizzazione, le regole di condivisione e altri meccanismi di condivisione vengono filtrati in base ai criteri specificati. Le regole di restrizione funzionano in modo opposto rispetto ai componenti di condivisione descritti in questo argomento; anziché aprire l'accesso agli utenti, lo limitano ulteriormente.
Le regole di restrizione sono disponibili per oggetti personalizzati, oggetti esterni, contratti, eventi, operazioni, schede attività e voci scheda attività. È possibile creare fino a due regole di restrizione attive per oggetto nelle versioni Enterprise Edition e Developer Edition e fino a cinque regole di restrizione attive per oggetto nelle versioni Performance Edition e Unlimited Edition. Le regole di restrizione vengono applicate alle seguenti funzioni di Salesforce:
| Casi d'uso delle regole di restrizione |
|---|
| Si desidera che determinati utenti visualizzino solo un insieme specifico di record. |
| Semplificare il controllo dell'accesso ai record con informazioni sensibili o riservate. |
| Rendere veramente privato l'accesso a contratti, operazioni ed eventi, poiché questo può essere difficile da ottenere utilizzando le impostazioni predefinite dell'organizzazione. |
Condivisione implicita
La condivisione implicita è automatica. Non è possibile disattivarlo né attivarlo: è nativo dell'applicazione. In altre parole, la condivisione implicita non è un'impostazione configurabile; tuttavia, è importante che ogni architetto comprenda. La condivisione implicita controllante fornisce l'accesso ai record controllanti (solo account) quando un utente ha accesso a opportunità controllate, casi o referenti per quell'account. Salesforce ha una policy di accesso ai dati che indica se un utente può visualizzare un referente (o un'opportunità, un caso o un ordine), quindi l'utente vede implicitamente l'account associato. La condivisione implicita controllata fornisce l'accesso ai record controllati di un account al titolare dell'account. Questo accesso è definito in corrispondenza del ruolo del titolare nella gerarchia dei ruoli. La condivisione implicita controllata si applica solo agli oggetti referente, opportunità e caso (controllati dell'account). I livelli di accesso che possono essere forniti sono Visualizza, Modifica e Nessun accesso per ciascuno degli oggetti secondari quando viene creato il ruolo. Impostando su Visualizza, il titolare dell'account può visualizzare implicitamente i record oggetto associati (referente, opportunità o caso). Impostando su Modifica, il titolare dell'account può modificare implicitamente l'oggetto associato (referente, opportunità o caso).
La condivisione implicita non si applica agli oggetti personalizzati.
Non esiste un modello di condivisione adatto a tutte le organizzazioni Salesforce. Ogni organizzazione ha requisiti e sfide diversi quando tenta di progettare il modello di condivisione migliore. È fondamentale utilizzare i componenti di accesso ai dati più appropriati per soddisfare i requisiti di condivisione dell'organizzazione. Gli scenari seguenti sono sfide comuni quando si tenta di progettare un modello di condivisione.
| Requisiti o sfide | Soluzione |
|---|---|
| Due in una scatola: un responsabile vendite di un'area di copertura geografica desidera anche accedere a un'altra area di copertura geografica per fornire assistenza. | Regola di condivisione basata sul titolare: Qui funziona una regola di condivisione basata sul titolare perché questi sono casi limite e non la norma. È accettabile anche che la regola di condivisione basata sul titolare fornisca un accesso maggiore di quello realmente necessario poiché si tratta di un responsabile, ovvero di una persona affidabile. |
| Gli utenti delle operazioni basate sul paese devono poter accedere a tutti i dati di vendita del paese. | Regola di condivisione basata sul titolare: Un uso molto comune di una regola di condivisione è quando un reparto diverso (diverso dalle vendite) necessita dell'accesso ai dati di vendita. |
| Almeno l'80% delle volte, è presente un team "core 4" in un account (Dirigente account, Agente di vendita interno, Consulente di vendita, Agente di vendita tecnico). Il sistema di record per l'assegnazione del team account è esterno. Esiste sempre un solo team per un account. | Team: Poiché è sempre presente un solo team per account, anche se sono presenti molti membri diversi con ruoli diversi, la funzionalità del team account soddisfa questo requisito. |
| I responsabili del team devono avere lo stesso accesso dei loro subordinati. | Gerarchia dei ruoli: La gerarchia dei ruoli risolve questo requisito consentendo ai responsabili di accedere ai dati dei loro subordinati. |
| Il team account assegnato non deve essere modificabile. | Team: Questo requisito non viene effettivamente soddisfatto con la funzionalità del team account. Tuttavia, ciò non dovrebbe impedire di continuare a utilizzare i team account. Tuttavia, ci sono diversi modi per bloccare le squadre. In questo caso, viene utilizzata la rimozione del layout di pagina del team account. |
| Deve essere presente una funzionalità "compagno" in modo che, quando qualcuno è malato o in vacanza, qualcuno senza accesso standard a un account o a un'opportunità possa essere accessibile e coperto durante il tempo libero. | Team: Un "amico" può essere semplicemente un ruolo nel team che soddisfa questo requisito. Tuttavia, la sfida deriva dal requisito precedente in cui i team non devono essere modificabili. L'unica soluzione è avere un gruppo di persone che possono modificare i team per creare il ruolo di amico quando necessario. |
| Quando una trattativa richiede una soluzione personalizzata, altre persone (che non fanno necessariamente parte dell'organizzazione di vendita) devono avere accesso alla trattativa. | Team: Un utilizzo abbastanza standard del team opportunità ottenuto aggiungendo manualmente un nuovo membro al team opportunità (tramite elenco correlato). Può essere eseguita anche tramite un trigger se si sa sempre chi deve essere aggiunto. In questo caso, è opportunità per opportunità. |
| Requisiti o sfide | Soluzione |
|---|---|
| Due team opportunità diversi di due unità operative distinte (Vendite al dettaglio e Remarketing) devono accedere allo stesso record account. Devono condividere i referenti ed essere a conoscenza di tutte le attività sull'account. Queste due unità operative hanno una gerarchia e roll-up propri. | Gestione dei territori: Il modo migliore per pensare a questo requisito è avere due rami di una gerarchia che possono essere strutturati in modo diverso. Ciò che giustifica la gestione dei territori è che esistono due livelli di queste due filiali diverse (entrambi i livelli con membri = team opportunità per quell'unità operativa) che necessitano dell'accesso all'account. Anche se si sarebbe potuto soddisfare questo requisito con un concetto di Teaming, era troppo granulare. La segmentazione delle vendite non era a livello di account ma a livello di gerarchia. |
| Esiste un gruppo separato di sviluppatori aziendali a cui è assegnato l'accesso ad account specifici per un team opportunità specifico (un territorio). Gli sviluppatori aziendali sono risorse condivise per i team opportunità, il che significa che ogni sviluppatore aziendale può essere assegnato a uno o più account per uno o più team opportunità. | Gestione dei territori: Poiché si tratta di un gruppo di utenti (o di un team) e ogni team di sviluppo aziendale può essere diverso in base all'account, e poiché la gestione dei territori era necessaria per un altro motivo, l'approccio probabilmente migliore è creare sottoterritori o filiali separate che rappresentano questi team di sviluppo aziendale. |
| Esistono ruoli di assistenza alle vendite non basati su commissione che necessitano di accedere agli account una tantum. | Team: La parte chiave del requisito è "base una tantum". Ciò significa che viene eseguito account per account in modo che i team account lo forniscano in modo nativo. |
| Il reparto crediti deve poter accedere a tutti gli account di una determinata unità operativa. | Regola di condivisione basata sul titolare: Questa è una situazione in cui in generale, per una determinata unità operativa, un gruppo di utenti deve vedere tutto. Questo requisito può essere soddisfatto con una regola di condivisione per un ruolo a cui appartiene il gruppo, un ramo della gerarchia dei ruoli a cui appartiene il gruppo (ruolo e subordinati) o anche un gruppo pubblico.Gestione dei territori: È anche possibile soddisfare questo requisito modellando il reparto credito come territorio con la stessa logica per l'unità operativa specificata. |
| I responsabili devono avere lo stesso accesso dei loro subordinati. | Gerarchia dei ruoli: La gerarchia dei ruoli risolve questo requisito consentendo ai responsabili di accedere ai dati dei loro subordinati. |
Che cosa accade alla gerarchia dei ruoli?
Non accade nulla alla gerarchia dei ruoli se si utilizza anche una gerarchia dei territori. Tuttavia, se si utilizzano insieme sia le previsioni basate sul territorio che le previsioni basate sui ruoli, è necessario gestire due gerarchie. In questo caso, si consiglia di utilizzare la gerarchia dei ruoli per modellare la struttura dei rapporti HR, quindi utilizzare la gerarchia dei territori per modellare la gerarchia delle vendite effettiva. La gerarchia dei territori è più adatta per modellare una struttura di rapporti a matrice, in cui qualcuno può fare capo a più responsabili.
Se non si utilizzano insieme previsioni basate sul territorio e previsioni basate sui ruoli, è possibile utilizzare solo la gerarchia dei territori come gerarchia delle vendite. In questo scenario, è meglio semplificare o appiattire il più possibile la gerarchia.
Non è consigliabile rendere identici la gerarchia dei ruoli e la gerarchia dei territori perché si verificano attività di condivisione non necessarie.
È ancora possibile utilizzare i team?
Riallineamento e riassegnazione
Grandi volumi di dati
Sia che si tratti di modellare per l'implementazione iniziale o di pianificare una modifica del riallineamento, è necessario prestare molta attenzione al volume dei dati. Esistono soglie in cui le prestazioni possono diventare un fattore, quindi è altamente consigliabile testare le modifiche in un Sandbox prima di procedere alla produzione. Questo test fornirà anche una base di riferimento per la durata della modifica.
Se si dispone di più di due milioni di account e sono stati implementati team o Gestione territorio di livello aziendale, è necessario prestare particolare attenzione alle prestazioni. Si tratta di componenti modello di condivisione complessi che possono generare un volume enorme di record condivisione e quindi transazioni di lunga durata.
Rinvio dei calcoli di condivisione
Dati e differenze di proprietà
Le differenze di dati sono definite come pochi record controllanti con molti record controllati. Queste distorsioni possono davvero danneggiarti quando alcuni account hanno molti referenti, opportunità o casi. Il rapporto in cui iniziamo a vedere un peggioramento delle prestazioni è 1:10.000. È consigliabile mantenere il rapporto il più vicino possibile a quello (è preferibile un rapporto più basso).
Le differenze di proprietà sono simili alle differenze di dati, tranne per il fatto che ci si riferisce a un singolo utente, ruolo o gruppo titolare di molti record per un oggetto. Come per le distorsioni dei dati, anche queste possono causare transazioni di lunga durata, causando un peggioramento delle prestazioni quando si verificano modifiche. Anche il rapporto consigliato tra titolare e numero di record è 1:10.000.
Se un singolo utente è titolare di più di 10.000 record, è consigliabile:
Il record utente del titolare non deve avere un ruolo nella gerarchia dei ruoli.
Se il record utente del titolare deve contenere un ruolo, posizionare il ruolo in cima alla gerarchia nel proprio ramo della gerarchia dei ruoli.
Impatto delle gerarchie account sull'accesso ai dati
Una volta completata l'architettura del modello di condivisione, probabilmente ci si chiederà perché un utente possa o non possa vedere un record. In genere, non si sente quando gli utenti possono vedere qualcosa che non dovrebbero, ma se necessario, esiste un modo per vedere ogni utente che ha accesso a un record e perché.
La sfida più difficile, e probabilmente più comune, è il motivo per cui un utente non può visualizzare un record. I livelli di sicurezza progettati determinano da dove iniziare. Se si conosce bene il modello di condivisione, probabilmente si sa quale componente dovrebbe aver fornito l'accesso e può iniziare da lì. Tuttavia, se si ha meno dimestichezza con il modello di condivisione, iniziare con la gerarchia dei ruoli e separare ogni livello per determinare quale deve fornire l'accesso. Di seguito è riportato un flusso per la risoluzione dei problemi.
j
