Salesforce » Seguridad y Gobernanza: La Guía Esencial para Admins y Developers [Masterclass]

Juan Manuel Garrido (00:00)

16 horas.

Qué alegría me da verlos aquí y comenzar una nueva clase. Muy bienvenidos. Vamos a arrancar full máquina dentro de algunos minutos. Voy ir saludando gente, alguna de las personas que están conectadas mientras esperamos que al resto de los teachers y al resto de las personas que se registraron para esta master class del día de hoy se conecten.

a quien veo muy fugazmente a Valery, a Juan, a Rodolfo, a Ernesto, Bárbara.

Fesal, Fesal, en el chat decime. ¿De dónde sos? Fesal, Linda, Enzo, Jesús, muy bien, de a poco, todos van llegando y les quiero hacer una charla introductoria de un tema que me está dando muchas vueltas por la cabeza mientras esperamos a que se suban todos y arranquemos.

esta clase en la tarde de hoy y es cómo todo está cambiando con Juan, con Fran. Qué hace, Fran? Buenas, buenas. ¿Cómo andan? Bien, bien. ¡Bua! ¡Saa! ¡Pichería pesada! Muy bien, escuchen, Mientras se va sumando gente, yo quería hacer una reflexión.

una reflexión acerca de cómo todo esto está absolutamente cambiando. Yes.

Hace 25 años atrás, el software se licenciaba con licencias por usuario. Tenías, por ejemplo, una empresa que quería digitalizar todos sus procesos con Oracle CRM. Y lo que tenía que hacer es pagarle a Oracle una licencia por cada humano, por cada usuario.

firmaban el contrato, Oracle lo desenviaba, descargaban el CRM, se lo tenían que instalar en infraestructura propia y después pagar planes de actualización, soporte técnico y toda la historia.

Antes de avanzar con esto, pregunto, Adrián, ¿te tocaste a lo largo de tu espectacular carrera con este modelo o ya arrancaste de una en la nube? Yo arranqué de una en Salesforce directamente. Todo el finche fue Salesforce en mi vida. Bien. ¿En qué año? 2016, creo. Muy bien. 2016. Volviendo a este esquema, allá.

1999 viene Salesforce y se comienza a gestar el software as a service, en donde las empresas tienen la posibilidad de, en un único pago, una suscripción, se sigue sumando gente, buenísimo, ya estamos a minutos de arrancar, en un único pago, una única suscripción, pagar la infraestructura, el mantenimiento de esa infraestructura, antivirus, firewall, actualizaciones, versiones nuevas.

cierta capacidad de soporte, etcétera. Y es lo que hoy conocemos. Hoy el software se, te dirían, el 99,9 % de los casos se consume así por suscripciones. Y ahora vienen toda esta historia de los tokens, los créditos, los flexi credits de Salesforce en donde acá comenzamos. Este es un tema que lo hemos hablado con Francisco.

hasta el cansancio. A mí particularmente me desquicia de entusiasmo pensar en que las empresas van a poder, primero, hacer una inversión en tecnología atada al retorno de la inversión, porque más créditos o más tokens uso, más valor obtengo. Por otro lado, optimizar mucho procesos de construcción de agentes, porque a más me pongo las pilas para construir un agente,

Menos créditos consumo, más eficiente es menos plata gasto. Y después tener esta historia variable de el negocio está lento, las cosas no se mueven como se deberían mover, el consumo de créditos va a ser más bajo, por lo tanto, el pago va a ser más bajo. Si es más alto, más alto. Francisco, ¿qué tenés como reflexión acerca de todo esto?

Supongo que eso va ser un desafío para Salesforce que tiene el modelo hoy de apenas te enchufo las licencias ya te empiezo a cobrar más allá de cuánto lo uses, cuánto no, sobre todo con el tema de la implementación porque los tiempos de implementación a veces son largos y mientras las licencias se pagan

Y ahora es un modelo como el que decís vos en el que depende del consumo, sea que depende de la implementación, o sea que… Que también es cierto que los clases para implementar una Asian Force por lo que yo estoy viendo son cortos, o sea son proyectos… Por lo menos lo que estoy viendo yo y los que me ha tocado participar son todos proyectos cortitos. Dos semanas, un mes, no son proyectos gigantes, me supongo que porque ya…

Y también esto es verdad, muchas de las cosas que se están haciendo ahora son como pruebitas de concepto o cositas chiquitas que están saliendo. Y me supongo que en el día mañana cuando haya una implementación grande va a traer Agent Force pero como una capita más. Pero en realidad todo el sigue siendo lo mismo. decir, tenés que seguir haciendo todas las 40 integraciones que tenías que hacer, 40 funcionalidades que tenías que hacer y encima de eso tal que ponés un poquito de Agent Force para una funcionalidad en particular.

O sea que para vos falta.

No, me parece curioso eso, cómo va a reaccionar Salesforce en ese sentido. Sí, digamos que en un mundo hermoso estaría bueno que el licenciamiento sea muy bajo durante toda la primera capa de implementación, en donde hay empresas que un año garpando licencia full máquina sin poder usarlo. Adrián, yo te quiero preguntar y ya arrancamos.

es el problema de todos los tiempos, eso. no pasa todos los días. Digo, ahí la forma o la justificación que nos sirve y que tiene sentido, por lo menos a nosotros siempre es la idea de que sabiendo de que vos desde el día 1 vas a tener que pagar las licencias, tienes que buscar proyectos en donde ya puedas empezar a usar la herramienta lo antes posible. Aunque sea para.

para, claro, los famosos MVP’s, pero aunque sea para, si bien por ahí no sé, podés hacer algo muy chiquito que por ahí no te genera un retorno en inversión inmediata y demás, pero si por lo menos te empieza a generar opción dentro de tus equipos. puedes empezar con algo muy chiquito, muy rápido y ya por lo menos mi equipo empieza a conocer Salesforce, por ahí las personas de la empresa que están contratando Salesforce empiezan a saber dónde están.

donde tienen que hacer clic para crear un cliente. Y eso ya es un montón, porque que las personas empiecen a adoptar Salesforce es la mitad del camino para poder ganar y para poder seguir con la herramienta. Sí, te quiero comprometer públicamente, Adrián, para que en el transcurso de próximas semanas, meses, hagamos una masterclass pura y exclusivamente destinada a estrategias de incremento de adopción por parte de usuarios.

y escuchen, escuchen, vamos a arrancar la clase con el chat. Me arranqué la primera clase y ya me están comprometiendo una segunda. Increíble. Así, escuchen, escuchen. Ni te presentamos, peor. No, pero para… Yo soy Francisco Morales. Ahí abajo lo dice. Vamos a hacer la presentación inicial de nuestra masterclass del día de hoy con el video que nos caracteriza y a partir de ahí arrancamos la clase.

Bienvenidos, bienvenidos a otra Master Class de Cell Force. ¿Cómo tenemos todos los jueves? Una reflexión. Francisco, la próxima vez que vayamos a Dream Force, vamos a grabar un montón de clips y vamos a construir un video. Ya está, ya fue ese video. Ese video hay que cambiarlo y tenemos que estar todos nosotros tirando facha. Buen jueves. Francisco, hoy tenemos un invitado especial. ¿Me contás quién es?

