Masterclass de Salesforce: Secretos Ninja para la Gestión de Errores en Flow

Link YouTube

https://www.youtube.com/watch?v=5eKkrTNs61I

Intro

Te sientes abrumado cada vez que un error inesperado en Salesforce Flow detiene tus procesos y afecta la productividad de tu equipo?

Estos contratiempos pueden generar frustración y pérdida de tiempo, afectando incluso la experiencia del usuario.

En esta clase en vivo, te guiaremos paso a paso a través de técnicas avanzadas para identificar y diagnosticar errores de manera efectiva.

Descubrirás cómo utilizar las herramientas nativas de Salesforce, para manejar errores de la manera correcta.

Además, exploraremos casos prácticos basados en escenarios reales, permitiéndote comprender y aplicar cada estrategia de manera inmediata en tus proyectos.

Imagina transformar cada error en una oportunidad para optimizar y mejorar tus procesos. Con los conocimientos adquiridos, serás capaz de anticipar problemas, incrementar la confiabilidad de tus implementaciones y, en última instancia, impulsar la eficiencia operativa de tu organización.

Esta capacitación te posicionará como un experto en la gestión proactiva de errores en Flow dentro de Salesforce.

No dejes pasar la oportunidad de mejorar tus habilidades y transformar la forma en que gestionas Salesforce Flow. Regístrate ahora y comienza a convertir los desafíos en éxitos.

[00:00:08.05]
Excelente tarde a todo el mundo, a todos los seres de esta galaxia y de la galaxia cercana que se están uniendo a otra nueva clase en [00:00:18.15] vivo de Salesforce. En esta oportunidad, Francisco Morales y yo estamos en la ciudad de San Francisco. Estamos visitando Salesforce. Estuvimos junto con Josué [00:00:30.03] y con Esteban grabando algunas capacitaciones que van a estar viendo el niño desde el piso 61 de la Salesforce Tower. Así [00:00:40.07] que estén atentos, van a necesitar ese contenido. Hoy, tal vez escuchen algún tipo de audio. Por [00:00:50.18] mí, estoy en el lobby del hotel, que no tenía buena conexión en otro lugar, me vine al lobby del hotel. ¿Qué es lo que van a estar viendo entiendo en la [00:01:01.03] capacitación de errores de flow, pero no cómo crear. Yo supongo que la mayoría de todos los que están aprendiendo flows, creando [00:01:12.09] flows e implementando flows, ya Tienen bastante experiencia generando errores. Acá vamos a estar aprendiendo cómo capturar esos errores para [00:01:23.18] evitar que los usuarios entren en crisis de nervios y no entiendan qué es lo que está pasando. Sobre todo, no es una interfaz de usuario amigable. [00:01:36.18] Josué, ¿cuál es el escenario en tu grandísima… Ese es el escenario más frecuente en donde te tocó [00:01:47.15] ver un flow siendo utilizado por decenas y decenas de usuarios, dices, y que de la noche a la mañana [00:01:58.08] dejó de funcionar.

[00:01:59.18]
Con Platanos, el escenario más común con el cual te cruzaste a lo largo de toda tu carrera profesional.

[00:02:05.07]
¿qué tal? Buenas tardes para todos. Un placer. Bienvenidos. No sé si lo dije. Yo creo que lo más común, por lo menos desde mi experiencia, es tener algunos [00:02:15.13] flows que se arman de manera personalizada para hacer creaciones de registro. Primero pido cierto set de datos, después complemento con otro datos, quizá una chiva juntos y ya te hace. [00:02:27.04] Donde tenemos cientos de usuarios haciendo cargas de esa información y eventualmente se ponga una validación nueva de que para el registro ahora tiene algún campo requerido nuevo o si sea cierto escenario, [00:02:38.04] hay que validar alguna cosa. Y entonces, ese flow que a mí me ayudaba, de repente empieza a estallar.

[00:02:46.10]
Y explota por el aire, porque realmente desconozco como sea el ecosistema de Salesforce en 10 años. Tal vez tenga la suficiente inteligencia [00:02:56.14] como… Y pienso que este delirio que voy a tirar ahora podría llegar a pasar. Si yo hoy en Salesforce, creo un nuevo custom field, [00:03:07.11] ese custom field lo tengo disponible en vistas de lista, en Page Layout, en landing record pages y en reports, en informes. ¿Quién te dice si uno fabrica una validation [00:03:18.15] rule en un objeto, capaz que Salesforce en algún momento tiene la capacidad de darse cuenta cuáles son todos esos que intervienen en ese objeto y propagar [00:03:29.10] esa validation de John Rule a ese lugar. Además de lo que comentó Josué recién, en tu carrera, ¿te cruzaste en algún momento con algún caso en [00:03:40.09] particular en donde todo el mundo, la gente dejó de andar?

[00:03:45.03]
Sí, obviamente. Me tocó varias veces. Y no sabes qué es lo que está pasando detrás.

[00:03:48.22]
Eso es lo que más me sustras.

[00:03:51.10]
Sí, porque no solamente no sabes lo que está pasando, porque el usuario lo que ve es un par de renglones en color rojo y el Admin de esa Salesforce [00:04:01.18] org sí recibe un correo electrónico. Después, el resto es todo blindado. Entonces, Francisco, ¿qué te parece si nos compartís [00:04:12.14] pantalla y nos hacés de alguna manera una introducción a cuál es la mejor práctica para poder gestionar la captura de errores [00:04:23.13] en un flow? Parece que se conectó Francisco, vamos a ir esperándolo. Ahí se está conectando de [00:04:33.18] nuevo. Bien. ¿Cómo estás?

