Seguimiento de actividades mediante publicaciones automáticas

Muchas veces encontramos en las escalas de tiempo (o timeline) de los diferentes registros un montón de publicaciones automáticas que o no nos sirven para nada o nos salvan la vida para conocer que ha pasado con ese registro, dejando una traza de gran valor.

Existen diversas publicaciones ya configuradas de sistema. Para poder activar y desactivar las reglas de estas publicaciones podemos ir a configurar su comportamiento en la Configuración avanzada (por suerte todavía lo encontraréis en la interfaz web legacy, porque en la nueva no se encuentra nada).

Dentro del menú encontraremos las entradas de Configuración de Fuentes de actividades y Reglas de Fuentes de actividades.

Configuración de Fuentes de actividades

En este componente se muestra todas las actividades que están configuradas para tener fuentes de actividades. Estas entidades pueden estar activas o inactivas y recibirán o no las publicaciones automáticas que se generen.

Para activar o desactivar una entidad es tan fácil como seleccionarla y se mostrarán en la barra de botones los botones Activar y Desactivar.

Reglas de Fuentes de actividades

En las reglas de fuentes de actividades nos mostrará todas las reglas configuradas de sistema para las publicaciones automáticas.  Las reglas están agrupadas según la entidad en la que actúan y a su vez pueden estar activas o inactivas, pudiéndose elegir que en una entidad solamente se lancen ciertas reglas.

Si pulsamos sobre una entidad nos llevará a la definición de reglas que tenga esa entidad, viéndolas todas conjuntas.

La verdad es que poca configuración se puede realizar sobre estas Fuentes de actividades de sistema, como mucho activar o desactivarlas, pero ¿qué pasa si queremos crear una publicación que no exista o para una entidad personalizada?

Fácil solución, creamos un workflow y en un paso creamos un registro de la entidad Publicación, donde detallaremos el mensaje y tipo de publicación que realizamos.

Publicación personalizada

En el sistema ya existen publicaciones pre-configuradas en las reglas de fuentes de actividades que se envían registros de entidades de sistema a una cola, pero no cubren todas las necesidades que podamos tener.

En este ejemplo vamos a crear una nueva publicación automática para un caso que nos informará cuando un registro se ha quitado de la cola en la que se encuentra.

Para realizar una publicación personalizada tenemos que realizar un workflow que cree un nuevo registro de la entidad Publicación, así que vamos a crear un nuevo flujo de trabajo asíncrono vacío de la entidad Elemento de cola que nos controlará los cambios en los elementos de cola de los registros de la entidad personalizada.

Nuestro flujo de trabajo debe quedar más o menos así, dependiendo de la lógica que se quiera aplicar para los casos particulares de cada uno.

El proceso se realiza sobre la entidad Elemento de cola y la condición de ejecución del proceso cuando se elimina el elemento de cola, ya que cuando hacemos la acción de quitar un elemento de cola lo que sucede es que el sistema elimina el registro.

En el cuerpo del proceso incluimos la comprobación para determinar si el objeto que contiene el elemento de cola es de tipo caso y en caso positivo actuamos creando un registro de la entidad Publicación.

• Incluimos el texto que queremos que se muestre (campo Text) 
• Indicamos el origen de la publicación (será una publicación automática, pero podíamos haber creado una publicación manual o un mensaje de ActionHub)
• Añadimos el campo Referente a al que hace referencia la publicación (el registro al que va a hacer referencia en este ejemplo es el caso que contiene el elemento de cola)
• Finalmente indicamos el tipo de publicación que se mostrará (elegimos una publicación de tipo Estado, esto determinará el icono que se muestre en la publicación y su comportamiento)

Una vez creado activamos el proceso y elegimos un caso que se encuentre en una cola. Al pulsar el botón Quitar de la barra de botones se producirá la magia.

Acudimos al caso y podremos ver en nuestra escala de tiempo el mensaje creado junto a los mensajes pre-configurados de sistema que tenemos activados.

Ahora ya podéis crear las publicaciones automáticas que necesitéis para dejar las trazas de movimientos en la escala de tiempo.

Quiero agregar un elemento a una cola, pero no se muestra la cola que quiero, ¿qué pasa?

¡Menos mal que existen las comunidades de usuarios!