Soy yo, pero… con otro nombre. No, es… Vamos. Bienvenido, Doni. Que es arquitecto… Bueno, no sé si es líder, rey supremo de los arquitectos de Nespón. Con quien tuve la suerte o desgracia de trabajar hace mucho tiempo, empezamos… Los dos empezábamos con Salesforce, dimos nuestros primeros pasos. Compañero banco. ¿Cómo?

compañeros de banco. Sí, sí, era una secundaria esa empresa donde trabajábamos y bueno, con el tiempo también para suerte, desgracia, nos hicimos amigos y bueno, y hoy le pedí que nos venga a una mano en esta masterclass porque la tiene muy clara con temas de seguridad y gobernanza y otros montón de temas como ya se vio ahí cuando estábamos charlando. Así que bueno, es un lujo, un honor y un capricho que teníamos de tenerte acá.

muchas gracias, gracias. Ahí me está, perdón, última pregunta con rapida, me está pidiendo a Esti si le podemos dar permiso para participar. Sí, creo que se está metiendo, a ver, para. No sé, pero creo que ese Esteban es él. Ok.

y ahí José me dice que está dos cuadros, así que ahí ya estaríamos. Muy bien, muy bien. Así que bueno, gracias Adri por el tiempo, por participar. Por favor, por favor, gracias por la invitación. Lo tenía pendiente, lo tenía pendiente de hace un tiempo y acá estamos. Qué lindo, qué lindo, va a ser la primera de varias. Bueno, Francisco, queda en tus manos. Muy bien. Bueno, vamos a comenzar. vamos a hablar de seguridad.

y vamos a comenzar, no va a ser muy quizás técnica porque si nos da el tiempo y si vemos que nos amerita vamos a mostrar alguna cosa en Salesforce pero más que nada es contar los conceptos porque es importante la seguridad, darle una vuelta contando experiencias que creo que es lo que más puede sumar y después mover la seguridad de Agent Force que creo que puede ser interesante porque hay como mucho

Incluso de mi lado, que yo ya hice algunas implementaciones de IJS, en verdad es como mucho misterio de cómo funciona eso. Pero quiero mostrar algunas cositas curiosas que fui encontrando. Primero aporte, si quieren. ¿No puedo compartir? sí, sí. No dije nada.

me avisen si ahí se puede ver la pantalla para compartir. El primer aporte que les quiero mostrar es este, vamos empezar por acá. Quise hacer la presentación con el amigo Shemini, la presentación con el que salió, lo que pasa es que si se fijan fue iterando porque como que se ve chiquito, no sé si se llega ver ahí pero que está como petizo. Compacto digamos.

Nunca me daba la opción de descargar esto, no sé si lo cambiaron o qué, o si estoy usando alguna cosa mal. Pero cuestión que nunca lo pude como descargar o hacer pantalla completa. Me dio esta opción de descargar, cuando me dio la opción de descargar hizo algo muy raro que se lo voy a mostrar, que alucinó como imágenes de indio. Acá hay un dibujo de una arquitectura de Salesforce que si se fijan está bien puesto acá y en este no sé por qué hizo.

Un señor que no sé quién será, será Gemini. Acá también puso como un cuadro. Escúchame, Francisco, ¿vos qué plan de Gemini tenés? El pro. ¿El pro? ¿Que eso lo estás usando con Google Workspace? No, lo estoy usando personalmente, lo estoy probando personalmente. Ok. Esta pregunta la hago, no está muy relacionada a la clase, pero la hago porque va a ser un tema cada vez más picante.

¿Cuánto estás pagando por esa cuenta? ¿11 dólares, 12? Sí, es el más bajo de todos. OK, OK. Y asumo que no lo hiciste con Google Workspace para no tener que subir la suscripción de todo. Exactamente. sea, lo estoy probando porque me di cuenta y esto también se los comparto como experiencia, que que a veces uno de manija, por lo menos me pasó a mí, ve una herramienta nueva y se sube y paga la suscripción manual Super Pro.

Y después al mes sale algo que lo deja totalmente… No sé si lo deja totalmente un sonido, pero sale algo mucho mejor y es igual, puta tibia. A mí también me pasa eso porque van haciendo así, ¿no? En un momento estaba chepití, de un vino cloth, chepití, ahora chévina y pega así y vamos a estornudar la semana que viene. Es una carrera, es una carrera, el pórmulo 1, sí, sí, sí, sí, sí, sí, sí. Y de golpe te das cuenta de tener cuatro.

40 mil suscripciones también esa. Tiene 50 mil suscripciones y no me da ninguna película como por las telas. No me da para ver. En un momento ayer estaba yo látigo en mano pero látigo en mano le estaba dando a Claude le lastimé toda la espalda y en un momento me dijo escúchame para ya está o pagás por mensaje o esperás hasta mañana. Lo manté.

Eso va a ser cada vez más frecuente. Eso va a cada vez más frecuente. Como para que vayamos teniendo. Eso va a ser cada vez más frecuente y yo sé que muchas empresas están a perdida. Creo que OpenAI está a perdida. Cuando estemos todos hasta OpenAI debe ser la que más a perdida está, creo yo. sea, van apostando todo a crecimiento en definitiva. Todo. Y cuando estemos.

absolutamente dependientes y ganché no nos queda otra que subir la suscripción de 20 dólares a 80 horas de todo, si no me queda otra y va a ser así. entonces apareció ese muchacho que es como un Pablo Escobar nacido en la India. Exacto, exacto. Y cuestión que nunca pude exportar la presentación, la verdad que estaba linda, tenía el logo y tal. Y ahí llegó mi amigo Adri con este aporte. Sí.

Esta aplicación se llama Gamma que yo no la conocía y literalmente en cinco minutos hicimos la presentación. Creamos la cuenta gratuita y hicimos la presentación que tiene 10, creo que hasta 20 era que me dijiste, 20 slides es gratis. Sí, 10 slides y te genera automáticamente gratis creo. No, es verdad. Y agregue uno. Yo le agregue uno. Y editar, que yo le tengo pánico escénico a editar PPTs y todo eso. Mi sueño es que haya una edición artificial que cree todas las PPTs.

que parece que es esta, pero editar es bastante fácil, sea, agregué un par de imágenes y todo que ahora van a ver y quedó bastante bien. Dime, dígame acceso a la cuenta pro que estamos pagando y la usas, Las recomiendo, las recomiendo fuertemente. Bueno, cuestión, después nos quisimos poner a jugar, agregar a Adri acá con tickets artificiales y ya nos faltaban dos minutos para la clase y yo digo, vamos, vamos, importante.

Entonces, bueno, bienvenidos a otra clase de los jueves. Hoy vamos a ver seguridad.

Primero, cuestión que es más filosófica y más de debate, que es un poco por qué la seguridad es crítica en Salesforce, pero en que en cualquier sistema, esto aplica a cualquier sistema.