[00:04:41.13]
¿cómo están todos? Buenas tardes. ¿Estás contento o te viste en la Salesforce Tower? [00:04:52.19] Muy lindo. Voy a compartir pantalla, entonces vamos a ver si quieres la demo. A ver cómo a ver errores. Vamos a hacer un caso que es bastante [00:05:03.13] común, que vamos a poner un formulario, como decía Josué, donde uno va a cargar datos para crear, por ejemplo, en este caso, que vamos a ver hoy, es contactos. [00:05:14.00] Lo vamos a hacer muy simple. Y el error que se va a dar es que alguien va a agregar, no sé, lo mismo, no vamos a pintar la cola, vamos a agregar una validation rule que va a [00:05:24.17] explotar. Y cuando explote, vamos a mostrar cómo se ve si no gestionamos ese error dentro del flow y cómo se ve si lo gestionamos bien? Y además, ¿qué otras cosas podríamos hacer, [00:05:35.00] además del típico camino de error que nos hace? Les voy a compartir pantalla.

[00:05:40.18]
Y tenemos magia, tenemos magia de la potencia. Quiero [00:05:51.12] comentar a todos los que se nos están uniendo. Número uno, gracias por estar conectados a esta clase. Número dos, van a recibir un link [00:06:02.10] con la grabación. Número tres, pueden hacer preguntas de dos formas. Número uno, en el chat, hagan la pregunta y la respondemos. Número dos, [00:06:12.22] hagan la pregunta en el chat y si quieren venir a pantalla, prender cámara, prender micrófono, podemos hablar también.

[00:06:25.07]
Muy bien. ¿Se ve la pantalla ahí? ¿Alguien me valida, porfa? Perfectamente. Creo que sí. Bien. Vamos a irnos a nuestro [00:06:36.01] entorno loco de Salesforce. Y como les decía, el caso que vamos a ver es un formulario de un contacto. Vamos a pedir una serie de datos al usuario y después vamos a [00:06:46.20] una validation rule a propósito. Entonces, lo primero que vamos a hacer es vamos a crear un flow nuevo. ¿Se [00:06:57.14] ve bien ahí el tamaño del texto o lo arrendamos un poquito?

[00:07:00.13]
Yo lo veo perfecto.

[00:07:02.13]
Sí, está bien. Vamos a crear uno nuevo. Esta parte, como decía Juan, la vamos a quimiar un poco solo lo básico de la creación de [00:07:12.15] flow, que va a ser, en este caso, Dele a la. No vamos a usar ningún template. Todo lo que vamos a ver ahora se puede usar [00:07:22.22] en los dos escenarios, en lo que es trigger, o sea, cuando tenemos alguna automatización que le para, por ejemplo, cuando se crea un contacto, se actualiza o lo que fuere [00:07:33.09] sobre cualquier registro. Pero en el caso que vamos a ver ahora de la demo, lo vamos a ver en un flow de pantalla para ver cómo le mostramos eso al usuario. Pero también aplica lo que es Trigger Flow. [00:07:44.05] En este caso, vamos a crear un nuevo de pantalla. Y lo primero que vamos a hacer es agregar esta pantalla que comento para pedir una serie de datos. [00:07:54.21] Entonces, vamos a poner…

[00:07:55.16]
Te puedo hacer una pregunta zarpadamente crítica para mí, Francisco? ¿Vos me estás diciendo que esto lo puedo usar en un record trigger flow?

[00:08:07.08]
Un momento.

[00:08:08.20]
Okey. Por lo tanto, la pantalla va a emerger y el error sucede En [00:08:18.23] realidad, lo que va a pasar es que vamos a tener la posibilidad de manejar el error, que es volver a donde sea que se esté ejecutando ese trigger flow.

[00:08:26.19]
Por ejemplo, porque podríamos estar desde la interfaz de usuario de Salesforce normal, actualizando un registro, o podríamos estar en un NWC Component, o podríamos estar en otro flow, actualizando lo [00:08:36.23] que sea.

[00:08:38.10]
Hermoso y un beso a Karin. Un beso a Karin, que nos está escribiendo en los comentarios. Hermoso, Francisco.

[00:08:45.18]
Muy bien.

[00:08:48.18]
Sepan que soy un interrumpidor serial y lo estoy demostrando.

[00:08:52.08]
Lo que vamos a hacer ahora es crear un nuevo recurso, en este caso, que va a ser un contacto, y [00:09:02.15] este contacto, lo que vamos a hacer para hacer eso es para agregar los campos. Un contacto loco, como le gusta la forma de ver. [00:09:14.10] Data Type, vamos a dejar record. El objeto le vamos a decir que es un contacto. Pero con contact, que tiene muchas cosas raras, entonces siempre [00:09:25.09] hay que elegir contact.

[00:09:27.04]
¿qué serían muchas cosas raras?

[00:09:28.22]
Muchos objetos de relación.

[00:09:31.01]
Muchas gracias a toda la gente que se está sumando, se sigue sumando gente a la clase. Los queremos mucho, y yo particularmente.

[00:09:40.14]
Muy bien. Entonces, sacar esto está bueno, nos muestra qué campos son los obligatorios, los requeridos, y después todos los campos. Entonces, esto [00:09:50.22] lo hace con el requerido de la base de datos. Entonces, lo primero que voy a hacer es, voy a arrastrar el full name porque lo quiero agregar porque es requerido. Y el full name es este famoso campo, que son 3, que por lo general es el [00:10:01.04] pronombre, el nombre y el apellido, pero eso se puede configurar. Y lo otro que voy a hacer es pedirle, además, un mail. Recuerden que esto es como para setear un poco la [00:10:11.16] prueba. Entonces, lo que voy a hacer es, voy a pedir la información de un contacto con su nombre y con su mail. Y posterior a eso, lo voy a guardar en la base de la propiedad de servicios. [00:10:22.05] Voy a hacer una cosita más, que ya es como una manía que tengo, que es sacar este botoncito de pausa. No vamos a entrar mucho en detalle de por qué lo hacemos, pero lo hacemos siempre.

