Organization-Wide Defaults (OWD) en Salesforce, explicados
Qué son los valores predeterminados (OWD), sus niveles de acceso, los defaults internos frente a externos y por qué todo solo abre acceso sobre esa base.
Los valores predeterminados de toda la organización son el punto donde empieza cada decisión de uso compartido en Salesforce. Acierta con ellos y el resto del modelo —jerarquía de funciones, reglas de uso compartido, recursos compartidos— tendrá unos cimientos limpios sobre los que construir. Equivócate (normalmente por dejarlos demasiado abiertos) y ninguna regla de uso compartido ingeniosa lo arreglará. Esta guía explica qué son y cómo configurarlos bien.
Qué son los valores predeterminados de toda la organización
Los Organization-Wide Defaults (OWD) definen el nivel base de acceso que tienen los usuarios a los registros que no son suyos, por objeto. Son el ajuste más restrictivo; todo lo demás existe para abrir acceso por encima de ese suelo.
Los valores predeterminados de la organización son el suelo. La jerarquía de funciones y las reglas de uso compartido son las formas de elevar a personas concretas por encima de él. Nada estándar te permite bajar por debajo.
Por eso el OWD es la primera capa del modelo de acceso a registros.
Los niveles de acceso
El OWD de cada objeto se establece en uno de estos valores:
| Nivel | Quién puede ver / qué puede hacer |
|---|---|
| Private | Solo el propietario (y los usuarios por encima de él en la jerarquía de funciones) pueden ver |
| Public Read Only | Cualquiera con acceso al objeto puede ver; solo el propietario puede editar |
| Public Read/Write | Cualquiera con acceso al objeto puede ver y editar |
| Controlled by Parent | El acceso sigue al registro maestro/principal relacionado |
Algunos objetos ofrecen variantes adicionales (p. ej. Read/Write/Transfer para leads y casos).
Defaults internos frente a externos
Muchos objetos permiten establecer valores predeterminados de la organización internos y externos por separado. El default externo rige para los usuarios de Experience Cloud (comunidad) y de portal, y puede —y normalmente debería— ser más restrictivo que el interno, para que las audiencias externas no hereden el acceso más amplio que tiene tu personal.
Buena práctica: empezar restrictivo, abrir de forma deliberada
La regla de oro:
Establece el OWD en el nivel más restrictivo que el negocio pueda tolerar —normalmente Private— y luego abre el acceso con la jerarquía de funciones y las reglas de uso compartido.
La razón es la dirección del modelo de uso compartido. El acceso es aditivo: siempre puedes añadir acceso sobre una base Private, pero no puedes usar las reglas de uso compartido para restar el acceso que un OWD demasiado abierto ya ha repartido a todo el mundo. Empezar con Private mantiene el modelo intencional, auditable y fácil de razonar.
Una forma rápida de decidir
Para cada objeto, pregúntate: ¿debería un empleado cualquiera que no es propietario de este registro verlo por defecto?
- No, nunca → Private.
- Pueden leerlo pero no cambiarlo → Public Read Only.
- Cualquiera puede editarlo libremente → Public Read/Write (poco habitual para datos sensibles).
Cambiar un OWD después de la puesta en producción
- Abrir un OWD (p. ej. Private → Public Read Only) tiene poco riesgo: solo concede más acceso.
- Endurecer un OWD (Public → Private) es el cambio que hay que planificar. Desencadena un recálculo de uso compartido y puede retirar acceso del que los usuarios dependen actualmente. Pruébalo en un sandbox y comunícalo antes de publicarlo.
Por qué el OWD es lo primero que hay que auditar
Como todos los demás mecanismos se construyen sobre él, un OWD demasiado abierto infla en silencio lo que todo el mundo puede ver, y resulta invisible hasta que alguien pregunta «un momento, ¿quién puede ver todo esto?». Cuando revisas el acceso, el OWD es la base que explica las mayores sorpresas.
AgentForceAccess hace que esa base sea legible: pregunta por qué un usuario puede ver un registro y te dice cuándo la respuesta es simplemente «el valor predeterminado de la organización es Public» —en lugar de una regla o un recurso compartido concreto— para que corrijas la causa en la capa adecuada.
Preguntas frecuentes
¿Qué significa cada nivel de acceso del OWD?
Private: solo el propietario y los usuarios por encima de él en la jerarquía de funciones pueden ver el registro. Public Read Only: cualquiera con acceso al objeto puede verlo, solo el propietario puede editarlo. Public Read/Write: todos pueden ver y editar. Controlled by Parent: el acceso sigue al registro maestro relacionado.
¿Por qué debería empezar con Private?
Porque el uso compartido es aditivo: siempre puedes abrir el acceso con la jerarquía de funciones y las reglas de uso compartido, pero no puedes usarlas para recuperar el acceso que un OWD demasiado abierto ya concedió. Empezar con Private y ampliar de forma deliberada mantiene el modelo intencional y auditable.
¿Qué son los valores predeterminados internos frente a los externos?
Muchos objetos permiten establecer un default distinto para los usuarios externos —usuarios de Experience Cloud / comunidad y portal— que puede ser más restrictivo que el default interno. Esto evita que las audiencias externas hereden el acceso que tienen tus usuarios internos.
¿Puedo reducir el acceso de un objeto después de estar en producción?
Sí, pero endurecer un OWD desencadena un recálculo de uso compartido y puede retirar acceso del que la gente depende ahora, así que pruébalo en un sandbox y comunica el cambio. Abrir un OWD tiene poco riesgo; restringir uno es el cambio que hay que planificar con cuidado.
Míralo en tu propia organización
AgentForceAccess explica, en lenguaje claro, por qué cualquier usuario puede ver cualquier registro o archivo, recorriendo todos los mecanismos de colaboración de Salesforce.
Solicitar acceso anticipado