Y es que a medida que crece, en realidad, un poco lo que charlábamos con Adri es que no necesariamente porque esté creciendo se da esta situación, pero imagínense un escenario de la vida real en donde vos tenés una empresa con diferentes actores o usuarios y no crees que todos vean todo, no crees que la persona que trabaja en cobranzas pueda acceder, por ejemplo, a los sueldos si están todos dentro del mismo sistema, o no crees que la persona de sueldos…

tenga información sobre lo que cobra un proveedor por una factura, por decir algo. Entonces, siempre va a estar como esta contienda de proteger los datos y que cada uno vea lo que tiene que ver. Y es por eso que es importante la seguridad, diría que más allá de Salesforce, en realidad en cualquier sistema, cualquier lugar que almacene información, vamos a este tema.

Literal es un kilo, ¿no? No veo un cliente que no se marea con esto que está mostrando. también si sale mal, si sale mal, tenés un problemón hasta legal. O sea, acá varía mucho de acuerdo a cada uno de los clientes, qué información manejen en sus instancias y todo eso. Porque digo, no es lo mismo por ahí una empresa que vende pan, por decir cualquier cosa.

que es un banco que tiene información supersensible dentro de sus R &D. Que si un empleado que tiene acceso a Salesforce y le damos permiso a que pueda descargar la información de todas las personas que están dentro del banco y que la publique en internet, en todos los diarios el banco ese. Olvidar. Por eso también, obviamente, creo que…

que es la sensibilidad del tema.

Claro, si, ni hablar, acá está como simplificado super bien, no es solo tecnología, es confianza, cumplimiento normativo, que es que estábamos diciendo y hasta continuidad de negocio, porque si te filtra, bueno, ha pasado, ¿no? Se viene a la cabeza con exchange, que pierden información, exchange de criptomoneda, que pierden información sensible y directamente después de eso quiebran porque ya la gente no confía o lo que sea y se va todo al diablo. Polial. Polial.

Entonces, un poco lo que decíamos, depende del negocio, también depende del tipo de información de ese negocio, porque en Salesforce a veces tenemos procesos separados y no tenemos necesariamente todos los procesos de una empresa, pero tenemos diferentes procesos sistematizados en Salesforce. Y acá lo que pusimos es como este grafiquito, lo que viene a representar es un concepto que ahí me gustaría que me ayude vos, Ari, porque me lo comentaste y me parecía te había contado.

Sí, que es, a ver, para todo esto Salesforce te da herramientas, básicamente, ¿sí? Para poder determinar quién puede o no puede ver un dato, ¿sí? Y la forma en la que originalmente Salesforce pensó en cómo dar acceso a estos datos es de una manera agregativa. ¿Qué significa esto? Significa que vos en vez de pensar, che.

voy a restringirle la visión a ciertos usuarios o cierto usuario que no vea tal dato, en realidad tenés que pensar qué usuarios sí pueden ver ese dato. sea, siempre vivir por el camino de quién sí puede. Entonces, dentro de Cephalos tenés un montón de herramientas. La verdad que en ese sentido a veces es hasta abrumador porque te confunde un poco cómo gestionar esa capa de datos que arrancan desde.

A nivel organización, en donde vos dentro de tu instancia de Salesforce definís, bueno, yo quiero que las cuentas las puedan ver todas las personas de mi instancia o no las pueda ver nadie. Y a partir de ahí, empezás a subir hacia perfiles, empezás a subir hacia roles y jerarquías, hacia reglas manuales para poder compartir datos, hasta llegar hasta el hecho de poder compartir.

un registro, un cliente de forma manual, haciendo clic en un botón del cliente y diciendo, bueno, que este, por una excepción, lo vea tal persona. Entonces, de nuevo, siempre el concepto es pensarlo de manera agregativa, ¿sí? Y que eso vaya sumando capas en donde primero yo trato de ser lo más restrictivo posible con esos registros a nivel por ahí de organización. Cuando voy hacia perfiles.

Sigo tratando de ser lo más restrictivo y por ahí residen en una capa en donde trabajo con PermissionSets o con alguna de las otras herramientas que te da Salesforce para poder dar acceso. Recién ahí empiezo a dar acceso a los registros. Pero siempre tratamos de que la base sea lo más restrictivo posible e ir sumando de a poquito capitas de acceso a los distintos registros con las distintas herramientas que da Salesforce. Perdón, Frank. Quiero decir, la tenemos en el escenario a Juliana que va a tirar alguna pregunta bomba.

para Adrián en algún momento? OK. Qué magnífica. Sí, una súper pregunta para Adrián. Es algo que me está pasando justo ahora en cuanto a todo esto que tú hablabas de entregar, o sea, de la como tener cuidado con ciertos datos que unos son más como delicados que otros. Entonces, por ejemplo, tengo uno de salud.

el sector salud es un tema delicado también. 100 % Y por ejemplo, tenemos un tema de limpieza de datos y no sabemos cómo sí dárselo como un artefacto de club porque sabes es algo de terceros. Entonces, que esas es mi duda, pero pues más adelante. bueno, bueno. Muy bien. Muy bien. Yo quería hacer una analogía sobre esto que estábamos diciendo. Entonces.

como para imaginarnos, luego ves como que vos en vez de arrancar en una sala toda iluminada y te van apagando luces, vos es al revés, vos arrancas en una sala totalmente oscura, no ves nada y vas prendiendo lucecitas de acuerdo a los permisos que vamos dando de visibilidad. Exactamente. Entonces, en esta arquitectura que, ¿cómo es que le decís? No me queda la palabra, no me termina de quedar la palabra. Agregativo, pero eso es un nombre que no sale de ninguna.

en ninguna documentación. No sale en las enciclopedias. No, no, un concepto. Vos arrancas desde los Org By Default, que es como los permisos base que va a tener toda la Org. Sí. Vas definiendo los roles que son… Los roles a mí siempre me resulta fácil pensarlo como… Justamente los roles dentro de una empresa. O sea, quién es el gerente. estructura. Sí, el organígrama de una empresa generalmente. Exacto.

un organigrame y ese organigrame básicamente lo que define es a nivel registro y es en esa jerarquía quién va a ver qué siempre de abajo para arriba o sea de arriba va a ver lo que ve el de abajo y no necesariamente de abajo va a ver de los niveles que están para arriba básicamente eso se empieza a mezclar un poco todo porque ahora vamos a ver que nosotros ahora estamos hablando en un nivel si quieren más horizontal de registro si después vamos a hablar en un nivel más como

perdón, vertical y después vamos a hablar más en un nivel horizontal, a nivel objetos, registros, campo, hay como muchas configuraciones. Eso es algo que está bueno. Como decía Adri, está bueno, es un arma de doble filo porque está muy bueno, vas a configurar todo al detalle, al tiempo en un momento se vuelve un confuso. Después tenemos la Chain Rules que también es básicamente para compartir de acuerdo a otros criterios que sean más específicos, que no necesariamente sean de jerarquía.

