Propiedad y ciclo de vida

🌐 También en 28 idiomas

English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 8 de 10 del capítulo Arquitectura de datos de Salesforce, capítulo 3 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Las relaciones tienen consecuencias · Siguiente: Mantener los datos consistentes

La pregunta que responde este módulo: ¿Quién es dueño del registro y qué le pasa a lo largo de su vida?

Cuando miro un modelo de datos, no solo quiero saber cuáles son los objetos y cómo se conectan. Quiero saber qué les pasa a los registros con el tiempo. ¿Quién los crea? ¿Quién es su dueño? ¿Quién puede reasignarlos? ¿Qué pasa cuando cambia la relación de negocio, cuando dejan de estar activos? ¿Deberían eliminarse alguna vez, y cuánto tiempo los conservamos? Nada de eso aparece en un diagrama entidad-relación (ERD): las cajas y líneas del modelo de datos del capítulo 2. Todo es arquitectura de datos. Y en Salesforce, la propiedad es donde el modelo de datos y el modelo de seguridad chocan.

La propiedad es más que un nombre en un campo

Los administradores ven Propietario en un registro y lo leen como una etiqueta: Bart es dueño de esta cuenta, Lisa es dueña de ese caso. Puede significar eso. Pero en Salesforce la propiedad también es un mecanismo de la plataforma. En los objetos que tienen propietario, el propietario determina quién puede ver el registro mediante la jerarquía de funciones, las reglas de uso compartido, las colas y la reasignación. Así que cuando pregunto “¿quién es dueño de este registro?”, no pregunto qué nombre va en la página. Pregunto qué comportamiento de seguridad y de ciclo de vida le estamos asociando. El propietario puede ser un usuario o, en algunos objetos (entre ellos los objetos personalizados, los casos y los candidatos), una cola, y en cualquier caso el propietario obtiene acceso total al registro (Understanding Sharing (opens in a new tab), en inglés).

Por eso separo la responsabilidad de negocio de la propiedad del registro. A veces son la misma persona. A veces no. Si el negocio dice que un despachador es responsable de una entrega, eso no convierte automáticamente al despachador en propietario. La responsabilidad puede vivir en su propio campo mientras la propiedad se establece para sostener la seguridad y la escala. No dejes que se confundan solo porque las dos usan la palabra “dueño”.

La tabla de uso compartido: donde la propiedad se convierte en acceso

Hay gente que ni siquiera sabe qué es la tabla de uso compartido (share table). Todo arquitecto de datos debería saberlo.

La mayor parte del uso compartido de un registro se guarda en un objeto de uso compartido (share object) relacionado, la versión de Salesforce de una lista de control de acceso (Understanding Sharing (opens in a new tab), en inglés). Cuenta tiene AccountShare, Contacto tiene ContactShare, y un objeto personalizado recibe el suyo: Truck__c tiene Truck__Share (Sharing a Record Using Apex (opens in a new tab), en inglés). Cada fila dice cuatro cosas:

• Qué registro: el ID del padre.
• Quién: un usuario o un grupo (un grupo público, el grupo de una función, un territorio).
• Cuánto: lectura (Read), edición (Edit) o todo (All, acceso total).
• Por qué: el motivo de la fila (row cause). Owner para el propietario, Rule para una regla de uso compartido, Manual para un uso compartido manual, Team, los motivos implícitos que Salesforce agrega entre una cuenta y sus hijos, y los motivos que un desarrollador define para el uso compartido con Apex.

En clase abro Workbench y consulto la tabla de uso compartido mientras comparto un registro, y tú ves cómo aparecen y desaparecen las filas. Cuando alguien pregunta “¿por qué esta persona puede ver eso?”, la respuesta muchas veces está en una fila, con su motivo.

Pero no todo está ahí. El valor predeterminado de toda la organización no es una fila. La jerarquía de funciones tampoco se guarda ahí: el acceso de las personas por encima del propietario se calcula cuando se necesita. Y View All, Modify All, View All Data y Modify All Data se saltan por completo la tabla de uso compartido (Sharing a Record Using Apex (opens in a new tab), en inglés). Como lo digo en clase: marca View All y te saltaste la tabla de uso compartido.

