Restriction rulesScoping rulesAdministração Salesforce

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.

AgentForceAccess 3 min de leitura
Três portais luminosos: um a abrir o acesso, outro a afunilá-lo e outro a destacar um subconjunto

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 rulesabrem o acesso. Concedem registos a utilizadores que de outra forma não os veriam.
  • Restriction rulesreduzem o acesso. Filtram registos que um utilizador, de outra forma, teria permissão para ver.
  • Scoping rulesfocam 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 rulesRestriction rulesScoping rules
Efeito no acessoAbreReduzNenhum
Controlo de segurança?SimSimNão (apenas foco)
O utilizador pode sobrepor-se?NãoNãoSim (mudar âmbito)
DireçãoAdicionar acessoRemover acessoFiltrar vista por omissão
Limite típicoMuitas~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