Salesforce » Rendimiento: Errores que todos cometen [Masterclass]

Juan Manuel Garrido (00:00)

Vamos todavía. Muy buenas tardes. Muy buenas tardes a todos. Dentro de algunos minutos ya vamos a comenzar formalmente nuestra nueva clase después de algunas semanas de vacaciones mientras esperamos que el resto del equipo se sume. Hoy saludamos. ¿Cuánta gente? Ya de una. ¿Cuánta gente? Juan Carlos, Natalia, César.

Natalia nuevamente, Eduardo, Jesús, Julián, Willy, Denise, José, Ernesto, Darío, Rodolfo, Oscar, Elisabeth, Carlos, Gustavo, un montón de gente, un montón de gente que se está conectando y ya estamos arrancando a full. No tenemos a Josu. ¡Lup buenas! ¡Qué locura! ¡Qué locura ese pelarro de Josu!

Muy bien, muy bien, muy bien, muy bien. Bueno, estamos a minutos de comenzar. Todavía no arrancamos. Espero que todos hayan pasado una noche buena, una Navidad maravillosa, un año nuevo. Josu, yo tengo la gran curiosidad de saber el nivel de comida, el nivel de comida en cantidad.

hartos niveles, murieron muchos animales lamentablemente para esta fiesta. ¿Se puede comentar qué tipo de carne has consumido? Pierna de cerdo, que acá le decimos pata flambeada. Muy bien. Costillas de vaca. Muy bien. Pollo. Hice una mami con el pavo, pero no funcionó. Creo que algo de cordero.

Es una locura. Es una locura. Te voy a contar algo, Josue. Brillante la cantidad de gente. Brillante la cantidad de gente que tenemos hoy. Se ve que nos extrañaban. Obviamente, hacia el final de la clase, como lo estamos haciendo en todas las clases, vamos a estar solamente por el chat compartiendo otro código para

participen del sorteo de las dos certificaciones que vamos a dar para que dos de ustedes tengan la posibilidad de certificarse disfrutando de nuestra plata porque pagamos nosotros. Hola Francisco, ¿cómo estás?

Buenas, ¿cómo andan? Bien, escúchame, viste que siempre hablábamos porque esperábamos que venga gente. Ya tenemos la cantidad mínima que siempre queremos tener de personas para arrancar. Por lo tanto, yo les diría, ¿les parece si vamos con el típico, famoso, espectacular video que próximamente iremos a cambiar y arrancar? Mirá, se llenó.

¿Qué pasó? ¿Qué pasó? Bien, chicos, un montón de gente, un montón de gente conectada, así que que, formalmente, si ustedes están de acuerdo, vamos a arrancar con la clase del día de hoy.

Bienvenidos, bienvenidos en este 2026 a la primer masterclass para Salesforce de este año. Estamos muy contentos por dos cosas. La primera, estamos cercanos a cumplir un año dando clases con aproximadamente, escuchen esto, 1400 alumnos, loco, es un montón, un montón de gente. Estamos realmente muy contentos y

A mí me gustaría preguntarle a Francisco Morales cuál es el tema de la clase de hoy.

Muy bien, feliz año para todos. Hoy vamos a ver, con muchas anécdotas, cuestiones que quizás todos hemos cometido en algún momento y nos han servido para curtirnos, para aprender, así que las vamos a compartir y algunos errores que son como muy comunes también y cómo solucionarlos. Eso es un poco lo que vamos a ver hoy. Además de cuestiones de optimización que ahí los chicos nos van a comentar, hoy Josu y Desti van a ser los…

los cracks que van a guiar la clase y bueno, cuestiones de optimización también vamos a ver. El primero feliz año para todos.

para todo y si te parece bien Francisco antes de darle la posta a Josu y a Bebu corazón me gustaría que eres en modo de microprimicia que tires una idea del focus del reemplazo de focus on force que estamos craneando a mí ya no cuentes mucho simplemente como para que estén todos ahí un poco pendientes

Tenemos una idea que es básicamente hacer como un sitio de capacitaciones que queremos que sea lo mejor de lo mejor en capacitaciones de Salesforce en español y que ayude a la gente a poder certificarse. Primero aprender Salesforce obviamente, muy enfocado en las certificaciones de Salesforce. Así que bueno, tendremos novedades dentro de poco de eso. Ya estamos trabajando en eso. Es un proyecto que estamos creando.

para todos ustedes y para que tengan la posibilidad de crecer en sus carreras sin tener que volverse locos a la hora de certificar. Josu, vamos con vos.

Estaba mutiado. Perdón, feliz año para todos. Aprovecho y saludo a todos los que están escuchando. Especialmente a Daro Kuk, que creo que es un amigo que tengo ahí de años por ahí dando vueltas. Bien, un poco la dinámica que habíamos pensado por hoy era hacerlo una especie de… No sé si decir de juego, pero arrancar con una premisa muy chiquitita y ver cómo quizá nos suele pasar pequeñas, no sé si decir malas decisiones o quizás desatenciones que a veces nos puede pasar por…

La prisa de entregar valor, de entregar solución, hace que esas pequeñas cositas de a poco vayan generando una bola de nieve que se va haciendo más grande y más grande y eventualmente, a ver, no sé, pusiste un nuevo campito que se calcula solo, funcionó, desplegaste a producción y se cayó todo. Veo errores raros, veo errores de límites, el usuario me llamó y dice que ha ido un CPU time limit exiled y no tiene idea qué es.

Entonces, poco era arrancar un recorrido súper súper chiquitito. Creo que lo vamos a dar por lo menos inicialmente foco a Flow para ver qué info es la que tenemos, pero es totalmente aplicable a Apex. Por ahí hay chicos que usan más coders. Las mismas precauciones que hay que tener en Flow los tenemos que tener en Apex también. No sé si querés meter algo de intro a este, sino vamos con el ejemplo.

No, no, sí, eso es que vos decís, o sea, como dijiste, bien todo lo que es Flow también se aplica al código y hoy más que nunca que están las herramientas de Bycoding, también hay que tener en cuenta esto de que hay que tener buenas prácticas también ahí y hay que también reglamentar un poco todo el desarrollo que se hace, no solo en Flow, también en código, porque sí, obviamente hay límites y cosas que nos chocamos siempre y nunca se sabe qué pasa y sí, sí, sí, coincido. Pero bueno, eso tenía para agregar.

Yo quiero agregar una cuestión que por lo menos a mí me ha pasado mucho y perdón que te interrumpa pero es muy filosófica si querés o de de maneras que es la típica de decir bueno hago esta solución para salir ahora del paso y después lo mejoro en el futuro la famosa técnica y eso nunca pasa o sea por lo menos es muy difícil después revisitar eso y acordarse y arraigarlo bien