Me he encontrado con un problema que no había manera de solucionar, pero gracias al Microsoft Dynamics CRM Forum un compañero de fatigas posteó donde encontrar la solución.

Vamos al lío.

De la noche a la mañana, en nuestro entorno de Dynamics cuando se quería agregar un elemento a una cola desapareció una de las colas más solicitadas. El pop-up de sistema con la lista de colas a las que agregar el elemento no incluía la cola deseada.

Rebusqué información sobre este caso, pero no fue muy fructífero, nada concluyente.

Revisando más a fondo vi que en otras vistas la cola aparecía, pero en la vista que se cogía por defecto no aparecía. ¿Cómo podía ser que la cola existiera, que se viera en otras vistas, pero no en esa vista por defecto?

Mirando las diferentes vistas de cola encontré la cola problemática: Colas de negocio (predeterminado).

Si vais a ver la configuración de la cola descubriréis que no es una cola al uso, es diferente, de sistema, y no se puede tocar ni ver que condiciones tiene.

Entonces, ¿cómo está haciendo el filtrado de las colas?

La verdad, ni idea, lo hace el sistema por detrás y no te deja ni verlo.

Buscando información sobre el tema topé con esta pregunta en Microsoft Dynamics CRM Forum, justamente mi problema.

https://community.dynamics.com/crm/f/microsoft-dynamics-crm-forum/193851/business-queues?pifragment-97030=1

La referencia de la solución no podía ser más clara y concisa, Power Platform & Dynamics CRM Tip Of The Day.

https://crmtipoftheday.com/170/there-is-no-queue-like-business-queue/

¡Genial! Ya lo tenía. Tan simple y tan complejo como que la cola desaparecida se ha especificado como Cola indicada (queueid) de un usuario.

Tan fácil como encontrar al usuario que tiene esa cola en el campo y cambiársela, pero esto no es así. Cuando acudes a una vista avanzada para ver los usuarios que tienen esa cola descubres que el campo Cola indicada no se puede visualizar ni filtrar. ¿entonces?

Bueno, yo he recurrido a Microsoft SQL Server Studio para hacer una consulta sobre la tabla systemuser con una cláusula de filtro con el GUID de la cola desaparecida para que me muestre los usuarios que tienen esa cola.

SELECT fullname

FROM systemuser

WHERE queueid = 'ABCDEF12-0000-0000-0000-ABCDEF123456'

De esta manera encontré los usuarios que tenían la Cola indicada con el valor de la cola desaparecida y ya solo faltaba ir al usuario y cambiarle el valor por su cola individual (la que tiene el formato <Nombre del usuario>).

Si alguien se ha preguntado alguna vez para que sirve el campo Cola indicada (queueid) que hay en el formulario de usuario, ya tiene una respuesta: 

Para complicar la existencia y generar problemas con las colas.

La clase de Coco: Establecer valor predeterminado vs. Establecer valor de campo

"Hola, soy Coco y hoy vamos a aprender la diferencia entre las acciones Establecer valor predeterminado y Establecer valor de campo en las Reglas de negocio de Dynamics 365".

Así empezaría la clase diaria Coco, nuestro amigo inseparable de Barrio Sésamo que llenaba las tardes de nuestra infancia y con el que tanto aprendimos muchos de nosotros.

Y la verdad es que, amigos míos, existe una diferencia entre estas dos opciones aunque sea sutil para muchos a la hora de crear una Regla de negocio que las contenga.

Yo antes pensaba que tanto daba establecer valores de una forma o otra, al final lo que quieres es que el campo tenga un valor que tu le marcas y punto. Pero claro, si las dos opciones hicieran lo mismo, se llamarían igual y no es el caso.

Vamos a ver cada caso.

Establecer valor predeterminado

Cuando aplicamos esta acción en una regla de negocio lo que estamos realizando es mostrar un valor en un campo de forma predeterminada. La idea es que la Regla de negocio debería cargar el valor de un campo en el formulario en el evento onLoad.

Esta opción es la opción por defecto que se usa en los Optionsets (Conjuntos de datos), pero la acción se puede usar con campos Numéricos, Texto, Fecha/Hora y Búsqueda.

Dependiendo del tipo de campo, el valor establecido puede variar, como por ejemplo, en un campo Fecha/Hora podrá definirse una fecha fija, se podrá elegir que copie el valor de otro campo de fecha, establecer una fórmula que sume o reste días a una fecha o a otro campo de fecha de la entidad o se podrá elegir realizar un borrado del valor del campo.