Acá podemos pensar, creo que el caso más común con el que lo da Salesforce es el tema de equipos de venta. O sea, tener un equipo regional, suponete en Buenos Aires y tener cuentas que estén en Buenos Aires. ese equipo va a poder ver las cuentas o los clientes que estén geolocalizados en Buenos Aires, por ejemplo. Y es un, de nuevo, esto ya es más horizontal. Vos estás ya, ¿no? Te olvidaste de una generquía.

vertical y estás pasando algo más horizontal. Después el manual sharing, que es lo que decía Adri, que es cuando vos querés compartir un registro específico con alguien específico que ninguna regla del sistema contempló. Acá podemos ver que Adri es un ejecutivo de Córdoba, pero yo que estoy en Buenos Aires quiero que vea una cuenta porque me voy de vacaciones. Me voy de vacaciones. La va a tomar él por algún motivo, porque le cayó mejor al cliente. Entonces se la comparto para que lo pueda ver.

Después el acceso de equipos, que justo en el ejemplo me lo pise con el general rules, es básicamente eso, armar un equipo y compartir una cuenta, por ejemplo, con ese equipo para que lo pueda ver. Y las de territorio, lo mismo, sea, nivel territorio, eso se escucha mucho, por ejemplo, en Philzarris también, toda la parte de jerarquía de territorios. No sé si se les ocurre algún otro ejemplo de algo de esto que pueda ser interesante.

Ahí solo para sumar, siguiendo con el ejemplo, con la analogía que creo que estaba bueno, al fin y al cabo son una serie de habitaciones en las cuales vas prendiendo luces. Lo que sí tienes ahí es que si vos, en la primera habitación prendiste una luz, después ya no la podés apagar más. Y esto nos ha pasado en proyectos en donde por ahí, por ejemplo, les voy a dar un ejemplo que digo.

Había arrancado, habíamos arrancado un proyecto muy grande en donde se trabajaba tanto para el segmento de clientes corporativos como para venderle a personas, ¿sí? Entonces, cuando se arrancó, se arrancó pensando en la parte del B2C, ¿no? De poder venderle a personas físicas. Y en ese momento era, bueno, los clientes de mi empresa, bueno, que todos los usuarios puedan ver todos los clientes. Total.

Si no lo atiende una persona del call center que generalmente no tiene nombre, no es que tienen un ejecutivo asignado o una persona fija asignada. Entonces, que se hizo es, bueno, vamos a poner en el doorway default que los clientes son públicos y que cualquiera los puede ver. Perfecto. Se seteó, funcionó, andaba todo genial. Se desarrolló, hicieron un montón de cosas, pasó el tiempo y en un momento dijeron.

Ahora queremos agregar todo lo que son los clientes corporativos. Pero, ¿qué pasa? Ahora no todos los clientes lo pueden ver todos. Los clientes corporativos solo lo puede ver la persona que atiende a ese cliente. Claro, en este momento, recién ahora se sumaron algunas herramientas para restringir accesos que incluso son bastante limitadas. Después vamos a hablar de eso. ¿Estás hablando de restriction rules? Restriction rules.

En ese momento no existían las restricciones, Ramos, lo dejó hace mucho esto. Hola, Josu Mendoza, que quede constancia en el recording de que soy el primero y el único que te saludó. Muy bienvenido a la Masterclass de hoy. Vale, porque yo lo estoy viendo. y ahí nada, nos encontramos con un problemón porque la posibilidad de poder acceder a todas las cuentas ya estaba seteada.

en el primer nivel de todo, que es a nivel de organización. Entonces, teníamos que cambiar ese y ajustar todo lo demás. O sea, un retrabajo muy grande. por eso digo que si vos prendes una luz al principio del camino, tenés que tener en cuenta que después no la vas a poder apagar. sea, o vas a hacer reto. O va a ser muy doloroso. Entonces, por eso hay que tener mucho cuidado con eso. Y en un escenario como ese, Adrián, ¿qué es lo que hicieron?

o sea, estabas compartiendo todas las cuentas, me imagino. Empezamos a gritar. Empezamos a gritar y… Te pones en posición fetal. ¿Le encontraron algún workaround, alguna solución alterna a la onda esa? No, ahí lo único que te queda es pasar a un… o sea, ajustar como corresponde el Orway Default en donde…

Por default, como lo dice la palabra, debería adaptar todo el privado. Esa es la realidad. O sea, lo que más te conviene, a no ser casos muy extraños, es que siempre el primer nivel de acceso es que esté todo privado. Y después ir ajustando y dando permisos y dando accesos a nivel de perfil, a nivel de Permision CES, a niveles un poco más avanzados en la pirámide, por decirlo. Pero la punta de la pirámide siempre… Siempre privado. Es un buen punto ese. es un punto que hay que tener como muy…

Muy presente. Siempre lo más privado posible y vas abriendo. Nunca mandara público porque… Te van a decir lo que le dijeron a Adri que ya me pasó y es… No, pero esto lo va… No puedo que cualquiera, está todo bien. Tranquilo, no te persigas. Pero al primer cambio… No pasa nada. La gente no va a competir. Ahí este es siempre privado y después si no está la clásica regla de sharing que creas la primera. Si el name no es igual a 1…

lo pueden ver todos y bueno, ya está. Es público para todos, pero en algún momento apagas esas sharing rule y listo. Es un lindo workaround, Josu. Es un lindo workaround. en el Organization Wide Default lo mandás como privado, ya te quedó como privado, tenés el sharing rule, cuando vos querés, como dijiste, lo apagás, lo cambiás y ya fue. Problema resuelto. Sí, me quemé ya alguna vez con ese. Bueno, esta es la regla de colaboración.

Si name no es igual a uno, listo, lo podemos ver todo.

Vos tenés a cuenta que te he llamado una y perdiste. Por eso, claro, justo hoy era la más importante. Pero por eso, esta clase como que la decidimos encarar así, no tanto en lo técnico, mostrar cómo se configuran las cosas, porque me parece que lo más importante en seguridad, o por lo menos lo que a mí me ha resultado más, es entender estos conceptos. O entender qué permisos o en qué casos deberías usar cada una de estas herramientas. Y después de configurarla, la verdad es que no es ninguna ciencia. Son reglas que se…

configuran por lo general declarativamente y que se hacen una vez en 10 minutos y ya está, no tiene gran ciencia, lo que sí puede ser difícil es esto, es entender los conceptos para que después lo tenéis que aplicar principalmente o por lo general en el inicio de un proyecto. sí. Y que tenéis que tener una visión holística, ahora se usa así holística. Olistica y sinérgica. holística. Tenéis que tener en cuenta…

como el mapa de seguridad entero. sea, si vos querés trabajarlo como herramientas separadas, ahí es donde empiezan los problemas. Porque después de golpe alguien ve algo y no tenés ni idea de por qué lo ve y te querés matar y empieza la búsqueda de en dónde le dando acceso, por qué está dando acceso, por qué justo tiene estar relacionado a este cliente que no sé qué que tiene. Porque después también hay un tema de…

