Esse texto foi traduzido usando o sistema de tradução automatizado do Salesforce. Pegue nossa enquisa para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida.
Note
O modelo de compartilhamento do Salesforce é um elemento essencial na capacidade da sua organização de fornecer acesso seguro aos dados do aplicativo. Portanto, é crucial arquitetar seu modelo de compartilhamento corretamente para atender aos seus requisitos de acesso a dados atuais e futuros. Neste documento, revisaremos componentes de acessibilidade de dados, casos de uso de modelo de compartilhamento e soluções reais de compartilhamento de clientes e forneceremos algumas diretrizes de solução de problemas.
Este documento é destinado a administradores e arquitetos avançados do sistema. Para entender os conceitos, você deve ter um Knowledge prático do modelo de compartilhamento e segurança do Salesforce. Os pré-requisitos para esse guia são:
Este guia se concentra nos principais recursos usados para controlar o acesso em nível de registro a objetos padrão e personalizados. Os tópicos não abordados neste guia incluem:
A segurança em nível de registro permite que você dê aos usuários acesso a alguns registros de objeto, mas não a outros. Como acontece com a maioria dos aplicativos, o acesso aos dados começa com um usuário. O aplicativo deve saber quem é o usuário antes de dar acesso. Para o Salesforce, há diferentes tipos de usuários e, às vezes, o nível de acesso é diferente por tipo. Em vez de revisar cada atributo de cada tipo de licença, vamos focar aqui os atributos interessantes que têm impacto significativo no acesso aos dados. A propriedade do registro e o acesso total são sinônimos e intercambiáveis e fornecem ao usuário o nível mais alto de acesso a um registro.
Usuários de alto volume
Usuários de alto volume (incluindo usuários com os tipos de licença Comunidade de clientes, Portal de clientes de alto volume e Site autenticado) não utilizam o modelo de compartilhamento, pois seus tipos de licença não oferecem suporte a papéis. Essas licenças têm seu próprio modelo de compartilhamento que funciona por correspondência de chave estrangeira entre o usuário (que contém a licença) e os dados nas pesquisas de Conta e Contato. Os administradores podem criar conjuntos de compartilhamento ou compartilhar grupos para conceder aos usuários de alto volume acesso a registros.
Licenças externas do Chatter Free e Chatter
As licenças Chatter Free e Chatter External não seguem o modelo de compartilhamento padrão. Essas licenças não têm acesso a registros do CRM (objetos padrão ou personalizados) e funcionalidades de Conteúdo e não oferecem suporte a papéis, portanto, não há compartilhamento.
Para o restante deste documento, estamos presumindo um tipo de usuário do Salesforce usando um modelo de compartilhamento completo. Consulte Licenças de usuário para obter mais informações sobre cada tipo de licença disponível.
Perfis e conjuntos de permissões
Perfis e conjuntos de permissões fornecem segurança em nível de objeto determinando quais tipos de dados os usuários veem e se eles podem editar, criar ou excluir registros. Para cada objeto, as permissões "Visualizar tudo" e "Modificar tudo" ignoram regras e configurações de compartilhamento, permitindo que os administradores concedam acesso rapidamente a registros associados a um determinado objeto em toda a organização. Essas permissões costumam ser alternativas preferidas às permissões administrativas "Visualizar todos os dados" e "Modificar todos os dados", que permitem aos usuários visualizar ou modificar todos os aplicativos e dados.
Os perfis e os conjuntos de permissões também controlam a segurança em nível de campo, que determina os campos em cada objeto que os usuários podem acessar. Por exemplo, um objeto pode ter 20 campos, mas a segurança em nível de campo pode ser configurada para impedir que os usuários vejam cinco dos 20 campos.
Recomendamos enfaticamente que você use conjuntos de permissões e grupos de conjuntos de permissões em vez de perfis para gerenciar as permissões de objeto de seus usuários. Como você pode reutilizar blocos de criação de conjuntos de permissões menores, pode evitar a criação de dezenas ou mesmo centenas de perfis para cada usuário e função de trabalho.
Propriedade do registro e filas
Cada registro deve ser de propriedade de um único usuário ou uma fila. O proprietário tem acesso ao registro com base nas Configurações de objeto do perfil do proprietário. Por exemplo, se o perfil do proprietário tiver a permissão Criar e Ler em um objeto, mas não a permissão Editar ou Excluir, o proprietário poderá criar um registro para o objeto e ver o novo registro. No entanto, o proprietário não poderá editar nem excluir o registro. Usuários superiores em uma hierarquia (papel ou território) herdam o mesmo acesso a dados que seus subordinados para objetos padrão. Se o subordinado tiver acesso somente leitura, os usuários acima dele na hierarquia de papéis também terão. Esse acesso se aplica a registros de propriedade dos usuários, bem como a registros compartilhados com eles.
As filas ajudam você a priorizar, distribuir e atribuir registros a equipes que compartilham cargas de trabalho. Membros da fila e usuários acima na hierarquia de papéis podem acessar filas de modos de exibição de lista e assumir a propriedade de registros em uma fila.
Se um único usuário tiver mais de 10 mil registros, como prática recomendada:
O registro de usuário do proprietário não deve conter um papel na hierarquia de papéis.
Se o registro do usuário do proprietário precisar conter um papel, coloque o papel no topo da hierarquia em sua própria ramificação da hierarquia de papéis.
Consulte Consulte Salesforce Well-Architected – Reliable para obter mais informações.
Padrões para toda a organização
As configurações de compartilhamento para toda a organização especificam o nível padrão de acesso que os usuários têm aos registros uns dos outros. Você usa as configurações de compartilhamento de toda a organização para bloquear seus dados no nível mais restritivo. Use as outras ferramentas de compartilhamento e segurança em nível de registro para dar acesso seletivamente a outros usuários. Por exemplo, os usuários têm permissões no nível do objeto para ler e editar oportunidades, e a configuração de compartilhamento para toda a organização é Somente leitura. Por padrão, esses usuários podem ler todos os registros de oportunidade, mas não podem editar nenhum, a menos que sejam proprietários do registro ou recebam outras permissões.
As configurações padrão para toda a organização podem ser alteradas de uma configuração para outra (Privado para Controlado pelo pai, então de volta para Privado). No entanto, essas alterações exigem recálculo de compartilhamento e, dependendo do volume, podem resultar em longos tempos de processamento.
Somente para objetos personalizados, você pode configurar a configuração Conceder acesso usando hierarquias. Se desmarcada (o padrão está marcado), os usuários acima na hierarquia de papéis serão impedidos de herdar o acesso. Essa configuração é encontrada nas configurações padrão de toda a organização.
Hierarquia de papéis
Uma hierarquia de papéis representa um nível de acesso a dados de que um usuário ou grupo de usuários precisa. A hierarquia de papéis garante que os gerentes sempre tenham acesso aos mesmos dados que seus funcionários, independentemente das configurações padrão de toda a organização. As hierarquias de papéis não precisam corresponder exatamente ao seu organograma. Em vez disso, cada papel na hierarquia deve representar um nível de acesso a dados de que um usuário ou grupo de usuários precisa.
Em organizações do Salesforce criadas na versão Spring '21 ou posterior, você pode criar até 5 mil papéis. Em organizações criadas antes da versão Spring '21, você pode criar até 500 papéis e entrar em contato com o Suporte ao cliente da Salesforce para aumentar esse limite. Como prática recomendada, mantenha o número de papéis internos para 25 mil e o número de papéis externos para 100 mil.
Como prática recomendada, mantenha a hierarquia de papéis para não mais de 10 níveis de ramificações na hierarquia.
Quando o papel de um usuário muda, todas as regras de compartilhamento relevantes são avaliadas para corrigir o acesso conforme necessário. Os colegas no mesmo papel não garantem acesso aos dados uns dos outros.
A modelagem da hierarquia de papéis começa com a compreensão de como a organização é estruturada. Isso geralmente é criado com base na compreensão do escopo de um gerente, começando do topo. O CEO supervisiona toda a empresa. O CEO normalmente tem subordinados diretos que podem ser segmentados por unidade de negócios (Vendas ou Suporte) ou região geográfica (EMEA, APAC). Essa pessoa então tem subordinados diretos que podem ser segmentados ainda mais, e assim por diante. Embora pareça muito como um gráfico organizacional de RH, ao modelar o acesso a dados, concentre-se na acessibilidade de dados com uma consideração para os relatórios de RH.
Sobreposições sempre são a parte complicada da hierarquia. Se eles estiverem em sua própria agência, precisarão de regras de compartilhamento, equipes ou gerenciamento de território para obter o acesso necessário. Se eles forem dobrados na hierarquia, talvez haja implicações de relatórios.
É importante passar o tempo configurando a hierarquia de papéis, pois é um dos aspectos fundamentais do modelo de compartilhamento.
| Casos de uso de hierarquia de papéis |
|---|
| Acesso de gerenciamento: a capacidade dos gerentes de ver e fazer o que seus subordinados podem ver e fazer. |
| Relatórios de gerenciamento – a capacidade de os relatórios serem totalizados de modo hierárquico para que qualquer pessoa acima da hierarquia veja mais dados do que aqueles abaixo deles. |
| Segregação entre ramificações organizacionais: diferentes unidades de negócios não precisam ver os dados umas das outras; ter uma hierarquia na qual você pode definir ramificações separadas permite que você segregue a visibilidade dentro de unidades de negócios, ao mesmo tempo que distribui a visibilidade até os níveis executivos acima dessas unidades. |
| Segregação dentro de um papel – em muitas organizações/aplicativos, as pessoas que desempenham todos o mesmo papel não devem necessariamente ver os dados umas das outras. Ter papéis hierárquicos permite que você defina um nó de "folha" em que todos os dados são essencialmente privados e ainda totalize esses dados para um papel pai que possa ver tudo. |
Grupos públicos
Um grupo público é uma coleção de usuários individuais, papéis, territórios e assim por diante, que todos têm uma função em comum. Grupos públicos podem consistir em:
Os grupos podem ser aninhados (Grupo A aninhado no Grupo B), mas não aninhe mais de cinco níveis. Aninhar tem impacto sobre a manutenção e o desempenho do grupo devido ao cálculo de associação ao grupo. Como prática recomendada, mantenha o número total de grupos públicos para uma organização para 100 mil.
| Casos de uso de grupo público |
|---|
| Quando você precisa fornecer acesso a um grupo arbitrário de pessoas, cria um grupo público para coletá-las e, em seguida, use outras ferramentas de compartilhamento para dar ao grupo o acesso necessário. Somente a associação ao grupo não fornece acesso a dados. |
| Os grupos também podem ser aninhados entre si, portanto, permitindo que um grupo aninhado obtenha o mesmo acesso que o grupo em que ele está contido. Isso permite a criação de hierarquias ad-hoc menores que não interagem necessariamente com as hierarquias de papel ou território. Se o Grupo A for membro do Grupo B, os membros do Grupo A terão acesso aos dados compartilhados com o Grupo B no mesmo nível de acesso que os membros do Grupo B. |
| Os grupos também podem proteger os dados compartilhados no grupo contra que sejam acessados por pessoas na hierarquia de papéis acima dos membros do grupo. Isso (e lidar com o acesso dos proprietários de registro e sua hierarquia de gerenciamento) permite a criação de grupos em que informações altamente confidenciais podem ser compartilhadas – os dados estarão acessíveis Apenas aos membros do grupo e ninguém mais na organização. Isso é feito usando a configuração Conceder acesso usando hierarquias. |
Regras de compartilhamento baseadas em proprietário
As regras de compartilhamento baseadas em proprietário permitem exceções às configurações padrão de toda a organização e à hierarquia de papéis que dão aos usuários acesso a registros que eles não possuem. As regras de compartilhamento baseadas em proprietário são baseadas apenas no proprietário do registro.
As regras de compartilhamento baseadas em proprietário do contato não se aplicam a contatos privados ou contatos que não estão associados a uma conta.
O limite total de regras de compartilhamento por objeto é de 300.
| Casos de uso de regra de compartilhamento baseado em proprietário |
|---|
| Situações de sobreposição ou gerenciamento de matriz baseado em papel: uma pessoa em Serviço deve poder ver alguns dados de Vendas, mas ela mora em ramificações diferentes da hierarquia para que você possa criar uma regra que compartilhe dados entre papéis em ramificações diferentes. |
| Para fornecer acesso a dados a colegas que têm o mesmo papel ou território. |
| Para fornecer acesso a dados a outros agrupamentos de usuários (grupos públicos, papéis do portal, territórios). Os membros dos agrupamentos que são proprietários dos registros podem ser compartilhados com os membros de outros agrupamentos. |
Regras de compartilhamento baseadas em critérios
As regras de compartilhamento baseadas em critérios dão acesso a registros com base nos valores de campo (critérios) do registro. Se os critérios forem atendidos (um ou muitos valores de campo), um registro de compartilhamento será criado para a regra. A propriedade do registro não é uma consideração.
O limite de regras de compartilhamento de usuário convidado e baseado em critérios por objeto é 50.
| Caso de uso de regra de compartilhamento baseado em critérios |
|---|
| Para fornecer acesso a dados a usuários ou grupos com base no valor de um campo no registro. |
Regras de compartilhamento de usuário convidado
Uma regra de compartilhamento de usuário convidado é um tipo especial de regra de compartilhamento baseada em critérios usada para conceder acesso de registro a usuários convidados não autenticados. O limite de regras de compartilhamento de usuário convidado e baseado em critérios por objeto é 50.
Aviso: O tipo de regra de compartilhamento de usuário convidado concede acesso a usuários convidados sem credenciais de login. Ao criar uma regra de compartilhamento de usuário convidado, você está permitindo acesso imediato e ilimitado a todos os registros que correspondem aos critérios da regra de compartilhamento a qualquer pessoa. Para proteger seus dados do Salesforce e dar aos usuários convidados acesso ao que eles precisam, considere todos os casos de uso e as implicações de criar esse tipo de regra de compartilhamento. Implemente os controles de segurança que você considera adequados para a confidencialidade dos seus dados. A Salesforce não é responsável por qualquer exposição de seus dados a usuários não autenticados com base nessa alteração em relação às configurações padrão.
| Caso de uso de regra de compartilhamento do usuário convidado |
|---|
| Para fornecer acesso a dados a usuários convidados não autenticados. |
Compartilhamento manual
Às vezes, é impossível definir um grupo consistente de usuários que precisam de acesso a um determinado conjunto de registros. Proprietários de registro ou outros usuários com privilégios adequados, como administradores do sistema, podem usar o compartilhamento manual para conceder permissões de leitura e edição a usuários que não têm acesso de outra forma. O compartilhamento manual não é automatizado, como configurações de compartilhamento de toda a organização, hierarquias de papéis ou regras de compartilhamento. Porém, oferece aos proprietários de registro a flexibilidade de compartilhar registros com os usuários que precisam vê-los.
O compartilhamento manual é removido quando o proprietário do registro muda ou quando o acesso de compartilhamento concedido não concede acesso adicional além do nível de acesso padrão de compartilhamento para toda a organização do objeto. Isso também se aplica a compartilhamentos manuais criados programaticamente.
Registros de compartilhamento manual são definidos como registros de compartilhamento com a causa da linha definida como compartilhamento manual.
Todos os registros de compartilhamento (objetos padrão e personalizados) com uma causa de linha definida como compartilhamento manual podem ser editados e excluídos pelo botão Compartilhar no layout de página do objeto, mesmo que o registro de compartilhamento tenha sido criado programaticamente.
| Caso de uso de compartilhamento manual |
|---|
| Para fornecer ao usuário a capacidade de conceder acesso (somente leitura ou leitura/gravação) ao registro atual a outros usuários, grupos ou papéis. |
Equipes
Uma equipe é um grupo de usuários que trabalham juntos em uma conta, oportunidade de vendas ou caso. Os proprietários de registro podem criar uma equipe para cada registro de sua propriedade. O proprietário do registro adiciona membros da equipe e especifica o nível de acesso que cada membro da equipe tem ao registro. Alguns membros da equipe podem ter acesso somente leitura, enquanto outros têm leitura/gravação.
Somente proprietários, pessoas superiores na hierarquia e administradores podem adicionar membros da equipe e dar mais acesso ao membro. Um membro da equipe com acesso de leitura/gravação pode adicionar outro membro que já tenha acesso ao registro ao qual a equipe está associada. O membro da equipe não pode dar a ele acesso adicional.
Criar um membro da equipe no aplicativo cria dois registros: um registro de equipe e um registro de compartilhamento associado. Se você criar membros da equipe programaticamente, terá que gerenciar o registro da equipe e o registro de compartilhamento associado. Há apenas uma equipe por registro (Conta, Oportunidade ou Caso). Se várias equipes forem necessárias, dependendo de suas necessidades específicas, considere o gerenciamento de território ou o compartilhamento programático
| Casos de uso da equipe |
|---|
| Para fornecer ao usuário a capacidade de conceder acesso (somente leitura ou leitura/gravação) a um único grupo de usuários (a equipe). |
| Se as equipes forem gerenciadas externamente, por exemplo, por meio de uma comissão externa ou sistema de gerenciamento de território, a integração poderá ser usada para gerenciar a equipe da conta. Há casos em que o gerenciamento de território em um sistema externo pode se alinhar a uma solução de equipe no Salesforce. |
| Vários proprietários de uma conta podem ser gerenciados pela equipe da conta. |
| Um único grupo de usuários (equipe) requer acesso somente leitura ou leitura/gravação a um registro de oportunidade. (Equipe de oportunidades) |
Hierarquia territorial
Ao usar o Gerenciamento de território Enterprise, você configura uma hierarquia de territórios que mostra a estrutura de território de um modelo e serve como seu principal ponto de interação. Se o Gerenciamento de território Enterprise estiver habilitado, você deverá gerenciar a hierarquia de papéis e a hierarquia de territórios. Para obter mais informações, consulte Gerenciamento de Território Enterprise na Ajuda do Salesforce.
Compartilhamento gerenciado do Apex
O compartilhamento gerenciado do Apex (também conhecido como compartilhamento programático) permite que você use código para criar configurações de compartilhamento sofisticadas e dinâmicas quando um requisito de acesso a dados não puder ser atendido por nenhum outro meio.
Se você criar um registro de compartilhamento programaticamente e a causa de linha pronta para uso (compartilhamento manual) for usada, poderá manter esse registro de compartilhamento com o botão Compartilhar no aplicativo. O registro de compartilhamento está sujeito a todas as regras com a causa da linha de compartilhamento manual, como exclusão após a transferência do proprietário.
Você também pode criar seus próprios motivos de compartilhamento do Apex para objetos personalizados para rastrear por que um registro com um usuário ou grupo de usuários e simplificar a codificação necessária para fazer atualizações e exclusões de registros de compartilhamento.
Para obter mais informações, revise Compartilhar um registro usando o Apex antes de considerar o uso de compartilhamento programático.
| Casos de uso de compartilhamento gerenciado do Apex |
|---|
| Nenhum outro método de compartilhamento (declarativo) atende às necessidades de acesso aos dados. |
| Há um sistema externo de verdade para atribuições de acesso do usuário que continuará a promover o acesso e a ser integrado ao Salesforce. |
| Desempenho ruim usando componentes de compartilhamento nativos. (Geralmente se aplica a volumes de dados muito grandes) |
| Funcionalidade da equipe em objetos personalizados. |
Regras de restrição
Em sua configuração de acesso a dados, talvez você queira impedir que os usuários vejam registros que podem conter dados confidenciais ou simplesmente não sejam essenciais para o trabalho deles. Você pode usar regras de restrição para permitir que os usuários acessem apenas registros que atendam aos critérios especificados. Quando uma regra de restrição é aplicada a um usuário, os registros aos quais o usuário recebe acesso por meio de padrões organizacionais, regras de compartilhamento e outros mecanismos de compartilhamento são filtrados por critérios que você especificar. As regras de restrição funcionam da maneira oposta aos componentes de compartilhamento discutidos neste tópico; em vez de abrir o acesso aos usuários, elas o restringem ainda mais.
As regras de restrição estão disponíveis para objetos personalizados, objetos externos, contratos, eventos, tarefas, quadros de horários e entradas de quadros de horários. Você pode criar até duas regras de restrição ativas por objeto nas edições Enterprise e Developer e até cinco regras de restrição ativas por objeto nas edições Performance e Unlimited. As regras de restrição são aplicadas aos seguintes recursos do Salesforce:
| Casos de uso de regra de restrição |
|---|
| Você deseja que determinados usuários vejam apenas um conjunto específico de registros. |
| Para simplificar o controle do acesso a registros com informações confidenciais ou confidenciais. |
| Para tornar o acesso a contratos, tarefas e eventos verdadeiramente privado, pois isso pode ser difícil de alcançar usando padrões para toda a organização. |
Compartilhamento implícito
O compartilhamento implícito é automático. Você não pode desativá-lo nem ativá-lo, ele é nativo do aplicativo. Em outras palavras, o compartilhamento implícito não é uma configuração configurável; no entanto, é importante para qualquer arquiteto entender. O compartilhamento implícito pai está fornecendo acesso a registros pai (somente conta) quando um usuário tem acesso a oportunidades filho, casos ou contatos para essa conta. O Salesforce tem uma política de acesso a dados que determina se um usuário pode ver um contato (ou oportunidade, caso ou pedido), então o usuário vê implicitamente a conta associada. O compartilhamento implícito filho está fornecendo acesso aos registros filhos de uma conta ao proprietário da conta. Esse acesso é definido no papel do proprietário na hierarquia de papéis. O compartilhamento implícito filho se aplica apenas a objetos de contato, oportunidade e caso (filhos da conta). Os níveis de acesso que podem ser fornecidos são Visualizar, Editar e Sem acesso para cada um dos objetos filhos quando o papel é criado. Ao configurar para Visualizar, o proprietário da conta pode ver implicitamente os registros de objeto associados (contato, oportunidade ou caso). Ao definir Editar, o proprietário da conta pode modificar implicitamente o objeto associado (contato, oportunidade ou caso).
O compartilhamento implícito não se aplica a objetos personalizados.
Não há um modelo de compartilhamento adequado a todas as organizações do Salesforce. Cada organização tem diferentes requisitos e desafios ao tentar arquivar o melhor modelo de compartilhamento. É crucial usar os componentes de acesso a dados mais adequados para atender aos requisitos de compartilhamento da organização. Os cenários a seguir são desafios comuns ao tentar arquitetar um modelo de compartilhamento.
| Requisitos ou desafios | Solução |
|---|---|
| Dois em uma caixa: um gerente de vendas de uma área de cobertura geográfica também quer acessar outra área de cobertura geográfica para ajudar. | Regra de compartilhamento baseada em proprietário: Uma regra de compartilhamento baseada em proprietário funciona aqui porque esses são casos de ponta e não a norma. Também é aceitável se a regra de compartilhamento baseada em proprietário fornecer mais acesso do que realmente necessário, pois esse é um gerente, um indivíduo confiável. |
| Os usuários de operações baseadas em país precisam de acesso a todos os dados de vendas do país. | Regra de compartilhamento baseada em proprietário: Um uso muito comum de uma regra de compartilhamento é quando um departamento diferente (além de vendas) precisa de acesso aos dados de vendas. |
| Pelo menos 80% das vezes, há uma equipe "núcleo 4" em uma conta (Executivo de conta, Representante de vendas interno, Consultor de vendas, Representante de vendas técnico). O sistema de registro para a atribuição da equipe da conta é externo. Sempre há apenas uma equipe para uma conta. | Equipes: Como sempre há apenas uma equipe por conta, mesmo que haja muitos membros diferentes com papéis diferentes, a funcionalidade da equipe da conta atende a esse requisito. |
| Os gerentes da equipe devem ter o mesmo acesso que seus subordinados. | Hierarquia de papéis: A hierarquia de papéis resolve esse requisito permitindo que os gerentes tenham acesso aos dados de seus subordinados. |
| A equipe da conta atribuída não deve ser modificável. | Equipes: Esse requisito não é realmente cumprido com a funcionalidade da equipe da conta. No entanto, isso também não deve impedir que você ainda use equipes da conta. No entanto, há várias maneiras de bloquear as equipes. Nesse caso, a remoção do layout de página da equipe da conta é usada. |
| Deve haver uma funcionalidade "amigável" para que, quando alguém estiver doente ou em férias, alguém sem acesso padrão a uma conta ou oportunidade possa ser acessado e coberto durante o tempo livre. | Equipes: Um "colega" pode simplesmente ser um papel na equipe que atende a esse requisito. No entanto, o desafio vem do requisito anterior em que o Teams não deve ser modificável. A única solução é ter um grupo definido de pessoas que possam modificar as equipes para criar o papel de colega quando necessário. |
| Quando um negócio exige uma solução personalizada, pessoas adicionais (que não estão necessariamente na organização de vendas) devem ter acesso ao negócio. | Equipes: Um uso bastante padrão da Equipe de oportunidades realizado adicionando manualmente um novo membro à Equipe de oportunidades (por meio da lista relacionada). Também pode ser realizada por meio de um acionador se você sempre souber quem deve ser adicionado. Neste caso, é oportunidade por oportunidade. |
| Requisitos ou desafios | Solução |
|---|---|
| Duas equipes de oportunidade diferentes de duas unidades de negócios distintas (Vendas de varejo e Remarketing) precisam de acesso ao mesmo registro de conta. Eles devem compartilhar contatos e estar ciente de todas as atividades na conta. Essas duas unidades de negócios têm sua própria hierarquia e totalizações. | Gerenciamento de território: A melhor maneira de pensar sobre esse requisito é ter duas ramificações de uma hierarquia que podem ser estruturadas de maneira diferente. O que justifica o gerenciamento de território é que há dois níveis dessas duas ramificações diferentes (ambos níveis com membros = a equipe de oportunidade para essa unidade de negócios) que precisam de acesso à conta. Embora você pudesse cumprir esse requisito com um conceito de Teaming, isso era muito granular. A segmentação de vendas não estava em um nível de conta, mas em uma hierarquia. |
| Há um grupo separado de desenvolvedores de negócios que são atribuídos e precisam de acesso a contas específicas para uma equipe de oportunidade específica (um território). Os desenvolvedores de negócios são recursos compartilhados para as equipes de oportunidade, o que significa que cada desenvolvedor de negócios pode ser atribuído a uma ou mais contas para uma ou mais equipes de oportunidade. | Gerenciamento de território: Como esse é um grupo de usuários (ou uma equipe) e cada equipe de desenvolvimento de negócios pode ser diferente por conta, e como o gerenciamento de território era necessário por outro motivo, a melhor abordagem provavelmente é criar subterritórios ou ramificações separadas que representem essas equipes de desenvolvimento de negócios. |
| Há papéis de suporte de vendas não baseados em comissão que precisam de acesso a contas de modo único. | Equipes: A parte principal do requisito é "base única". Isso significa que é feito em uma conta por conta, de modo que as equipes da conta fornecem isso nativamente. |
| O departamento de crédito precisa de acesso a todas as contas de uma determinada unidade de negócios. | Regra de compartilhamento baseada em proprietário: Esta é uma situação em que, em geral, para uma determinada unidade de negócios, um grupo de usuários deve ver tudo. Esse requisito pode ser cumprido com uma regra de compartilhamento para um papel ao qual o grupo pertence, uma ramificação da hierarquia de papéis à qual o grupo pertence (papel e subordinados) ou até mesmo um grupo público.Gerenciamento de território: Você também pode realizar esse requisito modelando o departamento de crédito como um território com a mesma lógica para a unidade de negócios fornecida. |
| Os gerentes devem ter o mesmo acesso que seus subordinados. | Hierarquia de papéis: A hierarquia de papéis resolve esse requisito permitindo que os gerentes tenham acesso aos dados de seus subordinados. |
O que acontece com a hierarquia de papéis?
Nada acontece com a hierarquia de papéis se você também estiver usando uma hierarquia de territórios. No entanto, se você estiver usando previsões baseadas em território e previsões baseadas em papel juntas, deverá gerenciar duas hierarquias. Nesse caso, recomendamos usar a hierarquia de papéis para modelar a estrutura de relatórios de RH e, em seguida, usar a hierarquia de territórios para modelar a hierarquia de vendas real. A hierarquia de territórios é melhor para modelar uma estrutura de relatórios de matriz, em que alguém pode gerar relatórios a vários gerentes.
Se você não estiver usando previsões baseadas em território e previsões baseadas em papel juntas, é possível usar apenas a hierarquia de territórios como a hierarquia de vendas. Nesse cenário, é melhor simplificar ou nivelar a hierarquia o máximo possível.
Não recomendamos tornar a hierarquia de papéis e a hierarquia de territórios idênticas porque isso causa atividade de compartilhamento desnecessária.
Você ainda pode usar equipes?
Realinhamento e reatribuição
Grandes volumes de dados
Não importa se você está modelando para a distribuição inicial ou planejando uma alteração de realinhamento, você deve considerar seriamente o volume de dados. Há limites em que o desempenho pode se tornar um fator, portanto, é altamente recomendável testar suas alterações em um sandbox antes da produção. Esse teste também fornecerá uma linha de base para quanto tempo a alteração levará.
Se você tiver mais de dois milhões de contas e tiver equipes implementadas ou Gerenciamento de Território Enterprise, você deverá prestar atenção especialmente ao desempenho. Esses são componentes de modelo de compartilhamento complexos que podem criar um grande volume de registros de compartilhamento e, portanto, transações de longa duração.
Adiar cálculos de compartilhamento
Skews de dados e propriedade
Os desvios de dados são definidos como alguns registros pai com muitos registros filhos. Esses desvios podem realmente magoar você quando algumas contas têm muitos contatos, oportunidades ou casos. A proporção em que começamos a ver a degradação de desempenho é de 1:10.000. Como prática recomendada, mantenha a proporção o mais próxima possível (preferencialmente menor).
Desvios de propriedade são semelhantes a desvios de dados, exceto que estamos se referindo a um único usuário, papel ou grupo que possui muitos registros para um objeto. Como acontece com distorções de dados, elas também podem causar transações em execução longa, causando uma degradação do desempenho quando ocorre uma alteração. A proporção recomendada de proprietário para número de registros também é de 1:10.000.
Se um único usuário tiver mais de 10 mil registros, como prática recomendada:
O registro de usuário do proprietário não deve conter um papel na hierarquia de papéis.
Se o registro do usuário do proprietário precisar conter um papel, coloque o papel no topo da hierarquia em sua própria ramificação da hierarquia de papéis.
Impacto das hierarquias de contas no acesso a dados
Depois de concluir sua arquitetura de modelo de compartilhamento, você provavelmente será questionado sobre por que um usuário pode ou não pode ver um registro. Geralmente, você não ouvirá quando os usuários poderão ver algo que não deveriam ver, mas, se necessário, há uma maneira de ver cada usuário que tem acesso a um registro e por quê.
O desafio mais difícil, e provavelmente mais comum, é por que um usuário não pode ver um registro. As camadas de segurança que você arquitetou determinam onde você começa. Se você conhece bem o modelo de compartilhamento, provavelmente saberá qual componente deveria ter fornecido o acesso e pode começar por aí. Porém, se você estiver menos familiarizado com o modelo de compartilhamento, comece com a hierarquia de papéis e despeje cada camada para determinar qual deve fornecer o acesso. Aqui está um fluxo de solução de problemas.
j