Así que quería comentar eso porque es una cosa que es más como… es general a todo. Muchas veces uno empieza a hacer algo, hasta incluso cosas de la casa, que dejas así como por un rato con una cinta. la pollo en campo acá no botea, entonces ya lo dejo así una semana. Después lo arreglo y nunca… ese después lo arreglo bien nunca. Jodio que a él no se toca, dicen. Es una gran máxima que nos trae problemas después. En Argentina tenemos el bicho que es…

provisorio para siempre. Mi abuelo sabía de esas, mi abuelo sabía muchas reglas provisorios para siempre. Bien, la invitación también para todos los oyentes si tienen experiencias que quieran comentar porque esto yo creo que nos va abrir a varias anécdotas, un poco incluso nos basamos en anécdotas para armar esta masterclass porque nos la vimos muchas veces, entonces empezarán a aparecer ejemplos, trataramos de no mencionar

clientes o empresas donde sucedió. Pero sí, la parte divertida de lo que pasó, cómo lo arreglaste, este se. Bueno, dale. Eso significa que si tenés ganas de subir al escenario y contar alguna anécdota en donde nos la pusimos en la pera o en tu proyecto, en comentarios poné uno y te subo al escenario.

Sin mencionar clientes, o sea, como dijo Josu recién, el requerimiento es no mencionar clientes o proyectos específicos. Vamos con vos, Josu. De una. Y vamos a hacer algo súper, súper simple. Y fíjense cómo esto se puede ir al, me permita decir carajo.

Lo que me van a disculpar hoy es que estoy con una sola pantalla, que si en algún momento me ve consultas, porfa, ayúdenme. Y esto es casi de sencillo. La relación cuenta-contacto. ¿Sí? Una cuenta puede tener muchos contactos, lo sabemos. En nuestra implementación, las cuentas tienen un manager que es quien gestiona esa cuenta o ese grupo de cuentas. Lo que nos piden es, cuando yo cargo un manager en una cuenta,

necesito que todos los contactos de esa cuenta pasen a estar bajo el ownership de ese manager. Eso se traduce en el owner debe ser el manager de la cuenta. Es así de chiquitito. Pensemos entonces cómo resolvemos esto. Tenemos Apex, sí, pero tratamos de evitarlo lo más que podemos. Tenemos workflows, viejísimo. Tenemos Process Builder, viejísimo, listo. Tenemos Flows.

Vamos a crear un flowcito entonces que nos ayude a resolver ese requerimiento. Yo haciendo un poquito de trampa me adelante para que no me vean armar el flow. Denme un segundo que lo voy a abrir por acá.

Y si en internet no anda con baña, pierde el juego el pasajero. está tan bien. Escúchame en, Sí. Sáxi en buen grado. Que bien. Aunque no anda bien en el celular.

Entonces vamos a abrir esta versión de Flow.

Entonces nada, solo recapitulando porque se hizo largo abrir el flow. Tengo una cuenta, tiene un manager y quiero que ese manager se replique a los contactos o que sea owner de esos contactos. Bien. Y acá vamos a hacer un juego. Yo voy a ir mostrando cómo está armado el flow y quiero que encaje el chat, vayan corrigiendo o que ven raro. Entonces, ¿qué hizo Josu Developer? Creó lo que decíamos, un record trigger flow.

que corre sobre cuenta, marcamos que cuando un registro se actualiza, lo marcamos como Action Related Records para que trabaje con registros relacionados, no en sí con la cuenta. Y lo primero que hace Honshu es hacer un GetContacts. Dice, dame todo el objeto contacto donde la cuenta relacionada al contacto sea la cuenta que activó mi record trigger flow.

Y peor disculpa que aparte me agarró gripe verano y lo estoy pasando un poco mal. ¿Qué es lo siguiente? Kizu Josu dijo, bueno, listo, vamos a iterar entonces los contactos que conseguí, del primero al último, les voy a asignar el owner, va a ser en este caso el manager de la cuenta, y actualiza el contacto con el dato que acabo de calcular.

Josué que hizo? Creo el flow, hizo un debut, funcionó y dijo listo terminé el requerimiento. Porque aparte me lo habían pedido para ayer porque siempre estamos corriendo de que todo lo que me piden tiene que estar para ayer, testeado y funcionando en producción en dos horas. Me voy a permitir mirar un poquito el chat a ver si encontraron cositas raras. No todavía va, por lo menos a mi no me parece nada. Por ahora está bien, sí, sí. Dicen que

Bien, entonces dicen que está bien. Ok, Esti. No, pará, no dicen que está bien pero nadie cuenta si algo está ¡Dios, mudo! Soy con el chat. ¿Qué pasa? ¡Vamos! No pasa nada, no pasa nada. ¿Por qué no parte desde Contact?

¿Por qué no parte desde el contact? Porque el requerimiento básicamente era cuando cambiaba el manager que se actualizan los contactos. Ese era el requerimiento. ¿Podría tener una feria cuando se crea el contacto? otra vez el manager. Podría ser otro requerimiento. Update dentro del form. Supongo que se refiere al… Perfecto. Eso es uno. Sí.

¿Y por ahora eso? hay un estado de retraso. Estamos todavía en nuevas ocasiones, no pasa nada. ¿Qué pasa? Muchas veces, y esto es real, me ha pasado en requerimientos para él, quizá un poquito más complejos, queremos hacer algo simple, muchas veces nos olvidamos de los criterios de ejecución de un flow, ejemplo. Acá estamos corriendo cada vez que la cuenta se actualiza y se actualiza el manager, que es lo que nos importa en nuestro requerimiento.

Y la verdad que acá no me estoy dando cuenta, simplemente estoy diciendo se actualiza la cuenta, acá le cambiaron no sé el nombre, o algún otro campo, el teléfono, somewhere else. Y esto, invisiblemente, por si de alguna manera, a mí me está consumiendo tiempo y recursos de mi organización. Y yo les decía, muchas veces hacemos un requerimiento, anda, lo probamos, funciona, producción. Y resulta que en producción, así como este flow, tengo 20, 30. He visto organizaciones de Echacuna, más de 300 flows sobre un solo objeto.

Entonces, ¿qué pasa? Todo empieza a comer tiempo de CPU, empieza a hacer queries, empieza a actualizar info hasta que se elfona en momento y dice, achazo, estás tocando límites, no podés laburar. Entonces, lo primero siempre es reducir el escenario al mínimo para que mi lógica se ejecute. Porque si no lo estoy haciendo todo el tiempo. Y de nuevo, quizá en una hora con 100 cuentas, 200 cuentas no pasa nada, tengo dos, tres contactos por cuenta, esto funciona.

