El volumen se encuentra con el modelo de uso compartido

También en 19 idiomas

English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

An old telephone switchboard in an empty room, dozens of cords plugged in, each one a separate connection from the shelf to a socket. — Imagen generada con IA

Módulo 3 de 4 del capítulo Diseñar para la escala, capítulo 7 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Puntos calientes: sesgo de propiedad, de padre y de búsqueda · Siguiente: Si no archivas hoy…

La pregunta que responde este módulo: ¿cómo se mantiene rápido con volumen un modelo que respeta el uso compartido?

El módulo anterior encontró los puntos calientes. Ahora añade la seguridad, que es donde una arquitectura de datos de aspecto razonable se vuelve cara. Nueve millones de órdenes de trabajo es un problema de volumen. Nueve millones de órdenes de trabajo, cada una visible exactamente para los usuarios internos correctos y exactamente para el socio minorista correcto, es un problema de uso compartido con volumen. Un registro no solo se almacena; Salesforce también tiene que responder ¿quién puede verlo? A escala, esa respuesta forma parte de la arquitectura de datos.

El uso compartido también son datos

Cuando los arquitectos cuentan el volumen, cuentan registros de negocio. Pero Salesforce también mantiene lo que sostiene el acceso: propietarios, funciones, grupos, reglas de uso compartido, registros compartidos explícitos, pertenencias. A pequeña escala puedes olvidar que ese trabajo existe. A gran escala no puedes. Por eso nunca digo “el equipo de seguridad ya resolverá el uso compartido más adelante”. La relación que elijo, el propietario, el padre, el modelo de usuarios externos: cada uno afecta al uso compartido. El arquitecto de datos y el arquitecto de uso compartido pueden ser personas distintas, pero sus arquitecturas están conectadas.

La tabla de uso compartido tiene su propio Número de Ceros

Chapter 3 introduced the share table: the share object behind each object, AccountShare for Account, Truck__Share for a custom Truck__c, where Salesforce keeps most of the sharing for a record, one row per grant: which record, who, how much and why (Understanding Sharing (se abre en una pestaña nueva); Sharing a Record Using Apex (se abre en una pestaña nueva)). It’s an object of its own, with its own rows, and at volume that’s exactly the point. The share table has its own Number of Zeros. ⟲

Salesforce describe tres tipos de tablas detrás del acceso a los registros. Las tablas de registros de objetos guardan los registros y quién es propietario de cada uno. Las tablas de uso compartido de objetos, los objetos __Share, “almacenan cada concesión de acceso en filas separadas llamadas filas de uso compartido, cada una de las cuales concede a un usuario o grupo acceso a un registro concreto”. Y las tablas de mantenimiento de grupos guardan quién pertenece a cada grupo y el acceso que las personas heredan a través de funciones y grupos (Record-Level Access: Under the Hood (se abre en una pestaña nueva), Winter ‘27, copia archivada (se abre en una pestaña nueva)). Cuando hablamos del recálculo, aquí es donde ocurre el trabajo: filas que se añaden y se eliminan en esas tablas.

Así que haz las cuentas para la tabla de uso compartido igual que las hicimos para los registros. Supongamos que cada una de los 9 millones de órdenes de trabajo de Steve Trucking se comparte mediante tres reglas de uso compartido: con los usuarios de su socio minorista, con los responsables de su centro de distribución y con una región de operaciones. El objeto de uso compartido de Work Order es WorkOrderShare, “una entrada de uso compartido en una orden de trabajo” (WorkOrderShare (se abre en una pestaña nueva)). Son tres de esas filas por orden de trabajo, unos 27 millones de filas de uso compartido detrás de 9 millones de registros, antes de las filas del propio propietario. Comparte los mismos registros con usuarios individuales en lugar de con grupos y las filas se multiplican por el número de personas. La tabla de uso compartido puede ser mucho más grande que el objeto que protege.

Clic para ampliar

Paso 1 de 3: los registros. Nueve millones de órdenes de trabajo.

Clic para ampliar

Paso 2 de 3: la tabla de uso compartido, tres reglas hacia grupos.

Clic para ampliar

Paso 3 de 3: el mismo acceso, compartido persona a persona. Cuenta la tabla de uso compartido, no solo los registros.

Por eso las palancas que mantienen rápido el uso compartido son, sobre todo, palancas sobre el número de filas:

Comparte con grupos, no con personas. El propio consejo de Salesforce: concede el acceso al grupo en lugar de a las personas, lo que “da lugar a menos filas de uso compartido y reduce así el volumen de datos de acceso a registros de tu organización” (misma fuente).
Un objeto de detalle no tiene ningún objeto de uso compartido. Su acceso viene de su principal, así que un hijo principal-detalle no añade filas de uso compartido (capítulo 3, y Principal-detalle con volumen en el módulo 2 para lo que eso cuesta).
Los usuarios de comunidad de gran volumen no usan filas de uso compartido. Llegan a los registros mediante conjuntos de uso compartido (sharing sets), una de las razones por las que esas licencias escalan (capítulo 3).
Usa un valor predeterminado público donde los datos no sean confidenciales. Un valor predeterminado de Solo lectura pública o de Lectura/Escritura pública no necesita filas de uso compartido para conceder lo que todo el mundo ya puede leer (consulta No sacrifiques la seguridad para optimizar, más abajo).

Conocimiento para el examen. Conoce el objeto de uso compartido (AccountShare, Object__Share): una fila por concesión, con un motivo de la fila (row cause); los tres tipos de tablas detrás del acceso a los registros (registros de objetos, uso compartido de objetos, mantenimiento de grupos); y que compartir con grupos en lugar de con personas significa menos filas de uso compartido.

Empieza por el requisito de acceso

No empiezo por qué función de uso compartido usar. Empiezo por ¿quién necesita acceso a qué? Para Steve Trucking, un requisito está claro: cada socio minorista ve sus propias entregas, nunca las de otro. Fácil de decir. A escala, enseguida quiero saber cuántos usuarios de socios hay, cuántas entregas, cómo se relaciona una entrega con su socio, quién es propietario de la entrega y qué ocurre cuando un usuario cambia de función, se añade o se elimina un usuario de un socio o cambia una relación con un socio, y con qué frecuencia ocurre todo eso. Primero va el requisito de acceso; luego, un modelo que lo soporte con los ceros que esperamos.

La propiedad determina el acceso

Por eso “¿quién debe ser propietario de la entrega?” no puede responderse de forma aislada. Si un usuario de integración es propietario de todas las órdenes de trabajo, la ingesta es fácil, pero si el negocio esperaba que la propiedad determinara el acceso, hemos renunciado a esa forma de controlarlo. Y si la propiedad no determina el acceso, forzar millones de registros por asignaciones de propiedad complicadas añade complejidad para nada. Así que mi regla para los registros creados por máquinas se aplica también aquí: ¿importa la propiedad para el uso compartido? Si importa, la propiedad debe reflejar el modelo de acceso. Si no, tenemos más libertad. Una sola decisión, tomada por el arquitecto de datos y el arquitecto de uso compartido juntos.

La jerarquía de funciones no es un organigrama

Los equipos diseñan la jerarquía de funciones como un espejo del organigrama. Luego la empresa se reorganiza, alguien mueve una función y Salesforce tiene que calcular las consecuencias para el acceso. A pequeña escala nadie lo nota. Con millones de registros, reorganizarse es una gran operación de datos. Por eso la recomendación para los propietarios de gran volumen es no darles ninguna función, o una función aparte y estable en la cima de la jerarquía (Ownership Data Skew (se abre en una pestaña nueva)). El principio se generaliza: a escala, la estabilidad es una característica del diseño. Cuantos más registros cuelgan de una estructura de uso compartido, con más cuidado la cambias.

Con los grupos pasa lo mismo. Los grupos públicos alimentan las reglas de uso compartido; los usuarios pertenecen a grupos; los grupos contienen grupos. Son herramientas útiles, pero si poblaciones enormes de usuarios y registros dependen de pertenencias a grupos que cambian todo el tiempo, necesitas entender el recálculo. Por eso los propietarios de gran volumen se quedan fuera de los grupos públicos que se usan como origen de reglas de uso compartido (misma fuente). La lección no es “los grupos públicos son malos”. Es: no conectes tu mayor concentración de registros a tus estructuras de acceso más volátiles sin pensarlo bien.

El recálculo del uso compartido es trabajo real

Steve Trucking cambia su modelo operativo: cientos de usuarios se mueven, cambia la propiedad, cambian funciones y grupos, cambia una gran regla de uso compartido. Suena a configuración. Pero la plataforma puede tener que recalcular el acceso en una gran población de registros, así que lo trato como una operación de datos. ¿Cuántos usuarios, registros, cambios de propiedad y de pertenencia? ¿Cuánto recálculo? ¿Podemos probarlo con el volumen real? ¿Cuándo debe ejecutarse, y qué ven los usuarios mientras tanto? Una gran realineación de seguridad merece la misma disciplina que una gran migración de datos.