[00:10:32.06]
Ese botón de pausa tiene que estar matado. Fran, ¿me da la posibilidad de pasar un pequeño aviso? Aviso número uno. [00:10:42.14] Alguna de estas próximas clases las vamos a hacer desde las oficinas de Salesforce Argentina en vivo. Por tanto, algunos de ustedes van a estar invitados. Aviso número dos, vamos a [00:10:53.06] estar sorteando abrazos presenciales de Josué para los que vengan a las oficinas de Salesforce más noticias acerca de eso en un futuro y sigamos, Francisco, con lo [00:11:03.17] que estabas diciendo.

[00:11:06.12]
Gracias. Está bueno el premio. De nuevo, sacamos el botón de pausas, lo ejecutamos. Lo guardamos. Y, [00:11:16.20] hasta acá lo único que tenemos es una pantalla que nos va a pedir el nombre. Si quieren voy a guardarlo para mostrarlo un poquito. Vamos a ponerle [00:11:27.14] Prueba de Manejo Roes. Si [00:11:40.06] lo vamos a devaguear, solamente nos va a pedir el nombre y el correo. Que recibe. Nos pide esto del [00:11:50.23] pronóstico, el saludo de esta cuestión que tiene Salesforce. Nombre, un apellido, que se fijan, lo único que es como obligatorio acá es un apellido [00:12:01.00] y un mail. Si nosotros vamos a completar esto y vamos a finish, termina el flow porque no tiene ninguna otra acción. Lo que nos está faltando ahora [00:12:12.06] es guardar eso en la base de datos. Estos datos que estamos recopilando aquí, guardarlos. Vamos a hacer de esta manera. En este caso, vamos a crear un Register. [00:12:24.18] Vamos a crear el contacto nuevo. El contacto loco, le hemos puesto loco, entonces vamos a hacer un contacto loco nuevo. Y en [00:12:35.18] Recibo pedir cuál es el que vamos a intercambiar y le vamos a decir qué es el contacto. Guardamos. Y [00:12:46.01] ahora, si te fijan, cuando haga el debate, vamos a hacer de vuelta, vamos a ver, voy a irlo de vuelta.

[00:13:00.09]
Sí.

[00:13:01.17]
A Josué y a Francisco les están enviando mensajes desde España, se ven que son gente muy querida.

[00:13:10.03]
Un saludo de España, gracias.

[00:13:12.19]
Un saludo.

[00:13:14.01]
Podríamos ver cómo hacemos con tu sorteo de abrazo, Josué, para gente de distintos lugares del mundo.

[00:13:22.00]
Lo hacemos globalmente igual.

[00:13:23.14]
También lo vamos a poner, me parece que es andar a Esteban, abrazar gente.

[00:13:29.01]
No, acá no hay otros países.

[00:13:31.01]
Muy bien, perfecto. Y yo coordino los abrazos. Sigamos.

[00:13:36.07]
Muy bien. Entonces, si nos fijamos ahora, le voy a poner cualquier apellido. No le estoy poniendo ningún mail, le podría poner algún mail, pero [00:13:46.10] si me voy al siguiente, ahora sí me lo voy a guardar en la base de datos. Y hasta acá está todo bien, nuestro flow funciona. Podemos devagar, lo podemos probar y anda. Pero, ¿qué pasa? Lo que nosotros queremos [00:13:56.15] ver ahora es qué pasaría si esto se se rompe. Si esta inserción a la base de datos con el contacto loco, por algún motivo se rompe, que es algo muy normal. Nosotros ya tenemos [00:14:06.21] armado nuestro flows con nuestra secuencia de pasos, que se valida algún campo o se agrega alguna transformación o algo, y esto [00:14:17.19] ya no funciona de la manera que funciona. O simplemente los datos están en una manera que no es consistente con lo que se espera la base de datos, que también puede ser también por validation rule, por transformaciones. Entonces, para [00:14:29.13] simular eso, lo que nosotros vamos a hacer es-Racisco pregunta, cuando validation rule, clarísimo, viene un animal, te pone una validation rule, importándole nada de la vida, [00:14:39.20] te clava el validation rule, rompe todo perfecto, eso está supernítido, se entiende.

[00:14:45.10]
¿qué querés decir recién con transformación?

[00:14:49.21]
Caos, vos vemos que hay un trigger que… No sé. Toma el nombre, lo acota, porque tiene muchos caracteres y lo hace más corto. Por decir un ejemplo [00:15:00.03] exagerado. Nombre acortado, ya tienen… Después hay otra variation rule o hay otra variación en un trigger que me gusta que tenga cuatro cada vez, pero estoy inventando un caso. [00:15:12.13] Eso también podría pasar. Entonces, no es solo la validation rule, sino que puede haber transformaciones en el medio de datos, llevar información de un lado para otro, [00:15:23.02] que puede hacer que eso ya no sea consistente y al final, falla. Entonces, vamos a tener como dos grandes aversos, por lo que estoy viendo en mi humilde experiencia, [00:15:33.18] que es cuando nosotros queramos hacer alguna inserción, los típicos DML, o actualizar algo en la base de datos o crear en la base de datos, es muy posible que haya un error, entonces [00:15:44.12] eso es lo que conviene atajar o cuando tenemos que hacer alguna consulta a la base. ¿Por qué? Porque nosotros vamos a hacer una consulta a la base y podemos [00:15:54.22] estar necesitando un registro para después, posteriormente, hacer otra operación. Por ejemplo, me voy a buscar un contacto que sea el contacto de compras para después [00:16:05.03] poder mandarle un mail más adelante en mi flow.

[00:16:07.10]
Primero me hago una query al contacto de compras y después, más adelante, le envío un correo. Y esa primera consulta que yo hice a la base de [00:16:17.11] datos, no me vuelve ningún registro, yo ya tengo que gestionar eso, arrojando un error, o gestionar el error ya cuando voy a mandar el mail, porque si no se va a romper y va a volar todo por los [00:16:27.15] aéreas, y al final es lo que siempre vamos a tratar de trabajar. Entonces, recapitulando, vamos a hacer una [00:16:38.13] validation rule sobre el objeto contacto, dijimos. Primero lo que voy a hacer es buscar el objeto de contacto. Como decía, hay varios. [00:16:49.23] Vamos a ir a Validation Rules. Vamos a crear una nueva y mi validation rule va a ser muy simple. Lo que le Lo que voy a decir es: [00:17:01.16] si un contacto es nuevo y no tiene mail, vamos a arrojar un error, porque nosotros vamos a querer que en la base de datos todos los contactos tengan un mail. [00:17:12.07] El nombre de la Validation Rules va a ser Y contactos sin e-mail.

