Restriction rules vs scoping rules vs sharing rules
As sharing rules abrem o acesso, as restriction rules reduzem-no e as scoping rules apenas definem a vista por omissão. Em que diferem e quando usar cada uma.
A maior parte do modelo de partilha do Salesforce só sabe abrir o acesso. As restriction rules e as scoping rules são as ferramentas mais recentes que mudam isso — mas fazem coisas muito diferentes e é fácil confundi-las. Eis como as três se relacionam.
O mapa numa linha
- Sharing rules — abrem o acesso. Concedem registos a utilizadores que de outra forma não os veriam.
- Restriction rules — reduzem o acesso. Filtram registos que um utilizador, de outra forma, teria permissão para ver.
- Scoping rules — focam a vista. Mudam que registos aparecem por omissão, sem alterar o acesso.
Duas destas afetam a segurança; uma não. É essa a distinção a manter clara.
Sharing rules: abrir o acesso
As sharing rules assentam por cima do org-wide default e concedem acesso adicional por propriedade ou por critérios. Só conseguem alargar o acesso — nunca estreitá-lo. Se precisar de relembrar como se comparam com a hierarquia, consulte sharing rules vs hierarquia de funções.
Este é o comportamento aditivo, em que vence a opção mais permissiva, que está no cerne do modelo de acesso a registos.
Restriction rules: reduzir o acesso
As restriction rules são a exceção ao princípio “a partilha do Salesforce só abre o acesso”. Uma restriction rule define que registos um utilizador tem permissão para ver e é aplicada por cima de tudo o que o modelo de partilha concedeu — filtrando, na prática, o resultado.
Se o org-wide default, a hierarquia de funções e as sharing rules em conjunto mostrassem a um utilizador 10 000 registos, uma restriction rule pode estreitar isso para o subconjunto que corresponde aos seus critérios.
Exemplo. Os agentes de suporte têm acesso alargado a Cases através de uma sharing rule, mas os contratados entre eles só deveriam ver casos não confidenciais. Uma restriction rule em Case — Confidential = false para o permission set dos contratados — remove os confidenciais daquilo que conseguem ver, mesmo que a partilha, tecnicamente, lhos tenha concedido.
É esta a ferramenta a que recorrer quando a pergunta é “como é que eu retiro acesso”.
Scoping rules: foco, não segurança
As scoping rules controlam que registos aparecem por omissão em list views, pesquisas e relatórios — com base em condições como proprietário, função ou região. Fundamentalmente:
As scoping rules não limitam o acesso. Um utilizador pode mudar o âmbito para “todos os registos a que tenho acesso” e ver tudo o que a partilha lhe concede.
São uma funcionalidade de produtividade: mostram primeiro a um representante atarefado a sua própria região, sem o obrigar a isso. Se um utilizador tiver de ser impedido de ver registos, as scoping rules são a ferramenta errada — use restriction rules.
Lado a lado
| Sharing rules | Restriction rules | Scoping rules | |
|---|---|---|---|
| Efeito no acesso | Abre | Reduz | Nenhum |
| Controlo de segurança? | Sim | Sim | Não (apenas foco) |
| O utilizador pode sobrepor-se? | Não | Não | Sim (mudar âmbito) |
| Direção | Adicionar acesso | Remover acesso | Filtrar vista por omissão |
| Limite típico | Muitas | ~2 ativas/objeto | ~2 ativas/objeto |
Combinando-as
Um objeto realista pode usar as três: um OWD Private, sharing rules para dar às equipas o acesso de que precisam, uma restriction rule para isolar um subconjunto sensível dos contratados e uma scoping rule para que cada utilizador aterre na sua própria região por omissão. Cada uma faz um trabalho; em conjunto, moldam tanto o que os utilizadores podem ver como o que veem primeiro.
O senão: o acesso efetivo é a soma
Sobrepor ferramentas que abrem, que reduzem e que focam torna a pergunta “o que é que este utilizador consegue mesmo ver?” genuinamente difícil de responder por inspeção — concessões de partilha menos filtros de restrição, ignorando o scoping. É exatamente esse o cálculo que a AgentForceAccess faz por si: pergunte ao que um utilizador consegue realmente aceder e ela tem em conta a partilha que o concede e as restriction rules que o reduzem, em linguagem simples.
Perguntas frequentes
Qual é a diferença numa só linha?
As sharing rules concedem acesso que um utilizador não tinha, as restriction rules retiram acesso que um utilizador tinha e as scoping rules apenas pré-filtram as list views e as pesquisas sem afetar o acesso de forma alguma.
Pode uma restriction rule sobrepor-se a uma sharing rule ou à hierarquia de funções?
Sim. As restriction rules aplicam-se por cima do modelo de partilha e filtram os registos que um utilizador pode ver, mesmo os que o org-wide default, a hierarquia de funções ou as sharing rules de outra forma exporiam. São a forma de reduzir genuinamente o acesso no Salesforce.
As scoping rules ocultam registos por motivos de segurança?
Não. As scoping rules apenas alteram o conjunto de registos mostrado por omissão em list views, pesquisas e relatórios. Um utilizador pode mudar o âmbito para "todos os registos a que tenho acesso", pelo que se trata de foco e produtividade, não de segurança. Use restriction rules quando o acesso tiver mesmo de ser limitado.
Existem limites para estas regras?
Sim. As restriction rules e as scoping rules estão, normalmente, limitadas a um máximo de 2 regras ativas por objeto e estão disponíveis para objetos personalizados e para uma seleção de objetos standard, como Account, Case, Contact, Event, Lead, Opportunity e Task. Verifique os limites atuais para a sua edição.
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