En este post, veremos cómo los formularios con Business Process Flows pueden verse afectados al guardar registros o mover pasos en un GMP, lo que puede ocurrir antes o después de desplegar su código en un nuevo entorno. También veremos cómo resolver estos errores en general.

Vamos a crear un nuevo flujo de proceso de negocio en la siguiente dirección https://flow.microsoft.com/:

Lo llamaremos flujo de Carl, en la entidad Cuenta :

El flujo tiene 2 pasos:

Si creamos una nueva cuenta, vemos el flujo :

Ahora añadamos esto a una solución:

Llamado Carl’s GMP:

Añadiremos todos los componentes: el GMP, el rol de seguridad, la entidad de cuenta y la nueva entidad creada en el GMP:

Exportemos la solución:

Haga clic en Siguiente:

Y la exportación :

Tenemos nuestra solución de exportación:

Ahora vamos a importarlo a otro entorno. Considere el primer entorno como su entorno de desarrollo y éste como su entorno de pruebas.

Haga clic en Importar al entorno de prueba :

Elige el ZIP :

Activar el flujo.

Ahora asegúrate de que la aplicación a la que estás conectado tiene BFP, por ejemplo, la aplicación por defecto.

Vamos a crear una nueva cuenta. Vemos el GMP, genial:

Haga clic en Guardar. Recibimos el mensaje de error «Access Is Denied. No tiene suficientes privilegios para acceder al objeto de Microsoft Dynamics 365 o realizar la operación solicitada. Para obtener más información, póngase en contacto con su administrador de Microsoft Dynamics 365.» Haga clic en Ver detalles :

Ver los detalles y descargar el archivo de registro no nos dice mucho – «at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.CreateInternal(Entity entity, InvocationContext invocationContext, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode, Dictionary`2 optionalParameters)» etc :

El verdadero mensaje de error está oculto. Pulsemos F12 y vayamos a las herramientas de desarrollo del navegador:

Salvando de nuevo, vemos :

En mi caso – POST https://crm308991.crm.dynamics.com/api/data/v9.0/$batch 403.

Al hacer clic en él, se accede a la pestaña Red. Vemos la solicitud de $batch:

Esto nos da :

Abramos el error en VS Code :

Este es un error 403 Forbidden. Vemos varias pistas en el documento, como CallerPrincipal, PrincipalId, etc., que nos indican que un proceso está fallando.

Lo interesante es este bloque, que indica que el privilegio mínimo requerido para AppendToAccess es Local, y hace referencia al privilegio prvAppendToWorkflow:

«RightsToCheck»:AppendToAccess»,RoleAccessRights»:None»,PoaAccessRights»:None»,HsmAccessRights»:None»,Messages»:[PrincipalHasOwnerPrincipalWithAtLeastBasicPrivilegeDepth=False»EntityUserGroupRights=None»MinimumPrivilegeDepthRequired=Local»GrantedRights=None»SecLib::AccessCheckEx2failed[PrincipalHasOwnerPrincipalWithAtLeastBasicPrivilegeDepth=False»EntityUserGroupRights=None»MinimumPrivilegeDepthRequired=Local»GrantedRights=None»SecLib::AccessCheckEx2failed[«PrincipalHasOwnerPrincipalWithAtLeastBasicPrivilegeDepth=False»»EntityUserGroupRights=None»»MinimumPrivilegeDepthRequired=Local»»GrantedRights=None»»SecLib::AccessCheckEx2failed[”PrincipalHasOwnerPrincipalWithAtLeastBasicPrivilegeDepth = False””EntityUserGroupRights = None””MinimumPrivilegeDepthRequired = Local””GrantedRights = None””SecLib::AccessCheckEx2 failed
En Roles de Seguridad, necesitamos un rol con este nivel de acceso. Añadámoslo a nuestro papel. Está en Personalización, llamado Proceso, el privilegio AppendTo:

Una vez definido esto, podemos registrar nuestro formulario:

Ahora, si tenemos un registro existente y tratamos de pasar al siguiente paso en un flujo de proceso de negocio sin definir este privilegio de seguridad:

Veríamos que el error real aparece en la interfaz de usuario:

Por lo tanto, establezca el privilegio y debería ser capaz de desplegar sus flujos de procesos de negocio con el acceso apropiado. Espero que esto te ahorre algún que otro dolor de cabeza.