Configuración de conexión Dataverse

Tu portal se comunica con Dataverse como una aplicación en sí misma, no como el visitante que casualmente está navegando por él. Eso tiene dos partes: un registro de la app en Microsoft Entra ID que posee las credenciales, y un usuario de aplicación en tu entorno Dataverse que les da una identidad y un rol de seguridad. Esta página recorre ambas y el acceso que realmente necesita el portal.

Esta no es la app de inicio de sesión
Este registro es la identidad de servicio propia del portal: lee y escribe datos en nombre del portal, y sus credenciales van bajo D365:ClientId / D365:ClientSecret. Un segundo registro separado gestiona la entrada de usuarios con Microsoft. Manténlos separados: este no necesita URI de redirección ni permisos delegados, pero tiene mucho más poder dentro de tu entorno. Consulta la configuración de inicio de sesión de Entra ID

1. Registrar la solicitud

Crea el registro en el centro de administración de Microsoft Entra, en el tenant que posee tu entorno Dataverse.

Navega por Entra ID > Registros de la app y selecciona Nuevo registro.
Introduce un Nombre que identifique el portal y el entorno, por Contoso Portal — Dataverse (Production)ejemplo. Nadie ve esto en una pantalla de consentimiento, así que prefiere claridad para quien lo audite después.
En Tipos de cuenta soportados, elige Solo inquilino único. Esta identidad nunca abandona tu organización.
Deja el URI de redirección vacío. Ningún usuario es redirigido aquí: el portal se autentica con el flujo de credenciales del cliente, máquina a máquina, sin navegador involucrado.
Selecciona Registrarse.
En la página de Resumen , copia el ID de la aplicación (cliente). Ese valor se convierte D365:ClientIden , y lo necesitas de nuevo en el paso 4 para crear el usuario de la aplicación.

2. Crear un secreto para el cliente

El secreto es la única credencial del portal, así que trátalo como la clave de los datos de tu entorno.

Abre Certificados y secretos en Gestionar y selecciona la pestaña de secretos del cliente.
Selecciona nuevo secreto de cliente, descríbelo por entorno (por ejemplo portal-production), y elige un plazo de expiración.
Copia la columna Valor inmediatamente — no el ID Secreto. Solo se muestra una vez, y se convierte D365:ClientSecreten .

Importante
Cuando el secreto expira, el portal deja de llegar a Dataverse por completo — no solo para una función, sino para cada solicitud — así que pon la fecha de caducidad en algún lugar donde la verás. Para producción, una credencial de certificado evita el precipicio de caducidad y AuthenticationType.Certificate acepta una en lugar del secreto.

3. Permisos de API: No se requieren

Este paso está deliberadamente vacío, y eso sorprende a la gente. Muchas indicaciones antiguas te dicen que añadas el permiso delegado de Dynamics CRM → user_impersonation . Ese permiso es para aplicaciones que actúan en nombre de un usuario iniciado sesión. El portal no hace eso: se autentica como él mismo, y su acceso viene íntegramente del usuario de la aplicación Dataverse que crees en el siguiente paso.

Nota
La propia guía servidor a servidor de Microsoft dice lo mismo: cuando te conectas como app, no concedes Access Dynamics 365 como usuarios de la organización, porque la aplicación está vinculada a una cuenta de usuario específica. Añadirla no rompe nada, pero otorga una capacidad que el portal nunca ejerce — déjala desactivada.

4. Crear el usuario de la aplicación en Dataverse

El registro de la app por sí solo no puede tocar los datos. Dataverse necesita un registro de usuario vinculado a él, que es lo que convierte el id del cliente en una identidad que tu entorno reconoce.

Inicia sesión en el centro de administración de Power Platform.
Selecciona Gestionar en el panel de navegación, luego Entornos y después tu entorno.
Selecciona Configuración > Usuarios + permisos > Usuarios de la Aplicación.
Seleccionar + Nuevo usuario de la app.
Selecciona + Añadir una app y busca tu registro por nombre o por el ID del cliente desde el paso 1, luego selecciona Añadir. Solo aparecen registros en la app Entra en esta lista — las aplicaciones empresariales no.
Elige una unidad de negocio. La unidad raíz es la respuesta habitual; una unidad hija reduce lo que el portal puede alcanzar incluso antes de que se apliquen roles de seguridad.
Selecciona el icono de edición junto a Roles de Seguridad y asigna el rol que has creado para el portal — consulta el siguiente paso para ver qué debe contener.
Selecciona Crear.

Propina
Un usuario de aplicación no consume ninguna licencia de pago, y solo puedes tener una por cada registro de una app de Entra por entorno. Usa un registro separado para cada entorno para que la revocación del acceso al desarrollo nunca afecte producción.

