Prácticas recomendadas para Dataverse

5 minutos

El modelado de datos es una ciencia, y existen profesionales y estándares establecidos para el modelado de datos. Para utilizar de forma eficaz el modelado de datos de Dataverse, no es necesario ser un modelador de datos profesional ni utilizar herramientas especiales. Se pueden utilizar herramientas populares como Microsoft Visio para crear rápidamente un diagrama de relación entre entidades (ERD) básico que visualice las relaciones y el flujo de datos entre tablas.

En esta unidad nos centraremos en algunas prácticas recomendadas generales para el modelado de datos para implementaciones de Dataverse, entre las que se incluyen:

Los modelos de datos deben actualizarse continuamente durante una implementación. Con frecuencia, un modelo de datos se diseña al comienzo de un proyecto, pero es importante que el proceso de diseño no se detenga en ese momento. A medida que avanza en la implementación, se agregarán nuevas columnas y tablas. Debe capturar estas nuevas columnas y tablas en el modelo de datos y convertirlo en un modelo de datos vivo. Además, debe recomendar a los clientes que sigan actualizando el modelo de datos a medida que mejoran el sistema.
Utilice las herramientas establecidas para ayudarlo a comenzar con el proceso. Hay herramientas de la comunidad disponibles con XrmToolBox que facilitan la generación rápida de diagramas ERD de su configuración de Dataverse. Entre estas herramientas se incluyen el generador de diagramas UML y el creador de diagramas de relación entre entidades. Después de completar las actualizaciones de configuración, puede generar un diagrama ERD actualizado.
No incluya cada tabla. Algunas tablas principales, como Actividades, Notas y Usuarios (propietarios de registros) están relacionadas con prácticamente todas las tablas de Dataverse. Si incluye todas las relaciones con estas tablas en su modelo de datos, el resultado será ilegible. La práctica recomendada es incluir solo las tablas principales utilizadas en la configuración en su diagrama de modelo de datos, y solo incluir relaciones personalizadas con las tablas Usuario y Actividad para maximizar la legibilidad.
Los modelos de datos deben incluir tablas externas de Dataverse. Si se está integrando con otros sistemas mediante conectores de datos o tablas virtuales de Dataverse, o si se está integrando con flujos de datos que se encuentran fuera de Dataverse mediante una integración, estos datos también deben representarse en el diagrama del modelo de datos.
Comience de manera sencilla con las tablas estándar y luego agregue relaciones de tabla personalizadas al modelo de datos.
La experiencia debería influir en el modelo de datos. En ocasiones, es fácil normalizar los datos en exceso, pero en el proceso puede hacer que la aplicación sea más complicada de usar.

Comience con lo que necesita ahora, pero diseñe el modelo de datos de manera que respalde lo que va a hacer en el futuro. Por ejemplo, si sabe que finalmente necesitará almacenar más detalles sobre zonas de ventas, puede usar una columna de texto para la zona, lo que hará que sea más difícil de implementar que si usa la relación de tabla de zona. Planifique con anticipación lo que se avecina.

Tablas listas para usar o personalizadas

En este tema, identificamos tablas estándar listas para usar que se utilizan en la configuración, junto con tablas personalizadas y el propósito para el que se utilizan. Esta información es importante porque Microsoft Dataverse tiene muchas tablas comunes y, como regla general, no se debe crear una tabla personalizada si ya existe una tabla estándar que aborde ese propósito. La razón es que, si sobrecarga su configuración con muchas tablas redundantes, afectará negativamente al rendimiento del sistema y hará que el sistema sea más difícil de usar (con un alto número de tablas redundantes que confunden a los usuarios en la búsqueda avanzada). Cada tabla personalizada debe tener un propósito específico.

Además, este tema también ayudará a identificar las tablas más utilizadas y a determinar si está en riesgo de sobrecargarlas.

Plantéese reemplazar las tablas estándar por tablas personalizadas