hasta que en algún momento se me llenó la or, quizá pasaron años. Y empiezas a pinchar por todo el lado y te das cuenta que tenés flujos que están corriendo todo el tiempo. Entonces, approach para nuestras automatizaciones, especificar bien cuando queremos que se ejecuten. Por ejemplo, acá yo puedo decir… Dale, Fran. No, iba a leer dos comentarios que me parece que van de la mano, dice… Eduardo me dice, ¿solo va a funcionar cuando haga una actualización en el cliente y si es nuevo no lo estaría haciendo?

Ese es correcto. Ese es una que creo que va de la mano de esto mismo. Y después Layton dice agregaría set entry conditions que solo sea cuando el campo owner de la cuenta se actualiza. Tal cual. Tal cual. Acá te agrego una experiencia personal. Hemos hecho proyectos que tienen muchas bu, sea business unit dentro de la misma organización.

Y es buena práctica ahí tener muy en cuenta el tema de los tipos de registro porque vos después, por ejemplo, haces una cuenta y una cuenta para una business unit tiene una automatización, pero para otra business unit no. poner esos filtros ahí adelante te ahorra romper todo cuando se agreguen ideas de negocio a una implementación porque nos ha pasado. nos ha pasado.

Y bueno, lo único que yo por ahora le reclamo a Selfort es que por ejemplo la parte de Record Types, creo, y por ahí algunos datos relacionados no los podés meter acá. Acá vos estarías obligado quizá a farcodear el Record Type ahí. O claro, tenerlo abajo como un Decision, que no tibio que sea. Claro, como lo haces en tráil pero después es como una magia, no haces nada. Claro, haces un Decision acá y decís che, si eso…

Sí. Pertenece a MiVeu, ejecuta, si no acá agregas un end y chau, algo como esto. Bien. Uy, no, lo rompí todo. A ver si puedo hacer. Sí, menú, ahí está. Lo vamos a deshacer para no cagar. Bien. Sí, los mismos países, viste? Cada vez que tenés muchos países en una org y van a decir que se complica. Cada país tiene sus propios preces y esas cosas. Sí. Bien.

Segunda recomendación, Esto también me pasó en un proyecto real. Nosotros acá hacemos, fíjense, un get de contacts donde tenés canal a cuenta y chau. Insisto, esto durante un tiempo va funcionar hasta que, por ejemplo, por que algo, no tenga más de 50.000 contactos en una cuenta. No sé si va a pasar, podría pasar. Por lo general lo que puede pasar va a pasar. Eso también, tengalo como una regla.

Si no, es muy poco probable, pero puede pasar sí, listo, va a pasar. Entonces, arreglénlo. Y creo que estoy bien peleando con algo así estos días, pero básicamente en mi proyecto, ¿qué me pasó? Teníamos una lista de productos que tenemos que levantar para asociar a listas de precios que se creaban. Nada, eso funcionó literal, un cliente que tuvimos creo que por tres años hasta que en un momento dice, che, la asignación de precios automático falla. No anda, y no puede ser, si eso funcionó, y nunca lo tocamos.

Y qué pasó, ya existían más de 50.000 productos en la or y esto empezó a fallar. Dice, che, no, me estás devolviendo más de 50.000 registros en la query. Va a pinchar. No hagan lo que hicimos en ese momento porque se lo pasó mucho. digo, che, fíjate que esto está fallando. Creo que pasaron 15 minutos y me hice listo campeón y lo arreglé. Tan rápido, ¿cómo hiciste? Y le puse un limit. Agarré y dijo, bueno, sí, dame, sabes qué, dame hasta 50.000.

La no buena práctica esa. Hace como no se me ocurrió antes. Bruto. Juzú, hay algo que estaban diciendo, perdón, Carlos dijo un comentario que dijo, se pueden fórmulas en el record type y creo que ha de razón, vos ahora en el flow podés elegir, tenés condition requirements, tenés el add, creo que podés poner una custom formula. no, no,

¿Viste donde tenes el Am? Sí, perdón. Ahí puedes acceder de alguna manera. Este es un gran truco. acá sí lo puedes hacer, tenés razón. Es bueno eso. Lo puedes hacer, el record. Bueno, justo ahí tiene record. a Carlos por… Bueno, justo por ahí no tiene, pero sí, puedes acceder a cosas relacionadas. Sí, totalmente. No, justo Carlos tiró y no lo quería dejar pasar. Básicamente lo que dice Carlos, por si no se entendió. Bueno, yo justo en esta órgano tengo tipos de registro.

en el objeto cuenta pero sería algo como esto si record.record.type.developer name

es igual por decir algo a business account. Entonces, de acá sí, no me acordaba, gracias, Carlos. Esto es algo que sí podés hacer. Entonces, de nuevo, recapitulamos un poco. Reducir la ejecución de mi lógica, de mis automatizaciones, al escenario donde yo necesito que corra. Y nunca jamás decir, no, lo dejo corriendo siempre por las dudas. Porque, de nuevo, haces eso con tres, seis, flows.

y en algún momento está pincha y te vienen a acorgar de que producción está caído, no pueden trabajar y en el peor de los casos terminas apagando flows en producción, que me ha pasado. Che, este flux que está corriendo del tiempo listo lo apaguemos, que el resto de cosas funcione y lo arreglamos. Bien, para acelerar un poquito, creo que alguien había mencionado en el chat, perdón, que puedo ver, que tenemos un update dentro de un fork, ¿qué va pasar?

Por cada contacto que yo actualice, estoy disparando de MNs. Y todos los triggers de contacto empezarán a correr. Y acá es donde empieza ese pequeño gran monstruo de… Esto es un record trigger de cuenta, pero estoy disparando en el record trigger de contacto. Y si los contactos actualizaron otros registros, esto se va al carajo. Entonces, nada. Buena práctica siempre esto que dar ir fuera.

de los ciclos de esta manera y estaría un montón de cosas. Parece una boluda, pero la verdad es que he visto muchas veces que se olvida. No sé si el flow te da esa sensación de como que está todo bien y te olvidás de poner cosas fuera de ciclos, por ejemplo. Y después está esta trampa que también la encontré en algunos proyectos donde hacen algo similar a esto. El flow es exactamente lo mismo, pero tengo la resolución de requerimientos, si se quieren entre comillas, en un subflow.

Entonces me dicen acá listo, sabes que ya no tengo DML ni queries dentro del Flow. Ya lo refactoricé y es óptimo. A simple vista parece que sí, pero cuando vas a ver ese Flow Reference… Eso pasa muchísimo. Pasa muchísimo. te hace perder mucho la noción de lo que estás haciendo adentro del subflow. Sí. Y claro, ¿qué pasa en mi subflow? ¿Estoy haciendo que te cuenta? Porque no me di cuenta y desde acá yo le paso el ID de la cuenta en vez de pasarles la cuenta.

y le paso el contacto que estoy iterando. Entonces hago una query de la cuenta, le guardo al manager, actualizo el contacto y la verdad es que la refactorización no es tal. Sigo teniendo lo mismo. Y a mí me pasó en un cliente bastante grande, con flujos bastante complejos, que tenía un subflow, con un subflow, donde dado cierto escenario, hacía un DML.