Salesforce también comparte algunos registros por ti, por cómo están relacionados. Es el uso compartido implícito, y funciona entre una cuenta y sus hijos. Si puedes ver un contacto, un caso o una oportunidad, también puedes leer la cuenta a la que pertenece. Y el propietario de la cuenta obtiene acceso a los contactos, casos y oportunidades de la cuenta, con un nivel que define la función del propietario (Implicit Sharing (opens in a new tab), en inglés). En las versiones recientes, Salesforce calcula parte de ese acceso a los hijos cuando se necesita en lugar de guardarlo como filas, así que no te sorprendas si una consulta a la tabla de uso compartido no lo muestra. Aquí solo te doy una pista; los detalles están en Relaciones y uso compartido integrado.

Una excepción más, para cuando tienes muchos usuarios externos. Los usuarios de comunidad de alto volumen, las licencias de Customer Community pensadas para miles o millones de clientes, no tienen función, no pueden estar en grupos públicos y no pueden recibir registros mediante reglas de uso compartido ni uso compartido manual (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab), en inglés). Para ellos, la tabla de uso compartido no es la respuesta: llegan a los registros mediante conjuntos de uso compartido (sharing sets), que hacen coincidir la cuenta o el contacto de un registro con los del propio usuario. Es una de las razones por las que esas licencias escalan. El curso Sharing and Visibility lo trata en Compartir con usuarios externos.

Y recuerda el módulo 7: un objeto de detalle no tiene ningún objeto de uso compartido. Su acceso viene del objeto de uso compartido del principal y de la configuración de uso compartido (Sharing Setting) del campo principal-detalle.

¿Por qué le importa esto a un arquitecto de datos? Porque la propiedad se escribe en esta tabla. Cada cambio de propietario, cada regla de uso compartido nueva, cada usuario que cambia de función o de grupo significa que Salesforce agrega y elimina filas. Con unos pocos miles de registros nadie lo nota. Con diez millones, y un solo usuario dueño de la mayoría, ese es el recálculo que veremos en un momento.

Conocimiento para el examen. El objeto de uso compartido de un objeto personalizado se llama Object__Share, como Truck__Share. Un objeto de detalle no tiene objeto de uso compartido: su acceso viene del principal. Y cuando cambia el propietario de un registro, se eliminan sus usos compartidos manuales, mientras que el uso compartido con Apex con un motivo propio del desarrollador se conserva.

Aquí es donde el modelo de datos le pasa el relevo al modelo de seguridad, y el resto lo enseño en el curso Sharing and Visibility Architect: Las 22 formas de compartir un registro de Steve, Valores predeterminados de toda la organización, propiedad, colas y jerarquía de funciones, Relaciones y uso compartido integrado para los usos compartidos implícitos, y Uso compartido programático y código seguro para los motivos de uso compartido con Apex. En este curso, el capítulo 12 lo junta todo para personas, aplicaciones y agentes.

A veces la propiedad se hereda

En el módulo anterior vimos que un hijo de principal-detalle no tiene propietario propio; sigue a su padre. A menudo eso es exactamente lo correcto. ¿Necesita el negocio un propietario distinto para cada artículo de una entrega? No. La entrega es dueña del ciclo de vida y el artículo le pertenece. Por eso el diseño de las relaciones y el diseño de la propiedad van juntos: cuando elegiste principal-detalle, ya habías tomado parte de la decisión de propiedad.

¿Quién es dueño de los registros que crean los sistemas?

Ahora se pone interesante. Una persona crea una cuenta, y quizá se convierte en su propietaria. Pero un ERP envía 100.000 transacciones durante la noche. ¿Quién es dueño de esas? ¿El usuario de integración? ¿Una cola? ¿Un propietario regional deducido de los datos? ¿Una cuenta de sistema en la que nadie ha pensado en cinco años? Y ahora los agentes también crean registros.