Pero en definitiva, lo que conseguimos aplicando este componente es asignar un valor al campo que se muestre en el formulario cuando se carga.

Establecer valor de campo

Esta acción la llevaremos a cabo en una Regla de negocio cuando queramos aplicar lógica de negocio e incluso no necesitemos tener el campo cargado en el formulario.

La Regla de negocio no hace falta que se ejecute en el onLoad, puede ser un campo de la entidad que requiere ese valor pero que ni siquiera se muestra. 

Esta acción lo que realiza es poner un valor que definamos en un campo de la entidad que definamos y las opciones que disponemos son iguales al anterior caso.

Mostramos un pequeño ejemplo en el que realizamos una comprobación, si un Caso tiene como Origen el valor Correo electrónico.

Si se cumple la condición lo que hace la acción Establecer valor de campo es establecer el valor del título con la cadena "[Mail]". Este campo Título no haría falta ni que se mostrara en el formulario si no quisiéramos.

Si no se cumple la condición, la acción Establecer valor predeterminado establecerá el campo Origen con la opción "Teléfono". Se cargará el formulario para que el usuario pueda tener este valor por defecto en el campo y lo pueda cambiar si lo desea.

Finalmente, para acordarnos de que opción es cual, si nos vamos al original, quizás la traducción en inglés nos quede más claro:

• Establecer valor predeterminado = Set default value
• Establecer valor de campo = Set field value

Pero cuando se traduce, el lenguaje se hace más ambiguo.

---

Enlaces con la información:

Set Default Value vs Set Field Value in Business Rule – Dynamics 365 CE - https://dynatecon.com/2020/06/13/set-default-value-vs-set-field-value-in-business-rule-dynamics-365-ce/

Setting Field Values vs. Setting Default Values in Business Rules - https://powerobjects.com/2015/02/05/setting-field-values-vs-setting-default-values-business-rules/

Merged & Child cases

A veces pasamos por encima de las diferentes opciones que nos da Out of the box el sistema sin tener muy clara su funcionalidad y no sabiendo como aplicarla en nuestro caso.

En el trato de casos encontramos unas funcionalidades que casi siempre se obvian. Unas de ellas son los casos fusionados (merged cases) y los casos hijos (child cases).

En la primera funcionalidad se trata de escenarios donde se abren múltiples casos sobre el mismo problema y se quieren relacionar los casos entre ellos.

Con los merged cases se puede relacionar dos o más casos a un caso que quede activo para trabajar, dejándo el resto como cancelados.

La segunda funcionalidad se puede aplicar cuando existe un caso que debe ser realizado por diversas personas o cuando la incidencia afecta a diferentes clientes.
Para trabajarlo de forma independiente, se crearía un caso hijo que pudiera ser tratado por diferentes agentes o se agruparían, creando una jerarquía de casos que permitiría simplificar las gestiones a realizar. Por ejemplo, se puede definir que cuando se cierre el caso padre se cierren los casos hijos o viceversa.

Adjunto el enlace al post que me ha dado la idea, por si queréis ampliar la información.

https://crmindian.com/2017/04/17/case-merged-vs-child-cases/

Ejecutar una regla de negocio cuando se crea un registro

Con la aparición de las reglas de negocio se ha conseguido introducir funcionalidades que antes eran complicadas para usuarios no programadores. Ahora, con esta funcionalidad, cualquiera puede crear reglas que permitan ocultar o mostrar campos, indicar la necesidad de un campo o bloquearlo si es necesario según las condiciones que le marcamos.

Son muy útiles para trabajar con formularios y poder establecer como los queremos y en que momento lo queremos.

Un problema que surge es cuando queremos ejecutar una regla de negocio en una entidad, se ejecutará en todos los casos y solo buscamos que se ejecute en un formulario en el momento de su creación, dejando aquellos que ya están creados con las condiciones que tienen.

Este problema surge porque las reglas de negocio se ejecutan en la carga del formulario y en el evento onChange de los campos y se ejecutaría para todas las veces que entrásemos en el formulario.

Un truquito muy interesante para solventar el problema es poder comprobar si el campo Fecha de creación (Created On) está vacío, el cual nos indicará que es un nuevo registro.