5. Asignar al usuario de la aplicación un rol de seguridad

Crea un rol de seguridad personalizado en lugar de reutilizar uno incorporado, para que el acceso al portal sea visible y revisable. Lo que necesita el rol depende de qué características del framework utilices:

Qué hace el portal	Acceder a las necesidades del puesto
Sirve los datos de tu portal	Crear, leer, escribir y eliminar en cada tabla que exponga tu portal, en el alcance que pretendes que alcancen los visitantes. Este es la mayor parte del rol y es completamente específico para tu aplicación.
Registros y inicios de sesión en los usuarios del portal	Crear, Leer y Escribir en `contact`, más Crear, Leer, Escribir y Eliminar en `adx_externalidentity`, que almacena el enlace entre un usuario del portal y un inicio de sesión externo.
Vincula las cuadrículas a las vistas de Dataverse y formatea los valores	Sigue `savedquery` leyendo para conocer las vistas a las que se vinculan tus cuadrículas, y sigue `organization`leyendo, `usersettings` y `timezonedefinition` así fechas, números y formato de moneda correctamente.
Envía un correo de confirmación y restablecimiento de contraseña	Crear, Leer y Escribir en `email`, Crear en `activitymimeattachment`, más los privilegios de Enviar Correo y Enviar Correo como Otro Usuario . La dirección del remitente que configuras se resuelve a `queue` un registro o `systemuser` , así que el rol también necesita Leer en esos — por eso enviar como esa dirección cuenta como enviar como otro usuario.
Valida la licencia del sitio web	Permiso para ejecutar la `ppp_ProWebsiteLicenseCheck` acción y leer los registros del portal web que se envían en la solución gestionada. Sin esto, todos los endpoints con licencia fallan.
Seguridad nativa de Dataverse (opcional)	Solo si activas el modelo de seguridad de vista previa: Crear y seguir `systemuser`leyendo, leyendo sigue `businessunit`, Crear y leyendo en `powerpagesusermapping`, leyendo y `powerpagesite` `mspp_webrole`, y la Ley de privilegios en nombre de otro usuario para que el portal pueda suplantar a cada usuario provisionado.

Importante
Resiste la tentación de asignar un Administrador de Sistema y sigue adelante. El portal está orientado a internet, y esta credencial es la que decide a qué llega un atacante si el secreto llega a filtrarse. Vale la pena la tarde que se tarda en construir un papel real — y un entorno de desarrollo es el lugar adecuado para descubrir qué te perdiste.

6. Guardar la configuración de conexión

El portal los lee desde la configuración en la D365 sección. Guárdalos en secretos de usuario durante el desarrollo para que nunca lleguen al control de versiones:

EmailSenderEmailAddress es la dirección desde la que se envía el correo saliente del portal. Debe coincidir con a queue o habilitado systemuser en el entorno — la cola es la opción habitual, ya que no vincula el correo del portal a una persona que podría marcharse más adelante.

Propina
En entornos alojados, suministra las mismas claves que variables de entorno o desde una tienda secreta, usando un doble guion en lugar de los dos puntos — D365__ClientId, D365__Secret — porque el separador de dos puntos no es portátil entre plataformas.

7. Conectar la conexión

El proyecto servidor se ConnectionOptions configura al registrar el framework:

La plantilla del proyecto escribe esto por ti, así que en un proyecto generado no hay nada que añadir aquí — proporciona los tres valores de configuración y la conexión funciona. Inicia el portal y navega a cualquier página respaldada por datos de Dataverse para confirmarlo.

Resolución de problemas

El que llama no es un usuario válido de Dataverse, o la autenticación falla por completo. El registro de la aplicación existe, pero ningún usuario de la aplicación está vinculado a él en este entorno. Los usuarios de la aplicación son por entorno — crear uno en desarrollo no aporta nada a la producción.
La autenticación falla con un secreto cliente inválido. Normalmente se copió el ID del secreto en lugar del valor del secreto, o el secreto ha expirado. Crea uno nuevo y actualiza la configuración.
Un principal carece de un privilegio. El rol del usuario de la aplicación carece de acceso a la tabla nombrada en el error. Dataverse almacena en caché los privilegios por nodo servidor, así que permitir uno o dos minutos después de cambiar un rol antes de concluir el cambio no ayudó.
Cada endpoint de datos devuelve 402. La comprobación de licencias del sitio web está fallando. Confirma que la solución gestionada está instalada, que un registro del portal web contiene tu clave de licencia y que el rol del usuario de la aplicación puede ejecutarse ppp_ProWebsiteLicenseCheck.
El correo falla con "No se puede encontrar un remitente con la dirección de correo".EmailSenderEmailAddress No coincide con ninguna cola ni usuario habilitado del sistema en el entorno.