[00:17:19.13]
Francisco, ¿yo te puedo pedir algo muy lindo?

[00:17:22.16]
Sí.

[00:17:23.18]
La validation rule, ¿la podrías construir con ChatGPT y ayudar a que nuestra mente se ilumine y [00:17:33.21] que poco a poco nos acostumbremos a adoptar esa herramienta? ¿Qué te parece?

[00:17:40.21]
Muy bien. La fórmula, me decís vos.

[00:17:43.13]
Sí, la fórmula de la validation Sí.

[00:17:46.16]
Muy bien. Entonces, Darío, me parece bien. Acá lo que tenemos que hacer es escribir una fórmula, que esto es un símil, una pseudo programación que tiene Salesforce [00:17:56.21] para básicamente indicar que cuando Y en esta condición que nosotros vamos a escribir aquí sea verdadera, va a arrojar un error en el sistema. Entonces, lo que Juan Manuel me propone acá es hacer que [00:18:07.23] escribir esto con ChatGPT. Entonces, vamos a hacerlo.

[00:18:10.11]
Se sigue subando más gente.

[00:18:14.11]
Porque nos No sé qué puedo hacer acá, haberle preguntado, pero vamos a decir: Necesito una validation role en Salesforce [00:18:25.17] para poder validar que tenga [00:18:37.07] mi contacto y que sea nuevo. Y voy a cambiar el modelo porque está de un lockdown. Vemos [00:18:47.22] que usted debería hacer algo rápido. [00:19:01.03] No, estaba compartiendo las cosas. Sí, igual, a ver si las tengo copiadas acá. Porque dice exactamente eso antes y era esto. Es [00:19:11.12] nueva y el mail no esté vacío. Perdón, que Me voy a dejar este vacío, porque recuerden que esto tiene que ser verdadero. Entonces, [00:19:23.06] podría haber usado los operadores y los campos, pero para no hacer eso, le pedía ya al CPT que me que lo haga y lo copiamos acá, que es lo que nos va a servir. Tenemos este siempre check [00:19:34.04] syntax acá, para ver si está todo bien. Así, el error, le vamos a poner… Y queremos [00:19:44.16] que… El contacto no tiene… [00:19:56.18] Alguno se va a dar cuenta de que hay formas de gestionar esto en el flow, por ejemplo, pidiendo que el campo email sea requerido en el mismo formulario o en el mismo nivel de campo. Pero bueno, para el caso práctico que estamos haciendo, lo vamos a hacer así.

[00:20:11.06]
Correcto, para acá. [00:20:21.17] Perdón. Voy a tener que cada tanto, porque no sé si se me corta por el internet. Si se corta o algo, me avisan por el…

[00:20:29.10]
Te avisamos venís perfecto. Venís perfecto y venimos todos disfrutando. Les recordamos a todos que estamos Francisco y yo desde San Francisco en Salesforce.

[00:20:41.04]
Entonces, tenemos nuestra nueva inflamante validation rule, que va a validar que sea nuevo [00:20:51.08] el contacto y que el email no esté en blanco. Entonces, ¿qué pasa? Ahora, cuando yo meta un contacto que no tenga email, esto va a explotar por [00:21:01.15] los sites. Y yo… Ya lo tengo guardado, vamos a desbargarlo. [00:21:19.14] Y para que vean cómo se ve esto, porque ahora no tenemos ninguna gestión de errores, cuando yo no le ingrese un mail, esto va a explotar. Entonces, eso. Ya vemos cómo Lo [00:21:30.05] todo así no sabía.

[00:21:31.14]
¿vos podés, Francisco, agrandar? Eso es horrible. Y es eso lo que ven los usuarios y no entienden nada.

[00:21:39.23]
Correcto. Entonces, ¿qué es lo que podemos hacer ante esto? Imagínese que que es superpotente, porque no es solo para este caso simple que estamos mostrando, sino que cualquier problema [00:21:50.06] que ocurra cuando nosotros queramos hacer alguna actualización o una inserción en la base de datos, que va a funcionar. Entonces, lo primero que voy a hacer Entonces, voy a volver [00:22:00.19] a Flow. Y si hago clic sobre la operación en particular de crear el registro, a ver que puedo agregar un camino [00:22:11.23] de fallo, como que si algo falla, vas a hacer otra cosa distinta a lo que es la gestión normal de flujo, pero si no, seguiría. Si yo, por ejemplo, acá agrego otra pantalla, [00:22:22.14] seguiría con esa otra pantalla. Vamos a hacer prueba de éxito. [00:22:39.19] Y acá ya vamos a mostrar al usuario. Que todo salió bien. [00:22:54.22] Todo fue bien, nos vamos a poner lane, y acá le vamos a Joder. Todo salió bien. [00:23:05.12] ¿Qué pasa? Si esta inserción en la base de datos va bien, nos va a mostrar esta pantalla, que nos va a decir que todo salió bien. Pero, ¿qué pasa? Si hay algún error, nosotros queremos que no siga la [00:23:15.22] ejecución, que no le mostre esta pantalla, sino que haga otra cosa, que es lo que vamos a definir acá.

[00:23:27.04]
Entonces, ¿qué pasa? Si nosotros tenemos algún error, le Vamos a mostrar algo un poco más… Que lo asuste menos al usuario, digamos.

[00:23:36.21]
Ponerle un poquitito más de onda, un poco más de amor.

[00:23:40.18]
Me asusto cuando hay silencio, porque no sé si se me cae la conexión. Entonces, Vamos a poner en este caso pantalla de error. Me [00:23:53.04] confundo siempre a lo que capaz que le pasa. El label con el API name.