Mi posición: depende de si la propiedad importa para el uso compartido. El usuario de integración, o el usuario del agente, es un usuario válido, y puede ser dueño de los registros. Si la propiedad determina el acceso en ese objeto (a través de la jerarquía de funciones o de reglas de uso compartido), asigna los registros al propietario correcto: un usuario real, una cola o un usuario propietario dedicado. Si no lo determina, mantener al usuario del sistema como propietario puede ser la mejor opción, porque así la pista de auditoría lleva directamente a lo que creó el registro.

En cualquier caso, decídelo a propósito. Una cuenta de integración que es dueña de todo se ha convertido en silencio en parte de tu arquitectura de seguridad, y alguien necesita saber qué pasa si algún día se desactiva.

La propiedad puede convertirse en un problema de escala

La distribución también importa. Diez millones de registros repartidos entre miles de propietarios es una forma. Diez millones de registros de un solo usuario es otra muy distinta. Salesforce lo llama sesgo de datos de propiedad (ownership data skew) cuando un solo usuario es dueño de más de 10.000 registros de un objeto (Ownership Data Skew (opens in a new tab), en inglés). Suele pasar cuando alguien estaciona todo en un usuario o una cola: todos los candidatos sin asignar en un usuario de relleno, cada registro de integración en el usuario de integración. Es inofensivo hasta que ese usuario se mueve en la jerarquía de funciones, o entra o sale de un grupo del que depende una regla de uso compartido. Entonces Salesforce tiene que ajustar una cantidad enorme de entradas de uso compartido, y aparecen recálculos que tardan mucho.

La recomendación es práctica. Reparte la propiedad entre más usuarios donde puedas. Si un usuario tiene que ser dueño de mucho, mantenlo fuera de la jerarquía de funciones; si necesita una función, ponlo en su propia función en la cima y no lo muevas, y mantenlo fuera de los grupos públicos que usan las reglas de uso compartido (Ownership Data Skew (opens in a new tab), en inglés). La misma idea aplica al padre con demasiados hijos del módulo anterior, el sesgo padre-hijo.

Así que la distribución es parte del modelo físico. No preguntes solo cuántos registros; pregunta cómo se distribuyen. Es otra versión del Número de Ceros: no solo cuántos ceros, sino dónde se concentran los ceros. La Parte 2 trata el sesgo a fondo; aquí quiero que lo veas venir. El curso Sharing and Visibility lo retoma en Uso compartido a escala.

El “propietario predeterminado” se convierte en arquitectura

Este es un patrón que veo todo el tiempo. Nadie sabe quién debería ser dueño de algo, así que alguien dice: “Asígnalos todos al usuario de integración”, o “crea un usuario genérico llamado Sistema”. Quizá eso sea lo correcto. Pero no lo hagas por accidente. Un valor predeterminado temporal tiene la costumbre de volverse permanente: dos años después cada registro pertenece a integration@company.com, nadie recuerda por qué, y cambiarlo es un proyecto. Es la Prueba de Reversibilidad del capítulo 1: antes de darle un millón de registros a un solo propietario, pregunta qué cuesta cambiar eso después.

La reasignación es un evento del ciclo de vida

Los propietarios cambian. Los representantes se van, los territorios se mueven, los equipos se reorganizan, las regiones se reequilibran. ¿Qué depende del propietario: el uso compartido, la automatización, los informes, las colas, los escalamientos, las integraciones? Si cambiar el propietario cambia quién puede ver el registro, la reasignación no es limpieza administrativa. Es un evento de seguridad, y con un millón de registros también es un evento operativo. Mira la tabla de uso compartido cuando pasa: los usos compartidos manuales se eliminan cuando cambia el propietario, mientras que el uso compartido con Apex con un motivo propio del desarrollador sobrevive al cambio (Understanding Sharing (opens in a new tab), en inglés). En clase comparto un registro con alguien, cambio el propietario y esa persona pierde el acceso. La sala siempre se sorprende.