En ocasiones, los creadores se plantean reemplazar la funcionalidad estándar por tablas personalizadas. El motivo es que si los creadores necesitan una oportunidad de venta, pero también un formulario más sencillo que el de la oportunidad estándar, se podría crear de forma más sencilla una tabla personalizada. Sin embargo, debe tener en cuenta a lo que puede estar renunciando si usa una tabla personalizada en lugar de una tabla estándar. El uso de una tabla lista para usar garantiza una mayor alineación con las características principales de la plataforma. Dado que se agregan más características con regularidad a las tablas estándar, puede beneficiarse de las nuevas características cuando se lancen. Por ejemplo, si decidió reemplazar la tabla de oportunidad estándar por una tabla de oportunidad personalizada, no podrá usar el complemento de Sales Insights para Microsoft Dynamics 365 Sales ni otras características de IA.

No vuelva a crear cuentas ni contactos

Al implementar soluciones de Microsoft Power Platform, por lo general, realizará un seguimiento de varios tipos de empresas, organizaciones y contactos en el sistema. Algunas de estas entidades representan a organizaciones de clientes, mientras que otras pueden ser organizaciones de asistencia y asesoría, como empresas jurídicas y de contabilidad. Algunas entidades pueden ser diversos tipos de organizaciones, como asociaciones de comercio.

El enfoque más común a la hora de gestionar varias categorías de relaciones de empresas es usar la tabla Cuenta para todos los tipos de organizaciones y una columna, como Tipo de relación, o un conjunto de opciones personalizadas para marcar empresas según su tipo o categoría. Puede filtrar las vistas según el tipo de empresa, y las reglas de negocio pueden mostrar u ocultar condicionalmente componentes de columna y formulario según el tipo.

Para beneficiarse de una integración estándar con aplicaciones de finanzas y operaciones de Dynamics 365 mediante el uso de la infraestructura de doble escritura, lo mejor es usar las tablas y columnas predeterminadas que la solución básica de doble escritura agrega al entorno de Dataverse.

Otro enfoque es crear tablas personalizadas para cada tipo de empresa. Una razón que suele usarse es "quizá necesite usar cuentas por otra razón en el futuro, por lo que no quiero personalizar la tabla de cuenta".

Antes de volver a crear la tabla Cuenta como una tabla de empresa personalizada, debe considerar seriamente a qué renuncia al crear una tabla personalizada. Tenga en cuenta los siguientes factores:

Varias direcciones: la tabla Cuenta tiene una capacidad de dirección única que admite varias direcciones. Las dos primeras direcciones se muestran en el formulario de la empresa, pero estos registros de direcciones se encuentran en la tabla Dirección del cliente relacionada. Si bien puede crear una tabla de dirección personalizada que esté vinculada a una tabla de empresa personalizada, la recreación de la lógica única donde las direcciones se almacenan en la tabla relacionada y se muestran en el formulario y las vistas de tabla requeriría desarrollo. Si necesita varias direcciones, use la tabla Cuenta.
Jerarquía de contactos: las cuentas son el elemento principal de los contactos. Las actividades relacionadas con los contactos se consolidarán en el registro de cuenta primaria. Esta jerarquía no se puede reemplazar por un registro de empresa personalizado. Puede crear más relaciones con tablas de empresa personalizadas, pero la relación de cuenta estándar/contacto no se puede reemplazar. Si la empresa tiene contactos con sus relaciones de empresa principales con este tipo de empresa, o si desea consolidar actividades de contactos a empresas, utilice la tabla Cuenta.
Control de mapa estándar: en aplicaciones basadas en modelo, el control de mapa estándar no admite tablas de empresa personalizadas.
Relaciones jerárquicas: las relaciones jerárquicas entre las cuentas primaria/secundaria y la visualización de jerarquía estándar, así como la consolidación de las actividades de la cuenta secundaria en la cuenta primaria, solo funcionan con tablas de cuenta estándar.
Columnas de búsqueda polimórficas: Dataverse incluye un tipo especial de columna de búsqueda polimórfica denominado columna de cliente. Esta columna permite vincular una fila a una empresa/cuenta o un contacto.
El marketing no funcionará: las listas de marketing solo pueden funcionar con contactos, cuentas y clientes potenciales, no con tablas personalizadas. Microsoft Dynamics 365 Customer Insights - Journeys puede enviar a cuentas y contactos, pero no a tablas de empresa personalizadas.