Entonces hicieron una carga masiva de registros que creo eran cuentas justamente. Y era che, pero yo no tengo de mail en ningún lugar porque está pinchando. Y claro, entre tantas ramificaciones de flow, una de los escenarios válidos era una actualización de un registro relacionado. Y qué pasa, todo el set de cuentas que estaban actualizando cumplía los requerimientos para que vaya por ahí. Entonces también ojo, ojito, ojazos diría un profesor mío. También con las refacturizaciones con subflows.

Esto es muy, muy común y tardás mucho a veces en darte cuenta, como decía Fran. Entonces, ¿qué pasa? Todo esto de nuevo. ¿Por qué estamos hablando de todo esto? Se come tiempo que inicialmente quizás es invisible en tu org, pero a medida que vas creciendo en registros, esto se puede llegar a pinchar. No necesariamente estás creciendo en automatización, sino que con registros de un momento a otro deja de funcionar y todo se mira en la cara y como…

Che, pero nadie tocó nada. ¿Quién desplegó? ¿Alguien subió algo? O hasta la pregunta ¿Alguien tocó algo en pro? Nada. Josu. Dale. Tengo una pregunta que me llega al WhatsApp directo. ¿Desde dónde? ver. Roberto de Wichita. Ok. Me dice. Josu. O sea, ya te lo escribes directamente para Exactamente para mí. Ok. Josu. ¿No es que en Salesforce todo es eterno?

y no hay límites, no entiendo lo de que me consume CPU. No es que la nube está en el cielo, está loco. No entiendo a los amigos de Wichita. Bien, piensen en Salesforce y la nube como un edificio de departamentos. Cada organización o cada cliente está en un departamento. Y en esos departamentos…

Vos tenés cierta cantidad de agua que podés usar, cierto ruido que podés hacer en ciertos horarios. Y básicamente esos servicios los estás compartiendo con otros departamentos que serían otros clientes. No nombro a mi empresa, tengo la empresa A y la empresa B compartiendo el mismo edificio. Está bien, las dos empresas no tienen ni idea que la otra comparte edificio con la otra. Pero Salesforce, para que todos convivan en paz y tranquilidad, te pone límites.

Che vos de agua puedes consumir 3 litros al día. Consumiste 3,1, si el rete che acá ya no puedes consumir más agua, espera mañana. Bueno, un poco pasa eso con los recursos, vayamos ya a la tecnología, en tiempos que puede durar una transacción, cantidad de queries que puedo hacer, cantidad de trabajos asíncronos que puedo tener corriendo. Selfort te pone el límite justamente para que todos vivamos en paz y tranquilidad, porque imagínate que vos haber hecho un mal desarrollo.

que funciona pero no es óptimo, hace que tu vecino no pueda entrar a Salesforce. Bueno, para que eso no pase, Salesforce te pone el límite y te dice, che, hasta acá puedes llegar. Y si te pasas de ahí, muy probablemente te bloqueo las transacciones por un rato. Suele ser a veces por una hora, por un día, 24 horas, depende. Pero es básicamente para que todos convivamos en paz y tranquilidad. Y nosotros, como consultores, nuestra obligación o nuestra tarea es que, justamente, automaticemos, siguiendo las buenas prácticas, para no molestar.

ni a nuestro cliente, ni a sus vecinos. No sé si se entendió.

Sí, y que también a veces ese límite de agua te lo cobran un poquito más si lo quieres ampliar. Claro que a veces pasa. Y después, una cosa que quiero también contar del tema flows, que también parece como muy atractivo a veces o parece muy fácil de resolver un problema, pero que después siempre termina mal, es poner a iris ahí adentro. Creo que en el código está como más naturalizado, que no hay que hacerlo y que está súper mal.

Pero creo que es mucho más normal ver una ID o una referencia dura metida acá adentro y eso después también siempre termina mal. Siempre que vos metes una ID está todo ese tema de que se supone que ahora los sandbox podrían tener los mismos ID pero es algo de lo que no te podés confiar nunca y es algo que no deberíamos hacer como buena práctica porque después el registro ese vos lo querés borrar o algo y querés agarrarte un nombre y no podés. O sea, dependés 100 % de eso que está ahí puesto.

por el proyecto que estamos trabajando en una empresa de transporte. Pues ahí es todavía peor porque ahí a veces está en el código también. Ahí hasta la gente lo tiene tatuado a los IDs. Sin mencionar la empresa, una empresa de transporte marítimo, muy grande, ahí se forma una bola de nieve. Es decir,

Porque en una colección de creadas hace cinco años atrás, se dijo, bueno, esto es provisorio, después lo arreglamos. Y después empezaron a aparecer más flows. pero qué fiaca ir a los otros flows y refactorizarlos para sacarles los IDs, jarcodeas. Lo hacemos, lo hacemos. Se está propagando.

Por eso hay que luchar mucho contra ese impulso que te dice lo hago así nomás mismo en los nombres de las variables muchas veces de los flow. Vos entras y dices de, por ejemplo, de una variable o un a. Y eso es porque alguien lo hizo así para empezar a probar algo, quedó, o sea se dio cuenta que iba por ese lado y lo dejó ahí porque es lo que decíamos al principio. Dice después lo arreglo y no llega nunca, entonces es mejor tratar de ir y hacerlo bien de una, que sí que es una faja. 16.30. Un segundo que tardás de más. Después hacen que quede más perorijito,

Sí, que no renegues a futuro porque por ahí, como te digo, estás apurado entregando, entregando, entregando, te sentís un crack y en el momento que pincha esa sensación de ser crack y se caiga todo también, te matas. sí. J. Ruiz dice, siempre se usa metadata o algo para evitar el uso de Jarkoder internamente, también he visto a Iris Cample, que es como una…

Es como un jacodero pero nivel pro, Elegante, claro. Juliana… Juliana tiró algo bastante interesante que después le hablamos del tema de permisos. Dice que da permisos a todos, no importa quién tiene que acceder a este campo, a todos. Esa es la típica… Emitado la parte… Borrar todo, sí, dame todos los permisos.

Total. eso, bueno, obviamente con PermissionSets o haciéndolo más granular se puede, en teoría, arreglar, ¿no? Porque si no, a nivel perfil ya como que Zenfone está queriendo deprecar que es permisos a nivel perfil y llevarlo más a lo que es PermissionSets y PermissionSet Groups. ¿Qué es eso de lo cual vamos a hablar probablemente en alguna clase exclusiva? Los PermissionSets.

y Permission Sets Groups son el futuro en cuanto a la administración de la seguridad dentro de Salesforce, en donde en el perfil de usuario principalmente quedará la asociación a la licencia, me imagino. No sé si a futuro un perfil de usuario, más allá de vincular a un humano con una licencia, pueda llegar a gestionar.