Adjunto un artículo donde se puede comprobar el funcionamiento descrito que puede ayudar en este caso y en diferentes casuísticas utilizando las reglas de negocio.

Referencias:

• Running business rule only on record create [http://himbap.com/blog/?p=2811]

Herramienta para formatear FetchXML (FetchXML Formatter Tool)

Siempre nos pasa lo mismo, encontramos una información que en un momento nos parece relevante y al cabo del tiempo la intentamos encontrarla, sin éxito. La hemos perdido entre toda la información que ha ido pasando por nuestras manos.

En este caso, hace aproximadamente un año, encontré una herramienta para ayudar a convertir el formato de FetchXML para utilizarlo como fragmento de código, FetchXML Formatter Tool.

Para ese uso se necesitan cambiar las comillas y otros caracteres que son incompatibles con el código, ya sea JavaScript o C#.

Esta es una sencilla herramienta independiente que copiando el texto del FetchXML te devuelve el texto formateado para el uso que se quiera dar (JavaScript o C#).

La herramienta se puede encontrar en la web de su autor.

FetchXML Formatter Tool en Arun Potti's MS CRM Blog

Quizás en XRMToolBox existe alguna herramienta parecida (aunque no exacta), pero al ser un pequeño ejecutable independiente puede ser más útil que tener que abrir toda la navaja suiza de soluciones.

Además, hoy he podido ver que han creado una versión en formato web, donde nos proporciona el código para C# y JavaScript en la misma página. La versión colgada en GitHub también ofrece la versión de JavaScript optimizada para JSLint.

FetchXML Formatter Tool online en Codepen
FetchXML Formatter Tool online en GitHub

Scriptlets (USD)

Que ganas tenía de escribir sobre Unified Service Desk (USD) y hoy por fin puedo comentaros un tema que he estado buscando y que no acaba de estar correcto en diversos sitios (entre ellos Microsoft) o no se entendía bien en diferentes webs.

Desde que conocí USD me tiene enamorado. Se trata de un escritorio unificado sobre el que realizar aplicaciones conjuntas con CRM y otras aplicaciones externas. Además es muy flexible y permite crear nuevos componentes o eventos.

El problema que he encontrado es a la hora de realizar la llamada a un Scriptlet.
Un Scriptlet es un fragmento de código (habitualmente JavaScript) que se puede invocar y te devuelve un resultado que puedes utilizar mediante la sustitución de parámetros en una llamada a la acción en USD, por ejemplo.

En primer lugar, debemos ir dentro de CRM a Configuración -> Unified Service Desk y aquí buscar el elemento Scriptlets.

Aquí podremos crear un nuevo Scriptlet.

Rellenamos el campo Nombre que tendrá el Scriptlet (muy importante después recordarlo) y en el campo Texto del script colocaremos nuestro script de JavaScript.

Comenzaremos el script como si de una función de JavaScript se tratara y finalizaremos la función con la cláusula return. Dentro podemos utilizar los parámetros de sustitución de USD, lo que nos da una gran ventaja para tener los datos del contexto y poder tratarlos.
Después cerraremos el bloque de la función y realizaremos una llamada a la función escrita.

Os lo presento con un ejemplo:

En este caso quiero utilizar tres parámetros que me llegan por CTI en un solo parámetro para utilizarlo en una búsqueda.

En mi caso el parámetro que quiero devolver será la variable paramtosearch y en la última línea de la función realizo el return de la variable.
Posteriormente realizo una llamada a la función con la línea SCM_CTIParamMultisearch();.
Esto ejecutará la función y el Scriptlet me guardará el resultado como parámetro de sustitución de USD.

Para poder utilizar ese parámetro de sustitución en una llamada a la acción, en una comparación o en cualquier lugar donde pueda usar variables de sustitución de USD, debo utilizar el nombre que le dimos al Scriptlet (no el de la función).
En mi ejemplo será el siguiente:

[[$Scriptlet.SCM CTI CallType parameter for multisearch]]

Y si voy al debugger, puedo ver que se ha creado un nuevo parámetro llamado $Scriptlet que como clave el nombre del Scriptlet (SCM CTI CallType parameter for multisearch) y como valor el resultado de la función ejecutada.

¡Así de fácil y así de difícil!

Solo un apunte más. En el nombre del Scriptlet se pueden incluir espacios. USD lo reconoce sin problemas.