Las unidades de negocio son contenedores que definen las fronteras de seguridad en tu organización. Diseñarlas correctamente es fundamental para que los niveles de acceso "Business Unit" y "Parent:Child" funcionen como esperas.
Objetivos de aprendizaje
- Comprender qué son las unidades de negocio y su rol en la seguridad
- Diseñar una estructura de BUs efectiva para tu organización
- Entender cómo la jerarquía de BUs afecta el acceso a datos
- Evitar errores comunes en el diseño de estructura organizacional
¿Qué problema resuelven las unidades de negocio?
Imagina que trabajas en una empresa multinacional con oficinas en España, México y Argentina. Cada país tiene su propio equipo de ventas, sus propios clientes, y por razones legales y de privacidad, los datos de clientes de un país no deberían ser visibles para vendedores de otro país.
Podrías intentar manejar esto con roles de seguridad, pero te encontrarías con un problema: los niveles de acceso en un rol son globales. Si un vendedor tiene Read a nivel User solo ve sus propios registros, pero si le das Read a nivel Organization puede ver todo. No hay un término medio que diga "ve todo lo de España pero nada de México".
Aquí es donde entran las unidades de negocio. Una Unidad de Negocio (Business Unit o BU) es una frontera lógica que divide tu organización en segmentos. Cuando combinas BUs con los niveles de acceso "Business Unit" y "Parent:Child", puedes crear exactamente ese tipo de segmentación regional, departamental o funcional que necesitas.
Anatomía de las unidades de negocio
Cada entorno de Dataverse tiene automáticamente una BU raíz (root business unit), que toma el nombre de tu organización. Esta BU es especial:
- No puede eliminarse ni deshabilitarse
- Está siempre en la cima de la jerarquía
- Es donde existen por defecto los administradores del sistema
A partir de la BU raíz, puedes crear una estructura jerárquica de BUs hijas. Cada BU tiene exactamente un padre (excepto la raíz, que no tiene ninguno) y puede tener múltiples hijas.
Lo crucial que debes recordar es que cada usuario pertenece a exactamente una BU. No puedes estar en dos BUs simultáneamente (aunque sí puedes pertenecer a equipos de otras BUs para acceso cruzado). Esta asignación es lo que determina qué datos ves cuando tienes privilegios a nivel "Business Unit" o "Parent:Child".
Un ejemplo típico de jerarquía
Veamos cómo podría verse la estructura de una empresa de servicios con operaciones en tres países:
Acme Corporation (BU raíz)
│
├── España
│ ├── Ventas España
│ └── Soporte España
│
├── México
│ ├── Ventas México
│ └── Soporte México
│
└── Argentina
├── Ventas Argentina
└── Soporte Argentina
Con esta estructura, un vendedor en "Ventas España" con privilegios a nivel Business Unit solo vería los clientes y oportunidades que pertenecen a usuarios de "Ventas España". Pero el director regional de España, ubicado en la BU "España" (un nivel arriba) con privilegios a nivel Parent:Child, podría ver todo lo de España incluyendo Ventas y Soporte.
El error más común: diseñar BUs como organigrama
Cuando la gente empieza a diseñar estructura de BUs, el instinto natural es replicar el organigrama de la empresa: un nivel para ejecutivos, otro para directores, otro para gerentes, otro para empleados. Esto es casi siempre un error.
El problema es que el organigrama refleja relaciones de reporte, no necesidades de acceso a datos. El CEO reporta a la junta directiva, pero eso no significa que debería haber una BU para la junta y otra para el CEO debajo de ella.
La pregunta correcta no es "¿quién reporta a quién?" sino más bien "¿quién necesita ver qué datos?". A veces estas preguntas tienen la misma respuesta, pero frecuentemente no.
Criterios para crear una nueva BU
Crea una BU cuando necesites una frontera de seguridad real. Algunos escenarios legítimos:
- Requisitos legales: Datos de diferentes países que por ley deben estar separados
- Confidencialidad comercial: Divisiones que compiten entre sí y no deben ver datos mutuos
- Privacidad de empleados: RRHH no debería ver datos de ventas y viceversa
- Clientes con acuerdos especiales: NDAs que exigen separación de datos
Si tu razón para crear una BU es "porque en el organigrama son departamentos separados" pero todos pueden ver los datos de todos, probablemente no necesitas una BU nueva.
Operaciones con unidades de negocio
Mover usuarios entre BUs
Cuando un empleado cambia de departamento o se transfiere a otra región, su usuario debe moverse a la nueva BU. Esto tiene implicaciones importantes:
Todos los registros que el usuario poseía permanecen en su ubicación original. María era dueña de 50 oportunidades cuando estaba en Ventas España. Si la mueves a Ventas México, esas 50 oportunidades siguen perteneciendo a ella, pero ahora ella está en una BU diferente. Esto puede crear situaciones confusas donde un usuario tiene registros "huérfanos" que ya no debería gestionar.
Por esto, antes de mover a alguien, generalmente debes reasignar sus registros a otro usuario o equipo de la BU original.
Deshabilitar una BU
No puedes eliminar una BU, solo deshabilitarla. Y antes de poder deshabilitarla, debes:
- Mover todos los usuarios a otras BUs
- Reasignar todos los registros propiedad de la BU o sus usuarios
- No tener BUs hijas activas
Es un proceso laborioso, pero tiene sentido: eliminar una BU sin más dejaría registros y usuarios en un limbo.
Consideraciones de rendimiento
La estructura de BUs tiene impacto en el rendimiento del sistema. Cuando alguien con privilegios a nivel Parent:Child consulta datos, Dataverse debe calcular qué BUs están debajo de la del usuario en la jerarquía. Cuantas más BUs y más niveles de profundidad, más complejo es este cálculo.
Mi recomendación general es mantener la jerarquía lo más plana posible, idealmente no más de 3-4 niveles de profundidad. Si te encuentras creando una jerarquía de 6 o 7 niveles que replica exactamente tu organigrama de 15 niveles, probablemente estás sobre-ingenierizando.
Igualmente, evita crear BUs "por si acaso". Cada BU tiene un costo administrativo y de complejidad. Crea BUs cuando haya una necesidad clara de seguridad, no preventivamente.
La BU raíz y los usuarios especiales
¿Dónde deberían estar los administradores del sistema? La respuesta tradicional es en la BU raíz, y hay buenas razones para ello. Un administrador con privilegios a nivel Organization puede ver todo independientemente de dónde esté, pero estar en la BU raíz clarifica que están "arriba" de la estructura operativa.
Lo que sí debes evitar es tener demasiados usuarios en la BU raíz. Si has creado una jerarquía de BUs para segmentar datos pero luego pones a todos los usuarios en la raíz, toda esa estructura no sirve de nada. Los usuarios deben estar en las BUs "reales" que corresponden a su función, no en la raíz por defecto.
Puntos clave
- Las BUs definen fronteras de seguridad, no solo estructura organizacional
- Cada usuario pertenece a exactamente una BU - esto determina su visibilidad con niveles BU y Parent:Child
- La BU raíz no puede eliminarse y está en la cima de la jerarquía
- Diseña la estructura basándote en requisitos de acceso a datos, no en el organigrama
- Mantén la jerarquía lo más plana posible (3-4 niveles máximo)
- Mover usuarios entre BUs tiene implicaciones de propiedad de registros