de permisos indirectos también que tiene Salesforce, que también es un problema una vez. Perdón el bocado, pero sobre eso no sé si lo mencionaron o no iban a mencionar que no hace tanto tiempo atrás, por lo menos yo descubrí que hay una forma de ver por qué cada usuario está teniendo acceso Lo vamos a mostrar. Es una partecita que vamos a mostrar ahora. Espoilando, disculpen. Pero eso resuelve muchísimo la verdad, porque…

Otra cosa, cada vez que hay un tema con la seguridad, son temas heavys, por lo general. sea, nunca te viene una queja o un pedido de un cliente con un tema de seguridad y es como decirte agregado un campo. Por lo general es alguien vio algo que no tenía que ver y está todo mal. sea, no suelen ser cosas liviales, digamos. Por eso es importante definirlo bien. Después habíamos agregado este slide que es básicamente…

como que el desafío acá crecer sin perder el control es justamente eso, a medida que vas agregando usuario, que vas agregando funcionalidad, que vas agregando integraciones, que vas agregando equipos dentro de una empresa, lo que estábamos hablando recién, va volviendo cada vez más complejo eso. Y a veces tener en cuenta todo eso, o mejor dicho, tener en cuenta todo lo que eso puede llegar a crecer, es muy difícil por no decir imposible. Entonces, por eso, tanto en Gambien esto de…

por la duda poner todo privado y andar dando de apuchitos, es preferible eso que arrancar ya dando mucho más permiso al que necesitas.

Bueno, cosas que vamos a hoy, poco de esto lo que estábamos viendo ya los fundamentos de la seguridad. Una cosa que para ahí nos dijimos, quizás porque lo tenemos como muy incorporado, que Salesforce le da mucho, como decimos en Argentina, bola, mucha atención, mucha presión al tema de seguridad en todo aspecto. Y creo que desde siempre, no sé a ti vos, Juanma, que estás desde que se fundó Salesforce, desde que nació Beño, pero yo desde que tengo memoria, Salesforce siempre está metiéndole…

tema seguridad y le da muchísima atención, supongo que por el tipo de cliente que tiene y también porque cada cosa que ellos hacen te sacan el último estándar de seguridad y siempre tienen lo último y lo más adaptado y lo que cumple con todas las normas, que eso también es como una tranquilidad, porque a veces los clientes grandes y eso te exigen ciertas cosas que vos sabiendo que vas con Safeforge podés demostrar.

lo mismo, no temas regulatorios y demás. Un poco de lo que estábamos charlando también recién, de ver un poco cuáles son las herramientas nativas, que casi todo es nativo, no sé si alguna vez le ha tocado hacer a ustedes chicos algo a medida por tema seguridad. La verdad que… la posibilidad de dar permiso por Apex, pero es un mundo que gracias a Dios no me tocó meterme jamás, porque cuando te metes en eso ya estás confundido. Yo lo pasé.

Esto es complicado. Por lo general si tuviste que llegar a dar un permiso por Apex, es porque algo ya era… A ver, Josu. Estoy tratando de acordar exactamente, pero tenía que ver con cuestiones de territorios. Justo te iba decir eso. En PhilService es muy… En PhilService podríamos decir que es la excepción, porque hay muchas reglas que no aplican y que un trabajo que empezó en un lugar puede terminar en otro, entonces eso hay que moverlo y ahí puede ser que…

Era un proyecto, creo que para una empresa de Brasil que dedicaba el agro, que tenía muchas reglas entre territorios. Estoy tratando de recordarme si yo fui parte de la construcción de todo ese monstruo que era básicamente cuando se creaba un territorio o cuando creabas una cuenta, para hacer un territorio, tenías un Apex gigante que borraba todos los objetos de ayer y volvió a calcular todo y era listo, ya está de nuevo todo tu…

tu visibilidad de registro recalculada. Claro, eso también es importante comentarlo. cuando nosotros le damos un perfil o un Allá en rubles y demás, Selfo por detrás hace una magia en donde genera registros de asignación de permisos. O sea, como un registrito en donde dice, bueno, este usuario puede ver todos estos registros. Que son invisibles, ¿no? O sea, no lo vemos. Pero por detrás existe todo eso.

Y bueno, y justamente lo que podés hacer por Apex es como crear esas relaciones. Los famosos videos de Back of Yer son esos. Claro. Tal cual. Sí, sí, sí. Muy bien. Entonces la magia pasa por ahí, más obviamente. Bien. El próximo tema, vamos ya directamente a las cuestiones, ¿no? A las cuestiones poquito más técnicas.

Primero que vamos a configurar muy posiblemente sean perfiles. Además de los software defaults, de la chain rule, que eso es más como fundacional de la org, cuando ya entramos a los usuarios en concreto, lo primero que vamos a tener es el perfil. Que acá también, esto cambió un poquito, porque nosotros teníamos perfiles y permissionsets, y en la época de antaño, el perfil era como la buena práctica y era lo estándar y por donde se arrancaba a configurar permisos.

Y hoy como que la recomendación de Salesforce es el perfil lo más, también otro modismo argentino, lo más choto, lo más precario posible, lo más restringido posible y todo lo vas dando y amplificando a partir de Permission Set y sobre todo Permission Set Groups. Es lo que viene a ser como una especie de perfil medio encubierto, Permission Set Groups, por lo menos así lo entiendo yo. En el perfil…

Justo yo leí una documentación que decía que tú de ahora en adelante tenías que agregarle el minimum access. Hay un perfil que Portifold se llama así, como que le agregas ese y ya de ahí en adelante los permissions. Es loco eso porque como que medio que despreciaron el perfil haciendo eso. Como que están diciendo bueno ya el perfil no lo usamos más y vamos todo con permissions de group que para mí no deja de ser

Lo están por llevar a morir. De hecho, de las pocas cosas que quedan en el perfil es como la aplicación que tenés por default para utilizar, o sea, qué line-up podés utilizar. Algún permiso básico sobre algunos campos de los objetos y después ya no se puede ir a permiso hacer. La licencia. La licencia. La licencia. Un punto. Un punto. Acordate, vos tenés licencia, 8.000 millones de licencias. Pero vos tenés como core.

la licencia Salesforce y la licencia Salesforce Platform. Sí, tenés toda la razón. Sí, pero eso cuando vos creas el Permission Set tampoco no te sale ahora la licencia también ahí. Si lo querés lo podés elegir. Lo que tiene el perfil a diferencia del… O sea, primero el perfil lo están tratando de precar, pero sigue siendo obligatorio. O todos los usuarios tienen que tener un perfil asignado. Entonces…

Ahí es, por ahí es un poco contradictorio dentro de Salesforce. Yo imagino que porque ya debe estar toda la estructura montada sobre esa estrategia y debe ser difícil deshacerlo. Lo que pasa con el perfil es que el perfil cubre todo. O sea, cubre desde permisos de objetos y campos hasta permiso de sistema, hasta permiso de apps, hasta todo lo que quieras. Entonces.