Bien. Perdón. Vuelvo un segundo y yo cierro la parte de flows, que creo que es lo que más trabajamos todos durante nuestras jornadas y ahora y yo creo que a futuro porque Salesforce sigue metiendo cosas a flows. Por ejemplo, cuando toman un decision, yo como ejemplo acabo de agarrar, por ejemplo, validar en un decision que el manager de la cuenta, recuerden, el requerimiento no sea nulo, isNull, false. Tenemos acá abajo algo que a veces no se mira.

que es básicamente ejecutar esto todo el tiempo, o sea, siempre que el registro cumpla la condición, o solamente cuando el registro cambió y empezó a cumplir la condición. No sé si lo estoy diciendo de forma clara. Yendo desde acá es, che, antes era nulo, sí, ahora dejó de ser nulo, sí, listo, entonces voy a ejecutar mi lógica. Si en el futuro se vuelve a actualizar la cuenta,

y el manager ya no era nulo, esto no se ejecutaría. Eso también es muy importante en los decisions. Y a veces no lo tomamos tanto en cuenta y solamente cuando esté cambiando es que a mí me importa hacer algo. Y esa no, pero esto también nos reduce un montón de tiempo. Fíjense que este flujo arrancaría, revisaría este decision, diría, che, ya no era nulo antes, sigue no siendo nulo, no hago nada, y me ahorro de hacer un get, un loop y un update, incluso habiendo optimizado toda mi parte del flow.

mmm… iba a decir algo más pero no me acuerdo, así que si quieren pasamos a otra cosa que no tenga que ver con Floss.

No, sí, eso está bien. Me parece que también sirve mucho por el tema de… Esto es muy peligroso para cuando esa acción, en este caso, estás asignando, pero ponerle, si esto envía un email, cada vez que actualizas en un campo, que no tiene nada que ver con lo que el flujo está chequeando, dispara un email. Y voy decir, ¿por qué dispara cada vez que actualizo algo que no tiene nada que ver? Y es por ese cheque vos pusiste abajo, así que sí, tal cual. Suponente que cuando cerrás una oportunidad, querés enviar un email… Ok, envía el email la primera vez, todos felices.

Después se actualizaba, no sé, la descripción de la oportunidad, envía otro email de che, la oportunidad está cerrada y ahí todos se preguntan ¿por qué se envió de vuelta? Y bueno, justamente es por eso. Tiene que solo cuando el requerimiento se cumplenó cada vez que está seteado así.

Bien.

¿Qué más teníamos? Bueno, un poco lo que decía… ¿Quién fue que lo mencioné? Perdón. Sobre los permisos. El mismo escenario, entre el apuro, che, tengo que crear un campo nuevo de manager, habiendo en cuenta. Y necesito que lo pase esta producción. Y la rápida, creo el campo, permiso para todos, lo pongo en el layout, lo agrego y nada, perdí el control real de quién debería poder manejar un manager o setear el campo, cambiarlo.

incluso verlo, eso es que también… De nuevo, muchas veces nos pasa que en el apuro de que las cosas funcionen y estén en producción, nos lleva a tomar esas pequeñas malas decisiones que, de nuevo, vas enganchando una con otra, una con otra y de repente te cae una auditoría de por qué un vendedor está bien del límite de crédito de algún cliente, por decir algo. ¿Sabes qué buena práctica, micro buena práctica te podés complementar ahí, Josu? Sí, obvio.

Vos tenés el Fistory Hilt, o el historial de campo, que de manera nativa, Headforce te permite tener un historial de campo de hasta 20 campos por objeto, con la posibilidad de pagar un pequeño upgrade y llevarlo a 60 campos. Suponete que el tema de la visibilidad, que es bastante sensible, como por ejemplo ver…

el precio de costo de un producto que un usuario estándar no debería poder acceder a ese valor, dejando tema, cuestiones relacionadas a la visibilidad que sí se suelen enforzar, pero no el tema de la modificación, si a los campos que son absolutamente críticos, como el número de una cuenta bancaria o como el límite de crédito, vos le ponés

dentro del Object Manager, te vas a History Field, te pones el check a ese campo que es crítico, te vas a asegurar que cada vez que se cambie el valor de ese campo, aparezca, fecha, hora, nombre del usuario que hizo la modificación, cuál era el valor anterior y cuál era el valor nuevo.

Y una de las cosas que también tienen que tener en cuenta es que esta funcionalidad permite utilizar reportes. Por lo tanto, vos tenés la chance de crear un reporte o un informe de auditoría que te vaya mostrando todos los cambios de campos específicos. ¿Qué opinas de esto, Josú? Termina siendo, o sea, súper útil, pero también, sea,

Todo lo que tiene Selforth es útil y por algo lo tiene, pasa también por las decisiones que tomas. Porque siempre ponerle de todo a… Historial de campo a todo, porque sí, está llenando la memoria de Selforth y como hablamos recién, todo tiene un límite, incluso el storage de Selforth. Entonces, auditar por auditar solamente para mí no es una buena práctica, por lo menos para mí, me pueden contradicir si quieren. Por esto que digo.

Quizá no lo va a ver nadie y a nadie le importa que el contacto antes era Juan y ahora es Juancho. Quizás sí le importa que cambié el DNI, por decir algo. La herramienta está en nosotros tomar buenas decisiones para que la responda óptima y, por supuesto, soporte o la información que necesita el cliente tener.

Muy bien, muy bien. Bueno, ¿qué otro tema tenemos? Y salimos de Flow.

Tiene que ver un poco con storage. Yo tengo un ejemplo que me habrá pasado creo que no hace más de un mes. Tengo un pequeño diagramita similar al que teníamos donde me dijeron, che, mira, yo tengo el objeto cuenta, cuentas personales en este caso, y tengo unas promociones que yo quiero asignar a los clientes. Y esto pasa, digamos, de decir, OK, tengo dos tablas o dos objetos. ¿Cómo hago esas asignaciones?

Lo normal o lo cotían y lo correcto, esto es para debatir, es lo que pasó. Es creamos, un objeto promo cuenta, donde dice, esta cuenta tiene estas promos, entonces hago un join y listo. Técnicamente tiene sentido, es algo como modelamos muchas cosas en Salesforce.

Algo que no Bueno, nada, voy y pregunto, che, ¿y cuántas promos tenemos? Y van a ser como mucho 20 promos. Ok, buenísimo. ¿Y cuántas cuentas tenemos en la base? En realidad nosotros teníamos 4 millones de cuentas, pero para este ejemplo lo traje con uno. Entonces digo, che, ¿y qué onda? ¿Cómo segmentas las promociones para las cuentas? Y es… No. Todas las promos son para todas las cuentas. Entonces ahí el análisis viene, che, ok, tengo un millón de cuentas. Tengo 20 promos.

