Los equipos permiten agrupar usuarios para colaboración y asignación de roles. Existen varios tipos con diferentes características y casos de uso que debes conocer para elegir el correcto.
Objetivos de aprendizaje
- Diferenciar entre los distintos tipos de equipos en Dataverse
- Saber cuándo usar Owner Teams vs Access Teams
- Implementar Azure AD Group Teams para gestión centralizada
- Diseñar una estrategia de equipos efectiva
Por qué existen los equipos
Los roles de seguridad son geniales para definir qué puede hacer alguien, pero surge un problema práctico: ¿cómo gestionas permisos cuando tienes cientos o miles de usuarios? ¿Asignas roles a cada persona individualmente? Eso se vuelve una pesadilla administrativa muy rápido.
Los equipos resuelven este problema permitiéndote agrupar usuarios y gestionar permisos a nivel de grupo. Asignas un rol a un equipo, y automáticamente todos los miembros del equipo obtienen esos privilegios. Cuando alguien nuevo se une, solo tienes que añadirlo al equipo. Cuando alguien se va, lo quitas. Simple.
Pero en Dataverse, el concepto de "equipo" va más allá de la simple agrupación. Hay varios tipos de equipos, cada uno diseñado para resolver problemas diferentes. Entender las diferencias es clave para usar la herramienta correcta en cada situación.
Owner Teams: los equipos tradicionales
Los Owner Teams (equipos propietarios) son el tipo más versátil y el que probablemente usarás más frecuentemente. Su característica distintiva es que pueden poseer registros.
¿Qué significa esto? En Dataverse, cada registro tiene un propietario, y ese propietario puede ser un usuario individual o un equipo. Cuando un equipo posee un registro, todos los miembros del equipo tienen acceso a ese registro según los privilegios del equipo.
Imagina un equipo de soporte nivel 2. Los casos escalados se asignan al equipo "Soporte L2" en lugar de a un individuo específico. Cualquier miembro del equipo puede trabajar el caso. Si alguien del equipo está de vacaciones, los demás pueden continuar sin problemas. No hay dependencia de una persona específica.
Características de Owner Teams
- Pueden tener roles de seguridad asignados directamente
- Pueden ser propietarios de registros (Accounts, Cases, Opportunities, etc.)
- La membresía se gestiona manualmente por administradores
- Pertenecen a una unidad de negocio específica
- Los miembros heredan los privilegios del equipo además de sus propios privilegios individuales
Un detalle importante: cada usuario puede pertenecer a múltiples Owner Teams, pero cada equipo pertenece a una sola BU. Esto significa que puedes usar equipos para dar acceso cruzado entre BUs. María está en la BU "Ventas España" pero pertenece al equipo "Proyecto Internacional" que está en la BU raíz. A través del equipo, María puede acceder a registros que normalmente no vería.
Access Teams: colaboración flexible
Los Access Teams son muy diferentes. No pueden poseer registros ni tener roles asignados. Su propósito es completamente distinto: permitir colaboración ad-hoc en registros específicos.
El escenario típico es este: tienes una oportunidad importante que normalmente solo vería su propietario, pero necesitas que varias personas de diferentes departamentos colaboren en ella. Podrías compartir la oportunidad individualmente con cada persona, pero eso crea múltiples registros de sharing que son difíciles de gestionar.
Con un Access Team, creas un "equipo" específico para esa oportunidad, añades las personas que necesitan acceso, y todos obtienen los permisos definidos en la plantilla del Access Team. Cuando el proyecto termina, el equipo se puede disolver sin afectar nada más.
Cómo funcionan los Access Teams
La mecánica es un poco diferente a los Owner Teams:
Primero, defines una Access Team Template a nivel de entidad. Esta plantilla especifica qué permisos tendrán los miembros del Access Team cuando se creen. Por ejemplo, una plantilla para la entidad Opportunity podría dar Read y Write pero no Delete.
Luego, en el formulario de la entidad (Opportunity en nuestro ejemplo), añades un subgrid o control que permite gestionar el Access Team de ese registro específico. Los usuarios con permisos adecuados pueden añadir o quitar personas del Access Team directamente desde el formulario, sin necesidad de ser administradores.
Cada registro puede tener su propio Access Team. El Access Team de la Oportunidad A es completamente separado del Access Team de la Oportunidad B.
Cuándo usar Access Teams
Access Teams brillan en situaciones de colaboración temporal y específica:
- Proyectos especiales que requieren personas de diferentes áreas
- Deals grandes donde participan múltiples roles
- Casos escalados donde varios especialistas necesitan acceso temporal
- Cualquier situación donde el sharing manual sería tedioso y difícil de mantener
AAD Group Teams: gestión centralizada desde Azure
Los Azure AD Group Teams (o Microsoft Entra Group Teams, usando el nuevo nombre) son relativamente nuevos y muy poderosos para organizaciones que ya gestionan sus grupos en Azure AD.
La premisa es simple: ya tienes grupos definidos en Azure AD para gestionar acceso a Office 365, SharePoint, Teams, etc. ¿Por qué no usar esos mismos grupos para Dataverse en lugar de crear una estructura paralela?
Un AAD Group Team está vinculado a un grupo de seguridad o grupo de Microsoft 365 en Azure AD. La membresía se sincroniza automáticamente. Cuando alguien es añadido al grupo en Azure AD (ya sea manualmente o mediante reglas dinámicas), automáticamente se convierte en miembro del equipo en Dataverse. Cuando es removido del grupo, pierde la membresía del equipo.
Beneficios de AAD Group Teams
Para organizaciones grandes con gestión centralizada de TI, las ventajas son significativas:
- Una sola fuente de verdad: La membresía se gestiona en Azure AD, no hay que mantener listas paralelas
- Onboarding automatizado: Cuando RRHH añade a alguien al grupo "Vendedores" en AD, automáticamente obtiene sus roles en Dataverse
- Offboarding automatizado: Cuando alguien deja la empresa y es removido de AD, pierde acceso a Dataverse automáticamente
- Auditoría unificada: Puedes ver la membresía de grupos desde las herramientas de AD que ya usas
Consideraciones importantes
Hay algunas cosas que debes saber antes de adoptar AAD Group Teams:
Funcionan como Owner Teams en cuanto a capacidades: pueden tener roles asignados y pueden poseer registros.
La sincronización no es instantánea. Hay un delay (generalmente minutos, a veces más) entre cambiar la membresía en Azure AD y que se refleje en Dataverse.
Los usuarios del grupo deben estar habilitados en el entorno de Dataverse. El simple hecho de estar en el grupo AD no les da acceso al entorno; deben tener licencia y estar provisioned primero.
El Default Team de cada BU
Hay un tipo especial de equipo que no creas tú: el Default Team. Cada unidad de negocio tiene automáticamente un Default Team que contiene a todos los usuarios de esa BU.
Su propósito principal es permitir asignar registros "a la BU" en general en lugar de a un usuario o equipo específico. Si tienes un registro que debería poder trabajar cualquier persona de Ventas España, puedes asignarlo al Default Team de Ventas España.
Eligiendo el tipo correcto
La decisión de qué tipo de equipo usar depende de tu escenario:
Si necesitas un equipo permanente que pueda poseer registros y tener roles, usa Owner Team. Esto cubre la mayoría de casos: equipos de ventas, equipos de soporte, departamentos funcionales, etc.
Si necesitas colaboración temporal en registros específicos y quieres que los propios usuarios gestionen quién tiene acceso, usa Access Team. Esto es perfecto para proyectos, deals grandes, o cualquier situación de colaboración ad-hoc.
Si ya gestionas grupos en Azure AD y quieres una sola fuente de verdad para membresía, usa AAD Group Team. Esto es ideal para organizaciones enterprise con procesos maduros de gestión de identidad.
Puntos clave
- Owner Teams pueden poseer registros y tener roles - usa para equipos funcionales permanentes
- Access Teams permiten colaboración ad-hoc gestionada por usuarios - para proyectos temporales
- AAD Group Teams sincronizan membresía desde Azure AD - para gestión centralizada de IT
- El Default Team incluye a todos los usuarios de una BU - evita asignarle roles
- Los usuarios pueden pertenecer a múltiples equipos de diferentes BUs para acceso cruzado