ProfilesPermission setsAdministração Salesforce

Profiles vs permission sets vs sharing rules no Salesforce

Profiles e permission sets controlam o acesso a objetos e campos; as sharing rules controlam que registos. Como o modelo de dupla verificação decide.

AgentForceAccess 3 min de leitura
Uma chave a passar por dois portões: uma grelha de permissões de campo e depois um portão com a forma de um registo

“Profiles vs permission sets vs sharing rules” baralha as pessoas porque os três não são alternativas — respondem a perguntas diferentes e funcionam em conjunto. Os profiles e os permission sets decidem o que pode fazer a um objeto; as sharing rules decidem a que registos o pode fazer. Eis como se combinam.

O modelo de dupla verificação

Cada acesso a um registo no Salesforce passa por duas verificações independentes:

  1. Verificação de objeto e campo — vinda dos profiles e dos permission sets: o utilizador tem CRUD sobre o objeto e field-level security sobre os campos?
  2. Verificação de registo — vinda do modelo de partilha: os org-wide defaults, a hierarquia de roles ou uma sharing rule concedem este registo específico?

A permissão de objeto é o portão. A partilha decide que registos passam por ele. Ambas têm de passar.

Esta é a base de todo o modelo de acesso a registos.

Profiles e permission sets: o “o que pode fazer”

Estes controlam o acesso ao nível do objeto e muito mais:

  • CRUD por objeto (Read / Create / Edit / Delete).
  • Field-level security — que campos são visíveis/editáveis.
  • Permissões de sistema, visibilidade de apps e separadores, e os contorna-acessos View All / Modify All.

Profile vs permission set

  • Um utilizador tem exatamente um profile — historicamente, a base das permissões.
  • Um utilizador pode ter muitos permission sets (e permission set groups) sobrepostos.

A abordagem moderna e recomendada é liderada pelos permission sets: manter o profile minimalista e conceder acesso através de permission sets, porque são mais fáceis de atribuir, reutilizar e auditar do que uma profusão de profiles. (As roles, em contraste, comandam a hierarquia de partilha — um eixo distinto dos profiles.)

Sharing rules: o “que registos”

As sharing rules não tocam de todo no acesso a objetos ou campos. Apenas alargam o acesso ao nível do registo — por propriedade ou por critérios — por cima do org-wide default. Para perceber como se relacionam com a hierarquia, veja sharing rules vs hierarquia de roles.

Fundamental: uma sharing rule não pode salvar uma permissão de objeto em falta. Sem Read em Opportunities, não há oportunidades, por muitas sharing rules que apontem para o utilizador.

Onde as permissões se sobrepõem à partilha

Há um ponto em que as camadas se cruzam: View All e Modify All (ao nível do objeto), e View All Data / Modify All Data (a nível de todo o sistema). Estas contornam totalmente o modelo de partilha — um utilizador que as possua vê todos os registos, independentemente dos OWD, da hierarquia ou das rules. Por serem tão poderosas, são a primeira coisa a verificar quando o acesso parece errado. Veja View All / Modify All — o contorno a vigiar.

Juntando tudo

PerguntaRespondida por
O utilizador pode sequer abrir este objeto?Profile / permission set (CRUD)
Pode ver este campo?Field-level security
Que registos do objeto pode ver?Modelo de partilha
Pode contornar a partilha?View All / Modify All

Para perceber porque é que um utilizador consegue ou não chegar a um registo, lê-se ambos os eixos em conjunto — permissões de objeto/campo e a partilha que se aplica a esse registo.

Ler os dois eixos ao mesmo tempo

O atrito está em que estes vivem em partes diferentes da configuração — os profiles e os permission sets num sítio, o modelo de partilha noutro — e é preciso intersetá-los mentalmente. O AgentForceAccess faz essa interseção por si: pergunte o que um utilizador pode fazer com um registo e ele contabiliza as permissões de objeto, a field-level security e o modelo de partilha em conjunto, citando exatamente o que concede ou bloqueia o acesso.

Perguntas frequentes

Qual é a diferença entre acesso ao objeto e acesso ao registo?

O acesso ao objeto (vindo dos profiles e permission sets) decide se um utilizador pode sequer tocar num objeto — Read, Create, Edit, Delete — e que campos vê. O acesso ao registo (o modelo de partilha) decide que registos específicos desse objeto ele pode ver. São precisos os dois.

Profiles ou permission sets — qual devo usar?

Existem ambos, mas a abordagem moderna é liderada pelos permission sets: manter os profiles minimalistas como base e conceder acesso adicional através de permission sets e permission set groups. Um utilizador tem um profile, mas pode ter muitos permission sets, o que torna o acesso mais fácil de atribuir e auditar.

As sharing rules concedem acesso ao objeto?

Não. As sharing rules apenas alargam o acesso ao nível do registo. Se um utilizador não tiver permissão Read num objeto através do seu profile ou de um permission set, nenhuma sharing rule lhe mostrará um único registo. A permissão de objeto é o portão; a partilha decide que registos passam por ele.

Como é que um profile se pode sobrepor a uma sharing rule?

Através de View All e Modify All. Estas permissões — ao nível do objeto, ou "View All Data"/"Modify All Data" a nível de todo o sistema — permitem que um utilizador veja ou edite todos os registos, independentemente da partilha. Situam-se acima do modelo de partilha, pelo que uma permissão se pode sobrepor àquilo que a partilha restringiria.

Veja na sua própria org

O AgentForceAccess explica, em linguagem clara, porque é que qualquer utilizador vê qualquer registo ou ficheiro — em todos os mecanismos de partilha do Salesforce.

Pedir acesso antecipado