Voy a generar una tabla join con 20 millones de registros sabiendo que todos van con todos. Entonces digo, che, no tiene sentido porque esto después lo tenemos que mandar por API a otro sistema, bla. Tomamos la decisión de no hacer nada en realidad en ese campo porque pasaba esto. Un poco desconecto que los convencí. Ten estas cuentas, ten estas promos y terminas armando una cosa gigante de relaciones entre objetos.

que conceptualmente tenía sentido, era correcto, pero no íbamos a usar para nada. ¿Con qué hiciste ese dibujito? ¿Ese dibujito usaste vos, el de abajo? Sí, obvio, agarré paint, lo abrí y empecé a tirar líneas. sí. ¡Tiro magia, tiro magia! Es una espectacularidad. Me encantó. Bien, entonces, esto era otro también mensaje. No es solo cumplir por cumplir, sino preguntar bien por qué queremos hacer, para qué queremos algo.

Y de última, una propuesta después para evolucionar esto fue, OK, ¿querés segmentar de alguna manera? Lo que vamos a hacer acá es asignarles como niveles a las cuentas y que las promos también tengan niveles. Pero esto no va a existir porque sigue siendo un producto factorial gigante. Te digo, si esta cuenta es nivel 1, dame las promos de nivel 1. Y no se las asigno realmente porque en este caso no nos importa decir, este cliente ya usó tal promo. Y si lo hiciera, en ese caso recién creó un registro.

Se debía de una cuestión de conocer también la plataforma, esto es así en Salesforce, porque cada registro te ocupa medio que lo mismo por esta cosa de que Salesforce te dice, dame un registro de 150 megas de espacio para un registro de cualquier cosa, tengas un campo, dos campos, tres campos o 50 mil campos. Entonces, saber eso es lo que te hace tener en este caso este análisis de decir, che, voy a crear 20 millones de registros que me van a ocupar lo mismo con un registro de cualquier otra cosa.

no vale la pena, porque por ahí si vos tuvieras una base de datos normal, fuera de Salesforce, esa relación entre espacio y registro no es tan lineal como la tiene Salesforce. No, igual es mala práctica, para mí cualquier sistema es mala práctica. Está bien, pero en Salesforce más todavía, porque creando un registro que te ocupa la misma cantidad de espacio que cualquier otra cosa, por algo que no te está portando prácticamente nada.

Sí, sí, sí. En ese sentido Sefor te lleva el límite para aplicarlo mejor en otros sistemas. Por ahí estás en otro sistema y sí. Te lleva el límite. Son 2K por registro. Si alguien en algún momento tiene curiosidad de saber qué cantidad de espacio de almacenamiento ocupa, cada registro son 2K. creo, si no recuerdo mal, que el valor…

o el espacio predeterminado de una Salesforce org tiene actualmente son de 10 gigas. Yo les quiero comentar que en la antigüedad ese espacio era de 1 giga. Estoy hablando hace más de una década atrás, sí, mucho más de una década atrás, cada Salesforce org tenía solamente 1 giga y hubo tanta presión por parte de los

de los usuarios del Salesforce, que, esto es irrisorio, cómo va a tener un solo giga de espacio de almacenamiento que se llevó a 10. De todas maneras, a 2K por registro, 10 gigas, ¿qué te da? 5 millones de registros, más o menos. Es un montón, pero, a ver, de nuevo, si empezás a crear objetos por crear y… ¿qué tal? Bien, como digo, insisto que hay mucho análisis que tenemos que hacer para tomar decisiones muchas veces, porque…

Teóricamente, técnicamente era una solución correcta, pero bueno, estamos en Salesforce y sabemos que hay ciertos límites. Aprovechaba también el bocado, hablando un poco de perfo, hay dos cosas. Salesforce nos permite ver el de storage, sea, cuánto está ocupado de mi org y cuánto está ocupado por cada objeto. Y me ha pasado mucho que me llamó el cliente y me dice, me llama Salesforce porque me quiere vender almacenamiento porque estoy a tope. Y la verdad es que no quiero pagarle más a Salesforce.

Esta parte en la Hospicia Salesforce de la charla se parló. dice cómo puedo hacer para reducir espacio. Y te venís acá. Y muchas veces me ha pasado de ver objetos, no sé si decir irrisorios, pero que no eran centrales para el proceso del cliente. Quizá email message me ha pasado. era, che, ¿por qué guardan todos los emails? Y porque alguien una vez dijo que estaría bueno tener todos los mails en Salesforce. ¿Los leen? ¿Se hace una editorial? No. ¿Podemos limpiar? Sí.

Me ha pasado también en un cliente que dijo, che, cada vez que yo tengo un cliente quiero la foto de perfil de mi cliente en la pantalla para saber con quién estoy hablando. Y eso ocupó todo el file storage. Y era solo porque quería ver la cara del cliente. Y dijimos, che, bueno, lo podemos migrar a no sé, a web service, a una story interna. Es no, si es solo para ver la cara del cliente, eliminarlo y chau. Vieron que hay decisiones de compra chiquita que después pueden traducirse a problemas, no sé si económicos, pero…

por lo menos amenazan la economía. Último y cierro parte de Storage, también sepan que hay un export de data, donde también tengo una anécdota, que básicamente vos de acá de Selfort podés exportar data para hacer backup. Vos decidís qué objetos querés exportar según lo que trabaje tu organización y esto te genera unos archivos comprimidos con CCB de toda la info.

Recomendación, sean conscientes cuando van a borrar porque me pasó que un cliente dijo sí, elimina todos los casos porque estoy hasta las bolas Perdón la palabra. De storage, necesito seguir creando casos, listo. Seguro lo borramos, sí, lo borramos y borralo, listo. Backup, tenemos todo almacenado, borramos casos. Dos semanas y viene el manager, creo que era de Chile, dice, ¿sabes qué? Necesito que vuelvan a subir a Salesforce todo el historial de los casos 2022 a 2024, creo que era.

Y era, pero dijimos que no, y nos hicimos el for, que ven que cargaba de nuevo y hubo que inventar external ID, volver a subir todo. Y la pasamos mal. Creo que pasamos un mes subiendo casos viejos con un record type de casos viejos, creo que era, no recuerdo cómo se definió. Solo para ahorrar storage y el delete que nos habrá tardado 20 minutos. Nos comimos un mes restaurando la data. ¿Juzu, y ahí la papelera de reciclaje no le es?

En ese momento, capaz que era, o sea, capaz que 10 o más años, no había papel en aquella época. Claro, o capaz que ya ha pasado, porque creo que lo almacenan 90 días y después chau. Sí, Mira, si hay que ahondar en detalle, me parece que existían, pero en ese momento Selfort te pedía cash para restaurar lo que estaba eliminado. No sé si ya había pasado más tiempo del que debería, o algo por el estilo, tomaron la decisión de que era más barato volver a subir todo que pagar a Selfort para restaurar.

