Las tres preguntas clave para determinar si requiere un entorno Multi-Org
El error común es abordar la pregunta "¿un solo Org o varios?" como si fuera una cuestión técnica de capacidad o rendimiento. En la mayoría de los casos, la respuesta técnica existe dentro de un solo Org: los Record Types, Profiles, Permission Sets y Sharing Rules son suficientes para separar unidades de negocio sin dividir el entorno en sí. Salesforce soporta a decenas de miles de usuarios y millones de registros en un Org individual — la capacidad casi nunca es la verdadera razón para una división.
La pregunta que realmente importa es la de la autonomía organizacional, y se desglosa en tres pruebas:
- Autonomía regulatoria genuina — ¿Existe un requisito legal o contractual para la separación física de datos (por ejemplo, una entidad legal separada con regulación local que prohíbe compartir infraestructura), a diferencia de una separación lógica que se puede lograr con el Sharing Model?
- Ritmo de cambio incompatible — ¿Una unidad de negocio requiere ciclos de lanzamiento frecuentes y rápidos, mientras que otra exige máxima estabilidad y una auditoría estricta, de modo que cada lanzamiento compartido se convierte en un punto de fricción constante entre los equipos?
- Modelo de datos que colisiona, no solo difiere — cuando una misma entidad (por ejemplo, "cliente" o "pedido") tiene una definición de campo obligatorio, un flujo de aprobación o una estructura de relaciones que entra en conflicto físico entre las unidades, y no solo difiere en la visualización.
Si ninguna de las tres se cumple de manera inequívoca, la solución correcta es un solo Org con separación lógica. Dividir "por si acaso" genera un costo operativo constante — gestión de usuarios duplicada, licenciamiento duplicado y mantenimiento de integración duplicado — a cambio de un problema que podría haberse resuelto con configuración.
Matriz de Decisión: Un Org frente a Varios Orgs
| Dimensión | Un Org con separación lógica | Varios Orgs separados |
|---|---|---|
| Costo de licenciamiento y mantenimiento | Más bajo — una sola licencia, gestión de usuarios centralizada | Más alto — duplicidad de licencias, duplicidad en la gestión de Releases |
| Visión unificada (Customer 360) | Natural — todos los datos en el mismo espacio de consulta | Requiere una capa de BI o integración dedicada |
| Autonomía operativa por unidad | Limitada — cada Release afecta a todos | Completa — cada unidad controla su propio ritmo |
| Cumplimiento de requisitos regulatorios estrictos | No es posible si el requisito es la separación física | El único que cumple con el requisito |
| Complejidad de integración entre unidades | Baja | Alta — requiere Middleware o ETL |
| Riesgo en futuras fusiones/divisiones | Bajo — solo cambio de permisos | Alto — un proyecto de migración completo |
En resumen: la opción predeterminada debe ser un solo Org, y la división solo debe elegirse cuando haya una respuesta positiva y clara a una de las tres preguntas anteriores, no como una respuesta a fricciones organizativas temporales.
Lo que sucede cuando se divide sin razón suficiente
Cuando una organización divide un Org por razones políticas (una unidad que quiere "su propio control") y no por razones técnicas genuinas, ocurren tres cosas en uno o dos años: Primero, se crea un registro de cliente duplicado en cada Org donde aparece la misma entidad comercial, sin una clave de identificación común. Segundo, cada cambio a nivel organizacional (como la actualización de un proceso de seguridad o la implementación de una nueva herramienta) se convierte en un proyecto separado para cada Org, lo que duplica el costo de cualquier cambio futuro. Tercero, la elaboración de informes a nivel de empresa requiere una capa de integración que no era necesaria inicialmente, y a menudo se construye bajo presión después de descubrir el problema, en lugar de como parte de la planificación.
Por lo tanto, uno de los principios rectores en la arquitectura de Salesforce es examinar primero si la necesidad organizacional se puede cumplir con permisos y Sharing Rules dentro de un solo Org, y solo después considerar la división.
Ruta gradual para quienes ya requieren una división
Cuando una de las tres pruebas mencionadas sí se cumple, la división debe llevarse a cabo en un orden que minimice el riesgo:
1. Defina un identificador global antes de la división
Antes de crear un segundo Org, establezca un campo de identificación uniforme (número de identificación fiscal, ID de cliente global o código similar) que permita en el futuro vincular registros entre los entornos. Sin esto, cualquier intento futuro de unificar la vista del cliente se basará en la coincidencia de nombre y dirección, lo que genera errores a gran escala.
2. Elija un patrón de integración según la dirección y el ritmo de los datos
Si se trata de una actualización periódica solo con fines de informe, un ETL programado es suficiente. Si se requiere una visión en tiempo real (por ejemplo, verificación de crédito entre unidades), se necesita una API síncrona con manejo de fallos y reintentos. La elección de un patrón incorrecto es la causa principal de que las integraciones Cross-Org fallen bajo carga — más detalles sobre este tema en patrones de integración de Salesforce.
3. Planifique la identidad y los permisos de acceso con antelación
Los usuarios que trabajan en ambos Orgs (por ejemplo, gerentes de cuentas globales) requieren una solución de identidad gestionada una sola vez, y no dos usuarios separados con dos contraseñas. La planificación de SSO entre Orgs evita una situación en la que cada cambio en los permisos de usuario se realiza manualmente en ambos entornos — este tema se detalla en arquitectura de SSO e identidad en Salesforce.
4. Pruebe los límites de la API antes de que la integración esté en producción
Cada llamada entre dos Orgs cuenta para la cuota de la API de ambas partes. El tráfico planificado sin una prueba de volumen puede afectar los límites diarios precisamente durante la carga máxima, es decir, justo cuando la integración es más necesaria. Esto debe verificarse de antemano con los Salesforce API Limits.
5. Defina un propietario y un proceso de gobernanza compartido para ambos Orgs
Alguien debe ser responsable de la coherencia de las decisiones arquitectónicas entre los entornos — estructura de campos, convenciones de nombres y políticas de cambio. Sin una propiedad central, los dos Orgs se dividirán también a nivel de estándares en un año, lo que hará que cualquier integración futura sea más costosa.
Escenario ilustrativo: un grupo asegurador con dos divisiones
El escenario es hipotético y tiene fines ilustrativos. Un grupo asegurador tenía una división de seguros generales y una división de seguros de vida, ambas operando bajo la misma entidad legal pero con reguladores diferentes y ciclos de aprobación de productos completamente distintos. La división de seguros de vida requería un control de cambios estricto con aprobación regulatoria para cada Release, mientras que la división de seguros generales quería lanzar mejoras semanalmente.
Una propuesta inicial fue dividir en un Org separado para cada división, pero al comparar con las tres preguntas, se encontró que solo el ritmo regulatorio (prueba 2) se cumplía realmente — el modelo de cliente y producto no entraba en conflicto (prueba 3 negativa), y no había un requisito de separación física de datos (prueba 1 negativa). La solución elegida fue un solo Org con dos "carriles de lanzamiento" separados dentro del mismo entorno — un Sandbox dedicado y un proceso de aprobación separado para la división de seguros de vida, utilizando un modelo de datos compartido para un único Customer 360. Se evitó la división completa, y con ello el costo de mantenimiento duplicado que habría sido necesario asumir durante años.
Riesgos comunes y cómo prevenirlos
- División "temporal" que se vuelve permanente — Un Sandbox que se convierte en un entorno de producción sin pasar por un control de seguridad. Se previene asegurando que cada Org con datos reales de clientes pase por un proceso formal de aprobación de Gobernanza, sin excepciones.
- Registros duplicados sin clave común — Ocurre cuando la división se produce antes de que se haya definido un identificador global. Se previene estableciendo el campo común como una condición previa para la división, no como un paso posterior.
- Cuota de API que se agota en momentos de carga máxima — Sucede cuando la integración entre Orgs se planifica según un volumen promedio y no un volumen pico. Se previene mediante pruebas de carga antes de la puesta en producción y la construcción de un mecanismo de Backoff.
- Deriva de estándares entre Orgs — Ocurre cuando no hay un único propietario para la arquitectura compartida. Se previene definiendo un comité de Gobernanza pequeño que apruebe los cambios en la estructura de datos en ambas partes.
- Informes de gestión poco fiables — Sucede cuando se intenta calcular KPIs interorganizacionales directamente desde Salesforce sin una capa de unificación. Se previene estableciendo una capa de BI dedicada desde el primer día de la división, no como un proyecto de corrección tardía.
Resumen
La opción predeterminada es un solo Org; la división es una excepción que requiere una justificación concreta en una de las tres pruebas: autonomía regulatoria genuina, ritmo de cambio incompatible o un modelo de datos que colisiona físicamente. Cuando la justificación existe, el éxito de la transición se mide por la preparación realizada antes de la división: un identificador global, un patrón de integración adecuado, identidad compartida, prueba de límites de API y una propiedad clara sobre los estándares compartidos. Una organización que omite esta preparación no ahorra trabajo, solo lo pospone a un momento en el que la corrección es mucho más costosa.