Y no recalcules todo después de cada cambio. Hacer un cambio, esperar a que todo se recalcule, luego el siguiente, y luego el siguiente, reconstruye el acceso una y otra vez mientras el diseño todavía se mueve. La respuesta de Salesforce para las grandes reorganizaciones son los cálculos de uso compartido diferidos: prepara todos los cambios de funciones, grupos y reglas de uso compartido, aplícalos en una ventana de mantenimiento negociada y deja que el recálculo se ejecute una sola vez (Deferred Sharing Maintenance (se abre en una pestaña nueva)). Cambio, cambio, cambio, recálculo una vez. Otras dos sugerencias de Salesforce reducen el trabajo: procesar los cambios de la jerarquía de funciones desde los nodos inferiores (hoja) hacia arriba, “para evitar el procesamiento duplicado”, y eliminar las vías de acceso redundantes, “como reglas de uso compartido que dan acceso a personas que ya lo tienen a través de la jerarquía” (Designing Record Access for Enterprise Scale (se abre en una pestaña nueva), Winter ‘27).

Conocimiento para el examen. Conoce las herramientas para los grandes cambios de acceso: los cálculos de uso compartido diferidos (prepara cada cambio, aplícalos en una ventana de mantenimiento acordada, ensayada en un sandbox de copia completa, recalcula una sola vez) y el bloqueo granular, activado por defecto, que permite que operaciones de funciones y grupos no relacionadas se ejecuten a la vez.

Clic para ampliar

A escala, reorganizar el acceso es una operación de datos.

“Aplazado” no significa improvisado. Si un cambio es lo bastante grande como para aplazar el uso compartido, quiero un plan: probado con un volumen realista, una ventana de mantenimiento que el negocio acepte, verificación, una alternativa si no termina, y entender lo que viven los usuarios mientras tanto. La recomendación de Salesforce es modelarlo primero en un sandbox de copia completa (misma fuente), porque un modelo de seguridad que funciona de maravilla con 5.000 registros de prueba no demuestra nada sobre 50 millones. Prueba el Número de Ceros para el que de verdad estás diseñando.

El bloqueo granular ayuda, pero no es una cura

Las actualizaciones de funciones y grupos bloquean las tablas de pertenencia a grupos mientras se ejecutan, lo que antes hacía chocar operaciones de uso compartido no relacionadas. El bloqueo granular, ahora activado por defecto, permite que operaciones de grupo no relacionadas se ejecuten a la vez (Group Membership Locking (se abre en una pestaña nueva)); la lógica de reintento, el procesamiento en serie y programar los trabajos de mantenimiento de grupos por separado para que no se solapen ayudan con lo que queda. Vale la pena recordar la idea: no bloquees más estructura de acceso de la que la operación necesita. Pero no concluyas que “los bloqueos están resueltos”. El bloqueo granular reduce parte de la contención. No rescata un mal modelo de propiedad, una jerarquía inestable ni un diseño de acceso que obliga constantemente a recálculos masivos. Las funciones de la plataforma ayudan; la arquitectura sigue importando.

Steve Trucking: aislamiento de socios a escala

En el Checkpoint 1, cada orden de trabajo lleva su socio minorista, de forma duradera, porque el aislamiento de socios es un requisito. Las cifras de escala hacen eso más importante, no menos: si Redrock es el 40 % del negocio, son unas 3,6 millones de órdenes de trabajo de Redrock en cinco años. La relación es correcta; Redrock realmente es un solo socio. Así que el diseño de acceso tiene que seguir la relación de negocio real (los usuarios del socio ven las órdenes de trabajo de su socio, los gerentes de centro de distribución solo las de su centro) en lugar de distorsionar el modelo. La estructura de una cuenta hija por centro de distribución del módulo anterior ayuda aquí dos veces: reparte los hijos y le da al acceso por centro de distribución algo real de lo que colgar.

Y mantén la autorización separada de la identidad. En el checkpoint decidimos no unificar los destinatarios entre socios, precisamente porque una identidad compartida es justo el tipo de vínculo que puede exponer los datos de un socio a otro. Incluso donde se usa la resolución de identidades dentro de un mismo socio, responde a ¿quién podría ser esta persona? El uso compartido responde a ¿quién puede ver este registro? Mézclalos y, a esta escala, el error no se comete una vez. Se comete millones de veces.

El acceso interno es otra cosa

Partners are only part of it. Coordinators, crews, care agents, operations, finance and sales need different things. A care agent may need broad visibility to answer “where’s my delivery?”; a crew only today’s stops, and the Recipient’s details only on the day; operations a region; finance the money, not every operational detail; sales the partner, not the Recipients. The Sharing and Visibility course goes through Steve’s 25 Ways to Share a Record; I won’t reproduce it here. The data architect’s job is to recognize that the model either enables those choices or constrains them. ⟲

