Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Formularios de Power Apps para SharePoint: por qué fallan en producción y cómo hacerlos fiables (Doblaje IA)

Transcript

Formularios de Power Apps para SharePoint: por qué fallan en producción y cómo hacerlos fiables (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Listo para 10 días de Microsoft 365, Copilot, IA, Azure
0:04
Speaker 2: y las personas que están dando forma al futuro del
0:06
Speaker 2: trabajo y... Este enero, M365 con regresa y venimos con
0:11
Speaker 2: más fuerza. Y venimos fuerte. Únete a nosotros para sesiones
0:14
Speaker 2: en vivo, demostraciones reales y conocimientos prácticos de MVPs y
0:16
Speaker 2: expertos de la industria de todo el mundo. Nada de
0:19
Speaker 2: diapositivas genéricas. Nada de tecnicismo sin terminar. Abordamos los desafíos reales.
0:23
Speaker 2: Copilot Studio, agentes de IA, Fabric, Seguridad, Gobernanza y Automatización.
0:29
Speaker 2: Ya seas un profesional de TI, desarrollador o líder empresarial,
0:33
Speaker 2: hay sesiones diseñadas para ti. Con 10 días completos, puedes
0:37
Speaker 2: explorar múltiples tecnologías y conectar con una comunidad global. Mira
0:41
Speaker 2: en vivo y lleva ideas prácticas de regreso a tu organización.
0:45
Speaker 2: Enero de 2027. 10 días. Una sola comunidad de Microsoft.
0:49
Speaker 2: El registro ya está abierto. Asegura tu lugar hoy mismo.
0:54
Speaker 2: Es m365.net. Únete ahora en m365con.net y nos vemos en
1:03
Speaker 2: vivo en enero. Tu formulario de SharePoint se ve increíble
1:06
Speaker 2: en Power Apps hasta que deja de verse así. De
1:08
Speaker 2: repente el botón no guarda correctamente. La validación de campo
1:11
Speaker 2: se comporta de forma extraña y el rendimiento parece que
1:13
Speaker 2: avanza entre el lodo. Aquí está la verdad. Los formularios
1:15
Speaker 2: de Power Apps suelen parecer engañosamente simples, pero contienen trampas
1:18
Speaker 2: que toman por sorpresa la mayoría de los profesionales. Hoy
1:21
Speaker 2: verás exactamente dónde surgen esas trampas en un formulario de
1:24
Speaker 2: solicitud real y las técnicas paso a paso para que
1:26
Speaker 2: tu formulario pase de verse bien a funcionar de manera confiable.¿
1:30
Speaker 2: Por qué los comienzos fáciles se convierten en problemas difíciles?
1:33
Speaker 2: Haces clic en ese pequeño botón de personalizar con PowerApps
1:35
Speaker 2: y en minutos tu formulario de SharePoint luce transformado. De
1:39
Speaker 2: repente ya no son solo cuadros y etiquetas. Es una
1:41
Speaker 2: aplicación pulida con menús desplegables, interruptores y una capa de
1:43
Speaker 2: diseño fresco. Siente como si hubieras construido una aplicación en
1:46
Speaker 2: tiempo recto. Esa es la parte emocional. Pero la emoción
1:48
Speaker 2: suele desvanecerse rápido porque esas victorias fáciles no siempre sobreviven
1:52
Speaker 2: al momento en que tu formulario se publica y la
1:53
Speaker 2: gente real empieza a usarlo y la empieza a usarlo.
1:55
Speaker 2: La razón por la que al principio parece tan simple
1:57
Speaker 2: es que PowerApps fomenta un enfoque visual. Arrastras un control
2:01
Speaker 2: a la pantalla, configuras una propiedad con una fórmula que
2:03
Speaker 2: parece casi Excel y responde exactamente como esperabas. En una
2:07
Speaker 2: sola sesión puedes ocultar campos, mover cosas y hasta añadir
2:10
Speaker 2: lógica que tomaría mucho más tiempo en la configuración nativa
2:12
Speaker 2: de formularios de SharePoint. Esa ilusión de progreso rápido es fuerte.
2:16
Speaker 2: Lo que aún no ves es todo lo que sucede debajo.¿
2:19
Speaker 2: Qué tan estrechamente se vincula esa lógica personalizada con los
2:21
Speaker 2: datos de SharePoint y lo frágil que se vuelve una
2:23
Speaker 2: vez que sales del entorno seguro del modo de vista previa?
2:25
Speaker 2: A medida que nosotros hemos pasado por... Probabas tu formulario
2:27
Speaker 2: con datos de muestra, haces clic en guardar y observas
2:30
Speaker 2: cómo envía el registro a la lista sin errores. Agregue
2:32
Speaker 2: algunas reglas de negocio, como completar automáticamente el nombre del
2:35
Speaker 2: solicitante o desactivar el botón de envío hasta llenar los
2:38
Speaker 2: campos obligatorios, y todo responde al instante. En esta etapa
2:41
Speaker 2: parece que has resuelto el problema. Entonces llega el lanzamiento.
2:44
Speaker 2: Alguien reporta que su botón de guardar no hace nada.
2:47
Speaker 2: Otra persona nota que el indicador de carga nunca se
2:49
Speaker 2: detiene al intentar abrir el formulario. O los campos se
2:51
Speaker 2: comportan de forma distinta dependiendo del navegador que se utilice.
2:53
Speaker 2: El mismo formulario que parecía estable en unas pocas pruebas
2:55
Speaker 2: cuidadosas ahora parece impredecible. Aprendí esta lección por las malas
2:59
Speaker 2: al crear un formulario de solicitud para un equipo interno.
3:01
Speaker 2: En las pruebas de control, el formulario parecía perfecto. Todos
3:04
Speaker 2: los campos estaban alineados, el flujo de envío se activaba
3:06
Speaker 2: y la interfase se sentía más rápida que la experiencia
3:08
Speaker 2: estándar de SharePoint. Pero durante la primera semana de uso
3:11
Speaker 2: en producción surgió un problema. Algunos usuarios no podían en absoluto.
3:14
Speaker 2: Otros guardaban datos en la columna incorrecta porque las fórmulas
3:17
Speaker 2: subyacentes no coincidían con cómo SharePoint interpreta ciertos tipos de campos.
3:21
Speaker 2: Algo tan simple como una columna de signo manejada en
3:23
Speaker 2: Power Apps como un valor verdadero o falso no se
3:25
Speaker 2: comportaba igual cuando los usuarios interactuaban con ella directamente desde SharePoint.
3:29
Speaker 2: Esa discrepancia causó problemas sutiles, pero perjudiciales. Parte de la
3:33
Speaker 2: trampa es asumir que lo que ve en la vista
3:34
Speaker 2: previa es lo que experimentarán sus usuarios. El modo de
3:38
Speaker 2: vista previa es esencialmente un entorno de demostración. No simula
3:40
Speaker 2: múltiples usuarios accediendo al mismo formulario, listas grandes con miles
3:43
Speaker 2: de registros o conflictos en tiempo real con flujos de
3:45
Speaker 2: trabajo en segundo plano. Te prueben condiciones limpias, pero el
3:48
Speaker 2: entorno de producción es complicado. La gente usa el formulario
3:51
Speaker 2: de forma diferente, las columnas en SharePoint imponen reglas que
3:54
Speaker 2: no consideró, y la lógica que crea hermética de repente
3:56
Speaker 2: muestra fallas. Es casi como probar con un modelo de
3:59
Speaker 2: juguete antes de pasar a la versión real. Las grietas
4:01
Speaker 2: solo aparecen una vez que aumentas caro. Otro punto ciego
4:04
Speaker 2: es la forma en que extendemos las columnas de SharePoint
4:05
Speaker 2: con la lógica de PowerApps. Una columna despegable en SharePoint
4:09
Speaker 2: puede parecer sencilla, pero al anular su comportamiento predeterminado en
4:12
Speaker 2: PowerApps esencialmente, ha reemplazado parte de la validación integrada de
4:15
Speaker 2: SharePoint con su propio código. Ese código no siempre se
4:19
Speaker 2: alinea con las restricciones de datos que aún existen en
4:21
Speaker 2: la lista. El resultado es una duplicación de la lógica.
4:24
Speaker 2: SharePoint intenta aplicar una regla mientras Power Apps aplica otra.
4:28
Speaker 2: Cuando se superponen, los usuarios reciben mensajes inconsistentes, fallos al
4:31
Speaker 2: guardar o datos que parecen limpios en el formulario pero
4:33
Speaker 2: que luego arruinan los informes. La pregunta más importante detrás
4:36
Speaker 2: de todo esto es si la complejidad realmente vale la pena.
4:39
Speaker 2: A veces solo necesita ajustar la apariencia de un formulario,
4:41
Speaker 2: pero una vez que lo abre, en Power Apps abre
4:43
Speaker 2: la puerta a una personalización interminable. Cada pequeña mejora. conlleva
4:47
Speaker 2: consecuencias ocultas, y cuanto más avanza, más difícil se vuelve
4:50
Speaker 2: a separar lo cosmético de lo estructural. Que parecía un
4:53
Speaker 2: atajo sencillo a menudo, termina siendo un formulario que requiere
4:55
Speaker 2: mantenimiento constante. Y la verdad es que el verdadero reto
4:58
Speaker 2: no es crear el prototipo, sino lograr que funcione cuando
5:00
Speaker 2: decenas o cientos de usuarios dependen de él cada día.
5:04
Speaker 2: Es por eso que los problemas a menudo no aparecen
5:05
Speaker 2: hasta después. Un formulario que funciona bien bajo tu control
5:08
Speaker 2: empieza a ralentizarse, a fallar o a confundir a los
5:11
Speaker 2: mismos usuarios a los que debía ayudar, lo que conduce
5:13
Speaker 2: a la siguiente trampa, problemas de rendimiento y adopción que
5:15
Speaker 2: solo Se revelan una vez iniciado el lanzamiento. Las trampas
5:19
Speaker 2: se ocultan tras el lanzamiento. Tu formulario superó todas las
5:21
Speaker 2: pruebas a las que lo sometiste. Luego llegaron los primeros
5:24
Speaker 2: usuarios reales, hicieron clic en enviar y todo se ralentizó
5:26
Speaker 2: al extremo. Las páginas que antes cargaban al instante ahora
5:29
Speaker 2: se quedan ahí con íconos de carga. Los botones que
5:31
Speaker 2: deberían activarse de inmediato tardan segundos en responder. El problema
5:34
Speaker 2: no es que tu formulario haya empeorado de repente. Es
5:36
Speaker 2: que los datos de producción exponen debilidades que las pruebas
5:38
Speaker 2: nunca revelan. Unas cuantas fórmulas y ajustes visuales no parecen
5:41
Speaker 2: pesados cuando solo tienes un puñado de registro de muestras.
5:44
Speaker 2: Agrega cientos o miles de filas a esa misma lista
5:46
Speaker 2: y de repente, lo que parecía fluido, empieza a sentirse
5:48
Speaker 2: casi inutilizable. La diferencia radica en la escala. Durante el diseño,
5:52
Speaker 2: trabajas con dieregistro. En producción, la gente trabaja con cientos
5:54
Speaker 2: de archivos adjuntos o listas que crecen hasta los miles.
5:57
Speaker 2: Ahí es donde aparece la latencia. Cada menú desplegable que
5:59
Speaker 2: necesite extraer elementos de una lista relacionada realiza una llamada
6:02
Speaker 2: por sí. Cada fórmula condicional que muestra o oculta campos
6:04
Speaker 2: se ejecuta en tiempo real cada vez que un usuario
6:06
Speaker 2: interactúa con el formulario. Pequeños costos que no notas individualmente
6:10
Speaker 2: se combinan en algo que todos notan Los usuarios de
6:13
Speaker 2: negocios esperan que un formulario responda con una página web.
6:15
Speaker 2: Los desarrolladores a menudo buscan la completidad. Añadamos lógica para
6:18
Speaker 2: cada condición. Hagamos cinco variaciones de la misma regla. Pero
6:21
Speaker 2: esas elecciones aumentan la carga en el backend. Una historia
6:24
Speaker 2: que destaca proviene de un formulario de solicitud que parece
6:26
Speaker 2: impecable en las pruebas. La lógica funcionaba, el diseño se
6:29
Speaker 2: veía bien. En el modo de vista previo tardaba menos
6:31
Speaker 2: de dos segundos en cargar por completo. La demostración impresionó
6:33
Speaker 2: a todos. Pero cuando se lanzó y un departamento con
6:36
Speaker 2: una lista que ya contenía mil solicitudes lo probó, el
6:38
Speaker 2: tiempo de carga aumentó a más de 15 segundos. Eso
6:41
Speaker 2: no suena terrible hasta que lo multiplicas por el uso diario.
6:44
Speaker 2: Medio minuto de espera por solicitud significaba docenas de horas
6:47
Speaker 2: desperdiciadas en todo el equipo. Y una vez que aparece
6:50
Speaker 2: el retraso, la gente deja de confiar en el sistema.
6:52
Speaker 2: Hacen clic en guardar dos o tres veces por pánico,
6:54
Speaker 2: lo que genera envíos duplicados y aún más frustración. Los
6:57
Speaker 2: formularios de ecológica dinámica pueden emplearlo. Digamos que establece reglas
7:00
Speaker 2: para la visibilidad condicional. Si alguien selecciona una solicitud de viaje,
7:03
Speaker 2: el formulario se expande con campos de destino. Si eligen
7:06
Speaker 2: una solicitud de hardware, aparece una sección diferente. En teoría
7:09
Speaker 2: esto hace que el formulario sea mucho más fácil de usar.
7:12
Speaker 2: En realidad, cada vez que un usuario selecciona o cambia
7:14
Speaker 2: un campo, la lógica interna se recalcula. Ese ciclo se
7:18
Speaker 2: repite constantemente creando una vacilación en la interfaz.¿ Los usuarios
7:21
Speaker 2: lo describen como que el formulario se retrasa o se congela?
7:24
Speaker 2: La verdad técnica es que el formulario está recalculando docenas
7:27
Speaker 2: de expresiones en tiempo real. A diferencia de las aplicaciones
7:30
Speaker 2: creadas específicamente para almacenar valores o procesar solicitudes por datos,
7:32
Speaker 2: PowerApps se optimiza automáticamente. Cada fragmento de lógica que escribes
7:35
Speaker 2: se ejecuta exactamente como se escribió cada vez. Aquí es
7:37
Speaker 2: donde los desarrolladores sin experiencia sorprenden. Asumes que la plataforma
7:41
Speaker 2: se optimizará internamente y que ciertas llamadas se almacenarán caché
7:43
Speaker 2: o se combinarán caché o se combinarán en una sola solicitud.
7:46
Speaker 2: Pero Power Apps no hace eso por ti. Recupera los
7:48
Speaker 2: datos por separado y recalcula las fórmulas literalmente. El resultado
7:51
Speaker 2: es una aplicación que funciona bien con una docena de elementos,
7:53
Speaker 2: pero que se ralentiza drásticamente a escala real. Los desarrolladores
7:57
Speaker 2: experimentados suelen trasladar la lógica compleja fuera del formulario a
8:00
Speaker 2: flujos de Power Automate o reglas de SharePoint, precisamente para
8:03
Speaker 2: reducir la carga de trabajo en el lado del cliente.
8:05
Speaker 2: El verdadero problema no es que ocurran estos inconvenientes, sino
8:08
Speaker 2: que suceden después de que tu equipo ha invertido tiempo,
8:10
Speaker 2: ha aceptado el flujo de trabajo y espera que todo funcione.
8:14
Speaker 2: Para un usuario de negocio, un retraso de 10 segundos
8:16
Speaker 2: significa que algo está roto. Para un desarrollador, 10 segundos
8:19
Speaker 2: pueden no parecer graves, pero el choque entre esas expectativas
8:21
Speaker 2: es donde surge la frustración. Desde la perspectiva del usuario,
8:24
Speaker 2: un formulario lento es una pérdida de tiempo. Desde la
8:26
Speaker 2: perspectiva del desarrollador, reescribir la lógica parece costoso cuando la
8:29
Speaker 2: funcionalidad ya está allí y está allí. Ambas partes tienen
8:31
Speaker 2: razón y ambas partes no se entienden. La lección aquí
8:33
Speaker 2: es simple. Diseña pensando en la producción, en condiciones de demostración.
8:37
Speaker 2: Si tu lista tendrá habitualmente miles de elementos, realiza pruebas
8:39
Speaker 2: con miles. Si tu lógica afecta múltiples columnas, mide su
8:42
Speaker 2: impacto en el tiempo de carga en escala. Si tu
8:45
Speaker 2: formulario necesita funciones de usabilidad como secciones condicionales, piensa cuidadosamente
8:49
Speaker 2: cuántas reglas acumulas directamente en el formulario. Cada segundo cuenta,
8:52
Speaker 2: y cada fórmula innecesaria volverá para complicarte más tarde. Una
8:56
Speaker 2: buena arquitectura marca más diferencia que unos efectos visuales curiosos.
8:59
Speaker 2: El rendimiento no es una función cosmética. Es la base
9:01
Speaker 2: real que determina si tus usuarios seguirán usando el formulario
9:04
Speaker 2: o lo abandonarán. Y ahí es donde aparece la siguiente trampa,
9:07
Speaker 2: la validación. Porque incluso si tu formulario carga lo suficientemente rápido,
9:10
Speaker 2: nada destruirá más la confianza que un guardado que falla,
9:12
Speaker 2: o peor, uno que acepta datos erróneos silenciosamente. Pesadillas de
9:16
Speaker 2: validación que no ves venir. En teoría, las reglas de
9:19
Speaker 2: validación parecen sencillas. Miras un campo y piensas si la
9:21
Speaker 2: fecha final es anterior a la inicial muestra un error.¿
9:24
Speaker 2: Qué tan difícil podría ser? El reto es que, al
9:26
Speaker 2: desplegar el formulario fuera de tu entorno de pruebas y
9:28
Speaker 2: llevarlo a un escenario real, esas reglas simples dejan de
9:30
Speaker 2: funcionar como esperabas. Una validación que funcionaba bien en la
9:34
Speaker 2: vista previa puede fallar silenciosamente en producción. O peor aún,
9:37
Speaker 2: activarse en el momento equivocado y bloquear a usuarios que
9:39
Speaker 2: creen haber hecho todo correctamente. Ahí es cuando lo que
9:41
Speaker 2: debería ser una protección sencilla parece que el formulario juega
9:44
Speaker 2: en tu contra. Tomemos el escenario de fecha de inicio.
9:47
Speaker 2: En una prueba de laboratorio, ingresas como fecha de inicio
9:49
Speaker 2: el 1 de mayo y como fecha fin el 30
9:50
Speaker 2: de abril, y tu regla lo marca de inmediato. Perfecto.
9:53
Speaker 2: Pero en producción... Alguien ingresa los valores en otro orden
9:56
Speaker 2: o edita un registro existente donde los campos ya están
9:58
Speaker 2: parcialmente llenos. De repente la validación no se activa hasta
10:01
Speaker 2: guardar o se dispara antes de que el usuario termine
10:03
Speaker 2: de escribir. Esto genera confusión. Envían el formulario, ven un error,
10:07
Speaker 2: corrigen el fallo, vuelven a enviarlo y entonces el formulario
10:09
Speaker 2: lanza un mensaje distinto por otra cosa. Estos errores acumulados
10:12
Speaker 2: parecen aleatorios para el usuario, pero a menudo es solo
10:14
Speaker 2: que las reglas se ejecutan inesperado. Otro problema común ocurre
10:18
Speaker 2: cuando las reglas se superponen. Quizás escribiste una fórmula para
10:20
Speaker 2: verificar campos obligatorios y otra para validar relaciones entre valores.
10:25
Speaker 2: Si ambas se activan al mismo tiempo, el usuario podría
10:27
Speaker 2: ver dos avisos de error a la vez. O peor
10:29
Speaker 2: todavía que un mensaje oculte al otro. En algunos casos,
10:32
Speaker 2: usuarios hábiles descubren pronto que pueden evitar la validación de
10:35
Speaker 2: Power Apps usando atajos de teclado haciendo clic fuera del formulario.
10:39
Speaker 2: O guardando desde otra vista en SharePoint. Parece que el
10:42
Speaker 2: formulario está roto. Para ti como creador, parece que las
10:45
Speaker 2: reglas en las que te esforzaste no se respetan. Ambas
10:48
Speaker 2: frustración real. Añadiendo más complejidad está SharePoint mismo. Power Apps
10:52
Speaker 2: no reemplaza la forma en que SharePoint aplica las restricciones
10:54
Speaker 2: de columna. Si una columna en SharePoint es obligatoria, SharePoint
10:57
Speaker 2: seguirá aplicando ese requisito, sin importar la lógica en Power Apps.
11:00
Speaker 2: El riesgo ocurre cuando tus reglas de validación no coinciden
11:03
Speaker 2: con cómo SharePoint interpreta ese mismo campo. Por ejemplo, podrías
11:06
Speaker 2: permitir cadenas vacías en Power Apps porque solo verificas campos visibles.
11:10
Speaker 2: Mientras tanto, SharePoint rechaza aceptar el mismo registro porque su
11:13
Speaker 2: columna está marcada como obligatoria, aunque el campo no se
11:15
Speaker 2: muestra en tu formulario personalizado. El resultado es un sistema
11:17
Speaker 2: de seguridad y no muestra un error claro al usuario.
11:20
Speaker 2: Solo ven un icono de carga o un mensaje genérico
11:22
Speaker 2: de que no se pudo guardar. Esta brecha entre las
11:25
Speaker 2: reglas de Power Apps y la aplicación de SharePoint es
11:27
Speaker 2: lo que erosiona rápidamente la confianza. A los usuarios no
11:30
Speaker 2: les importa si el error proviene de tu fórmula o
11:32
Speaker 2: del sistema de Photoshop. Solo ven que un formulario en
11:35
Speaker 2: el que confiaban ha comenzado a rechazar sus datos. Es
11:37
Speaker 2: como construir una presa que parece sólida en las pruebas,
11:40
Speaker 2: pero al llenarla de agua a gran escala aparecen pequeñas
11:42
Speaker 2: fugas donde menos esperabas. Cada fuga parece manejable por sí sola,
11:47
Speaker 2: pero el patrón envía una señal. No se puede confiar
11:49
Speaker 2: en esta estructura. Puedes imaginar lo que eso le hace
11:51
Speaker 2: a la adopción. Con un par de malas experiencias, la
11:53
Speaker 2: gente deja de ingresar datos por completo o comienza a
11:55
Speaker 2: inventar trucos para evitar usar el formulario. Este es el
11:58
Speaker 2: punto donde los profesionales suelen dedicar más tiempo a la
12:00
Speaker 2: resolución de problemas. No en el diseño ni en la distribución,
12:03
Speaker 2: sino en investigar por qué ciertos casos aislados dejan el
12:05
Speaker 2: formulario en estados impredecibles. Terminas probando 20 combinaciones distintas de
12:09
Speaker 2: entradas solo para entender cómo se activan las reglas Cuanto
12:12
Speaker 2: más profundizas, más ves que la validación no trata de
12:14
Speaker 2: escribir una o dos fórmulas ingeniosas. Se trata de establecer
12:18
Speaker 2: niveles de verificación que consideren el comportamiento del usuario, las
12:20
Speaker 2: restricciones de SharePoint y casos extremos que no puedes prever
12:22
Speaker 2: hasta que el formulario se implementa. El enfoque más sólido
12:25
Speaker 2: es pensar en la validación por capas. Una capa en
12:28
Speaker 2: Power Apps para obtener retroalimentación inmediata. otra en SharePoint para
12:32
Speaker 2: asegurar la integridad de los datos sin importar cómo se
12:34
Speaker 2: guarda el registro, y pruebas adicionales no solo con entradas limpias,
12:36
Speaker 2: sino con la realidad compleja de usuarios editando registros, omitiendo
12:39
Speaker 2: campos opcionales o ingresando fechas que abarcan años en lugar
12:42
Speaker 2: de semanas. Si refuerzas tus reglas con la configuración de
12:45
Speaker 2: SharePoint y tratas la validación de PowerApps como la primera
12:47
Speaker 2: defensa en lugar de la única, creas barandillas en lugar
12:50
Speaker 2: de barreras frágiles. La lección principal es esta. La validación
12:54
Speaker 2: no falla porque las reglas sean incorrectas. Falla porque no
12:56
Speaker 2: estén alineadas entre PowerApps y SharePoint, o porque solo se
12:59
Speaker 2: prueba en condiciones perfectas. La fiabilidad proviene de crear capas
13:03
Speaker 2: y planificar errores, no solo de programar para el camino ideal.
13:05
Speaker 2: Y es exactamente aquí donde vemos surgir la mayor brecha
13:08
Speaker 2: de fiabilidad. Entre formularios creados nativamente en SharePoint que simplemente
13:12
Speaker 2: aplican reglas y formularios personalizados de Power Apps que lidian
13:14
Speaker 2: tanto con la flexibilidad como con la imprevisibilidad.¿ Formularios nativos
13:19
Speaker 2: contra Power Apps?¿ Habilidad contra flexibilidad? Si los formularios integrados
13:23
Speaker 2: de SharePoint hacen el trabajo desde el inicio,¿ por qué
13:25
Speaker 2: molestarse en cambiarlos por Power Apps? Esa es la pregunta
13:28
Speaker 2: que la mayoría enfrentamos cuando la emoción de la personalización desaparece.
13:32
Speaker 2: Los formularios nativos de SharePoint pueden parecer simples, pero casi
13:34
Speaker 2: nunca fallan. Obtienes una validación de entrada fiable, una visualización
13:38
Speaker 2: consistente en todos los dispositivos y cero mantenimiento. El inconveniente
13:40
Speaker 2: es que son rígidos. Si desea que un campo aparezca
13:42
Speaker 2: solo bajo ciertas condiciones, o si necesita secciones que se
13:45
Speaker 2: ajusten dinámicamente a las reglas de negocio, la opción predeterminada
13:47
Speaker 2: no le servirá. Power Apps promete cerrar esa brecha dándole
13:51
Speaker 2: control sobre la lógica, el diseño y la automatización de
13:53
Speaker 2: formas que SharePoint por sí solo no puede igualar. El
13:55
Speaker 2: contraste es evidente en el momento en que los prueba
13:57
Speaker 2: uno al lado del otro. Un formulario predeterminado de SharePoint
13:59
Speaker 2: se abre al instante, no requiere configuración y aplica configuraciones
14:02
Speaker 2: de listas sencillas. Pero el diseño está restringido. No puede
14:05
Speaker 2: decir mostrar este campo solo si quien lo solicita es
14:07
Speaker 2: un gerente. O contraer estos campos cuando se elige una
14:09
Speaker 2: respuesta determinada. PowerApps interviene ofreciendo esa flexibilidad. Quiere menús desplegables
14:14
Speaker 2: en cascada vinculados a una lista de bus. No es verdad.
14:17
Speaker 2: Quiere secciones que se revelen solo cuando se cumplen ciertas condiciones.
14:20
Speaker 2: Eso lo logra con un par de formas. Es empoderador,
14:23
Speaker 2: pero con esas libertades viene un tipo de inestabilidad que
14:25
Speaker 2: no se ve hasta más tarde. Aquí es donde reside
14:28
Speaker 2: el dilema. Estabilidad o flexibilidad. Puede elegir un camino, que
14:31
Speaker 2: sea aburrido, pero consistente, o puede tomar la ruta que
14:33
Speaker 2: ofrece la experiencia de usuario exacta que imaginó, pero que
14:36
Speaker 2: puede frustrarlo más tarde cuando aparezcan problemas. En un proyecto
14:41
Speaker 2: de formulario de solicitud, la elección se inclinó hacia la flexibilidad.
14:44
Speaker 2: El equipo quería visibilidad condicional. Ciertos tipos de solicitudes necesitaban
14:47
Speaker 2: un panel de información adicional, mientras que otras no. En
14:50
Speaker 2: el SharePoint nativo, esto no era posible sin crear formularios separados.
14:53
Speaker 2: Power Apps parecía la solución obvia. Durante el desarrollo y
14:56
Speaker 2: las demostraciones iniciales, el formulario funcionó de maravilla. Seleccionar viajes
15:00
Speaker 2: activaba una sección para los detalles del vuelo. Elegir hardware
15:03
Speaker 2: intercambiaba sus campos por especificaciones de equipo. Se sentía adaptado
15:06
Speaker 2: al proceso de una manera que el estándar nunca podría ofrecer.
15:09
Speaker 2: Y lo llegó con el asumido. Todo funcionaba sin problemas
15:12
Speaker 2: en los navegadores de escritorio, pero en el momento en
15:13
Speaker 2: que los usuarios intentaron enviar desde dispositivos móviles, las secciones
15:17
Speaker 2: se desalinearon, los botones se deslizaron por debajo del borde
15:19
Speaker 2: de la pantalla. Cierta lógica condicional se ejecutaba de forma
15:21
Speaker 2: inconsistente según el cliente móvil. Las funciones que el formulario
15:24
Speaker 2: predeterminado de SharePoint manejaba sin problemas, como la representación consistente
15:27
Speaker 2: en distintos formatos, se convirtieron repentinamente en formatos, se convirtieron
15:29
Speaker 2: repentinamente en puntos críticos. Para solucionar estos detalles, tuvimos que
15:32
Speaker 2: repensar partes del diseño, probar con varias aplicaciones móviles y
15:35
Speaker 2: aceptar que algunos usuarios siempre tendrían una experiencia menos predecible.
15:39
Speaker 2: Ese fue un precio que el equipo no había considerado
15:40
Speaker 2: al buscar flexibilidad. Y es un recordatorio de algo fácil
15:43
Speaker 2: de pasar por alto. La estabilidad no significa solo que
15:46
Speaker 2: no se bloquee, significa un comportamiento consistente en cualquier escenario
15:50
Speaker 2: que encuentren sus usuarios. La presión que impulsa a las
15:53
Speaker 2: personas hacia Power Apps suele ser la lógica de negocio.
15:55
Speaker 2: Los procesos reales rara vez encajan en un formulario genérico.
15:58
Speaker 2: Cosas como requisitos condicionales, valores predeterminados o aprobaciones de varios
16:01
Speaker 2: pasos lo alejan de los formularios nativos. Y los flujos
16:04
Speaker 2: de trabajo integrados con Power Automate funcionan mejor cuando se
16:06
Speaker 2: activan mediante campos y reglas personalizados definidos en Power Apps.
16:10
Speaker 2: Es por eso que, aun con los riesgos, las organizaciones
16:12
Speaker 2: siguen cambiando sus formularios. No es porque Power Apps se
16:15
Speaker 2: vea mejor, es que los formularios nativos a menudo no
16:17
Speaker 2: pueden manejar procesos de negocio reales sin adaptarse a las
16:19
Speaker 2: limitaciones de la tecnología. Aun así, voces expertas en la
16:23
Speaker 2: comunidad señalan un peligro aquí. Usar power apps para cambios cosméticos,
16:27
Speaker 2: como reorganizar campos o hacer que el formulario se vea
16:29
Speaker 2: más limpio, rara vez justifica el intercambio. Los ajustes cosméticos
16:33
Speaker 2: son la razón menos valiosa y más arriesgada para adoptar
16:35
Speaker 2: power apps. Si su caso de negocio es simplemente mejorar
16:38
Speaker 2: la estética, puede terminar sacrificando la consistencia por muy poco
16:41
Speaker 2: beneficio duradero. Sin una razón sólida basada en la funcionalidad,
16:45
Speaker 2: la fiabilidad que se pierde puede superar por completo los
16:47
Speaker 2: beneficios o beneficios. Esa es la verdad. La fiabilidad suele
16:51
Speaker 2: disminuir cuando se reemplaza una solución nativa solo porque Power
16:53
Speaker 2: Apps está disponible, no porque sea la opción adecuada. Cambie
16:56
Speaker 2: un formulario que simplemente funciona por uno que requiere atención constante.
17:00
Speaker 2: Cada nuevo campo corre el riesgo de romper una fórmula.
17:03
Speaker 2: Cada actualización de la plataforma requiere volver a rezar el producto.
17:05
Speaker 2: El costo no es inicial, es el mantenimiento a largo
17:07
Speaker 2: plazo y la frustración del usuario. La clave no es
17:09
Speaker 2: evitar Power Apps por completo, sino mantener la intencionalidad. Pregúntese
17:13
Speaker 2: si la personalización aporta un valor que SharePoint no puede
17:15
Speaker 2: ofrecer de ninguna otra manera. Si es así, vale la
17:17
Speaker 2: pena planificar la complejidad adicional. sino mantenga el formulario nativo.
17:21
Speaker 2: Una solución suficientemente buena y estable casi siempre supera a
17:24
Speaker 2: una ingeniosa que colapsa bajo el uso diario. Entonces la
17:26
Speaker 2: verdadera decisión no es simplemente SharePoint frente a PowerApps, sino
17:29
Speaker 2: saber cuándo optar por la fiabilidad básica y cuándo aceptar
17:32
Speaker 2: los riesgos de personalizar. Porque una vez que personaliza, asume
17:35
Speaker 2: desafíos que no puede ignorar y el éxito depende de
17:37
Speaker 2: si los previó. Y eso lleva directamente a la pregunta
17:40
Speaker 2: más importante. Si decide usar PowerApps,¿ qué estrategias pueden evitar
17:44
Speaker 2: que su formulario se vuelva frágil con el tiempo? Estrategias
17:48
Speaker 2: prácticas para formularios de power-ups duraderos. Entonces, si los formularios
17:51
Speaker 2: de power-ups son frágiles,¿ qué se necesita realmente para construir
17:53
Speaker 2: uno que perdure? Esta es la parte que mucha gente
17:55
Speaker 2: se asalta. Pasan directamente del diseño al lanzamiento pensando que
17:58
Speaker 2: un puñado de correcciones de errores mantendrán el formulario estable.
18:01
Speaker 2: La realidad es que la estabilidad no consiste en reparar
18:03
Speaker 2: grietas individuales, sino en dar forma a los cimientos antes
18:06
Speaker 2: de que aparezcan las grietas. Aprendí esto de la manera
18:08
Speaker 2: difícil con un formulario de solicitud que seguía ralentizándose sin
18:11
Speaker 2: importar cuántas ajustes hiciera. La versión que finalmente resistió fue
18:14
Speaker 2: la construida con disciplina desde el principio en lugar de
18:16
Speaker 2: con correcciones ingeniosas al final. La primera estrategia es mantener
18:19
Speaker 2: la lógica ligera. Cada fórmula que añades en PowerApps parece
18:22
Speaker 2: pequeña de forma aislada, pero es procesamiento adicional que se
18:24
Speaker 2: ejecuta en tiempo real en el dispositivo del usuario. Si
18:27
Speaker 2: acumulas suficientes, tu formulario se volverá lento. Delegar tareas puede
18:31
Speaker 2: marcar la diferencia entre algo que perdura y algo que
18:33
Speaker 2: termina fallando. Power Automate es más adecuado para operaciones pesadas
18:36
Speaker 2: como enviar correos, crear elementos relacionados o iniciar flujos de
18:39
Speaker 2: trabajo o El sistema puede manejar esas tareas en segundo plano,
18:42
Speaker 2: dejando a tu formulario de Power Apps libre para enfocarse
18:44
Speaker 2: en la entrada y presentación. Lo mismo ocurre con el
18:46
Speaker 2: propio SharePoint. Si un campo siempre debe contener un correo válido,
18:50
Speaker 2: deja que SharePoint aplique ese tipo de columna. Evita duplicar
18:53
Speaker 2: reglas en Power Apps a menos que necesites una respuesta
18:55
Speaker 2: visual inmediata. Segundo, no pruebes solo con los cinco registros
18:58
Speaker 2: que agregaste para el desarrollo. Diseña tu plan de pruebas
19:01
Speaker 2: con datos secales al producir. Si esperas miles de filas
19:03
Speaker 2: en la lista subyacente, carga miles durante las pruebas. Los
19:07
Speaker 2: formularios que parecen rápidos en la vista previa pueden comportarse
19:09
Speaker 2: de forma muy distinta al extraer datos de una lista
19:11
Speaker 2: con meses de solicitudes o archivos adjuntos grandes. La caída
19:14
Speaker 2: en el rendimiento solo se nota a gran escala y
19:17
Speaker 2: si la detectas antes del lanzamiento te ahorras el ciclo
19:19
Speaker 2: de quejas de usuarios que descubren retrasos en su trabajo diario.
19:22
Speaker 2: Esto parece tedioso pero a menudo revela cuellos de botella
19:25
Speaker 2: antes y te da tiempo para simplificar cálculos o reducir
19:27
Speaker 2: el número de controles en una pantalla. Una tercera medida
19:30
Speaker 2: de seguridad estaban capas. Power Apps debería manejar el lado
19:33
Speaker 2: amable de la validación. guiando a los usuarios, mostrando mensajes
19:36
Speaker 2: instantáneos y resaltando campos faltantes. Pero las restricciones de SharePoint
19:40
Speaker 2: deben respaldar esas reglas. Piénsalo como dos puertas que deben
19:42
Speaker 2: cerrarse con llar de una. Si la validación de Power
19:45
Speaker 2: Apps no detecta una entrada incorrecta, SharePoint garantiza la integridad
19:48
Speaker 2: antes de que el registro se guarde. Este enfoque por
19:50
Speaker 2: capas evita esa brecha confusa donde Power Apps dice que
19:52
Speaker 2: todo está bien, pero SharePoint lo rechaza silenciosamente. También significa
19:57
Speaker 2: que los informes son consistentes, ya que la calidad de
19:59
Speaker 2: los datos no depende solo de que los usuarios llenen
20:01
Speaker 2: el formulario como esperabas. Cuarto, documenta tus fórmulas a medida
20:04
Speaker 2: que avanzas. Esto suena aburrido, pero tú y yo del futuro,
20:07
Speaker 2: o peor aún, el colega que lee el formulario perderá
20:09
Speaker 2: horas tratando de entender una expresión que parecía obvia en
20:11
Speaker 2: su momento. Incluso una línea breve de explicación sobre fórmulas
20:15
Speaker 2: complejas puede evitar mucha confusión más adelante. Comentar el código
20:19
Speaker 2: no es glamuroso, pero en Power Apps importa más porque
20:21
Speaker 2: las fórmulas suelen mezclarse dentro de las propiedades. Si notas,
20:25
Speaker 2: olvidarás por qué escribiste una regla de cierta manera y
20:27
Speaker 2: dudarás en tocarla incluso cuando lo necesites. La documentación mantiene
20:30
Speaker 2: tu formulario fácil de mantener. Finalmente reside la tentación de
20:33
Speaker 2: realizar un lanzamiento masivo de golpe. Lance el sistema en
20:35
Speaker 2: fases manejables. Implemente el formulario primero en grupo piloto, deje
20:38
Speaker 2: que lo usen en condiciones reales y escuche con atención
20:40
Speaker 2: sus comentarios. Encontrará casos aislados, descubrirá problemas de rendimiento y
20:45
Speaker 2: entenderá el comportamiento real del usuario antes de que toda
20:47
Speaker 2: la organización dependa de él. Iterar por fase genera confianza
20:51
Speaker 2: y le da espacio para corregir las estructuras subyacentes sin
20:53
Speaker 2: la presión de que todos exijan fiabilidad desde el primer día.
20:56
Speaker 2: Lo que une todos estos pasos es la disciplina. No
20:59
Speaker 2: pude evitar del todo la complejidad una vez que abrí
21:01
Speaker 2: un formulario de SharePoint en Power Apps. Pero usted