Y recuerda que la propiedad no es lo mismo que el acceso. El propietario no es la única persona que necesita ver un registro, y Salesforce tiene muchas formas de conceder acceso: la jerarquía de funciones, las reglas de uso compartido, los equipos, los territorios, el uso compartido manual y el programático. El curso Sharing and Visibility profundiza en todo eso, empezando por Las 22 formas de compartir un registro de Steve. La idea del arquitecto es más simple: no uses la propiedad para resolver todos los problemas de acceso. Si estás moviendo propietarios solo para que alguien pueda ver un registro, probablemente estás resolviendo el problema equivocado.

La creación es solo el principio

Gran parte del modelado de datos se detiene en la creación: los campos, el objeto, la relación, listo. Pero el registro puede vivir diez años. Se actualiza, cambia de propietario, cambia de estado y de relaciones, se vuelve inactivo, pasa a ser historial, puede necesitar archivarse y algún día quizá eliminarse. La arquitectura no es solo cómo nace el registro. Es lo que pasa desde que nace hasta que muere.

Click to enlarge

No elimines algo solo porque es viejo

Un socio minorista deja de enviar trabajo. ¿Eliminar la cuenta? No automáticamente: sus entregas, reclamos e historial de facturación siguen importando. Un camión se retira. ¿Eliminarlo, junto con su historial de entregas y sus reclamos por daños? La cosa puede haber dejado de estar activa, pero sus datos no. Así que separo inactivo de desaparecido. Un camión retirado puede quedarse en el modelo; un exempleado todavía puede aparecer en el historial de auditoría. La arquitectura tiene que conservar los hechos que importan después de que termina la relación operativa.

La retención es un requisito del negocio

La otra cara: conservarlo todo para siempre tampoco es arquitectura. El almacenamiento crece, los informes se vuelven lentos, la búsqueda se llena de ruido, y la ley de privacidad puede decir que algunos datos tienen que irse. Así que quiero una respuesta explícita a ¿cuánto tiempo conservamos esto?. “Salesforce lo guarda” no es una política de retención.

Y, sobre todo, esta es una pregunta sobre datos transaccionales. Los datos de referencia (los productos, los tipos de servicio, los centros de distribución) no crecen mucho, y otros registros apuntan a ellos, así que normalmente se quedan. Los datos de clientes están en medio: puede llegar el día en que des de baja a un cliente, sobre todo cuando guardas datos personales y se acaba el motivo para conservarlos. Pero el volumen está en las transacciones: las entregas, los pedidos, los casos, las citas, que se crean todos los días, para siempre. Eso es lo que crece hasta cientos de millones de filas, y ahí es donde la retención tiene que ser explícita: quizá dos años de datos operativos en la organización, siete años de registros financieros en algún lugar, noventa días para algunas fotos. Son reglas de negocio y, si nadie ha preguntado, debería hacerlo el arquitecto.

Lo digo en clase desde hace años: si no estás archivando hoy, ¿vas a archivar alguna vez? “Ya nos ocuparemos más adelante” tiene la costumbre de convertirse en un proyecto de emergencia con trescientos millones de registros. La Parte 2 tiene un módulo entero sobre archivar y depurar, construido sobre la misma pregunta.

Steve Trucking: ¿quién es dueño de una entrega?

Una entrega se crea a partir del manifiesto del socio minorista, mediante una integración, unas 3.300 veces al día. ¿Quién es su dueño? No el socio minorista; esa es una relación de negocio. Tampoco el destinatario. El equipo la ejecuta, pero ¿debería el registro cambiar de propietario cada vez que los equipos cambian de camión? ¿El despachador? ¿El centro de distribución? ¿Una cola? ¿El usuario de integración que la creó?

Ahora aplica este módulo, empezando por la pregunta que lo decide: ¿la propiedad determina el acceso de alguien a las entregas? En Steve Trucking, no. Los despachadores ven las entregas de su centro de distribución, los equipos ven las de sus rutas y cada minorista ve las suyas en el portal de socios. Nada de eso depende de quién es dueño del registro; viene del centro de distribución, la ruta y el socio.

Así que mi respuesta es: el usuario de integración es dueño de las entregas. Es un buen ejemplo de un usuario de sistema que es dueño de registros a propósito:

• La pista de auditoría es honesta. El propietario de cada entrega dice de dónde vino: la integración del manifiesto.
• El acceso viene del uso compartido, no de la propiedad. Las reglas de uso compartido basadas en criterios sobre el centro de distribución le dan a cada equipo de centro de distribución sus entregas; los socios llegan a las suyas a través del portal.
• El sesgo se elimina desde el diseño. Con 3.300 al día, el usuario de integración pasa de 10.000 entregas en tres días, así que es sesgo de propiedad desde el primer día, y está bien si lo planificamos. El usuario de integración no tiene función, así que no hay nada por encima de él en una jerarquía que haya que recalcular, y se queda fuera de los grupos públicos que usan nuestras reglas de uso compartido.
• Nadie reasigna las entregas. Los equipos cambian de camión y los despachadores cambian de turno, y el propietario nunca se mueve, así que no hay tormenta de reasignaciones ni usos compartidos manuales que perder.

Y deja por escrito qué pasa si ese usuario algún día se desactiva o se reemplaza, porque ahora es dueño de millones de registros. Esa es la decisión que el próximo equipo va a necesitar encontrar.

Más allá del examen: lo que cambia la IA. Los agentes crean y cambian registros a velocidad de máquina. Si un agente crea 100.000 registros con su propio usuario, “ya arreglaremos el propietario más adelante” se convierte en sesgo, un recálculo del uso compartido y un proyecto de limpieza. Decide la regla de propiedad del agente antes de que salga a producción, con la misma pregunta: ¿la propiedad importa aquí para el uso compartido?

Lo que decide aquí un arquitecto

• Si la propiedad representa una responsabilidad de negocio, un mecanismo de seguridad o ambas cosas, y dónde vive la responsabilidad si no es en Propietario.
• Si los registros necesitan su propio propietario o deberían heredarlo de un padre.
• Quién es dueño de los registros que crean las integraciones y los agentes, según si la propiedad determina el uso compartido.
• Cómo se distribuye la propiedad, y cómo evitar el sesgo de propiedad cuando un usuario tiene que ser dueño de mucho.
• Cuándo los registros pasan a inactivos, cuándo se archivan, cuánto tiempo se conservan y cuándo es correcto eliminarlos.

Cuando mires un modelo físico, no preguntes solo dónde se guardan los datos. Pregunta quién es su dueño hoy, quién podría serlo mañana y qué pasa cuando ya no los necesitemos. A continuación: incluso con el objeto, los campos, las relaciones y el propietario correctos, los datos todavía tienen que seguir siendo confiables.

Explora

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (en inglés), consultado el 2026-10-13: los propietarios (un usuario, o una cola en objetos personalizados, casos y candidatos) obtienen acceso total; la mayor parte del uso compartido vive en un objeto de uso compartido relacionado; la jerarquía de funciones se calcula en tiempo de ejecución; los usos compartidos manuales se eliminan cuando cambia el propietario, el uso compartido gestionado con Apex se conserva; los valores del motivo de la fila.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (en inglés), consultado el 2026-10-13: AccountShare, MyCustomObject__Share; los objetos de detalle no tienen objeto de uso compartido; lo que el objeto de uso compartido no registra (valores predeterminados de toda la organización, jerarquía de funciones, View All y Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab) (en inglés), consultado el 2026-10-13: el acceso entre una cuenta y sus contactos, casos y oportunidades.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) y Sharing Rule Considerations (opens in a new tab) (en inglés), consultado el 2026-10-13: sin funciones, sin reglas de uso compartido ni uso compartido manual; en su lugar, conjuntos de uso compartido.
• Curso Sharing and Visibility Architect: Las 22 formas de compartir un registro de Steve, Valores predeterminados de toda la organización, propiedad, colas y jerarquía de funciones, Relaciones y uso compartido integrado, Uso compartido programático y código seguro, Compartir con usuarios externos, Uso compartido a escala.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) y Parent-Child Data Skew (opens in a new tab) (en inglés), consultado el 2026-10-02.