Por lo tanto, en casi todas las situaciones, la tabla Cuenta debe usarse para registros de empresas de todo tipo, con las siguientes excepciones:

Tipos menores de empresas que no son relacionales y tienen atributos mínimos. Piense en un tipo de organización sin contactos ni dirección y que solo existe con fines de búsqueda.
Empresas no calificadas o sin comprobar importadas desde tarjetas de presentación o formularios web que no queremos que contaminen la tabla Cuenta. Para estas situaciones, puede utilizar la tabla Cliente potencial.

Reutilice tablas del sistema

Supongamos que tiene un requisito empresarial que es similar a las oportunidades, pero que en realidad no es una oportunidad de ventas. En esta situación, podría plantearse la reutilización de las tablas del sistema o la creación de tablas nuevas.

En las siguientes secciones se explican los factores que debe considerar antes de reutilizar las tablas del sistema.

Piense en el futuro

El futuro de Microsoft Power Platform avanza más rápido que nunca, por lo que el uso de tablas de formas no estándar puede causar problemas si Microsoft realiza cambios en la tabla que está utilizando. Además, si elige reutilizar una tabla del sistema apenas usada, como Contratos, Microsoft podría optar por poner esa tabla en desuso en el futuro. Las tablas personalizadas no quedan en desuso. Asimismo, si reutiliza una tabla del sistema, piense en qué podría hacer si más adelante necesita esa entidad para los fines previstos. Clientes que han reutilizado un caso y, finalmente, cuando precisaban la administración de casos, tuvieron que abordarla por medio de tablas personalizadas, porque la tabla de caso estándar ya se usaba para propósitos diferentes.

Tenga en cuenta la sobrecarga

Muchas tablas del sistema tienen algunas columnas que no se pueden eliminar de los formularios. Por ejemplo, algunas columnas de tablas, como Caso de oportunidad y Campaña, no se pueden eliminar del formulario. Si bien puede ocultar estas columnas, tener varias columnas bloqueadas en el formulario puede agregar sobrecarga a la configuración del entorno.

Tenga en cuenta la experiencia del usuario

Si su caso de uso es inferior al 50 % en consonancia con la funcionalidad de la tabla estándar, una tabla personalizada suele ofrecer a los usuarios una experiencia de usuario más sencilla que reducir una tabla del sistema más compleja. También es posible agregar flujos de procesos de negocio a cualquier tabla, incluidas las tablas personalizadas, lo que puede hacer que la experiencia del usuario de una tabla personalizada sea igual o mejor que la reutilización de una tabla del sistema.

Evite errores comunes

Entre los problemas comunes del modelado de datos se incluyen:

Demasiadas tablas: probablemente normalizadas en exceso.
Demasiadas columnas en una tabla: probablemente debería haberse creado una tabla independiente.
Utilice las herramientas: formularios de vista rápida en lugar de columnas repetidas.
Evite el tipo de datos Sí/No: si se pueden agregar más valores o si necesita almacenarlos como desconocidos.
Errores de formato: está bloqueado continuamente con el formato de tipo de datos.
Piezas no utilizadas: evite crear piezas del modelo de datos que no tenga previsto utilizar.

Prueba de concepto

Dataverse facilita la creación de un entorno de prueba, y es una opción rápida para crear tablas y relaciones. Puede crear una prueba de concepto para probar su modelo de datos y comprobar cómo podría ser la experiencia del usuario.

Continuar