(Nivel Medio) Cómo saber si se ha modificado una columna en concreto de SharePoint en Power Automate

Hace unos días os contaba a todos los Power Users cómo saber si una columna en concreto de una lista o librería de SharePoint se había modificado. Era una versión totalmente #NoCode y podéis echarle un ojo aquí.

La solución en sí tenía un problema bastante importante: la duplicidad de la información y la doble modificación del elemento, doblando las ejecuciones del flujo en sí. Hoy, os traigo la opción con un poquito (no mucho) más de código. Aunque la haya nombrado "Nivel avanzado", simplemente trabaja con la API de SharePoint y poco más. Parece mentira que con las mejoras que se están haciendo en los triggers (o desencadenantes) de SharePoint en Power Automate, aún no podamos fijar condiciones sobre columnas modificadas, solo condiciones sobre "qué valores debe tener la columna".

Pero como siempre decimos, cuando una puerta se cierra, otra ventana se abre y hoy os vengo a mostrar cómo detectar cuando una columna en concreto de una lista o librería a un nivel #LessCode Justo este ejemplo también lo expliqué en la sesión de Power Platform Bootcamp Madrid, la sesión está colgada en youtube y si accedéis desde este enlace os llevará al momento justo donde lo explico.

Contexto: Tenemos una lista de Productos mantenida por un equipo de Marketing, necesitamos notificar al equipo de Diseño de IT SOLO cuando se modifique el nombre del producto. Si los otros campos se modifican, no debemos hacer nada.

Para empezar, debemos asegurarnos que nuestra lista tiene activado el versionado de elementos. La solución consiste en guardar dos versiones de cada elemento de la lista; cuando el elemento es modificado, accederemos a las versiones mediante la API y nos fijaremos en si el valor de la columna es distinto entre las versiones o no.
No necesitamos muchas versiones, solo guardar 2 versiones: la actual cuando el elemento es modificado y la anterior a ésta, para comprobar si la columna es diferente o no.

Accedemos a la lista -> Configuración de la lista. Una vez ahí vamos a configuración de versiones (Versioning settings) y fijamos como "2" el número de versiones y le damos a Aceptar:

Una vez tenemos la lista configurada (atención! Es recomendable configurarlo al crear la lista) la magia está en Power Automate. Así que creamos un flujo automático con el desencadenador (trigger) de SharePoint "Cuando se modifica un elemento". En principio no sería necesario tener en cuenta el caso "Cuando se CREA O modifica un elemento", puesto que no nos interesa avisar a Marketing cuando se da de alta al Producto, simplemente cuando se modifica el nombre del producto.

El siguiente paso es añadir una acción de llamada HTTP GET a la API de SharePoint. Necesitaremos utilizar la salida del desencadenador para obtener la ID del elemento que se ha modificado e introducirlo a la  URI de la petición:

Importante añadir el número de versiones que queremos traernos, es el número "2" al final de la URI. Obviamente ni guardamos más versiones, tal y como hemos configurado, ni necesitamos más para resolver este caso de uso.

Una vez obtenidas las versiones, con una acción de "Componer" podemos extraer fácilmente y únicamente la información que nos interesa de cada versión recuperada:

Principalmente necesitaremos la ID del elemento, el título (nombre) que tiene actualmente el producto (aquí podría tratarse de cualquier otro campos que nos gustaría analizar si ha cambiado o no) y por último el nombre de la versión.

¿Y ahora? Pues simplemente tenemos que comprobar si justamente en este cambio que ha realizar un usuario sobre el elemento, se ha modificado el nombre del producto o no. Si en ambas versiones el título es igual, es un caso que debemos ignorar.

Para crear la comparación, solo comentaros que la primera versión que tendremos siempre será la más "nueva", la última modificación, y segunda versión será la más "anterior". Para acceder a los valores simplemente debemos utilizar las funciones first/last sobre la función de Seleccionar.

¡Listos! Sin modificaciones extras al elemento, sin mucho código (debéis admitir que sin conocimientos de la API, con una simple llamada lo tenéis solucionado) y sin ejecuciones secundarias del flujo por rebote.

Obviamente este método tiene un gran problema: seguimos consumiendo recursos de ejecuciones de flujo en nuestra organización. Cada vez que hay una modificación en la lista, este flujo se ejecuta sí o sí. Esperemos que pronto nos ofrezcan (por fin) una solución nativa en el conector sin que impacte en nuestro consumo de Power Automate.

¿Tenéis alguna duda de Power Automate? No dudes en planteármela, puede convertirse en el siguiente artículo del blog.