[00:23:58.09]
Bien, bien. Se viene una clase de nomenclatura para Flow. Nomenclatura para Flow, tengo un montón de cosas para compartir y para [00:24:08.11] cranear en vivo con todos ustedes para tener una nomenclatura espectacular y que nos De esa clase nos va a quedar un documento biónico, galáctico [00:24:19.06] y potente, que después vamos a publicar y cada uno de ustedes va a tener, que nos va a permitir construir flows de manera ordenada y de manera nomenclada [00:24:30.15] para que a la hora de que esos flows en el futuro sean modificados por otras personas, lo único que sientan hacia nosotros sea amor.

[00:24:43.05]
Entonces, vamos a Ahora, agregar acá un mensaje que acá podemos tener dos enfoques. O le mostramos [00:24:53.13] el usuario, el enfoque que me gusta más a mí, que es simplemente informarle que ha ocurrido un error y tomar otra acción, que es un poco lo que voy a [00:25:03.21] plantear acá, porque nosotros, primero que nada, voy a agregar el playtext para mostrar algo. [00:25:14.08] Mensaje error. Y si nosotros queremos agregar el error crudo, como viene, vamos a tener un… Acá. [00:25:24.17] Me corrigen los… Pero es este esta variable, que es flow. Fold_message, que básicamente, ¿qué [00:25:35.03] es lo que falló? O sea, esto es lo que nos viene crudo de nuestra validation route o del sistema, en realidad, porque podría ser un trigger, podría ser otra cosa. Les [00:25:45.21] voy a mostrar primero cómo se ve eso. Vamos a guardar acá. Vamos a guardar. [00:26:00.00] Muy bien. Entonces, vamos a devariar. Lo que vamos a hacer ahora es no le vamos a incluir un… No, no, le vamos a incluir un mail, así vemos cómo se ve que siga el flujo normal y después vamos [00:26:10.04] a hacer uno que no tenga mail, a ver si nos va a entrar por el error.

[00:26:14.10]
Me Me encantó, me encantó. Vamos en esa.

[00:26:22.15]
Acá, este es el famoso todo siguiente.

[00:26:25.16]
Gracias a toda la gente conectada en vivo. Vamos.

[00:26:29.12]
Pero Y le vamos a poner un mail, dijimos. Entonces, acá. La [00:26:40.07] pantallita de que todo salió bien porque le pusimos un mail. Acá tendríamos otra cosa que me acabo de dar cuenta. Cuando llegamos a la pantalla final, tendríamos que sacarle para que no pueda [00:26:50.21] volver a hacer esto todo el tiempo. Entonces, voy a ir a finish, again. Y para mostrar ahora cuando Y cómo gestionamos nuestro [00:27:01.03] error, voy a poner prueba con error y no me va a venir ningún correo. Paso [00:27:11.18] siguiente. Esto es lo que nos muestra que Por lo menos no tan rojo, pero tampoco sigue siendo algo muy… Porque [00:27:22.17] empieza con una cuestión un poco más técnica, 100% técnico, y después acá sí nos tira el mensaje que nosotros le habíamos agregado a nuestra validation route, que es el contacto no tiene e-mail, por favor, ingrese uno, [00:27:33.10] y después más mensajes técnicos. Entonces, solo lo que les decía es que yo soy más pro de… Vamos a volver yo al constructor. Más pro de [00:27:47.18] Ocurre un error. Hemos informado para el admin del sistema. Porque acá puede haber distintos errores. [00:27:58.09] Entonces, solamente con que el usuario sepa que ha habido un error, ya estaríamos y abajo, si quieren, dejen el mensaje.

[00:28:04.12]
Después, otra cosa que se puede hacer también es parciar este error de mensaje con alguna fórmula o algo así, pero ahí sí hay que empezar a tener en cuenta todos los errores que puede [00:28:14.12] haber, porque ese custom validation exception que se ve, lo voy a mostrar para que seamos claros, no siempre es igual. Entonces, [00:28:26.23] puede haber que hacer como varias fórmulas dependiendo de dónde se rompe. En cambio, si nosotros ponemos un error genérico al usuario simplemente informándole que hubo un error y que lo estamos revisando, que el admin fue advertido, [00:28:40.04] cubrimos el escenario de que el usuario sepa que es lo que, por lo menos, que falló.

[00:28:43.23]
Okey, Franche, Y nos preguntas. Sonia dice: ¿Deberíamos tener cuidado con validation rules cuando tenemos [00:28:53.23] un flow funcionando?. ¿Cuál es tu respuesta?

[00:29:00.22]
¿cómo?

[00:29:01.07]
Perdón, se me cortó. Preguntas: ¿Deberíamos tener cuidado con los validation rules cuando tenemos flows funcionando?. Asumo que estás preguntando: ¿Me puedo delirar?.

[00:29:11.18]
Especial atención, sí, tal cual. Hay que tener cuidado Claro. Y esto como buena práctica para, por lo menos, estar cubierto del lado [00:29:21.19] de los flows. Y cada vez que vas a hacer un DML, tener algún manejo de errores, de saber que puede fallar. Cada vez que vas a actualizar un registro, saber que puede [00:29:31.23] fallar y cortar la ejecución del flujo hacia algo más controlado.

[00:29:39.04]
Okey. Lo dijiste en lenguaje developer. Si tenés admins que dicen: ¿De qué goma me está hablando? Dml, más controlado. [00:29:49.18] ¿Cómo podemos traducir esto que acabás de decir a un lenguaje que un admin que está arrancando puede interpretar?

[00:29:58.17]
Cada vez que vos vas a hacer un cambio en un registro, tenés que tener en cuenta que eso puede fallar. Lo que estamos viendo acá es justamente, si [00:30:09.04] eso falla, por ejemplo, acá tenemos que crear un contacto. Si esa creación falla, ¿qué vamos a hacer con el usuario? Si le mostramos el mensaje así como viene, que en realidad es lo que hace Salesforce, ahí no tenemos [00:30:19.21] que hacer nada, eso va a generar más confusión que otra cosa. Entonces, tendríamos que llevarlo hacia una pantallita un poco más linda que diga: Ha ocurrido un error, nos estamos ocupando, [00:30:30.09] Algo por el estilo, que es un poco lo que estamos viendo en este escenario en particular.

