Skip to main content

Decisiones de arquitectura de Business Unit

Cuándo partir un tenant en múltiples Business Units, cuándo quedarse single-BU, los cuatro patrones comunes (por-marca, por-región, por-producto, padre+sandbox), qué se propaga desde el padre vs qué está aislado, y el checklist de decisión antes de crear una BU nueva. Anclado a los rollouts multi-tenant de Cleon y los costos de migración de equivocarse con la arquitectura.

Marco de decisión·Actualizado 2026-05-19·Escrito por Lira · Editado por German Medina

Las Business Units son el mecanismo de Marketing Cloud para dividir un tenant en sub-tenants independientes — audiencias separadas, Send Definitions separadas, Automations separadas, API users separados. La decisión de usar multi-BU (o quedarse single-BU) es una de las elecciones arquitectónicas más grandes en una implementación de MC. Se hace una vez en bootstrap y es difícil de deshacer, porque cada asset creado vive en una BU específica y no hay operación para moverlo a otra BU — solo recrear. Ver gotchas — #2.

Esta página es el framework de decisión para esa elección. Recorre los cuatro patrones comunes de BU y cuándo encaja cada uno, la tabla de qué se propaga desde BUs padre vs qué controla cada BU independientemente, más el checklist que Cleon recorre antes de crear cualquier BU nueva.

El árbol de decisión

Arrancá acá ─→ ¿El tenant envía a audiencias disjuntas
                que nunca deberían ver el data de la otra?
                ├── Sí ─→ Candidato multi-BU. Seguí.
                └── No ─→ BU única. Pará acá.
                          
Candidato multi-BU ─→ Elegí el eje de separación:
                       ├── Por marca       (Acme + Acme Pro + Acme International)
                       ├── Por región      (Americas + EMEA + APAC)
                       ├── Por producto    (Newsletter + Promo + Support)
                       └── Padre + sandbox (Producción + Staging)
                       
BU por-eje ─→ Para cada BU que crearías, preguntá:
              ├── ¿Los users en esta BU necesitan acceso SOLO a su data?
              ├── ¿Los Sender Profiles + From Names son distintos acá?
              ├── ¿Las Send Classifications son regulatoriamente distintas?
              └── ¿Esta BU va a enviar al menos mensualmente?
              
Si las 4 son sí ─→ Creá la BU.
Si alguna es no ─→ Reconsiderá; el trabajo puede no justificar el overhead operacional.

Los cuatro patrones comunes

| Patrón | Cuándo encaja | Costo | |---|---|---| | Por marca | Acme + Acme Pro + Acme International — identidades de marca verdaderamente independientes, distintas entidades legales, distintas políticas de Privacidad | Overhead operacional alto (Sender Profiles separados, SAPs separados); costo de compartir audiencia medio (muy raro) | | Por región | Americas + EMEA + APAC — distintos requerimientos de data-residency (GDPR vs CCPA vs LGPD), distintos defaults de locale | Overhead operacional medio (equipos regionales + auditoría); costo de compartir audiencia bajo (sends regionales no se solapan) | | Por producto | Newsletter + Promo + Transactional — distintos perfiles de volumen (transaccional necesita reputación de sender separada del marketing) | Overhead operacional bajo si los productos comparten la mayoría de la config; costo de compartir audiencia alto si el mismo subscriber recibe emails de cada producto | | Padre + sandbox | Producción + Staging dentro del mismo tenant (si tu edición de MC lo permite) | Costo ongoing bajo; costo SAP de una vez alto (cada BU recibe su propio SAP); valioso para testear cambios de config con seguridad antes de que peguen en prod |

Elegí el eje primario primero, después agregá más BUs solo cuando el segundo eje esté independientemente justificado. Un tenant con Acme-Americas-Newsletter, Acme-Americas-Promo, Acme-EMEA-Newsletter, Acme-EMEA-Promo son cuatro BUs en dos ejes — operacionalmente caro, justificado solo cuando los dos ejes son verdaderamente disjuntos.

Qué se propaga desde la BU padre

Esta es la tabla que necesitás antes de decidir si una división de BU ayuda:

| Item | Comportamiento | |---|---| | Subscriber Attributes (perfil All Subscribers) | Compartido entre todas las BUs — definido una vez a nivel enterprise | | Master Subscriber List (_Subscribers) | Compartida entre todas las BUs por default; las sub-BUs ven todos los subscribers | | Data Extensions | Creados en una BU específica; no automáticamente compartidos. Para compartir, usar Shared DEs de Enterprise 2.0 explícitamente | | Sender Profiles | Creados en una BU específica; pueden clonarse entre BUs pero no auto-propagados | | Sender Authentication Package | Por-BU; cada BU tiene su propio dominio de envío + DKIM + alineación DMARC | | Defaults de From Address / Reply Address | Por-BU; el setting a nivel BU overridea cualquier default a nivel cuenta | | Send Classifications | Definidas a nivel enterprise; disponibles para todas las BUs salvo restricción | | Installed Packages | Instalados en la BU padre; toggle Available in this Business Unit por-BU (ver gotchas — #6) | | Permisos de usuario | Por-BU; un usuario puede tener roles distintos en BUs distintas | | Credenciales API | Atadas a BUs específicas vía el scope a nivel BU del Installed Package | | Automations | Por-BU; no pueden referenciar assets de otra BU directamente | | Journeys | Por-BU; pueden leer DEs de BUs hermanas solo vía configuración explícita de Shared DE | | Audit Trail | Por-BU; los eventos de audit muestran el contexto de BU pero los logs son tenant-wide |

La conclusión: la mayoría de los assets son por-BU (DEs, Sender Profiles, Automations, Journeys), mientras que la identidad es compartida (Subscriber Attributes, Master Subscriber List). La falla del hand-off pasa cuando los equipos asumen que los DEs se propagan hacia abajo desde un padre — no lo hacen. Un DE creado en el padre es invisible a las BUs hijas salvo que se comparta explícitamente.

Patrones a preferir

Arrancá con una BU; partila cuando un eje sea inequívoco

El tenant single-BU es el más barato de operar. Multi-BU agrega overhead operacional en cada capa: cada Sender Profile es por-BU, cada credencial API es por-BU, cada Automation vive en una BU, cada reporte está filtrado por BU. Difería la partición hasta que al menos uno de: límite regulatorio, requerimiento de reputación de sender, o disjuntez de audiencia sea inequívoco.

Documentá el eje de la BU explícitamente

Nombrá cada BU con una convención que encode su eje. Acme-Brand-Newsletter o Acme-Region-EMEA se lee correctamente seis meses después del rollout. BU_2 o Acme Sub no. La convención Cleon: el nombre de la BU incluye la etiqueta del eje y el valor (ej. Acme-Region-Americas no solo Acme-Americas).

Defaulteá BUs nuevas con toggles explícitos de Installed Package

Después de crear una BU, inmediatamente recorré la lista de Installed Packages y explícitamente toggleá Available in this Business Unit ON u OFF para cada uno. Default-on (el path de menor resistencia) significa que cada credencial API que tiene el padre ahora es usable en la BU nueva; default-off y tenés que deliberadamente agregar cada una. La convención Cleon: default-off, agregá explícitamente cada package por BU.

Corré un test de "primer send" desde cada BU nueva antes de abrirla a usuarios

El test de smoke atrapa Sender Profiles mal-configurados, fallas de propagación de SAP, y toggles faltantes de Installed Package antes de que arranque el trabajo real de producción en la BU nueva. El patrón de test send de setup de SAP — Paso 6 aplica a cada BU nueva.

Usá Shared DEs de Enterprise 2.0 con moderación y documentá cada uno

Los Shared DEs son el mecanismo legítimo para acceso a data cross-BU. También son un vector de confusión (¿qué BU escribe? ¿qué BU lee?). Cada Shared DE debería tener un dueño documentado (la BU que escribe), readers documentados (las BUs que leen), y una review de schema al crearlo. Sin documentación, la segunda persona que hereda el Shared DE no sabe con quién puede hablar al respecto.

Planeá SAP por-BU antes de activar cualquier send de producción

Cada BU necesita su propio SAP completo (ver setup de SAP). Correr sends de producción desde una BU con el dominio de tracking default es el desastre de deliverability cubierto en gotchas — #9. La convención Cleon: una BU no está "activa para enviar" hasta que su SAP esté completo y un test send lo verifique.

Patrones a rechazar

"Simplemente creá otra BU" como band-aid para colisiones de nombres

Si dos equipos quieren usar el mismo nombre de DE con schemas distintos, crear una BU separada por equipo no resuelve el problema — solo lo mueve. El fix real es nombrar los dos DEs distinto y mantenerlos en la misma BU donde se pueden operar juntos.

Una BU por campaña

Las BUs a nivel campaña son operacionalmente catastróficas. Cada campaña necesita su propio Sender Profile, su propio trabajo de SAP, su propio audit trail. Las campañas son Send Definitions o Journeys; deberían vivir adentro de una BU, no ser una BU.

Reads cross-BU vía "todos tienen acceso a todo"

Si le das a cada usuario acceso a cada BU, anulaste la separación. O comprometete con la separación de BU con el modelo de acceso por-BU que viene con eso, o quedate single-BU y usá Folders + naming de DE para organización.

Sandbox-sin-SAP

Una BU "Sandbox" que usa el SAP de la BU padre (o ningún SAP para nada) está enviando desde el dominio equivocado — confundiendo destinatarios y quemando reputación de sender cuando los test sends llegan accidentalmente a subscribers reales. O la BU Sandbox tiene su propio SAP usando un subdominio dedicado (ej. sandbox-mail.yourbrand.com), o no envía externamente para nada.

Mover assets entre BUs

No hay operación mv. Si te encontrás queriendo mover assets entre BUs, la arquitectura de BU está mal — pausá el trabajo, replanteá el eje de BU, recreá en la ubicación correcta. Hacer esto una vez durante bootstrap cuesta días; hacerlo después cuesta semanas.

BU por-producto cuando los productos comparten audiencia

Si el mismo subscriber recibe emails de Acme-Newsletter, Acme-Promo, y Acme-Support, partirlos entre BUs duplica la carga de mantenimiento de subscribers — cada cambio de lista tiene que aplicarse tres veces. Quedate single-BU y usá Send Classifications + Folders para separar los productos operacionalmente.

El checklist de decisión antes de crear una BU nueva

Antes de crear cualquier BU nueva, recorré este checklist:

  • [ ] El eje de separación es inequívoco (marca, región, producto, sandbox)
  • [ ] Al menos uno de los cuatro criterios "regulatorio / reputación de sender / disjuntez de audiencia / acceso de usuario" justifica la BU nueva
  • [ ] El volumen de send esperado de la BU es al menos mensual (BUs de bajo volumen no ganan su overhead)
  • [ ] El Sender Authentication Package se va a configurar por-BU antes de que cualquier send de producción dispare
  • [ ] La lista de Installed Packages fue auditada; cada uno está explícitamente toggleado para la BU nueva
  • [ ] Un Sender Profile está configurado para la BU nueva con el From Name + Reply Address correctos de marca
  • [ ] Al menos un test send verificó el SAP de la BU end-to-end (ver setup de SAP — Paso 6)
  • [ ] El acceso de usuario es por-BU; nadie tiene acceso por default; el acceso se otorga explícitamente
  • [ ] El nombre de la BU sigue la convención de naming (etiqueta del eje + valor)
  • [ ] Una review documentada de "primer mes después de la creación" está scheduleada para atrapar drift antes de que se componga
  • [ ] La decisión está documentada en el runbook de infraestructura del equipo (qué eje, qué BUs, quién posee cada una)

Cuando los once se disparan, la BU está lista para crearse. Si alguno es poco claro, la respuesta es "no crees la BU todavía" — el costo de una BU injustificada es años de arrastre operacional.

Relacionado

Progreso del catálogo: con esta página, Config tiene 3 page-pairs (gotchas + setup de SAP + arquitectura de BU). Siguiendo la forma SQL/SSJS/AMPscript, las próximas piezas apuntan a Send Classifications (reference), arquitectura de Data Extension (production-note), estrategia de Subscriber Key (decision-framework), y el Style Guide de Config.