Organization-Wide Defaults (OWD) no Salesforce, explicado

Os org-wide defaults são o ponto de partida de todas as decisões de partilha no Salesforce. Acerte neles e o resto do modelo — hierarquia de funções, sharing rules, partilhas — terá uma base sólida sobre a qual assentar. Erre neles (normalmente por serem demasiado abertos) e nenhuma quantidade de sharing rules engenhosas o irá corrigir. Este guia explica o que são e como defini-los bem.

O que são os org-wide defaults

Os Organization-Wide Defaults (OWD) definem o nível base de acesso que os utilizadores têm aos registos que não lhes pertencem, por objeto. São a definição mais restritiva; tudo o resto existe para abrir o acesso acima deste piso.

Os org-wide defaults são o piso. A hierarquia de funções e as sharing rules são as formas de elevar pessoas específicas acima dele. Nada padrão lhe permite descer abaixo dele.

É por isto que o OWD é a primeira camada no modelo de acesso aos registos.

Os níveis de acesso

O OWD de cada objeto é definido para um dos seguintes:

Nível	Quem pode ver / fazer o quê
Private	Apenas o proprietário (e os utilizadores acima dele na hierarquia de funções) pode visualizar
Public Read Only	Todos os que têm acesso ao objeto podem visualizar; só o proprietário pode editar
Public Read/Write	Todos os que têm acesso ao objeto podem visualizar e editar
Controlled by Parent	O acesso segue o registo master/parent relacionado

Alguns objetos oferecem variantes adicionais (por exemplo, Read/Write/Transfer para leads e cases).

Defaults internos vs. externos

Muitos objetos permitem definir org-wide defaults internos e externos separados. O default externo rege os utilizadores de Experience Cloud (comunidade) e de portal e pode — e normalmente deve — ser mais restritivo do que o interno, para que as audiências externas não herdem o acesso mais amplo que o seu pessoal tem.

Boa prática: começar restritivo, abrir de forma deliberada

A regra de ouro:

Defina o OWD para o nível mais restritivo que o negócio consegue tolerar — normalmente Private — e depois abra o acesso com a hierarquia de funções e as sharing rules.

A razão está na direção do modelo de partilha. O acesso é aditivo: pode sempre adicionar acesso sobre uma base Private, mas não pode usar sharing rules para subtrair o acesso que um OWD demasiado aberto já distribuiu a todos. Começar em Private mantém o modelo intencional, auditável e fácil de raciocinar.

Uma forma rápida de escolher

Para cada objeto, pergunte: deve um colaborador qualquer que não é proprietário deste registo conseguir vê-lo por defeito?

Não, nunca → Private.
Pode ler mas não alterar → Public Read Only.
Qualquer pessoa pode editá-lo livremente → Public Read/Write (raro para dados sensíveis).

Alterar um OWD depois de entrar em produção

Abrir um OWD (por exemplo, Private → Public Read Only) tem baixo risco — apenas concede mais acesso.
Restringir um OWD (Public → Private) é a alteração a planear. Desencadeia um recálculo de partilha e pode remover acesso de que os utilizadores dependem atualmente. Teste num sandbox e comunique antes de avançar.

Porque o OWD é a primeira coisa a auditar

Por ser a base sobre a qual todos os outros mecanismos assentam, um OWD demasiado aberto inflaciona silenciosamente aquilo que toda a gente consegue ver — e é invisível até alguém perguntar “espera, quem é que consegue ver todos estes?”. Quando reviu o acesso, o OWD é a base que explica as maiores surpresas.

O AgentForceAccess torna essa base legível: pergunte porque é que um utilizador consegue ver um registo e ele indica-lhe quando a resposta é simplesmente “o org-wide default é Public” — em contraste com uma regra específica ou uma partilha — para que corrija a causa na camada certa.

Perguntas frequentes

O que significa cada nível de acesso do OWD?

Private — apenas o proprietário e os utilizadores acima dele na hierarquia de funções conseguem ver o registo. Public Read Only — todos os que têm acesso ao objeto podem visualizar, mas só o proprietário pode editar. Public Read/Write — todos podem visualizar e editar. Controlled by Parent — o acesso segue o registo master relacionado.

Porque devo começar com Private?

Porque a partilha é aditiva: pode sempre abrir o acesso com a hierarquia de funções e as sharing rules, mas não pode usá-las para retirar um acesso que um OWD demasiado aberto já concedeu. Começar em Private e alargar de forma deliberada mantém o modelo intencional e auditável.

O que são os org-wide defaults internos vs. externos?

Muitos objetos permitem definir um default separado para utilizadores externos — utilizadores de Experience Cloud / comunidade e portal — que pode ser mais restritivo do que o default interno. Isto evita que audiências externas herdem o acesso que os seus utilizadores internos têm.

Posso reduzir o acesso de um objeto depois de entrar em produção?

Sim, mas restringir um OWD desencadeia um recálculo de partilha e pode remover acesso de que as pessoas dependem atualmente, por isso teste num sandbox e comunique a alteração. Abrir um OWD tem baixo risco; restringi-lo é a alteração a planear com cuidado.