[00:30:40.21]
También, en determinados casos, hasta podés decir, como estabas sugiriendo en el chat, contactá a tu admiro, si querés, hasta le clavas el mail.

[00:30:50.21]
Un poco lo que quería mostrar ahora como una segunda etapa es qué podemos hacer nosotros desde ese lado también, porque nosotros proactivamente podríamos ya avisarle, enviarle un mail, Al [00:31:01.10] admin, podríamos buscar un correo de un admin y mandarle un correo también a él para no esperar que el usuario le avise. Entonces, se va bajo la silla. [00:31:16.20] Vamos a hacer una prueba para mostrar cuando falla. No le vamos a poner el correo. A [00:31:28.10] mí me gustaría más mostrar este de error que esto de acá. O sea, este mensaje de error como para que el usuario sepa que pasó algo. Y lo mismo que decían, acá también le podríamos decir: Contactate con [00:31:39.02] manuelgarrido@systemas. Com o lo que sea.

[00:31:43.04]
La dirección de la casa de talles técnicas.

[00:31:48.01]
Yo quería un poco comentarles sobre eso, que nosotros acá podríamos tener algún enfoque más proactivo. Pense que muchas veces cuando tenemos un [00:31:58.09] error, después nos interesa medir de eso. Entonces, una buena política de manejo de errores es, por ejemplo, crear un registro en algún [00:32:08.11] objeto que represente un log de error, por ejemplo. Que eso es algo que hay muchas empresas que ya lo tienen implementado, que se llaman frameworks de gestión de errores, donde uno de los objetos [00:32:20.01] de nuestra distancia de Salesforce va a representar un log cada vez que haya un error. Entonces, algo que podríamos hacer acá es cada vez que hay un error, creamos un registro dentro de ese [00:32:31.03] ¿Para qué? Para que después se pueda medir cuántas veces fallaron las pantallas, qué tipo de error se está teniendo el usuario y demás. Práctico.

[00:32:41.07]
Y yo empiezo desde que avances. Desde que avances, lo tenemos a Luis desde Colombia, que está haciendo un planteo, a ver si lo pongo. Vamos. [00:32:51.15] Luis, lo que dice es que en este ejemplo que estás dando es claro de dónde viene el error. Pero, ¿qué ¿Qué hacemos cuando descubres [00:33:02.01] el origen del error? ¿Cómo podemos identificar en el flow de dónde vienen? Si vienen de una variation rule, si vienen de un trigger, de un agujero negro. ¿De [00:33:13.18] qué forma podríamos nosotros, como admins y como developers, entender de dónde está viniendo ese error. Y gracias, Luis, por tu pregunta.

[00:33:24.03]
Acá tenemos que hacer como un… Luego lo dejo contestar a los chicos, a Josio y a Steve. Tenemos que hacer un planteo, que quizás es un [00:33:34.03] poco más atrás, que decir qué tanto queremos atajar el error o qué tanto queremos prevenir el error. Porque como bien dicen ahí, es claro que esto viene de una vez en un roll porque lo estamos haciendo acá. Pero [00:33:44.16] en realidad, lo que nosotros queremos plantear en este escenario y con todo lo que es la gestión de errores, es saber que hubo un error y dirigir al usuario hacia otro lado [00:33:54.19] y cortar la ejecución. Después, de dónde viene el error, Bueno, eso lo podemos… Es como más contingencia, es más como: Una [00:34:04.22] vez que hubo un error, le mandamos un mail al admin y ahí se van a poner a ver qué es lo que falló y cómo resolverlo. Pero ya no es cuestión, no sé si me explico, ya no sería [00:34:15.04] tanto el ámbito, el flow, mostrarle al usuario de dónde vino el error. No es necesario saberlo en este contexto. Quizás, ya [00:34:25.19] cuando le enviaste el mail al admin o ya cuando el usuario, porque le lo pusiste acá en un mensaje, lo llamó y le dijo: Mirá, el error que me está saliendo es…

[00:34:34.11]
Dice que necesita el contactor mail. Bueno, vienen acá y reparan eso, reparan el flujo o reparan la validation rule o el trigger o lo que sea que se haya roto. [00:34:45.14] No te voy a decir, me explico. Como que filosóficamente, dentro del flow, no te debería interesar tanto de dónde vino, sino que solamente tener un plan B, que es, [00:34:56.03] si algo falla, mostrarle un mensaje y que después que se pueda depurar esto, que se pueda saber de dónde vino el error, pero eso ya es otro ámbito. No [00:35:06.09] sé si me explico con lo que digo. Y ahí, si los chicos quieren sumar algo… Porque podría saber, por ejemplo, pensándolo así en voz alta, con el un poco de mensaje. No, mira, vamos de vuelta. [00:35:18.23] Si vos quisieras saber que en este caso, por ejemplo, es una validation role, voy a dejar esto en blanco. [00:35:30.12] Yo podría saber, por ejemplo, que ponía este texto, buscando este texto en una fórmula, podría decir: Si falla esto, es una validation role. Pero si lo piensan, yo no me [00:35:40.22] debería estar como atajando tanto en el sentido de saber de dónde viene, si viene una validation rule o si viene de un trigger.

[00:35:46.16]
Porque en realidad lo que a mí me interesa es decirle al usuario algún error, nos estamos ocupando, queda tranquilo y no seguir haciendo las otras cosas que tiene que seguir haciendo el [00:35:56.18] flow, porque ya hay algo que falló. Entonces, fue clara la explicación, ahí me dice.

