Sharing rules vs. role hierarchy no Salesforce: a diferença

A role hierarchy e as sharing rules são os dois mecanismos a que os administradores mais recorrem — e os dois que mais frequentemente se confundem. Ambos alargam o acesso a registos, mas em direções diferentes e por razões diferentes. Acertar nesta distinção é a diferença entre um modelo de partilha limpo e um emaranhado de regras sobrepostas.

A diferença numa linha

• Role hierarchy — concede acesso de forma automática e vertical: qualquer pessoa acima do proprietário do registo no organigrama herda o acesso do proprietário.
• Sharing rules — concedem acesso de forma deliberada e horizontal: a pares, a outras equipas ou a grupos que a hierarquia nunca ligaria, com base na propriedade ou em critérios de campo.

Ambas assentam sobre o org-wide default e só podem abrir o acesso, nunca o restringir. (Veja todas as camadas em quem pode ver um registo.)

Role hierarchy: o acesso sobe na hierarquia

Quando Grant Access Using Hierarchies está ativado para um objeto, os gestores herdam automaticamente o acesso aos registos detidos por — ou partilhados com — utilizadores abaixo deles. Sem regra, sem configuração por registo.

Exemplo. Um org-wide default Private em Opportunities. Um comercial é dono de um negócio. O seu gestor, e o VP do gestor, conseguem vê-lo automaticamente porque estão acima do comercial na hierarquia. É a role hierarchy a fazer o seu trabalho.

Isto é perfeito para a visibilidade gestor-vê-equipa e é também a fonte mais comum de surpresas do tipo “porque é que conseguem ver isto?” — porque ninguém o configurou registo a registo.

Sharing rules: o acesso abre-se lateralmente

As sharing rules estendem o acesso através da hierarquia, a utilizadores que o organigrama mantém separados. Duas variantes:

• Baseadas na propriedade (ownership-based) — partilham registos detidos por um grupo (role, public group, território) com outro grupo.
• Baseadas em critérios (criteria-based) — partilham registos que correspondem a valores de campo (por exemplo, Region = EMEA) com um grupo, role ou território.

Exemplo. As vendas EMEA e APAC são ramos separados da hierarquia, por isso nenhum vê os negócios do outro. Uma regra baseada em critérios — Region = EMEA → partilhar Read com o grupo APAC Leadership — abre exatamente esse acesso entre ramos sem mexer na hierarquia.

Quando usar cada uma

Necessidade	Usar
Gestores veem os registos da sua equipa	Role hierarchy
O acesso segue as linhas hierárquicas automaticamente	Role hierarchy
Duas equipas pares têm de ver os registos uma da outra	Sharing rule (ownership-based)
Partilhar registos que correspondem a critérios de campo (região, tipo, fase)	Sharing rule (criteria-based)
Partilhar com um public group ou território	Sharing rule
Acesso pontual a um único registo	Manual share (nenhuma das anteriores)

Elas acumulam-se — e é aí que está a armadilha

Como o acesso é aditivo e vence a permissão mais ampla, a role hierarchy e as sharing rules combinam-se. Um utilizador pode obter acesso a um registo através da hierarquia e através de duas sharing rules ao mesmo tempo. Nenhuma se sobrepõe às outras; qualquer uma delas é suficiente.

É também por isso que se instala uma partilha demasiado abrangente: cada regra parece razoável isoladamente, mas é a união entre hierarquia + regras + manual shares que um utilizador realmente vê — e ninguém tem essa imagem completa na cabeça.

Nenhuma restringe — por design

Se precisar de reduzir o acesso, as sharing rules e a role hierarchy não ajudam. Aperte o org-wide default, ou use restriction rules. Acrescentar mais uma sharing rule só pode abrir mais acesso.

Ver o efeito combinado

A parte difícil não é nenhum dos mecanismos — é a sua soma. Para saber porque é que um utilizador vê um registo, tem de avaliar a hierarquia e todas as sharing rules aplicáveis e os manual shares em conjunto.

O AgentForceAccess calcula essa união por si: pergunte porque é que um utilizador consegue ver um registo e ele diz-lhe se é a role hierarchy, uma sharing rule específica, ou ambas — em linguagem clara, com o mecanismo identificado.

Perguntas frequentes

Qual é a diferença essencial numa frase?

A role hierarchy abre o acesso para cima e automaticamente ao longo das linhas hierárquicas, enquanto as sharing rules abrem o acesso lateralmente e de forma intencional, a utilizadores que uma hierarquia nunca ligaria.

Se ambas pudessem conceder acesso ao mesmo registo, qual prevalece?

Não importa — o acesso no Salesforce é aditivo e vence a permissão mais ampla. Se a role hierarchy ou uma sharing rule conceder acesso, o utilizador tem acesso. Nunca é preciso que ambas "concordem".

Uma sharing rule pode retirar acesso?

Não. As sharing rules e a role hierarchy só podem estender o acesso acima do org-wide default. Para reduzir o acesso altera-se o org-wide default, ou usam-se restriction rules — não sharing rules.

Ainda preciso de sharing rules se a minha role hierarchy estiver bem construída?

Normalmente sim. Uma hierarquia só exprime acesso vertical, de gestor sobre subordinado. No momento em que duas equipas pares, ou um role noutro ramo, precisam de ver os registos uma da outra, só uma sharing rule consegue exprimir isso.