Y ahí también como buena práctica es cada vez que te piden tocar algo de la data de producción, eso tiene que estar firmado con sangre en un correo por la persona que te lo está pidiendo y tener que tener todas las garantías que puedas tener de que si vos vas a hacer algo, eso está muy bancado por la gente que te lo está pidiendo porque una cagada ahí es… bueno, se imaginarán.

sea, puede ser una boludez o puede ser muy muy sensible y una caída muy grande. Entonces, primero lo mejor es evitar todo eso. O sea, si le podemos dar la herramienta para que lo hagan ellos, o sea, la gente del negocio, mucho mejor. Pero si no podemos, porque lo tenemos que hacer nosotros, tienen que cubrirse por todos lados. Por más que parezca de ponerse en forro o poca voluntad, es realmente lo que vale la pena. Porque si no, después te podés quemar heavy con eso. Entonces…

Bueno, eso, tener presente esa cuestión. Tengo una pregunta para Bebu Corazón que la puede responder. ¿Está de vacaciones? no, está acá. ¿Qué haces de ti? Estoy dando mi apoyo acá. Pensábamos que estaba de vacaciones. Claro. Mariana de Berlín te está mandando una pregunta a Bebu y dice ¿cuáles son las prácticas

las buenas prácticas para archivar información vieja de objetos de manera automática a lo largo del tiempo. Bien, archivarlas dentro de Salesforce, no se, depende del requerimiento, ¿no? Las querés tener en otro sistema. Ahí depende, ¿no? Si por ahí lo querés tener dentro del mismo Salesforce, podés usar, podés hacer uso de lo que es el Big Object, también es como una especie de licencia que tenés que pagar.

Pero, bueno, Salesforce recomienda también usar los Big Objects porque es básicamente un objeto que te deja almacenar millones y millones de registros, pero lo malo es que no puedes hacer nada, o no puedes automatizarlo, no puedes hacer un flow, ni un trigger, ni nada. Esas una de las maneras. Y si no, otra forma, si por ahí no se quiere dentro de Salesforce y no le querés pagar a Salesforce para que te abrite los Big Objects, es, bueno, tener una base externa, tener una base de datos externa, no sé, como decían Amazon.

o una base de datos, no sé, MongoDB, una base de datos. Y todos los días programar un export, ¿no? O, bueno, depende de la frecuencia, semanalmente, y enviar esos registros a un archivo y ese archivo automatizarlo para que se suba a la base de datos externa, que, bueno, en este caso no estaría dentro del Salesforce. Y después ahí podés conectar lo que sería external objects, ¿no? External objects con la base de datos externa donde están sus registros robados.

eliminados, que ya no están más en Salesforce. Y, por ahí los que querés acceder igualmente en Salesforce, bueno, ahí haces la conexión con External Objects, que también es otra característica de Salesforce que también es paga, que te deja tener los objetos como si fuese en Salesforce, pero sin ser de Salesforce, porque la base de datos no está en Salesforce. El uso está muy bueno eso que estás diciendo. El uso pensado para External Objects me da la sensación que es para integrar

con aplicaciones externas, por ejemplo, tener un ERP del estilo de SAP, como querían decir, y parte de la base de datos de SAP exponerla dentro de Salesforce. Tal cual, tal cual, tal cual. Y ahí sí, vos podés hacer automatizaciones y todo tal cual, como un objeto normal, solo que no vive en la base de datos de Salesforce. Pero ahí, bueno, yo me topé con problemas con eso porque dicen que…

Es bastante, el precio de eso es bastante elevado para, no sé, depende de lo que quieras hacer, Pero sí, hay que tener cuidado con eso también. una práctica también en donde hay aplicaciones en el App Exchange que hacen lo que voy a relatar ahora y que incluso lo puede hacer uno, son objetos de consolidación. Por ejemplo, oportunidades. Imaginad de tener trillones de registros en oportunidades. Bueno, hace una cosa. Tené.

las oportunidades de los últimos cuatro años y de los años anteriores, lo que vos podrías hacer es, con un proceso, recorrer todas las oportunidades de una cuenta de un mes particular y creas en otro objeto un registro que tenga la totalización de todas las ventas que vos hiciste durante un mes. Entonces, la información la seguís teniendo.

dentro de Salesforce, la seguís teniendo accesible y lo que terminaste haciendo es meter en 12 registros, un registro por mes, la totalidad de oportunidades de un año de cada cliente. Ese tipo de práctica se utiliza mucho y permite de una manera consistente tener gobernado el tamaño de la base de datos. Claro.

apoyadísimo en esta constrain que decíamos de que para Salesforce cada registro pesa lo mismo. Entonces ahí podés hacer esto de decir bueno resumo 150 mil registros en unos solos. No quiero ovardear acá. Pienso que es un límite imaginario lo del tamaño de 2k por no sé si físicamente. No físicamente creo que es imposible pero bueno también me supongo que así se aseguran de que. Te imaginás que lo haga físicamente.

Para mí es imaginario, no creo que físicamente en el data center de Salesforce cada registro tiene un solo campo completado. No, claro, por el resto te lo lleno de unos, no creo. Buena pregunta. Para ahí cerrando, si ya están en una organización en la que hay muchos flows, hay triggers, pincha por time limit, yo creo que al que más tiempo le dan…

Al que más miedo le tengo, perdón, es al CPU Time Limit. Hay una herramienta que creo que la hemos mencionado en alguna otera Masterclass que está disponible para visión de Studio Code, donde ejecutan ustedes lo que sea, el envío de mail, la actualización de cuenta, se baja en el log y esto te arma como una especie de call tree, donde te dice qué es lo que está haciendo cada uno. Fíjense que me va diciendo cuántos SQL queries tiró.

cuántos registros devolvió, cuánto tiempo de CPEO Time Limit está ocupando cada uno. También tenés una vista de análisis, donde te dice en porcentaje, por ejemplo, los tiempos, cuál es el método que más está ejecutándose, cuántas veces ejecutó cada uno, como para ir sabiendo hacia dónde virar cuando se encuentran con estos problemas. Porque muchas veces entramos a orcas que existen hace tiempo, no tenemos el control sobre todo, y nos tenemos que adaptar también un poco a lo que hay dentro de la orca.

a medida que nosotros podamos meter buenas prácticas. Esto se llama Logan A Laser, está disponible para Visual Studio Code y la verdad es que a mí me ayuda mucho porque incluso cuando estás viendo desde acá, ya te pone una línea roja diciendo acá pinchó, este es el error, entonces puedes ir a mirar un poco más. Muy bueno. Esto en curso la anda, sí, porque es lo mismo. Estoy en curso, de hecho, en este momento. Está muy bueno, ché. Hay…