[00:36:02.18]
Sí, sirvió. Cuando decés que hay muchas organizaciones que se están ya ocupando de hacer toda una gestión de errores y grabando errores [00:36:12.19] en un objeto, ¿cuál sería la idea detrás de eso? Si vos pudieses, en pocas palabras, tirar conceptualmente cómo hoy [00:36:23.06] una persona que está viendo esta clase en vivo, que la está viendo grabada, ¿cómo puede implementar eso en su propia organización?

[00:36:39.18]
Que se nos quedó Francisco.

[00:36:43.18]
¿y qué te parece o ¿cuál fue, mientras esperamos a que vuelva a la conexión de Francisco, nos ayudas a entender cómo se podría realizar una gestión de errores [00:36:55.12] escribiendo los errores en un objeto?

[00:36:59.07]
Sí, a ver, Va a depender mucho de que estás avanzada, tener ya tu org nueva, por ahí es mucho más simple, como poner una regla de cada vez que yo [00:37:09.08] voy a hacer una actualización de datos en base, tener, llamémosle un Try and Catch, si somos developers, o tener un default, un error path, que es lo que estamos viendo ahora con Fran, [00:37:19.19] y decir: Okey, y cada vez que suceda esto, creemos un registro de bitácora con la información que nos da Salesforce. Esa información de bitácora vamos a poder sacar, por [00:37:30.15] ejemplo, los tipos de errores, que es lo que estamos viendo ahora como field… Perdón, una validez en el campo. Podrías tener otro tipo de error, como que estés tocando el límite, [00:37:41.10] o quizá la actualizar, como dijiste, disparó o de la automatización y estás fallando por allá, bueno, tienes los diferentes tipos de errores y la idea es bajar a tu equipo de [00:37:53.16] personalización de CRM, decir: Vamos a tomar estas políticas, creamos este objetito, ¿qué va a ser? Se va a llamar error log, tiene un campo para que pongas el código de error, tiene [00:38:04.11] un campo para que pongas el usuario que lo está ejecutando, fecha y hora, ya lo vas a tener por sistema y quizá el texto, el mensaje que vos puedas capturar, lo guardas en un campo de texto.

[00:38:16.05]
Claro, algo sumamente interesante es que también vas a poder hacer informes sobre esa objeta.

[00:38:21.11]
Claro, una vez que ya tengas todo registrado, después vas a poder tener una explotación de datos en cuanto a errores. Quizá no es para qué tenemos Salesforce, pero también te va a a entender en [00:38:31.21] dónde por ahí estás teniendo el mayor dolor. Quizá tenés un proceso de venta con muchas validaciones en las oportunidades y vas a saber que por ahí tu foco va a estar en… No sé, [00:38:42.06] por ejemplo, tenés un flujo que hace la creación de oportunidades y tus mayores errores van por ahí, vas a poder decir a tu equipo técnico: Che, hagan foco en esto para que [00:38:53.05] mejoremos la vida del usuario y defende ver tantos errores, básicamente. Es un poquito más complicado, si tu org ya tiene tiempo de existencia, pero bueno, pasan por una decisión de decir qué tanto le queremos facilitar [00:39:03.09] la vida de nuestros usuarios.

[00:39:05.08]
Francisco, volviste, te habías quedado un par.

[00:39:07.23]
Volví.

[00:39:09.06]
Les comentábamos, Francisco y yo estamos en Cali, mañana estamos desde las oficinas de Salesforce, en particular evento. Francisco [00:39:19.21] está en la vivencia del hotel y ahora cuando terminamos la clase nos vamos para la Salesforce Tower y estamos lidiando con, al menos nosotros dos, con algunos temas relacionados a la [00:39:31.11] conexión de Internet, porque estamos en el hotel. Francisco, ¿quieres compartirnos nuevamente pantalla? Retomamos.

[00:39:38.05]
Vamos con una partecita que quedaba. [00:39:48.11] Por otra pantalla completa. Muy bien. El éxito. ¿Ahí se ve?

[00:39:52.06]
Sí, papá, claro.

[00:39:54.02]
Muy bien. Estábamos diciendo que acá Esto se pone potente porque nosotros podríamos… Incluso, podemos [00:40:04.13] pensar en un flow que se dedique solo a gestión de errores. Entonces, cada vez que hay un error, simplemente llamamos a ese flow.

[00:40:14.11]
Es algo que deberíamos construir en una clase y regalárselo a todo el mundo. Eso es algo que la humanidad necesita.

[00:40:24.14]
Exacto. Entonces, por ejemplo, podríamos tener un flujo que ya haga todo eso, que ya mande un mail, que ya crea un registro en un objeto, que sea un log de un error, etcétera, [00:40:34.15] que haga todo lo que toda nuestra gestión de error va a hacer. Y llamamos de desaflow cada vez que hay un DML o una query o una [00:40:44.22] pantalla que tenga como alguna cosa medio tricky. Y puede haber un error acá, lo llamamos a nuestro subflow, gestionar error, le pasamos como un error [00:40:55.20] del mensaje y ya con eso Algo simple y práctico. Y dentro de este subflow, como decíamos, podemos mandarle un [00:41:06.15] mail al admin o a los admins, que esto es lo que tengamos que hacer. Y también podremos, incluso, dentro de este subflow, tener una pantalla que sea una genérica que diga: [00:41:17.01] Sabemos que hubo un error, vamos a trabajar en eso, por ejemplo.

[00:41:24.02]
Podría ser una buena idea, Fran, ¿podría ser bien enviarle un correo electrónico al usuario como para que el usuario diga: Okey, esto es [00:41:34.04] oficial? ¿De verdad? ¿Sí quedó registrado? ¿Sí lo entendieron y por eso estoy recibiendo el mail?

