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

Hoy os traigo una de las principales necesidades cuando trabajamos con actualizaciones de elementos/archivos en listas/librerías de SharePoint. Actualmente el trigger que disponemos en Power Automate de "escucha" a cambios en listas y librerías es "cuando un elemento se modifica". Hasta ahí perfecto, ¿pero qué sucede cuando lo que nos interesa no es cuando el elemento en sí se modifique, sino cuando se modifique SOLO una columna o propiedad en concreto?

La información que recibimos junto al trigger corresponde a la modificación del elemento, pero nos devuelve todas las propiedades del elemento como tal. En esta imagen tenéis un ejemplo:

En esta entrada os mostraré la alternativa más fácil para controlar el caso que inicialmente he expuesto, y que además es fácil de asimilar para un perfil de usuario no técnico. No requiere conocimientos de desarrollo, simplemente tener un conocimiento de gestión de SharePoint y Power Automate. Tiene, como toda solución, sus pros y sus contras que voy a comentar al final de todo.

Vamos allá: manos a la obra.

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.

Primero lo que vamos a hacer es crear una nueva columna en nuestra lista de SharePoint, esta columna la vamos a llamar "Titulo_copia" y será de tipo "Texto de una sola línea". No le ponemos ningún valor por defecto.

Nos vamos a asegurar que en las vistas disponibles a nuestros usuarios, el campo no se está mostrando.

En caso de estar trabajando con Tipos de Contenido (Content Types), nos aseguramos de ocultar este campo en los formularios (aquí ya depende de si trabajamos con los formularios de Power Apps u otros personalizados).

Vamos a crear nuestro flujo en Power Automate con el trigger "Cuando un elemento se crea o modifica" ¿Cómo sabemos si se ha modificado o creado como nuevo? El campo "Titulo_copia" siempre guardará el último valor del Título. Para ello vamos a crear una condición en nuestro flujo: Comprobar si Titulo es igual a Titulo_copia.

En la rama del SÍ, simplemente incluiremos un Finalizar, no nos interesa este caso (La columna Título no se ha modificado).

En la rama del NO, vamos a incluir otra condición para tener en cuenta el primer caso inicial: Se ha creado el elemento por primera vez, la columna "Titulo_copia" estará vacía y por lo tanto no debemos notificar IT Design en este caso. Incluimos una condición: Comprobar si el campo Titulo_copia está vacío (es igual a null) o no.

En la rama del SÍ, simplemente no haremos nada, la dejamos en blanco (¡pero atención, no colocamos ningún "Finalizar", puesto que nuestro trabajo no termina aquí).
En la rama del NO, vamos a crear la acción de la notificación al equipo de IT Design (en este caso mandamos un correo, pero eso ya lo dejo a gusto del usuario).

Fuera de la condición, es decir una vez ejecutadas las ramas del Sí o del No, colocaremos la última acción de nuestro flujo: Actualizar el elemento de SharePoint para asignar (ahora sí) a la columna "Titulo_copia" el nuevo valor. Recuerdo que si tenemos campos obligatorios, deberemos especificar su valor obligatoriamente; simplemente copiamos el campo que leemos del la salida del trigger.
¿Por qué lo hacemos fuera de la condición? Muy sencillo, es una acción que debemos realizar tanto si la columna estaba vacía como si no. En este caso lo podríamos haber hecho tanto antes de la condición como después, como yo he hecho.

Y ya lo tendríamos, listo para utilizar. Hay que tener en cuenta una cosa (y además será uno de los puntos en contra de este método): la actualización del elemento, nuestra última acción, desencadenará otra llamada al flujo de manera consecutiva (¡Estamos modificando el elemento!). Por suerte esta segunda ejecución terminará sin hacer nada.

PROS DE ESTA SOLUCIÓN
Fácil de implementar, el usuario no necesita pelearse con APIs y puede resolverlo simplemente utilizando las acciones incluidas en Power Automate

CONTRAS DE ESTA SOLUCIÓN
Estamos duplicando columnas, no sucede nada si solo inspeccionamos una en concreto, pero imaginemos qué pasaría en una lista/librería de 20 columnas. Para cada columna que nos interesara, deberíamos crear su doble y por consiguiente, nuestro flujo (las condiciones) se iría complicando.
Ejecutamos la modificación del elemento y por consiguiente tenemos doble ejecución (consumo) de flujos diarios.
Las columnas "Modificado Por" Y "Modificado" quedan alteradas, ya que nosotros volvemos a modificar el elemento para incluir el nuevo título.

Lo FÁCIL es rápido de implementar, pero a la larga nos puede salir CARO. Si bien es cierto que esta solución nos ayudará a salir del paso y en un entorno donde ni el número de ejecuciones del flujo sea importante, ni las columnas de Modificación tampoco, sea una muy buena manera de solucionar.
Yo recomiendo a muchos usuarios no técnicos aprender a resolver ciertos casos de la "mejor manera". Al principio el aprendizaje costará, pero los beneficios valdrán la pena y la calidad de nuestra solución será más alta.

En la siguiente entrada os mostraré cómo resolver este escenario de un modo un poco más complejo, pero más eficiente y limpio.

¡Pasad buena semana!