A veces la seguridad debería cambiar el modelo. Cuando dos tipos de información tienen propietarios, ciclos de vida, públicos o necesidades de uso compartido completamente distintos, puedes amontonar controles de nivel de campo en un registro, o separar los datos en su propio objeto con su propio límite. No separo solo para evitar configurar la seguridad a nivel de campo, pero la seguridad es un motivo legítimo para cambiar el modelo físico.

El uso compartido tiene su propio Número de Ceros

Dos diseños con 10 millones de registros cada uno: uno con una propiedad sencilla, una jerarquía estable, pocas reglas de uso compartido y poca rotación de pertenencias; el otro con una propiedad muy distribuida, funciones que cambian con frecuencia, grandes grupos anidados, muchas reglas de uso compartido y reorganizaciones constantes. El mismo número de registros, un problema de escala completamente distinto. Así que, para cada objeto de gran volumen, también quiero las cifras del modelo de acceso: cuántos propietarios y qué concentración, el acceso por defecto, qué relaciones de jerarquía, reglas y grupos importan, cuántos usuarios externos, y qué pasa cuando alguien cambia de función, se añade un socio o se reorganiza una región. Luego una pregunta: ¿cuál es el mayor recálculo que podría provocar este diseño? Ese es el escenario que quiero probar.

Clic para ampliar

Cuenta el modelo de acceso, no solo los registros.

No sacrifiques la seguridad para optimizar

Hay una conclusión peligrosa que evitar: el uso compartido es caro, así que hagamos todo público. No. El rendimiento no es una excusa para abandonar un requisito de seguridad. La propia recomendación de Salesforce traza la línea en el lugar correcto: “Usa un modelo de uso compartido predeterminado de toda la organización de Solo lectura pública o de Lectura/Escritura pública para todos los datos no confidenciales” (misma guía). Los datos no confidenciales pueden ser públicos; los confidenciales siguen protegidos, y el diseño tiene que soportarlo. El trabajo es una arquitectura que satisfaga ambas cosas: una propiedad más sencilla, jerarquías más estables, un mejor diseño de grupos, separar datos con distintas necesidades de seguridad, relaciones distintas, reorganizaciones planificadas. “Privado es más lento, así que hazlo público” no es una estrategia de arquitectura.

Más allá del examen: lo que cambia la IA. Los agentes recuperan y agregan datos más rápido que cualquier persona, lo que hace más peligroso un modelo de acceso demasiado amplio. No confíes en un prompt que diga “no muestres los datos de Brightwave a Redrock”. El límite pertenece a la arquitectura: la autorización debería limitar lo que un agente puede alcanzar, no las instrucciones lo que decide revelar. Escala el modelo de autorización junto con el modelo de datos.

Lo que decide aquí un arquitecto

Qué relaciones, propietarios, funciones, grupos y reglas de uso compartido determinan el acceso para cada objeto de gran volumen.
Si los propietarios de gran volumen y otros puntos calientes están aislados de las estructuras volátiles de jerarquía y grupos.
Cómo se prueban, se programan, se recalculan una sola vez y se verifican las grandes realineaciones de acceso con el volumen de producción.
Si unas necesidades de seguridad distintas justifican separar los datos en lugar de complicar el acceso a un registro.
Cómo el acceso de socios, empleados, aplicaciones y agentes sigue ligado a las relaciones de negocio, no a atajos de identidad.

Es fácil dibujar un diseño seguro para 1.000 registros, y uno rápido donde todos lo ven todo. El trabajo del arquitecto es el sistema en el que sobreviven ambos: las personas correctas ven los datos correctos, y sigue funcionando cuando añadimos los ceros. A escala, el uso compartido forma parte de la arquitectura de datos.

Explora

Object Reference for the Salesforce Platform, WorkOrderShare (se abre en una pestaña nueva) (Winter ‘27), checked 2026-11-01. ⟲
Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (se abre en una pestaña nueva) (Winter ‘27): leaf-first hierarchy changes and removing redundant access paths, checked 2026-11-01. ⟲
Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (se abre en una pestaña nueva), Group Membership Locking (se abre en una pestaña nueva) and Deferred Sharing Maintenance (se abre en una pestaña nueva), checked 2026-11-01. ⟲
Para profundizar: el curso Sharing and Visibility Architect, Uso compartido a escala (coming soon).
SteveTechArc, Documentos de Salesforce por versión: estas guías, una por año desde Winter ‘16, cada una con una copia archivada.
Salesforce, Record-Level Access: Under the Hood (se abre en una pestaña nueva) (Winter ‘27, copia archivada (se abre en una pestaña nueva)), consultado el 2026-10-20.
Apex Developer Guide, Understanding Sharing (se abre en una pestaña nueva) and Sharing a Record Using Apex (se abre en una pestaña nueva), checked 2026-11-01. ⟲