[00:41:41.09]
Sí, acá con todo lo que es el módulo de acciones de flows, podemos, por ejemplo, mandar un mail. Ahí sería, no sé. Avisar al usuario [00:41:53.02] de un error. Se fuera que la pantalla no fuera suficiente, porque también, como le decía, y volviendo un poco a la primera parte. Nosotros esto lo podríamos tener dentro de un Trigger Flow. Entonces, [00:42:03.13] ahí ya es un poco más difícil controlar qué es lo que está viendo el usuario. Entonces, ahí tiene más sentido quizás avisarle con un mail que haya fallo algo. Podríamos agregar, [00:42:14.05] por ejemplo, en el Y el error. [00:42:30.19] El texto de error, aquí. O lo podría tener… Eso también podría ser. Podría tener una variable que tenga un mensaje de error [00:42:41.14] formulado y enviarlo. Y otra cosa que podría ser acá es poner el usuario. [00:42:52.21] Esto podría ser… O sea, quién va a recibir este mail, podría ser el mismo usuario. Y relacionarlo al registro del que está donde está basando. Parece que como justo acá estoy creándolo, no tendría sentido que [00:43:03.22] me ponga el concepto. Yo estoy haciendo la actualización sobre ese registro y eso falló. Sí podría relacionar ese mail avisando al registro que ya existe.

[00:43:16.13]
Pero de nuevo, acá las oportunidades son infinitas, porque una vez que ya lo que pasa es esto, que parece una cosa muy rival, muchos flow, por no decir que [00:43:26.13] la gran mayoría no tienen esta gestión de errores, y esto me viene a la cara del usuario directamente. Y si se fijan, fue tan simple como decir: Un camino de error, y [00:43:36.23] con eso voy a hacer algo, que es mostrar una pantalla. Se puede volver tan complejo como queramos, pero por lo menos ya tenerlo contemplado, que nos ahorra muchos dolores de cabeza.

[00:43:46.10]
Espectacular. Entonces, vamos a recapitular un poco. Flow, de manera nativa, no tiene una gestión [00:43:56.21] de error ni siquiera poco no la tiene. Y de esta manera, lo que estamos logrando es notificar al usuario, [00:44:08.02] notificar al administrador, incluso si hacemos la implementación de grabar en un objeto, tener la posibilidad de un registro por cada error y [00:44:18.21] en base a eso sacar informes o hasta incluso algún tipo de automatización para algo crítico, como detectar un registro en [00:44:29.14] el donde se estén grabando los mensajes de error y hacer una publicación en un grupo de chatter, por ejemplo. Lo que sí vamos a hacer en una próxima… Que [00:44:40.14] avanzar más profundamente en la construcción de un flow, que van a poder llamar desde otros flows, nosotros se los vamos a [00:44:51.12] regalar a todos ustedes. Al final, siempre agradeciendo toda la gente que preguntó y toda la gente que se conectó Hoy grito menos, [00:45:02.04] saben que en las clases suelo gritar como un animal, estar en el lobby del hotel, estoy un poco más contenido y van a estar recibiendo la [00:45:13.02] grabación de esta clase. Palabras finales. Estio Josué, ¿quieren decir algo?

[00:45:21.10]
Sí, por ahí comentar de que esto está… Bueno, reforzar un poco lo que se trató en la clase de sumar estos manejos de errores. Quizá hoy es simple, porque Y lo que hablamos al final de tener todo [00:45:31.13] un framework de manejo de errores, es increíble, estaría buenísimo tenerlo siempre. Quizá en las organizaciones que estamos trabajando no es tan simple, pero por lo menos tener [00:45:41.15] una pantallita que dé un poco de info suma un montón, porque desde mi experiencia en los últimos proyectos que tuve. Nadie hace cosas con buena intención, pero por ahí teníamos algunos triggers [00:45:52.01] medio pesados y hasta incluso tocamos límites. Un dev no se dio cuenta y puso un demand dentro de un flow. Entonces, yo solo estaba creando un contacto, pero por atrás estaban creando un caso, una [00:46:02.11] oportunidad, una cuenta, hacer gente, disparar un montón de cosas. Y el tema es que nada, apareció un error de: Pasó algo. Incluso a vos, como debo, cuando vas a dar un soporte, [00:46:13.00] tener algo que te diga un poco más que te va a servir tu usuario va a entender y por ahí vos te conectas a una call y: Mirame, estás en este error en pantalla.

[00:46:20.16]
Ahí, el campamento está bueno, pero ves, no sé, insertion failed, el asiento de un socle queries. Sabés que en algún momento algo está pasando y se te está yendo de las [00:46:30.23] Resumen, superimportante de mostrar un poco más de info, tanto para el usuario como para nosotros que estamos administrando las plataformas. Si pueden poner un framework, igual, mucho mejor.

[00:46:41.04]
Este irá nos una reflexión.

[00:46:43.07]
Sí, lo último que me encantó dijo. Sí. Lo otro que la gente se olvida mucho a la hora de hacer flows es agregar descripciones a los elementos. Superimportante, supermedio [00:46:53.15] importante.

[00:46:53.23]
Y luego como que ser mejores.

[00:46:56.07]
Sí, críticamente importante. Bueno, a toda la audiencia, a toda la gente que está ahora conectada en vivo y que va a ver estas grabaciones. Se van a LinkedIn. [00:47:08.00] En LinkedIn, buscan Josué Mendoza. Ese es el capo de Josué. Esteban Morales. Ese es el groso y amoroso de Esteban. Después, Francisco [00:47:18.14] Morales. Y por último, Garrido. Búsquennos en LinkedIn. Pídanos conexiones y estén atentos a toda la documentación técnica [00:47:29.05] que vamos a estar publicando. Yo estoy casi diariamente, Francisco también y Josué y Esteban están empezando a tirar una magia maravillosa. [00:47:39.10] No se olviden, vamos a estar en las oficinas de Salesforce junto a ustedes. Vamos a ver si los podemos llevar a invitar para que estén en vivo. Tampoco se olviden de que vamos a estar sorteando abrazos [00:47:49.23] de Josué a la gente. Y nos vemos nuevamente en dos semanas en la próxima clase en vivo [00:48:00.12] de Salesforce. Los queremos un montón. Nos vemos en 14 días.

[00:48:06.04]
Feliz tarde para todos.

—

Desde EGA Futura ayudamos a empresas usando Salesforce