Quem vê um registo no Salesforce? Como o acesso é decidido

Se administrar uma org de Salesforce durante tempo suficiente, mais cedo ou mais tarde alguém perguntará: “Como é que esta pessoa consegue ver aquele registo?” A resposta honesta é que o Salesforce nunca decide a visibilidade de um registo num único sítio. Sobrepõe vários mecanismos uns aos outros e concede a união de todos eles.

Este guia percorre cada camada pela ordem em que o Salesforce a avalia, para que possa raciocinar sobre qualquer questão de “quem vê o quê” a partir dos primeiros princípios.

A única regra que explica tudo

A partilha no Salesforce é aditiva e prevalece a mais permissiva. Parte-se do nível mínimo definido pelos org-wide defaults e, a partir daí, todos os outros mecanismos só podem adicionar acesso por cima. Nada no modelo de partilha padrão retira acesso.

Por isso, quando estiver a investigar por que motivo um utilizador vê um registo, nunca está à procura da regra que o permite e de uma regra que o bloqueia. Está à procura de uma única concessão — porque uma basta.

Se nem que seja um mecanismo conceder acesso, o utilizador tem acesso. Ponto final.

Camada 1 — As permissões de objeto decidem se, não quais

Antes de a partilha ser sequer considerada, o utilizador precisa de acesso ao nível do objeto através do seu perfil ou conjuntos de permissões:

Read / Create / Edit / Delete no objeto.
View All ou Modify All no objeto, que ignoram completamente a partilha desse objeto.

Se um utilizador não tiver permissão Read em Opportunities, nenhuma regra de partilha do mundo lhe mostrará uma oportunidade. As permissões de objeto são o portão; o modelo de partilha é o que acontece depois de o atravessar.

Camada 2 — Os org-wide defaults definem o limite mínimo

Os org-wide defaults (OWD) definem o nível mais restritivo para cada objeto:

Private — só o proprietário do registo (e quem está acima dele na hierarquia de funções) o pode ver.
Public Read Only — todos podem visualizar, só o proprietário pode editar.
Public Read/Write — todos podem visualizar e editar.

Tudo o que se segue existe para alargar o acesso acima deste limite mínimo a pessoas específicas.

Camada 3 — A hierarquia de funções propaga o acesso para cima

Se a opção Grant Access Using Hierarchies estiver ativada para o objeto, qualquer pessoa acima do proprietário do registo na hierarquia de funções herda o acesso do proprietário. É por isto que um gestor de vendas vê os negócios dos seus comerciais sem qualquer regra explícita — e é, isoladamente, a razão mais comum para acessos inesperados.

Camada 4 — As regras de partilha abrem o acesso lateralmente

As regras de partilha estendem o acesso através da hierarquia, a pares e a outros ramos:

Baseadas na propriedade — partilham os registos detidos por um grupo de utilizadores com outro grupo.
Baseadas em critérios — partilham os registos que correspondem a valores de campos (por exemplo, Region = EMEA) com um grupo, função ou território.

Ambas concedem acesso a um grupo de utilizadores de uma só vez, o que torna uma regra baseada em critérios demasiado abrangente num culpado frequente quando “demasiadas” pessoas conseguem ver algo.

Camada 5 — Partilhas manuais e implícitas

Partilha manual — o botão Share num registo, que concede a um utilizador ou grupo específico acesso a esse único registo.
Partilha implícita — comportamento incorporado, como o acesso a uma conta-mãe que implica acesso limitado aos seus casos e contactos filhos.
Apex managed sharing — partilhas programáticas criadas por código personalizado, muitas vezes as mais difíceis de detetar.

Camada 6 — Equipas e territórios

As equipas de Account, Opportunity e Case concedem acesso a esse registo aos membros da equipa listados.
O Enterprise Territory Management concede acesso com base nos territórios a que um utilizador e um registo pertencem.

Juntando tudo: como rastrear qualquer acesso

Para responder a “por que motivo este utilizador vê este registo”, verifique cada camada até encontrar uma concessão:

O utilizador tem Read no objeto (ou View All) através do perfil/conjunto de permissões?
O OWD já é público para este objeto?
Está acima do proprietário na hierarquia de funções?
Alguma regra de partilha o inclui?
Existe uma partilha manual, implícita ou em Apex?
Está numa equipa, ou num território correspondente?

O primeiro “sim” é a sua resposta — e lembre-se de que pode haver mais do que um. Para a versão passo a passo deste rastreio, consulte um utilizador consegue ver um registo que não devia; o mesmo modelo rege quem pode ver um ficheiro, uma vez que os ficheiros herdam o acesso do registo.

É exatamente este o trabalho que o AgentForceAccess automatiza: pergunte em linguagem corrente por que motivo um utilizador vê um registo, e ele rastreia todas as camadas acima e cita a concessão exata que o permite.

Perguntas frequentes

Um System Administrator ignora o modelo de partilha?

Sim. As permissões "View All Data" e "Modify All Data" — atribuídas por defeito ao perfil System Administrator — ignoram por completo os org-wide defaults, as regras de partilha e a hierarquia de funções. As permissões de objeto "View All" / "Modify All" fazem o mesmo para um único objeto.

Se duas regras de partilha se aplicarem ao mesmo registo, qual prevalece?

A mais permissiva. O acesso no Salesforce é aditivo: concede a união de todas as regras aplicáveis. O acesso nunca pode ser reduzido por se adicionar outra regra — apenas alargado.

Porque é que um gestor vê registos que nunca lhe foram atribuídos explicitamente?

A hierarquia de funções concede aos gestores acesso aos registos detidos por (ou partilhados com) utilizadores abaixo deles na hierarquia, desde que a opção "Grant Access Using Hierarchies" esteja ativada para esse objeto.

As permissões de objeto e as definições de partilha fazem a mesma coisa?

Não. As permissões de objeto (nos perfis e conjuntos de permissões) decidem se um utilizador pode aceder a um objeto e o que pode fazer com ele. O modelo de partilha decide que registos específicos desse objeto pode ver.