Uno de los aspectos clave en la implantación de un sistema de gestión empresarial, como Dynamics 365 CRM, es la correcta administración de la información en la herramienta. Desde un enfoque funcional, revisaremos las principales características que ofrece la herramienta para centralizar la información, mejorar su eficiencia y optimizar los flujos de negocio.
Tabla de contenidos
El desafío de la gestión de información en CRM
La gestión de la información en CRM ha presentado una gran variedad de desafíos en las implementaciones. En algunos casos, las empresas adoptan el estándar de Microsoft sin requerimientos adicionales, mientras que, en otros casos, las estructuras organizativas son tan complejas que no encajan fácilmente en un modelo relacional.
Además, suele ser necesario replantear el concepto desde diferentes perspectivas, lo que exige a los interlocutores un alto nivel de abstracción para comprender la flexibilidad y el alcance del sistema.
Dataverse: la base de datos de Dynamics 365 CE
Dataverse es la base de datos central utilizada en las aplicaciones de Customer Engagement (CRM), encargada de almacenar y estructurar la información de clientes, ventas y otros procesos.
La gestión de la información es propia de la base de datos, teniendo las mismas características (ventajas y desventajas) en todas las aplicaciones estándar: ventas, servicio al cliente, marketing, servicio de campo, operaciones de proyecto, etc.; así como cualquier aplicación “custom” basada en este modelo de datos.
La organización
La organización (también conocida como la unidad de negocio raíz) es el nivel superior en la jerarquía de unidad de negocio.
Las aplicaciones de Customer Engagement crean automáticamente la organización al aprovisionarlas. El nombre de la organización se deriva del nombre de dominio cuando se aprovisionó el entorno.
A los efectos, siempre encontraremos esta Unidad de Negocio Organización dentro de cualquier instancia de CRM, que representa el conjunto total de información de la base de datos y es un nivel de acceso a la información (como veremos en los roles de seguridad). Es la única unidad de negocio que no puede tener una unidad de negocio primaria.
Su configuración, no suele ser objeto de un requerimiento en particular por su naturaleza automática, salvo que se considere algún cambio en el nombre del dominio que se instanció originalmente. Todos los nuevos usuarios del sistema serán asignados de manera automática a la Organización.
Unidades de negocio
- Una unidad de negocio es una agrupación lógica de actividades de negocio relacionadas.
Si los procesos de negocio propios de la organización en cuestión están estructurados en departamentos o divisiones que tienen, (por ejemplo: productos, clientes y listas de marketing independientes) es necesario indagar específicamente sobre la posibilidad de formalizar dentro del sistema diferentes unidades de negocio.
En la mayoría de los casos, las empresas estructuran sus equipos en función de su visión, misión, objetivos estratégicos o necesidades operativas, administrativas y financieras.
Una compañía del segmento “Middle Market”, casi con toda seguridad, verá reflejada su estructura organizativa, en la estructura propuesta por la marca y será necesario indagar en los aspectos operativos requeridos antes de definir la configuración adecuada del sistema.
- Los usuarios pueden acceder de forma segura a los datos en su propia unidad de negocio, pero no pueden acceder a los datos en otras unidades.
Esta particularidad de las unidades de negocio añade un grado de abstracción, que es importante alcanzar con los dueños del producto (usuarios y demás) antes de fijar un camino a seguir en su implantación.
Si cada usuario sólo puede pertenecer a una unidad de negocio, por un lado, tenemos el concepto de “silo único informativo” que nos permite fomentar acciones de compromiso con el cliente, como el “crosselling”, o servicio postventa multidisciplinar y, por el otro, tenemos la necesidad de mantener un orden eficiente del trabajo que se sustenta en CRM. Y si por un lado, tenemos la virtud de segmentar la información vía unidades de negocio, por otro lado, tenemos la estanqueidad entre departamentos, pudiendo impactar negativamente en los procesos, sobre todo, operativos, duplicando acciones, perdiendo la visión 360, etc.
Por lo tanto, si la organización usuaria de CRM tiene una definición particular sobre esta cuestión, deberemos tener muy presente la posibilidad de poder ofrecer únicamente una “solución de compromiso”.
Los equipos
Cada Unidad de Negocio, tiene un Equipo (Propietario) con el mismo nombre que la Unidad y que agrupa a todos los Usuarios de esa Unidad de Negocio. Pueden existir varios Equipos dentro de una Unidad de Negocio.
Por definición, son una agrupación de usuarios, que, aun perteneciendo a una sola Unidad de Negocio, pueden incluir Usuarios de distintas unidades. Cada usuario puede pertenecer a uno o varios equipos.
En la práctica, los equipos propietarios son muy parecidos a un usuario en particular, ya que pueden ser propietarios de registros y tienen roles de seguridad asignados que pudieran modificar la seguridad asignada a sus miembros.
Es importante tener presente que, si bien un Equipo tiene acceso a las Unidades Negocio suma de los valores distintos de las Unidades de Negocio de sus miembros, no sucede igual con sus permisos, dado que, si el Equipo no tiene una definición más permisiva, los privilegios de los miembros responderán a la asignación individual de cada uno de ellos.
En Dynamics 365 CE, tenemos dos tipos de equipos: Acceso y Propietarios. Para entender la diferencia entre Equipos de Acceso y Equipos Propietarios, es clave conocer sus funciones dentro de Dynamics 365 CE. Mientras que los primeros se utilizan para compartir registros sin cambiar su propiedad, los segundos pueden ser propietarios de registros y definir permisos de seguridad.
- Equipos de Acceso
Un Equipo de Acceso no es propietario de registros propios y no tiene los roles de seguridad asignados al equipo. Los miembros del Equipo tienen privilegios definidos por sus roles de seguridad individuales y por los roles de los equipos de los que son integrantes.
Los registros se comparten con un Equipo de Acceso y a los integrantes del equipo se les asignan derechos de acceso sobre los registros, como Lectura, Escritura o Anexar.
Además de esto, los Equipos de Acceso se forman y se disuelven dinámicamente.
- Equipos Propietarios
Un Equipo de Propietarios tiene registros y roles de seguridad asignados. Los privilegios del Equipo se definen mediante roles de seguridad. Aunque los Equipos proporcionan acceso a un grupo de usuarios, se deben asignar roles de seguridad que concedan los privilegios necesarios sobre los registros propiedad del usuario en cuestión. Estos privilegios no se pueden aplicar asignando roles de seguridad a un equipo y después agregando el usuario a ese equipo.
Un Equipo Propietario tiene derechos de acceso total a los registros que posee el mismo, motivo por el cual los registros de la tabla deben ser propiedad del Equipo Propietario y no de solo uno de sus miembros.
El número de Equipos Propietarios suele definirse durante la fase de diseño del sistema Dynamics 365 CE, en función de la estructura organizativa y las necesidades operativas de la empresa.
Artículos recomendados:
- Nueva experiencia Intrastat en Dynamics 365 Business Central
- Cómo utilizar varios libros de amortización para activos fijos en Dynamics 365 Business Central
- Cómo automatizar tareas diarias con Power Automate y Dynamics CRM: Ejemplos concretos
Los usuarios
Un Usuario es cualquier persona que trabaje para una unidad de negocio que use Dynamics 365 Customer Engagement. Todos los usuarios deben estar asociados con una sola unidad de negocio, como hemos visto antes, en ausencia de otra asignación, pertenecerán a la Unidad de Negocio Organización, por ende, a su Equipo Propietario del mismo nombre.
Para poder acceder al CRM debe cumplir con una serie de requisitos:
- Disponer de un usuario de Active Directory (Entra) para esa Organización (dominio)
- Disponer de una licencia de uso de la aplicación
- En el caso de que el entorno de CRM esté regulado por un Grupo de Seguridad de Office, pertenecer al mismo.
Una vez cumplas con estos requisitos, estarás en disposición de ser nombrado usuario de ese CRM en particular y tras asignarte nominalmente un Rol de Seguridad podrás usar el sistema. Descontando el que esté activo el sistema de doble autenticación, ya podrás usar la herramienta.
Dejando a un lado los posibles matices aparentes relacionados con el nivel de licenciamiento (Enterprise, Profesional, Team Member, etc.), lo que determina la manera en la que un Usuario interactúa con la información de CRM, son sus asignaciones de Roles de Seguridad.
La asignación de un Rol de Seguridad a un usuario se realiza dentro de su Unidad de Negocio. Si el usuario cambia de Unidad de Negocio, será necesario reasignarle los roles de seguridad correspondientes.
Roles de seguridad
Los roles de seguridad se definen teniendo en cuenta tres aspectos de la base de datos:
- La tablas o entidades existentes (accesibles) de la base de datos y determinadas funcionalidades.
- Las operaciones que se pueden o no realizar sobre esas tablas.
- El alcance de las operaciones.
- Tablas y funcionalidades
Todas las tablas (accesibles) desde el punto de la seguridad se comportan igual, tanto las tablas propias del CDM (Modelo Común de Datos) que sigue Dataverse, como las tablas creadas exprofeso para responder a necesidades propias del negocio, pero con una serie de particularidades importantes:
- Todas las tablas tienen un Tipo (Estándar, Actividad, Virtual y Elástico). Según su tipo podrán tener o no un atributo Propiedad del registro (caso Estándar y Elástico) que podrá tomar los valores de Organización o Usuario o equipo. En el caso de definir Propiedad del registro Organización, las operaciones se definirán en términos de Organización o Nada, no siendo posible discernir Unidades de Negocio.
- Las tablas del Tipo Actividad no aparecerán en el conjunto de tablas asignables, respondiendo a la definición de privilegios de una sola tabla llamada Actividades.
- Las tablas del Tipo Virtual siempre se definen como de Propiedad de la Organización.
- La seguridad para las funcionalidades (ej: Exportar Excel) siempre se hace en términos de Organización o Nada.
- No todas las tablas tienen disponible la definición de todas las operaciones y/o todos los alcances.
- Operaciones
Son las acciones CRUD propias de todas las bases de datos (Crear, Leer, Escribir y Borrar), más algunas acciones propias del Dataverse:
- Anexar y Anexar a: hace referencia al control sobre el establecimiento de relaciones 1-n y n-1, es decir, que el usuario utilice un registro en particular como clave foránea en los atributos de otro (de su misma tabla o de otra) y al revés.
- Asignar: es la posibilidad o no de cambiar el propietario de los registros de una tabla.
- Compartir: esta operación es la de crear Equipos de Acceso.
La concreción más clara para explicar las implicaciones que el Alcance (Profundidad) de una Operación sobre una Tabla (privilegio), la encontramos en el atributo Propietario.
Como hemos visto en los registros de una Tabla, debido a la definición del Tipo de Tabla y de la Propiedad del Registro, pueden presentar excepciones en cuanto a su funcionamiento, pero todos los registros, tendrán por norma, un valor asignado para Propietario.
Se entiende que, si un Rol de Seguridad tiene definida para una Operación el Alcance Ninguna, no permitirá a los usuarios con ese Rol de Seguridad realizar esa Operación. En el otro extremo del Alcance, encontramos la Organización que implica que el usuario tendrá el Alcance máximo posible dentro de los registros de esa Tabla de la base de datos.
Una configuración muy utilizada del Alcance es Usuario. Nos sirve para otorgar al Usuario permisos de Operación sobre los registros si, y sólo si, son de su propiedad. Por todo lo explicado anteriormente, esto es extensible a los Equipos Propietarios, ya que pueden aparecer como valor en el campo Propietario de un registro.
Cuando existe definición clara de Unidades de Negocio y se implementan dentro de la Organización, tienen un papel relevante los valores de Alcance de Unidad de Negocio y Unidad de Negocio y Secundaria.
En la práctica, cuando un Rol de Seguridad tiene definido un Alcance de Unidad de Negocio, el usuario con ese Rol asignado podrá realizar la Operación en todos aquellos registros que tengan como Propietario algún miembro de la Unidad de Negocio. Al incluir las Unidades de Negocio Secundarias, sumamos los registros cuyos Propietarios pertenezcan a Unidades de Negocio que tengan como Unidad de Negocio primaria la del Usuario en cuestión.
Seguridad jerárquica
El modelo de seguridad de jerarquía es una extensión de los modelos de seguridad de Dynamics 365 CE existentes que ya hemos visto. Puede usarse junto con el resto de los modelos de seguridad.
La seguridad de jerarquía proporciona un acceso más específico a registros de una organización. En situaciones complejas, empezamos creando varias unidades de negocio y por último agregamos la seguridad de jerarquía permitiendo un acceso más específico a los datos.
La seguridad jerárquica admite dos enfoques: Administrador o Posición.
- Jerarquía de Administrador
El modelo de seguridad jerárquico de Administrador se basa en la cadena de administración o la estructura de subordinados directos, donde la relación del administrador y del subordinado se establece mediante el atributo “Administrador” del registro en la entidad de usuario del sistema.
El usuario seleccionado como Administrador de otro, debe estar dentro de la misma unidad de negocio que el otro, el usuario subordinado o, en la unidad de negocio primaria de la unidad de negocio del subordinado. Esto le permitirá tener acceso a los datos del subordinado.
Con este modelo de seguridad, los usuarios Administradores de otros podrán tener acceso a los datos a los que los tienen acceso sus subordinados directos, con la potestad de realizar todas las operaciones Lectura, Escritura, Actualización, Anexar, Anexar a. Pueden realizar acciones en el nombre de sus subordinados directos o acceder a información que necesita su aprobación.
Un administrador tiene el acceso de sólo lectura a los datos del subordinado no directo, en la misma cadena de administración.
- Jerarquía de Posición
Se definen diferentes posiciones de trabajo en la organización y se organizan en la jerarquía de Posición. Luego, definimos qué posición ocupa cada usuario. Si bien un usuario sólo puede tener definida una Posición, esta Posición no es exclusiva de un solo usuario, pudiendo varios usuarios tener esa misma posición.
Los usuarios de las posiciones más altas en la jerarquía tienen acceso a los datos de los usuarios de las posiciones de nivel más bajo, en la ruta de antecesor directo.
La jerarquía de Posición permite el acceso a los datos a través de unidades de negocio.
Las posiciones directas más altas tienen acceso con todas las operaciones disponibles a los datos de las posiciones inferiores en la ruta de antecesores directos. Las posiciones no directas más altas tienen acceso de Solo lectura a los datos de las posiciones inferiores en la ruta de antecesores directos.
La gestión de información en Dynamics 365 CRM requiere un equilibrio entre seguridad y accesibilidad. Comprender la jerarquía de organización, unidades de negocio, equipos y roles de seguridad es clave para diseñar una estructura eficiente que esté alineada con las necesidades operativas de cada empresa. ¿Quieres que te ayudemos? ¡Rellena el formulario y nuestros expertos se pondrán en contacto contigo!
Roberto Mena
Operaciones Dynamics 365