Cuando Salesforce empezó a ir por una estrategia de empiezo a migrar cosas chiquitas, ¿sí? O sea, no sé, construyo, me hago un sandbox, construyo una historia de usuario así chiquitita y despliego esa historia de usuario y sigo con el flujo. Lo que pasa es que casi siempre está involucrado el perfil y el perfil te lleva cuando vos querés pasar de un ambiente de desarrollo, un ambiente productivo, por decirlo de una forma, o a otro ambiente, a un ambiente medio.

el perfil te lleva por dependencia, te lleva todo. Porque vos quisiste crear un campo, pero por ahí habías creado otro de prueba que no lo querés migrar y de golpe el perfil te dice, pero existe ese campo de prueba, también lo tenés que migrar. Y entonces te empezás con unos problemas. Acá creo que no se salva nadie. De esas historias no se salva absolutamente nadie. sea, el perfil tiene mucha dependencia. En el PermissionSet no, porque vos podés crear un PermissionSet para darle el permiso a un campo nada más. Immigrás eso y listo.

Y no necesitas poner ni permiso de sistema, ni permiso de app ni de nada. Pero yo te desafío ahí. No termina haciendo eso mucho más difícil de mantener. Porque si vos haces por cada funcionalidad un PermissionSet, después tenés que acordarte todos los PermissionSet y los PermissionSets de que le tenés que pasar a algún usuario para que haga lo mismo que hace otro usuario. Yo trato de que los PermissionSets sean anatómicos. Exactamente. Editar oportunidad, leer oportunidad. Sí, bueno, esa sería la buena práctica, Josu.

El tema de agrupar los Permission Sets. Después lo has llevado a 2 Permission Sets Groups. De todas maneras, yo continúo con mi obsesión de que en algún momento vamos a necesitar que alguna IA se conecte a toda la metadata de una Salesforce org y que vos le digas, escúchame, este flaco, José Gómez, ¿qué ve, qué no ve, qué tiene, qué no tiene? ¿No?

De hecho lo vimos en Dreamforce, no sé si lo llegamos a contar en alguna de estas clases, acordás? Deberíamos volver a hablar de Gear Set. Bueno, Gear Set lo había mostrado, pero también en mismo Cellforce, mostraron una confiden… O sea, te ibas a la setup, como siempre, y tenías como una gente para decir, che, ¿de dónde se utiliza tal campo? O, ¿qué perfiles tienen acceso a este objeto? Y desde el mismo Cellforce, No recuerdo el nombre de la tool.

Pero lo estaban mostrando, que era como para eso. Prontealo y que él te responda quién o qué tiene acceso.

y canto. en la gente de la editorial. Sí. Está bueno. Bien, bueno, entonces, haciendo esa discriminación entre lo que es perfil que está quedando de precado y PermissionSite que es como… iba a decirlo nuevo, pero realidad no es nuevo, pero esa es que tenemos que apuntar como buena práctica. Después agregamos esto que es tema de un poco lo que veíamos la otra vez con Name Credential que es para todo lo que tiene que ver con integraciones.

Acá lo mismo Salesforce te da como mucha versatilidad para que vos, cuando desarrollas una integración, puedas definir distintos niveles de acuerdo a lo que el otro sistema te exige como seguridad, porque vos podés decir, un gerente puede, vamos imponer, ¿no? Estoy imaginando, pero tenés un error webcomponent que trae información de otro sistema y te la muestra en vivo. Un gerente puede tener un nivel de acceso en ese otro sistema desde el que Salesforce está trayendo información que no tiene una persona que es supervisada, por ejemplo.

Entonces la forma de tener como esos niveles mapeados podría ser con NameCreation distintos en ese otro sistema. Y acá también un poco juega a esto que decíamos recién, que Salesforce para todo lo que es integraciones y seguridad está como siempre en el tope, siempre está muy bien ranqueado y le da mucha atención a este tema. Este lo vamos a pasar más bien rápido, porque quiero venir a Restriction Rules que es lo que…

nuestro amigo Adri, le vamos a poder sacar jugo. Contanos, ¿qué son las Restriction Rules? ¿Qué son diferentes? Después de mucho tiempo, en donde, les digo yo y la palabrita que me entede, que es un modelo agregativo en donde vas prendiendo y después una vez que prendiste algo no lo podés apagar, aparecieron las Restriction Rules. Que ahora no aparecía hace un par de años, no mucho. No me acuerdo exacto, pero si fue hace dos años, creo que es mucho.

Que básicamente lo que inventaron fueron reglas para restringir visibilidad. O sea, se venía pidiendo hace mucho. Y ahora tenés la posibilidad de que si le diste permisos a alguien para poder ver algo y de golpe te diste cuenta de que hay una casuística especial en donde no tiene que poder verlo, poder crear una restriction rules y decir, bueno, que este usuario no vea los clientes que son de tipo gobierno.

sea, también, de nuevo, son herramientas muy simples. Vos elegís algún capítulo y decís si es igual a algo o si es distinto de algo, que no lo vea tal usuario. No tiene mucha más gracia que eso. Lo que tienen las restriction rules es que están buenas en el sentido de que, o sea, si vos haces bien tu arquitectura de permisos, no deberías de tener que usar nunca una restriction rules.

Salesforce un poco que medio que te incentiva no las uses. Como el mundo no es perfecto. No, pero pará, porque ahí en defensa de los que alguna vez podemos usar esto, a veces pasa que realmente la arquitectura cambia porque vos tenías antes solo un departamento de ventas y de repente se suma un departamento de marketing y de repente se un departamento de compras. Entonces lo que ya era una cuenta para uno cambia.

Y los permisos cambian. sea, eso pasa. Más allá de que después vos podés haber hecho macanas al principio, una empresa que empiece a sumar departamento es lo más normal del mundo. Una empresa que cambie de parecer. También. También. Si no, no es una empresa. Pero bueno, nada. Se sumaron estas nuevas funcionalidades. Están muy buenas. El tema es que tienen algunas restricciones. Las restriction rules tienen restricciones.

¿Cuáles son las restricciones? No se pueden usar en objetos estándar prácticamente, lo cual es doloroso, porque si vos lo querés usar generalmente en las cuentas, en los contactos, en las oportunidades, no lo podés hacer. Solo admiten algunos poquitos objetos estándar que creo que son tareas, eventos, algunos temas de contratos, si no me acuerdo, y algo más, pero son, deben ser tres o cuatro como mucho.

Y se pueden usar prácticamente o casi que se crearon prácticamente para objetos custom. Que a su vez, el control de los permisos sobre objetos custom son casi que los más fáciles, porque lo que tenés con los objetos estándar como cuentas, contactos y oportunidades, está este concepto también que existe dentro de Salesforce que es la seguridad implícita que es que si vos tenés acceso a una cuenta, vas a tener acceso a los contactos que estén relacionados.

O si vos tenés acceso a cierta, no sé, también a un cliente, vas a tener acceso a las oportunidades que tienen esos clientes. O sea, seguridad es que vos no le das permiso literalmente a ese objeto a esa persona, por ahí le das a otro. Pero como ese otro tiene una relación dependiente, se genera una seguridad implícita, le llaman. Pero, no dejan de ser una herramienta muy poderosa, porque la realidad es que a más de uno.