Otra herramienta si queréis también, y cerramos, Josu, esta está buena para el código, pero quizás una más para ver la performance del entorno, creo que da para otra masterclass, porque es bastante completa y es dentro de todo, o sea, no es algo súper nuevo, pero es algo que sé porque está metiendo también bastante ahora, comparto pantalla, le muestro un toque, que es, vamos a ver acá.

Es el Scale Center, no sé si lo llegaron a escuchar. Perdona, ver, vamos a… Vamos no, no lo conocía. Vamos acá, vamos a… A entrar a esta org… no, en esta… Creo que ya… En esta estoy comiando. Si tú haces el setup… Y acá buscas el Scale Center… Este también es pago. Bueno, no es pago, sino que tienes que hablar con un representante de Salesforce y te lo habilitan.

Tienes que hablar con un ejecutivo para que te lo encuentren. Sí, sí, Bueno, esta primero que nada para Apex, está buena. Esta simplemente te avisa el coverage de tu código. O sea, por si algún día querés saber tu coverage y no te querés meter en la Developer Console, te metés al Application Tech Execution y acabes todo el coverage para ver la salud también de tu org, de cómo están los tests y cómo está corriendo todo. Después la otra.

No me dejas aluviarme, no sé, Josu, vos si tenías la Orglobea porque a mí no me está pareciendo. No, pero igual si querés lo contamos. Básicamente es un análisis de salud de tu Org. Acá, acá, esto, exacto. Ahí está. Esto de acá. No lo encontrado. Pero sí, tal cual. Es un análisis de salud de tu Org que te hace, como dice Josu, y donde vos podés programar qué es lo que querés que pase. Por ejemplo, si querés ver cómo es el horario pico.

No, suponete a las 3 de la tarde, están muchos usuarios conectados al labor y querés identificar, no sé, identificaste que en ese horario pico hay un cierto delay al crear tal registro, una oportunidad de actualizar, notás que hay como un delay, vos con esto lo podés, o sea, deja de ser una sensación tuya y lo podés poner a prueba con esto y donde vos decís cuándo querés probarlo, por ejemplo acá te dice identificar el horario pico.

tenés que más o menos saber qué es lo que querés probar, ejemplo, ejecutar un batch que se ejecuta a esa hora para enviar emails o actualizar oportunidades. Y vos, acá vas diciéndole esa información y esto te lo hace. Te lo hace a ese horario pico, te crea un set de datos de prueba que obviamente vos lo tenés que pasar y le decís qué querés que se ejecute. Quiero que se ejecute este flow con este batch.

Y después esto te va a hacer un análisis con las métricas de lo que estuve identificando con esos tests que vos le dijiste que corra a ese horario pico. Entonces acá puedes hacer reportes, puedes ver más o menos cuántos segundos tardó en crearse, en actualizarse una oportunidad para que dejes de pensar que es una sensación de que viste a veces decir, che, la orga está muy lenta. Bueno, con esto por ahí lo puedes parametrizar y lo puedes analizar. Y bueno, nada, es algo que está bastante bueno que…

No lo voy a hacer ahora porque es bastante más complejo de lo que uno cree porque tiene varias etapas pero vale la pena porque te dice realmente cuándo está lenta, cuál es el tiempo aproximado que se toma en hacer tal operación, en enviar un email y todo eso. que nada, está bastante bueno. Sí, sí, les dejo la información porque está bastante bueno. Y bueno, es para que cuando vean que la orga está lenta, es básicamente… Es para discutir cuando te dicen que se va formando a lento. Sí.

Total, total, sí, sí, Me gustaría spoilear algo, si les parece, con la idea de… Quiero spoilear algo con la idea de que Fran lo comente, con la idea de que Fran lo comente y es algo en lo que estamos trabajando y que en un futuro les vamos a compartir a todos ustedes. ¿Qué es esto, Fran? Muy bien. Antes de pasar a eso, dice si te lo abritan gratis, pregunta Eduardo, ¿ves ti?

Tenés que hablar con un representante de ventas. Yo creo que sí, creo que te lo abritan gratis. Porque yo lo tenía ahí abilitado y no hice nada. Estamos armando una guía de estándares de desarrollo que va a tener un poco de todo. a tener… Hay muchas guías de buenas prácticas de Apex y Salesforce tiene las propias de Flow. Nosotros lo que estamos haciendo es mezclar un poco todo el universo de desarrollo en Salesforce y armar nuestras buenas prácticas. Con un objetivo…

Podemos decir doble. Por un lado, estandarizar todos los desarrollos que vayamos a hacer y por otro, que esto sea lo que le damos de comer a un cursor o a un antigravity para que todo lo que ya nos desarrolle no nos desarrolle con nuestras buenas prácticas. Y tenga en cuenta todos los temas de no meclatura, de no meter demos dentro de For, además de las obvias.

cómo nomenclar las cosas, cómo nomenclar los nodos de los flows. Es una de estandarizar todo. Así que es eso. Queremos hacer un estándar de industria, si pudiéramos con esto. Lo que sí me gustaría comentar es, son 38 páginas de documento, número uno. Número dos, no existe en planeta Tierra.

Esto que están viendo acá no lo tiene ni Salesforce, no existe. Lo tuvimos que construir nosotros. Número 3. Les vamos a dar acceso a este documento para que lo puedan utilizar en sus proyectos. Y número 4 también lo vamos a dar en formato de prompt para que puedan meterlo como instrucciones en herramientas como Cursor y a la hora de hacer diseño con Gemini.

Chat ChipiKey o Cloud también lo puedan usar. Próximamente, de nuevo, les vamos a dar acceso a esto. Es un trabajo en progreso. Y realmente el mérito de haber empezado todo esto es de Fran. Lo terminamos co-creando, pero el mérito es de Fran. Y en el chat, lo que están viendo la grabación saben que no van a tener acceso, pero en el chat compartí el.

código para que puedan formar parte del sorteo que vamos a hacer de certificaciones. Bien, creo que ya estamos, ¿verdad?

Estamos redondeando la clase. Un montón de gente. info. Bien, mucha info. En 24 horas van a tener la grabación. Les mandamos un beso gigantesco el jueves de la semana que viene. Ya recuerden, ya estamos activando todas las semanas a las 4 de la tarde. Tenemos clase el jueves próximo con la teacher Angie.

Comenzamos con las clases de inglés para self force. Jueves de la próxima semana, master class, después inglés para self force y así, eternamente. Los queremos un montón. Que tengan una tarde hermosa. Fue un placer gigantesco y como no están sugiriendo más música de despedida, sigo con la misma que recomendó la Inteligencia Artificial a la espera de que nos den un…

una sugerencia de vídeo para poner al final. Los queremos muchísimo. Chao. Nos vamos.

y