incluyéndome, nos ha salvado más de una ocasión. Pero bueno, ahí está, ahí en un dibujito que explica un poco. Antes de las restriction rules, de nuevo, este concepto de va subiendo la escalerita y tenés distintos niveles para poder restringir o habilitar un registro, ¿sí? Empezando desde el Orbit Default hasta el último paso que es darle a alguien algo manual.

Después de que se crearan las restriction rules, mediante restriction rule, podés ocultar algunos objetos en todos los niveles. Registros. Registros, perdón, en todos los niveles. Adri, estoy recibiendo mi WhatsApp privado una consulta de Jonathan Caprile desde Wyoming preguntando si las restriction rules tienen algún tipo de impacto en la performance.

de cómo cargan vistas de listas, informes y búsquedas y cuál es la cantidad máxima de restriction rules que se pueden tener por objeto. Bien, la cantidad máxima de restriction rule por objeto son dos. Así que piénsela bien porque no tiene oportunidad de esto. Qué poquito que me dimos. Así que piénsela bien. después, sí, no solo la restriction rule tiene impacto en todo lo que es performance. sea, esto que hablábamos nosotros de

que por detrás Salesforce lo que hace es generar registros en donde enlaza a un usuario con los registros a los cuales puede acceder. Lo que termina haciendo es que empiecen a producirse límites después si vos tenés un modelo de seguridad muy complejo que tiene Sharing Rule, que tiene Restriction Rule, que tiene permisos heredados por todos lados, que tiene Manual Sharing. Después lo que te puede empezar a pasar es que te empezás a encontrar con errores de bloqueo.

generalmente creo que son, si no me equivoco. No me acuerdo bien el término en inglés, pero en español es lo que hago. Que vos por ahí querés actualizar un registro y te dice, no, no se puede actualizar un contacto porque está pensando a quién le tiene que dar permiso ahora que le cambiaste este atributo. ¿Por qué? Porque si vos tenés un contacto que está relacionado con 10,000 usuarios y vos decís, bueno.

Estos usuarios lo pueden ver si el atributo es igual a tanto. Estos otros sí, la combinación de estos cinco atributos es igual a tal otro. Cuando vos cambias algo de eso, Salesforce tiene que empezar a a borrar todos esos registros y volver a crear registros de acuerdo a las sharing rules, restriction rules, etcétera. Y ahí se puede producir un mecatón. Pero por eso hay que tener cuidado cuando se arman todos estos modelos de seguridad.

Y tratar de usar las herramientas más básicas que tiene seguridad, por lo menos mi recomendación es, tratemos de cubrir todo con lo más básico que son PermissionSet, OrwareDefault y no mucho más. Siempre, obviamente, después aparecen las casuísticas y los requerimientos y demás que vamos a necesitar más cosas. Pero hay que tener cuidado con cómo armamos ese modelo para que no se nos empiece a bloquear toda la org. Así

¿Podemos mostrar rapidito cómo ver en un registro que hablábamos con el Cosu al principio? ¿Cómo en un registro quién y por qué tiene permisos? Que me parece que es algo que puede estar interesante. Eso está bueno, porque te salva. Muchas veces te salva. A voy a tratar de compartir pantalla. A mí me salvó un proyecto entero, eso te digo. Y me queda la duda porque yo lo encontré metiendo mano en Classic. Pero creo que ya está en Lightning. Eso.

porque hoy cuando me lo mostró dije lo mismo, dije eso no es lo que estaba en Classic y ahora está en… bueno ahora, yo digo ahora pero capaz que estaba de antes y no lo había visto

A ver… Y después antes de terminar tenemos la pregunta de Juliana que está esperando para Pregunta bomba. Sí.

¿Ahí se ve? Sí, señor. Muy bien. Bueno, esto es sencillito. Como ahí decía Josu, esto antes estaba solo en Classic. ¿Para qué sistema es esto? Esto se llama Salesforce. Esto se llama Dynamics. Antes vos solo en Classic podías acceder a esta funcionalidad que básicamente lo que hace, y ahora se los voy a mostrar, es, te dice, ¿quién puede ver este registro?

Entonces, vos estás parado sobre un cliente, ¿sí? El famoso Acme que todos conocemos. Y vos decís, bueno, ¿y quién tiene acceso a esta cuenta? Antes, para poder acceder a eso, tenías que pasarte a Classic, ir hacia el layout del Classic del cliente y había un botoncito que te permitía ver ese acceso. Hoy, por suerte, ya sumaron ese botoncito onlining. Medio oculto, igual, porque tenés que agregarlo vos al layout, no es que te viene por default.

Pero es este botoncito que ven acá que se llama Sharing Hierarchy. Que si ustedes hacen clic en ese botón, lo que van a ver son una lista de usuarios y de todos los usuarios que tienen acceso a este registro. ¿Qué tipo de acceso tienen? Full access, full access, full access. Y si ustedes le dan acá a ver más información sobre el acceso de este usuario, te va a decir por qué lo puede ver.

Y acá te va a decir, bueno, lo puede ver porque es administrador, básicamente. Esto está muy bueno también para todo eso que mencionaba yo de los permisos indirectos. Sí, los permisos indirectos que te da Salesforce cuando por ahí vos podés ver a este cliente porque justo sos dueño de un contacto que tiene una relación más ternita con este cliente. te iba a decir, pero si yo no…

No le estoy dando esta persona en el perfil permiso para ver clientes. ¿Por qué lo puede ver? Bueno, si te metes acá y pasa algo de ese estilo, acá te va a explicar justamente por qué es que lo ve. Y esto te salva. Muchas veces te salva. Es como el debugging de permisos, por decirlo de una forma. FSHENG 游 游 游

y bueno, era una obra con sharing rules, reglas de colaboración con jerarquía, y era, ¿por qué Fran ve esto? Y llegábamos a esta pantalla, aparecía Fran como una de las personas que podía ver la cuenta, y era porque Fran era owner de una cita de servicio relacionada a una work order, relacionada a la cuenta que estaba podiendo ver Francisco. Y bueno, con eso resolves como esa… No sé si dudas o por esas cosas medio locas, y decís, ¿por qué Corn no lo está viendo?

bueno, usas esto y te allana quizá dos o tres días quizá de estar analizando por qué corno, framería, esa cuenta. Sí, porque hay un tema que no hablamos que es todo el tema de grupos públicos, territorios, PhilServe, bueno, y me supongo que otros módulos tendrán también su propia lógica de permisos que va por encima, o sea que usa las herramientas estas, pero medio que hace lo que hace una cosa diferente. sea, las usas las conviene. respuesta, y por oportunidad. Sí, sí.

Para CES también creo que hay territorios de ventas y ese tipo de cosas. Exacto. territorios hay que se comparte por varias nubellitas. Bueno, antes de pasar a la súper pregunta de Juliana, ¿Juan, ma, hay algún anuncio para hacer? ¿Algún grupo de WhatsApp que queramos promocionar? ¿Algún código loco que queramos pasar? Sí, absolutamente sí. Quiero aclarar que, como sabía que iba a venir el grosso, el berraco capo de Adrián,

Esta clase tenemos duración extendida en caso de que queramos extender. Tenemos un grupo de WhatsApp que ahora, José Mendoza, va a pasar el link en la caja de chat en donde quiero que te sumes a ese grupo de WhatsApp por dos cosas. Primero, Meta le da un límite a los grupos de WhatsApp y todavía no estamos.

llegando al límite. Estamos cercanos a la mitad del límite. Una vez que llegamos al límite no vas a poder ingresar. Y número dos es porque ahí estamos en contacto toda la semana. Inclusive hacemos preguntas y respuestas. Eso por un lado. Por otro lado, quiero contar que estamos sorteando certificaciones de Salesforce. Hay dos precios de certificaciones. Hay certificaciones de 200 dólares y hay certificaciones de 400 dólares.

Vamos a certificar, sortear ambas y en un rato en la caja de chat solamente para las personas que estén aquí en vivo en esta masterclass van a poder obtener un código que les va a dar acceso a ese sorteo. Y los que estén viendo esto en LinkedIn o en YouTube, tienen que estar en vivo. Ahí pasó, Josu, pasó el link al grupo de WhatsApp. No es el código.

y vos cuantos certificaciones tenes hablando de certificar el sorteo? 9 certificaciones. 9 certificaciones. Como a… mira. Ahí tenes. Bueno, entonces ahora vas a poder responder la pregunta de Juliana sin ningún problema. No sé si me certificen eso. Cuando vos quieras, Juliana.

Sí, chicos. Pues ahora que pasó toda la charla, si tengo como otra pregunta, ¿cómo hacen ustedes para tener como una plantilla o algo para definir el tema de los permisos? O sea, ¿qué tienen en cuenta? Antes, yo me acuerdo que yo hice una plantilla como con perfiles y les ponía como los perfiles que más o menos íbamos a crear y si podían leer, escribir, eliminar y demás. Pero ¿cómo le hacen ustedes como para organizar esa plantilla para los clientes?

Si quieren, respondo yo y después los dejo también que den su lado uno porque acá no sé si hay una receta, es más… tenemos un librito y creo que todos empezamos con ese Excel de las filas. Todos empezamos con ese Excel, en mi caso también, yo creo que lo que más me sirvió ahí y por ahí es más conceptual que una fórmula que es, al principio yo lo macheaba o lo pensaba también como perfiles, O sea, digo, me anoto cinco perfiles…

Y empiezo, como decías vos, empezamos a decir, bueno, qué objeto, una matriz de objeto, perfil, quién tiene acceso y demás. Ahí lo que mí me sirve es no pensar la solución cuando estoy anotando eso. O sea, no querer solucionarlo en ese momento, sino entender qué perfiles, pero no de Salesforce, sino qué perfiles de personas en el proyecto tienen que tener acceso a qué. Y una vez que tengo eso, si quieres también, en un Excel, documentado como sea,

buscarle la vuelta para ver si eso lo resolvemos o con una restriction rule o con un permission set o con cualquiera de todas las herramientas que nombramos hoy. Entonces, por ahí, ahí, la solución es, no sé, estamos hablando de comerciales, supervisores y directores de una empresa, lo anotamos así, que seguramente es como el cliente nos lo va a poder transmitir, anotamos esa matriz de restricciones y después decimos, bueno, por ahí hacemos un único perfil. Deciden ciertas cosas.

Por ahí, además de hacer un único perfil, sé, hacemos dos permission sets y cosas así. Pero eso lo que a mí me funciona, que más que una plantilla es una forma de pensarlo. No sé, ahí los chicos en Hotsu o Fran, si usted tiene alguna otra estrategia. Me pasa un poco lo mismo. sea, como que al principio también lo pensaba así en un Excel y pensaba como tratar de resolver los perfiles. Y ahora lo pienso muchísimo más en funcionalidad. O esta funcionalidad.

¿Quién va poder acceder? Bueno, Adri. ¿Cuál es el rol de Adri en la empresa? Y en base a eso, ahí voy para atrás. O sea, ahí voy y veo qué objetos, qué registros, qué el ánimo de componen, qué flow, etcétera, le debería dar acceso a Adri. Me pasa cada vez más eso. Sí, sí, sí. No este tema de sharing rules, permisos y demás. En determinadas organizaciones es un trabajo de tiempo completo. Suelen poner a un humano.

que lo único que hace es administrar toda esta historia, es un delirio. Sí, sí, sí. Yo he estado en proyectos muy grandes que habían arquitectos que se dedicaban a eso nada más. Así que sí, sí, sí, Bien, bien. Bueno, escuchen. En EGAFutura.com barra Salesforce, en el botón de arriba, si le haces clic, vas a ver todas las próximas clases en donde con Josu, con Bebé Corazón y con Francisco.

Nos requetar recontra, pusimos las pilas y armamos un calendario que va varios meses en el futuro. Ahí vas a ver cuáles son todas las próximas clases y poder registrarte en cada una de ellas, recordando que todos los jueves en el mismo horario tenemos clases de Self Force. Un jueves, Master Class de Self Force, tocando particularmente algún tema profundo e interesante y

al jueves siguiente, inglés para celpos. En la masterclass de hoy, yo estoy muy agradecido con Adrián. un placer, un honor inmenso tenerte acá y convocándote, como dije al principio, públicamente para que estés presente de nuevo. Y a nuestra invitada estrella sorpresa, Juliana, muchas gracias por atacar con preguntas. Y siempre que te veamos conectada.

vamos a apelar a tu intelecto para que puedas con tu látigo mental preguntarle algo a alguno de los chicos. Bien, escuchen, ¿algo para decir? Gracias a todos. Muchas gracias. Gracias por invitarme. La próxima me tienen que enseñar a cambiarme el nombre de acá abajo y a tirar fuegos artificiales, globos, toda la magia que está tirando Frank que no sé qué botones tanto. Hay cosas, te queda mejor ese nombre y dos, eso con la Mac, boludo.

3, si no me equivoco fue la última masterclass del año, el jueves que viene Singles para Cellforce y después tenemos Navidad y el nuevo. Así que gracias por acompañarnos este año, un abrazo. Una locura, es una locura, insisto, ahora no vamos ir con música, no me están sugiriendo, pero dos cosas, primero el vídeo de arranque lo vamos a tener que hacer

todo nuevo con clips. Incluso, Fran, ¿vos te acordás cuando estábamos ahí en Mil Bali y agarramos el coso ese para grabar el titulo que vos dijiste tiene un montón de funcionalidad para grabar videos? No grabamos ninguno. Lo vamos a hacer en nuestro próximo Self Force. Y creo que necesitamos hacer una canción propia con inteligencia artificial. He escuchado canciones con inteligencia artificial que son una locura. Eso hay que hacer. Eso es lo que Esa es la que va. Nos vamos.

con música. Los queremos un montón y nos vemos en la próxima clase. Chao.